Tag Archives: CUCM

Jul 19

iDivert in CUCM 9.1

Posted on by

CUCM 9.1 has included a new edition of the iDivert feature. The legacy iDivert does still exist and is the Default setting in CUCM.

Legacy iDivert allows you to essentially divert incomming calls to your extension to your voicemail. The new iDivert now prompts you with a menu to either divert the call o your voicemail or to the voicemail inbox of the extension that may have forwarded the call to your extension.

Scenario, Phone A with extension 1001 had CFA set to Phone B with extension 1002. A call comes into Phone A which then is forwarded to Phone B. User at Phone sees that this call is originally for Phone A. By pressing iDivert, Phone B has the option to divert the call to either Phone A’s voicemail or Phone B’s voicemail. Phone B user elects to divert the call to Phone A’s mailbox by toggling to Phone A on the iDivert Menu and pressing Select.

NOTE: This will only work if CUC is configured to look at the first redirecting number rather thatn the last redirecting number. (image below) Otherwise the iDivert menu will only be able to divert calls to the their own voicemail inbox.

idivert

 

Mar 21

RSVP

Posted on by

RSVP is a topology aware Call Admission Control (CAC) mechanism. As with any CAC mechanism the main purpose is to determine whether a call has enough bandwidth to proceed. RSVP supports any network topology and can pass through non-rsvp aware routers. Non-rsvp aware router will ignore and forward all rsvp messages.

RSVP signalling uses the same IP route as the media stream would take. If bandwidth on any link throughout the network is not sufficient, the reservation fails. If there is sufficient bandwidth throughout the network the reservation succeeds.

RSVP calculation

Lets work with G729 codec. Now before I get into how RSVP calculates bandwidth requirements, let do a quick refresher on payload sizes, and rtp stream size requirements for G729.

Below is a quick calculation on the three sampling sizes available for configuration in CUCM and CME.

10ms sampling size
IP Header = 20bytes
UDP Header = 8bytes
RTP Header = 12bytes
Payload = 10bytes
Total 50bytes per packet

1000ms / 10ms (sampling size)  = 100packets per seconds (pps)

100pps x 50bytes = 5000bytes per second

Convert to kbps = 40kbps. This is needed to for a single call with G729 with 10ms sampling size.

20ms sampling (Default for both CUCM and CME)

IP Header 20bytes
UDP Header 8bytes
RTP Header 12bytes
Payload 20bytes
Total 60bytes per packet.

1000ms / 20ms = 50pps

50pps x 60bytes = 3000bytes per second

Convert to kbps = 24kbps. This is needed to for a single call with G729 with 20ms sampling size.

30ms Sampling size

IP Header 20bytes
UDP Header 8bytes
RTP Header 12bytes
Payload 30bytes
Total 70bytes per packet

1000ms / 30ms = 33pps

33pps x 70bytes = 2310bytes per second

Convert to kbps = 18.4kbps. This is needed to for a single call with G729 with 30ms sampling size.

As we can see the 10ms sampling size requires the highest amount of bandwidth being 40kbps. Keep that in mind for a later discussion.

RSVP bandwidth pool is configured on each router’s interface with the ip rsvp bandwidth bandwidth command.

The bandwidth entered should equal the number of calls that is allowed to stream across the interface simultaneously. Working from the default (20ms sampling size), if we want to restrict calls to a maximum of 5 calls, we would enter 136kbps for the bandwidth. You are probably saying, the bandwidth should be 120kbps as 5 x 24kbps equals 120kbps. BUT RSVP doesn’t know the sampling size when the its setting up the reservation. All RSVP knows is the codec type, in this case its G729 which uses a maximum of 40kbps, remember going back to the previous discussion, a 10ms smapling size equals 40kbps. RSVP allows for the maximum size for a G729 call initially, until the rsvp process can look inside the voice stream and determine what sampling size the codec is using. Generally default is left, there the size is 24kbps, RSVP then throttles down the bandwidth needed to 24kbps. Therefore we always add 16kbps (the difference between a 20mx sampling size packet to a 10ms sampling size packet) to the rsvp bandwidth. This allows the last call to be initiated at 40kbps, before being throttled down. If we didn’t add the 16kbps onto the bandwidth needed, the last call would never be allowed to be setup as the RSVP process would have 24kbps left in the bandwidth pool, but 40kbps is needed to initially setup the reservation.

RSVP for CAC purposes is a DiffServ Model, not InetServ model. Yes RSVP traditionally speaking is an InetServ model as the RSVP process sits on the Control and Data Plane of the router. However RSVP used by CUCM sits only on the Control Plane, hence controls the Call Admission Component and not the actual QoS which runs on the Data Plane level. The QoS is left up to the LLQ mechanism.

Configuring RSVP

Commands

Interface G0/0
ip rsvp bandwidth kbps
 Dspfarm profile 2 mtp
Codec g729
Codec pass-through
Rsvp
Maximum sessions software 4 (Ensure this number is greater than or equal to the number of  calls desired.

 Sccp local Loopback 0
Sccp ccm 10.0.0.1 identifier 1 version 7+
Sccp ccm 10.0.0.2 identifier 2 version 7+

Sccp
 Sccp ccm group 1
 Bind interface loopback 0
 Associate ccm 1 priority 1
 Associate ccm 2 priority 2
 Associate profile 2 register HQ-RSVP

Notes:

*Can only use one codec assigned to an MTP resource, although you can have variations of the codec in same MTP resource. Eg G729a G729ab etc

*The MTP resource can also be used for other purposes, not just rsvp. So its always a good idea to allow maximum sessions higher to what is allowed by RSVP CAC as other process maybe using ghe MTP resource and consuming a session.

Mar 16

Displaying Logged in Users and their Devices using CUCM Shell

Posted on by

We all know in CUCM we can find logged in Users by clicking on the Device Tab then selecting the  Active Logged in Users dropdown on the top right of the window. This displays a list of currently logged in users and what device they have logged onto. To do this in the shell so we can export to a text or CSV file run the following command

run sql select d.name, eu.userid, p.name from extensionmobilitydynamic emd, device d, device p, enduser eu where emd.fkdevice=d.pkid and emd.fkdevice_currentloginprofile=p.pkid and emd.fkenduser=eu.pkid

This will output currently logged on profiles and their relating device. If we just wanted show output for a particular user, for example John Doe, with userid jdoe. We would run the following.

run sql select d.name, eu.userid, p.name from extensionmobilitydynamic emd, device d, device p, enduser eu where emd.fkdevice=d.pkid and emd.fkdevice_currentloginprofile=p.pkid and emd.fkenduser=eu.pkid and eu.userid=jdoe

This will show the following columns: Device Name, User ID, UDP Profile Name

If you would like to add in the DN, simply include the relevant dnorpattern fields.

Let’s take this a step further. Let’s say we are migrating to a new CUCM Cluster and we need to login users to the phones they were logged into on the existing CUCM Cluster.

Once we have this output, we can convert to CSV via the Import Data functionality in Excel, I use space as a separator, then bring together the UDP Profile name with a simply Excel formula. Now we merge the data into the EM Login URL. The URL is below

http://IP.ADDRESS:8080/emapp/EMAppServlet?device=#DEVICE#&&userid=USERID&seq=PIN

Simply reference the EM login URLs with a scripting language of your choice and run against the new CUCM Cluster. Users will be auto logged into their phone