4 Ways to Protect CUCM Meetme Conferences with PIN

One of the useful features Cisco Unified Communications Manager provides is Meet Me conference. Admin defines the phone number for each conference room, and users need to dial the conference number to join the meeting. The common problem is that Meet Me conferences are not secure enough, anyone who knows the conference number can dial it and join.

This article describes the ways to add the PIN authentication to the CUCM Meet Me feature, which forces users to enter PIN before joining the meeting.

1. TCL script for CUCM Express (CME)

If you use Cisco UCM Express (CallManager Express), you can deploy the TCL IVR script that plays a voice prompt, waits for the user to enter PIN and checks if it matches the one configured in application or not before routing the call further. The TCL script and its discussion can be found here - https://communities.cisco.com/message/151723

2. Cisco Unity Express/Connection

You can also use Cisco Unity to provide your employees with password protected Meet Me conferences. In the following  article you can learn, how to setup the Meet Me authentication with the help of Cisco Unity Connection (CUC) - http://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/118722-configure-cucm-00.html

3. Cisco Unified Contact Center Express (UCCX)

If you have UCCX deployed, you can use it as an audio front end to meet me conferences. There are several UCCX scripts around the web which prompt the user for Meeting ID and password and if the entered PIN is correct, transfer the call to the MeetMe bridge. Meeting IDs and passwords are managed by the UCCX admin.

The common issue with these approaches is that you use Unity or UCCX for something that they’re not initially designed for. Thus when using these “workarounds” you still face  with some restrictions and lack of user features. So, the fourth way is to turn to the app from the authorized Cisco Solution Partner.

4. Commercial app

For a quite affordable price you can get the solution on top of the Cisco Meet Me conferencing feature that allows you to:

• schedule Meet Me conferences from a web-calendar;
• use the MS Outlook plugin to schedule the meetings from the Outlook calendar;
• use only one phone number for all meet me conferences, when user calls are routed to  appropriate  meetings in accordance with the entered PIN;
• protect meetings either by PIN or by Caller ID;
• control the conference with the web-interface – the meeting organizer can see the list of  participants and disconnect anyone when needed;
• start the meeting from any phone - without the necessity to use a Cisco IP phone to initiate the meetme bridge;
• control the resources of the conference bridge.

One of the top 3rd party apps which can be used for MeetMe Security is Aurus PhoneUP. Aurus PhoneUP is the bundle of apps that works in Cisco UC & Collaboration environment. The PhoneUP solution counts more than 10 modules and includes the full-featured solution for Cisco Meet Me PIN authentication and scheduling.

Don't think about paying for 3rd party products. Think smarter about how much will you save if you use 3rd party product to protect MeetMe free solution versus the charges for global meeting solutions.

RSVP Basics

In IP Telephony World, RSVP is a CAC mechanism that can reserve bandwidth for the length of the call. If any router along the path cannot reserve the requested bandwidth, the originating gateway, CUBE, or CallManager can reroute the call, send it with different marking, or drop it.

One drawback to RSVP is that the reservation process causes some delay in call setup. To minimize this, include RSVP control messages LLQ.

RSVP Signaling

Its Network control protocol (protocol number 0x2e and operates at L3) that allows internet applications to reserve QoS resources for their traffic. Note that RSVP will do the signaling for reservation but the actual reservation should be done by queuing mechanisms.

RSVP messages 

1. Path Message

It’s sent by the sender through the path provided by routing protocol towards the receiver. It will store flow info in each node and enables each node to realize the previous and next hop of the session. Those messages are sent periodically. They are used to form RSVP neighbor ship.

2. Reservation Message

Those are sent from receiver to sender and should follow the exact path of Path Message (it will use Path messages to obtain reservation message path). It’s used to maintain reservation state in each router. It is sent periodically.

3. Confirmation and Error Messages

Those are classified as path-error, reservation-error, and reservation-acknowledge messages. Path error messages are generated from path messages and in direction towards sender. At each hop the destination address is the previous hop. Reservation error messages are generated by reservation request and sent towards the receiver. Information carried in error messages can be:

1. Admission failure
2. Bandwidth not available
3. Service not supported

Reservation acknowledgments are generated by sender to confirm the receipt of reservation request.

4. Teardown Message
Those are used to remove RSVP state from each node without waiting for timeout. It can be initiated by host to tear down reservation or router in case reservation timed out. It has two types depending on the initiator (sender/receiver): Path teardown and reservation-request teardown.

RSVP operation

A typical RSVP session involves the following sequence of events:

1. A potential sender starts sending RSVP Path messages to the session address (destination address).
2. The receiver receives the Path messages.
3. The receiver sends appropriate Resv messages toward the sender through the same path of Path messages. These messages will carry FlowSpec, which is used by routers along the path to make reservations in their link-layer media.
4. The sender receives the Resv message, and then it starts sending application data.

Once those steps are completed successfully, RSVP demon will set arguments in packet classifier (to identify RSVP flows) and packet scheduler (on routers) for the desired flow to be processed using the underlying queuing mechanism.

Note that this sequence of events is not necessarily strictly synchronized. For example, application data can flow before the sender receives Resv messages. Application data that is delivered before the actual reservation contained in the Resv message is typically treated as best effort, nonreal-time traffic with no QoS guarantee.

RSVP reservation Style

Before proceeding with reservation style, four terms should be defined:

1. Distinct reservation: Each receiver establishes its own reservation with each upstream sender.
2. Shared reservation: All receivers make a single reservation that is shared among many senders.
3. Explicit sender: List all selected senders.
4. Wildcard sender: Select all senders, which then participate in the session.

Reservation style is used by the receiver to define how reservations are accomplished with multiple senders. From the above options, below reservation styles were defined:

1. Fixed filter (FF): This reservation style consists of distinct reservations among explicit senders. Examples of applications that use fixed-filter style reservations are video applications and unicast applications, which both require flows that have a separate reservation for each sender.
2. Wildcard filter (WF): This reservation style consists of shared reservations among wildcard senders. This type of reservation reserves bandwidth for any and all senders, and propagates upstream toward all senders, automatically extending to new senders as they appear. A sample application for wildcard filter reservations is an audio application in which each sender transmits a distinct data stream. Typically, only a few senders are transmitting at any one time. Such a flow does not require a separate reservation for each sender; a single reservation is sufficient.
3. Shared explicit (SE): This reservation style consists of shared reservations among explicit senders. This type of reservation reserves bandwidth for a limited group of senders. A sample application is an audio application similar to that described for wildcard filter reservations.

RSVP Basic Configuration

RTR(config-if)# ip rsvp bandwidth !! Enable RSVP on interface. Without this RSVP messages can’t be received/send. Also, once reservation installed, BW will be subtracted from max-reserved-bandwidth.

RTR(config)# ip rsvp sender session-ip-address source-ip-address protocol des-port-num src-port-num previous-hop-address previous-hop-interface bandwidth burst-size !! Install RSVP sender statically in DB. ip rsvp sender-host command can be used to simulate sender (use proxy feature). Same can be done for receiver.

RTR(config)# ip rsvp neighbor access-list !! To restrict RSVP neighbors

RTR(config)# ip rsvp udp-multicasts des-address !! Instruct the router to send UDP multicasts whenever it generates IP multicasts. This is required sometimes for trigger other hosts.

RTR(config-if)# ip rsvp precedence conform value exceed value !! Set IPP

RTR(config-if)# ip rsvp tos conform value exceed value !! Set ToS

RTR(config-if)# ip rsvp signaling DSCP value !! Set DSCP value for RSVP messages to prioritize them

SENDER-1#sh ip rsvp interface detail fa0/1

 Fa0/1:

   Interface State: Up

   Bandwidth:

     Curr allocated: 32K bits/sec

     Max. allowed (total): 256K bits/sec

     Max. allowed (per flow): 64K bits/sec

     Max. allowed for LSP tunnels using sub-pools: 0 bits/sec

     Set aside by policy (total): 0 bits/sec

   Admission Control:

     Header Compression methods supported:

       rtp (36 bytes-saved), udp (20 bytes-saved)

   Traffic Control:

     RSVP Data Packet Classification is ON via CEF callbacks

   Signalling:

     DSCP value used in RSVP msgs: 0x3F

     Number of refresh intervals to enforce blockade state: 4

     Number of missed refresh messages: 4

     Refresh interval: 30

   Authentication: disabled

!! Define policy to restrict/control RSVP messages

RTR(config)# ip rsvp policy local default|acl …

RTR(config-rsvp-policy-local)#{accept | forward} {all | path | path-error | resv | resv-error}

For better performance, minimize the bandwidth consumed by RSVP messages, and reliable RSVP messaging; RSVP periodic refreshment and reliable messaging feature can be enabled.

Also, RSVP can be made compression aware in order to reserve bandwidth for compressed traffic rather than uncompressed one. RSVP messages authentication is supported and can be implemented on per-neighbor basis.

One more option is to change hop IP address of RSVP messages that will be provided to neighbor in path messages (PSB Path State Block). Usually physical interface address will be provided in path messages.

Remarking Calls over Two CoS MPLS WAN

I had a scenario where the client bought two CoS L3 MPLS links for all his offices (HQs & BRs). 20% CoS1 is used for voice calls while 80% CoS3 for data.

As you know, MPLS providers will drop excess packets on CoS1. The excess packets from CoS1 won't be remarked. For other CoSes excess packets are remarked to default CoS.

Initially, we deployed E-LCAC for his network to make sure that once CoS1 is full calls are blocked. The client decided not to go for AAR.

The demand for On-Net calls increased and the users started getting "Not Enough Bandwidth" message very frequent.

Increasing E-LCAC location bandwidth wasn't an option as this will degrade overall calls performance due to packets getting dropped at CoS1 (remember excess packets at CoS1 are dropped).

The client didn't want to invest on upgrading CoS1 and wanted to pass excess calls over CoS3.

Challenges

- Network devices won't be able to do this as they mark packets not calls. This means that packets for a single call can have different marks which is very bad.

- CUCM won't be able to do this as CUCM doesn't set in the call path. It does signaling only.

Solution

The solution was to combine CUCM and Network devices with an RSVP E-LCAC deployment. This will utilize the fact that RSVP CAC will remark the calls to default DSCP in case RSVP reservation fails.

1. CUCM will try to reserve bandwidth using static location 

2. Next CUCM will try to allocate RSVP agents for the call

3. In case RSVP bandwdith is available, reservation is made and the RSVP agent will pass the calls as CoS1 (DSCP=EF)

4. In case RSVP bandwidth isn't available (fully consumed), reservation will failed. CUCM will still allocate RSVP agent without RSVP reservation. The RSVP agent will pass the calls as CoS3 (DSCP=0 by default)

Configuration Steps

I won't be detailing the step by step config as this can be lengthy. However, I will list summary steps and some relevant config.

1. In CUCM create locations for each office and a transit location called MPLS.

2. Connect the offices locations to MPLS location using links.

3. Link bandwidth should equal the total bandwidth of the office (CoS1 + CoS3).

4. In your E-LCAC location configuration, configure RSVP settings to optional (video desired) 

5. Configure software MTP at the gateway of each location. The MTP codec should match your inter-region codec and the maximum number of sessions should accommodate for the entire office bandwidth (CoS1 + CoS3)

e.g. if you are using G729 and your office bandwidth is 2 Mbps, then the max number of sessions should be > 86.

dspfarm profile 3 mtp 

 description **** RSVP CAC MTP ***

 codec g729r8

 rsvp

 maximum sessions software 100

 associate application SCCP

6. Create MRGs per office with the software MTPs associated and MRGLs per office. Assign the MRGLs to offices SIP/H323 Trunks/Gateways

7. Configure RSVP on the office routers. The amount of RSVP bandwidth should equal CoS1 and the max per-RSVP session bandwidth should be for 1 call + buffer (for G729 the max per-RSVP session bandwidth should be 40kbps).

 interface GigabitEthernet0/1

  ip rsvp bandwidth 400 40

  ip rsvp data-packet classification none

8. You can change the default DSCP marking for failed RSVP reservations from service parameters

 

Note: By default, RSVP attempts to process every packet not just provide CAC. Turn this off with the ip rsvp data-packet classification none interface command.

LDAP Users Import Failed with Custom User Fields

When configuring "Custom User Fields To Be Synchronized", every time you add anything to the section at : System > LDAP > LDAP Directory > Custom User Fields To Be Synchronized, the synchronization process fails.

Checking CUCM traces for DirSync and found this exception:

2014-06-06 15:50:52,830 ERROR [DirSync-DBInterface] common.DSDBInterface (DSDBInterface.java:534) - DSDBInterface.executeSQL Calling rollbackTransaction

2014-06-06 15:50:52,831 ERROR [DirSync-DBInterface] common.DSDBInterface (DSDBInterface.java:535) - DSDBInterface.executeSQL Caught SQLException, Error code=-217

2014-06-06 15:50:52,831 ERROR [DirSync-DBInterface] common.DSDBInterface (DSDBInterface.java:300) - DSDBInterface.updateUserInfo Error code=-217

2014-06-06 15:50:52,831 ERROR [DirSync-DBInterface] common.DSDBInterface (DSDBInterface.java:301) - DSDBInterface.updateUserInfo java.sql.SQLException: Column (customfield1) not found in any table in the query (or SLV is undefined).

MESSAGE Column (customfield1) not found in any table in the query (or SLV is undefined).

Of course customfield1 not found, this is not a column in the DB. The sync should update table 'customuserattributedata' table, column 'value' not column 'customfield1'…

admin:run sql select * from customuserattributedata

pkid tkcustomuserattribute fkenduser value

==== ===================== ========= =====

Table remains empty.

This is a bug fixed in version 9.1.2 and later CSCug93527.