Unanswered Question
Jul 17th, 2009

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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.6 (5 ratings)
Jonathan Schulenberg Fri, 07/17/2009 - 11:30

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?

hattingh Mon, 07/20/2009 - 14:42

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



James Hawkins Sat, 07/18/2009 - 00:59

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?

hattingh Mon, 07/20/2009 - 10:22

Information on SIP trunk validations completed for the UC500/SBCS series can be found at

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 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.



aharon-n Sat, 07/18/2009 - 22:55


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.



vbharga Mon, 07/20/2009 - 09:20

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.

hattingh Mon, 07/20/2009 - 10:05

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.



aharon-n Mon, 07/20/2009 - 10:37


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.

vbharga Mon, 07/20/2009 - 11:26

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.


tedgarner Sun, 07/19/2009 - 10:27

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?


hattingh Mon, 07/20/2009 - 10:08

There is no PGW-CUBE configs on 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.



vbharga Mon, 07/20/2009 - 10:12


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.


tedgarner Mon, 07/20/2009 - 10:22


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?


hattingh Mon, 07/20/2009 - 10:34

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).


tedgarner Mon, 07/20/2009 - 12:19


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.


Sushil Kumar Katre Sun, 07/19/2009 - 20:17

Hi Christina,

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.

-> Sushil

hattingh Mon, 07/20/2009 - 07:55

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



Sushil Kumar Katre Mon, 07/20/2009 - 20:51

Hi Christina,

You have given me a lot of points not to go for a direct SIP trunking :)

Thanks a lot!!!

-> Sushil

calmichael Mon, 07/20/2009 - 10:18

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)?


hattingh Tue, 07/21/2009 - 05:46

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.



hattingh Tue, 07/21/2009 - 13:19

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.



shell99101 Mon, 07/20/2009 - 11:37

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?

Thank You,


vbharga Mon, 07/20/2009 - 18:47


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:

Please make sure that you have it configured appropriately in the trunk configuration page.


shell99101 Tue, 07/21/2009 - 11:36

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?


vbharga Tue, 07/21/2009 - 13:48

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.


vbharga Tue, 07/21/2009 - 06:10

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.


hattingh Wed, 07/22/2009 - 05:28

No, CUBE does not need DSPs to do DO-EO interworking. CUBE needs DSPs when the media stream must be manipulated, such as xcoding and SRTP-RTP conversion.



vbharga Wed, 07/22/2009 - 05:29

No, it will not. The translation consists of terminating and re-originating that INVITE message. The outgoing INVITE has an SDP which has the codecs that you define on the dial-peer and the IP+Port of the CUBE. The CUBE now completes the Offer-Answer process separately with both of the call legs - one with DO to the CUCM and one with EO to the service provider.

Once the two processes are complete and the session is established, the media flows through the CUBE.


Stoyan Stoitsev Wed, 07/22/2009 - 06:59

Thank you for the great info but it raises some more questions :)

When we get in a situation where on the outbound call leg the EO negotiated g729 and on the inbound DO CUCM sent g711 where do we need to transcode?

Do we need xcoder registered in the CUBE or in CUCM? I guess in CUBE.



vbharga Wed, 07/22/2009 - 07:49

The CUCM will be unaware of the codec mismatch in this case and the CUBE will need to do the transcoding if a common codec can not be negotiated on both incoming and outgoing legs. And, yes, you will need DSPs for doing the transcoding.

Needless to say, such cases should be minimized with careful design.

hattingh Wed, 07/22/2009 - 10:38

Just to add... and for CUBE to switch in a xcoder is independent of DO-EO. It has purely to do with codecs negotiated on each side - if there is no common codec, and CUBE is configured for xcoding, then it will switch in a xocder for the call flow.


hattingh Sat, 07/25/2009 - 16:13

The best practise design would be for CUCM to do DO, CUBE to do DE-EO conversion to the SIP trunk and to use the same codec e2e, either negotiate G.711 or G.729 e2e. Getting a G.711 SIP trunk is better for both voice quality as well as faxing, than getting a G.729 SIP trunk from the provider.

If the above is not possible, then have CUBE do the xcoding.



bartymil123 Thu, 07/23/2009 - 18:44

Hi Guys,

We have a working SIP trunk on CUCM6. But we have only been able to get the trunk working by currently routing the external interface (ip provided by ISP) on our remote G/W internally and configuring that IP on our CUCM SIP trunk config. Whats the recommend solution for this situation. Should we be doing some NAT on the remote G/W? If so could you point me in the direction of some cofig examples?


hattingh Fri, 07/24/2009 - 06:09

You should terminate the external SP IP address either on an SBC (such as Cisco Unified Border Element, CUBE) and then connect the SBC to your CUCM on an internally address. The SBC will do NAT, and many other interop and security features.

Configuration examples are posted at > Cisco Unified Border Element.



bartymil123 Sun, 07/26/2009 - 00:22

great thanks, those documents are really useful. we are running adventservicesK9-m 12.4(24)T

you need to purchase a feature licence is that correct? does this add any extra features to the IOS we are running or its just a licence to use the CUBE function? do we need to get a new IOS version.


hattingh Mon, 07/27/2009 - 09:36

Yes, you need a feature license for CUBE. There are several choices. This covers CUBE functionality (essentially the "allow connections..." CLI) only.

Other IOS Features will depend on what image you have. If you already have a CUBE-capable image (such as IP Voice or SP Svcs) and need only the common/basic CUBE features, then you do not need to upgrade, you only need to add the feature license.

If you do NOT have a CUBE-capable image, or wish to use some of the more sophisticated CUBE features (video, flow-around...), then you will need to upgrade to the IVS (no security) or AVS (security) images and add the feature license.

More info/details in the Ordering Guide at



BikkeBikke1972 Fri, 07/24/2009 - 01:48

Hi, I've been searching DTMF conversion (Outbound to Inbound), and I'd like to know detail how Cisco GW to send DTMF tone (telephone events).

I found below question during web search.


Please see at

How Cisco sends DTMF tones...

Upon DTMF detection, Cisco GW starts sending tone updates immediately. It sends the initial packet 3 times, the initial tone duration is set to 0. Then it keeps sending updates every 50 ms until the end of the tone. Once the end of the tone is detected, Cisco GW sends the final packet 3 times with the correct “final” duration.


According to her question, it looks like that Cisco GW sends telephone-event every 50msec.

However, I couldn't understand how long duraion.

Does Cisco GW set "40msec" for 1st received telephone event, and set "40+Xnd(msec)" for 2nd or lator packets on the basis of RFC2833?


hattingh Fri, 07/24/2009 - 16:55

This will require some research. I'll get back to you next week.



hannyong Sat, 07/25/2009 - 09:50

Hi, my customer uses a CS2000 softswitch. I was told, that it supports SIP Trunk. Just wondering if:

1) CS2000 SIP Trunk implementation is the same as CUBE SIP Trunk?

2) Would appreciate it, if you could point me to some direction, as to some SIP parameters when CS2000 talks to CUBE. In other words, what would my VOIP dial-peer be, in order for CUBE to talk to a CS2000?

Thanks in advance :)



hattingh Sat, 07/25/2009 - 14:47

1) Yes, you can connect CUBE to any other SIP destination such as a Nortel CS2K.

2) We have not done any specific interop with a Nortel CS2K, but we have done so with a CS1K. Configuration App Notes for the CS1K can be found at > "Cisco Unified Border Element".



hattingh Fri, 07/31/2009 - 10:39

Sorry for the delay. Research says when CUBE converts DTMF from an out-of-band (OOB) ingress method to RFC2833 egress, it does the following:

- It ignores the "begin" event from the OOB side

- When the "end" event from the the OOB method arrives, CUBE starts sending out RFC2833 DTMF packets to the egress side

- 1st packet is the digit begin packet

- 2nd and 3rd packets are redundant packets for the first one

- 4th packet is a refresh packet with 50ms in the duration field

- 5th packet is the end packet with 100ms in the duration field

- 6th and 7th packets are redundant packets for the end packet

Various bug fixes and feature enhancements have been made in this area, so behavior may be different based on what release you have. In some releases the above 6 packets are sent out in one single burst, and in other releases there is an artificial delay between some of the packets as some IVR systems cannot deal with the single burst.

If you have a problem in this area with a deployment, pls work with Cisco TAC who can then look into more detail into what the exact problem is and which of the various changes made in this area may resolve your problem and what IOS release that change is in.



say8746 Fri, 07/24/2009 - 06:32

In a multisites scenario with centralized cube(s) how would CAC work on a PER SITE basis? Also, what are the main differences/ advantages of flowing through vs. flowing around CUBE and which method would you recommend? Thnx ...

hattingh Sat, 07/25/2009 - 15:10

You could use CUCM Locations CAC to account for the BW of calls from the remote offices to the central site.

CUBE can do CAC on the SIP trunk itself, i.e. allow only as many calls on the SIP trunk from the SP as you want to, or as the SLA specifies.



hattingh Thu, 07/30/2009 - 11:25

Apologies, I see I did not respond to the part of your question about flow-through (FT) and flow-around (FA).

The predominant CUBE deployment is in FT mode. In FA mode only the signaling passes through CUBE, but the media flows directly between the endpoints (like a GK architecture). The main advantages of FA is higher CUBE scalability, and media path optimization (shortest path, i.e. least latency). The disadvantages are that you lose a number of CUBE (SBC) media manipulation features because CUBE does not see the media - often these features are the very reasons you put an SBC into your network to begin with. And this is why most deployments use FT mode.

The CUBE media manipulation features you lose in FA mode include SIP DO-EO interworking, RFC2833 conversion to OOB DTMF mechanisms, xcoding, topology hiding on the RTP stream, and SRTP-RTP conversion.



say8746 Thu, 07/30/2009 - 13:34

Would CUCM block the remote site and would not pass the call to the CUBE if there was not enough bandwidth and the call was intended to be a SIP trunk call? Remember there will be two call scenario here SIP trunk to PSTN with x number of channels and inter-site calls within the CUCM Enterprise network. With that would CUCM differentiate between the two? Thnx again...


This Discussion