Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to how to transition from TDM to SIP Trunks for CUCM 4.x, 5.x or 6.x with Cisco experts Christina Hattingh and Vivek Bhargava. Christina is a technical marketing engineer in the branch office Unified Communications group at Cisco, focusing on unified communications technologies and network deployments on the Cisco 2800 and 3800 Series Integrated Services Routers. Unified communications technologies integrated in Cisco IOS Software offer numerous communications services, such as voice and video gateways, call control, network services, and applications. In this role, Christina helps guide development projects, trains Cisco sales staff and Cisco resale partners on new Cisco IOS-based voice technologies, and advises customers on unified communications network deployment and design. Christina has been with Cisco Systems since 1998 and holds a graduate degree in computer science and mathematical statistics. Vivek Bhargava is a Technical Marketing Engineer in the Voice Technology Group at Cisco, focusing on the Unified Communications technologies, network design, and deployments. His technology interests include IP Voice Protocols, Media Resources, and Enterprise-Service Provider connectivity. In this role, Vivek helps develop Unified Communications design guidance and best practices, works with partners, Cisco field personnel and customers to apply these best practices, and takes the field experiences back to the development teams for product improvement. Vivek has been with Cisco Systems since 1999 and holds a graduate degree in Computer Science from University of California, Santa Barbara.
Remember to use the rating system to let Christina and Vivek know if you have received an adequate response.
Christina and Vivek might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through July 31, 2009. Visit this forum often to view responses to your questions and the questions of other community members.
One of the issues that frequently comes up with provider SIP trunks is how to quickly diagnose service or quality problems. This has been well understood with legacy ISDN circuits but SIP trunks are entirely different animal.
Assuming CUBE is the border element, what tools exist within IOS or from external applications to monitor the quality and status of the SIP trunk?
Also, in the event that you need to troubleshot an issue (e.g. voice quality) with a provider, what is the best way to find the root cause and avoid finger pointing with the provider?
You're right that SIP trunk monitoring methods in the industry are not yet nearly as well understood or developed as that for TDM trunking.
CUBE as a demarc point at the edge of your network helps with this. As an IOS feature set, you essentially have the same tools available as you would on the VoIP side of an IOS box used as a TDM GW, such as CDR, syslog, EEM, IP SLA and SNMP.
Additionally on CUBE you have support for the OOD Options Ping to "keepalive" the L7 status (L3 mechanisms like ICMP ping are also available) of the SIP peer and busy out dial-peers (routes) if the SIP peer is not responding. More info at
The in-dialog options ping to monitor the status of specific calls is also available, more info at
Statistics about an active call, including statistics such as round-trip time (RTT) can be gathered from the CISCO-VOICE-DIAL-CONTROL-MIB. For example âRound Trip delayâ is contained in the following variable:
1102966.1 = Gauge32: 6 milliseconds
In the US I believe that Cisco certify/recommend SIP providers for compatibility with the UC500.
Are there any plans to extend this program internationally and for larger systems so that SIP providers can offer "Certified Cisco Compatible" SIP services?
Information on SIP trunk validations completed for the UC500/SBCS series can be found at https://supportforums.cisco.com/docs/DOC-9830
There is no intent for this information to be North-America specific. There is a lot of ongoing work with NA, European and Asia/Pacific SPs and guides for interconnecting with all these offerings are done based on business case and posted as soon as they are available.
For enterprise configurations with CUCM and CUBE, the interop guides are posted at www.cisco.com/go/interoperability. This too is a world-wide effort and SPs are validated depending on business case, not on geography. Also, the documents posted are merely guides/examples developed for convenience of implementation. You can connect Cisco equipment (CUBE) to any SP SIP trunk based on standards compliance.
Is there a way configure authentication for SIP trunk. now there are service providers that supply SIP trunk connection to business but they demand user and password authentication for billing.
At the SIP protocol level, yes, the CUCM SIP trunk can both challenge a received request and reply to such a challenge from another SIP server. This is also called "Digest Authentication" and forces a user to send their credentials (user/password) before the server will act on their request.
If you are looking for an IVR level prompt for the user, a TCL or VXML application can be run on the CUBE or SIP GW for user authentication.
Hope this helps.
Just to add, CUBE also supports SIP Digest Authentication.
CUBE also supports SIP registration with a SIP server where credentials are quoted which can be checked by the registrar.
I'm looking at CM 6.1 and I don't see where I can configure a user on the trunk so I will be authenticate to the service provider.
You will need to configure a SIP Realm under Administration->User Management and there is no need to associate it with a SIP Trunk.
The user name and password are configured in this realm definition.
I am trying to configure a SIP trunk, via CUBE from PGW 2200 9.7(3) to CUCM 7.x.
There are quite a few CUBE configuration examples on CCO pertaining to using CUBE to connect CUCM to various soft switches or SIP enabled PBX's.
I have not been able to find an example of how CUBE should be configured to go between CUCM and PGW.
Does such a document exist?
There is no PGW-CUBE configs on Cisco.com that I'm aware of. Internal sources that have done this recommend using the same configuration on CUBE for PGW as you use for CUCM. There is nothing specific for, or particular to, PGW that you need to do on CUBE that we're aware of.
SIP connectivity between the PGW and CUCM is being deployed on a limited basis and there are no general configuration documents available at this time.
However, the PGW team can be directly engaged and can provide configuration details as required for a particular design.
Hope this helps.
Thanks very much. My impression was that all I would have to do on CUBE specifically was to convert from Delayed Offer to Ealry Offer on the out bound calls and I have done that.
What I am finding that is that now, when CUBE sends the Early Offer INVITE to PGW, PGW rejects it says the Port is not available.
WireShark shows that the INVITE goes out to 5060 as the destination port with the source port random (in the 50,000 range).
Is there a way to either force CUBE to use 5060 as the source port or force PGW to accept INVITES from any port?
There is no way today to configure the source port sent by CUBE. I do not know if the PGW can be configured or not. On CUBE you can try the following CLI - this will stop the port from being randomly chosen and may help:
One other piece of info about PGW interop that just came in is that PGW uses SIP INFO for OOB DTMF while IOS (CUBE) supports only receiving of SIP INFO for DTMF, but will never send it. For sending OOB SIP DTMF, CUBE supports SIP Notify and KPML (and of course RFC2833 but that's considered inband).
For specific configuration commands I will need to check and get back to you. I assume you have already consulted the provisioning guide available at:
Chapter 3 in this guide in particular deals with setting up of SIP profiles. Let me know if your question is not answered in this section.
SIP profiles are new to 9.8 aren't they? We are currently running 9.7(3) although will likely be upgrading in a few weeks time.
I was waiting for a long time for this topic to come. I would like to thank NetPro for providing an opportunity to talk on this subject.
Now, talking about the SIP trunks with SPs for PSTN access, I believe we should be able to form a Diirect SIP trunk between Cisco Communications Manager and the SP.
But most of the time I have heard people recommending a CUBE in between. I guess its not a mandatory component, and it should be feasible to form a direct trunk between CUCM and SP SIP Server.
I wanted to undersand, how do I decide, whether ot position a CUBE in case SIP connectivity is required for PSTN access. What are the deciding factors and what benifit does CUBE offers as compared to a direct SIP trunk.
A direct SIP trunk is certainly technically feasible, but it is an inflexible and insecure solution and therefore strongly NOT recommended.
Reasons to terminate a SIP trunk on an enterprise demarc such as CUBE include but are not limited to:
- Lack of call admission control (SLA enforcement and DOS attack mitigation) on the SIP trunk
- Visibility of the CUCM and endpoint IP addresses to the SP network (and therefore to potential hackers)
- Very limited SIP trunk load balancing and redundancy capabilities
- No SIP trunk sharing between multiple CUCM clusters or other IP-PBX/proxy call agents in the enterprise
- No SIP malformed packet or other protocol level attack mitigation for your CUCM
- No way to troubleshoot voice quality problems to determine if it's your network or the SPs network at fault
- Much more limited toll fraud prevention techniques on the SIP trunk
- No way to control IP QoS settings on the incoming packets from the SP, and no way to customize them on the outgoing packets
- No way to manipulate SIP msging from the SP before it hits your CUCM to customize it to what CUCM/IP-PBX prefers to see
- Limited means of complying to the SP UNI (SIP msg manipulation on outbound msgs to the SP, and capabilities such as early-offer)
- Having to implement the SP UNI on CUCM instead of your enterprise preferred policies (and having to replicate this on every CUCM and IP-PBX routing calls to the SIP trunk)
- Having no way of doing a SIP registration to the SP when this is required on the SIP trunk
I have a customer who recently moved to a CUBE to provide H.323 to their CUCM and SIP to their SIP provider who have an odd issue.
The customer has a claim that one of their larger customers has told them that they do not receive ringback tones when they call. Ringback has been tested from various other sources and it appears to work.
Are the methods for providing additional mechanisms for ringback tone that were applicable for H.323 and PSTN applicable to SIP as well?
Which mechanisms should be applied to which call legs, in which direction and which protocol (inbound or outbound call legs (distinct dial peers are in use), and on SIP or H.323)?
Let me see if I can find some specific configuration pointers for you and get back to you. It may be best just to contact TAC.
From talking to a few folks it would appear that we support ringback in all scenarios, SIP or H.323. But there is an open bug for one scenario right now which seems to be what you've run into (CSCsj18827). Feel free to work with TAC on this - there is no fix for this bug yet, but they can link your TAC case to the bug.
We are using SIP trunk via Paetec and can not get the Mobile Connect feature in UCM to work. It appears it does not work due to this feature does not utilize a Diversion Header and simply sends the call out using the original calling number of the person that dialed from external. Are you aware of anyone not being able to use the Mobile Connect feature for single number reach via a SIP Trunk?
I am not sure about Paetec, but Mobile Connect feature has been tested with a number of service providers.
Diversion header for Mobile Connect calls are indeed supported. Please refer to this link: http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/rel_notes/6_1_4/cucmbe-rel_note-614.html#wp854592.
Please make sure that you have it configured appropriately in the trunk configuration page.
If this is the case I'm not sure why it does not work. If we forward a phone to an external number and dial, we see the Diversion Header added to the SIP message. When dialing the Mobile Connect number the outbound SIP message does not include a Diversion Header. We are running 7.1 but the same results were also on 7.0 UCM version. Any Ideas?
I checked with Product Management and this is a 6.1.4 feature which will appear in CUCM 7.1(3) release scheduled for later this year.
So your options are to - go to 6.1(4) if possible or to see if Paetec can allow calls that appear to come from a different number than they expect from the enterprise.
To generate an offer in the initial outgoing INVITE message (the Early Offer or "EO"), the CUCM needs a well defined set of codec(s) and IP+Port.
In some cases, the CUCM may not have all of that information from the endpoint that is initiating the call. In those cases, the CUCM needs to allocate an MTP for which all of these attributes are known and use those values in the offer SDP.
Once the session is established, the media is then patched through from the MTP to the originating endpoint.
Note that the CUBE is also capable of converting between an INVITE with no SDP (Delayed Offer or "DO") to an INVITE with Early Offer. An MTP will not be required if the CUBE is so utilized.