So I have set up a SIP trunk (via an Enterprise CUBE) to a UK SIP provider. It works, I can place a call and it connects, two-way voice all is good. There are of course 2 call legs, one from CUCM (v8.6) to the CUBE via SIP and a second from the CUBE to the provider. Just for clarity the CUBE has a public address to which the dial-peer binds SIP for the external call leg, and a private address to which the dial-peer binds SIP for the internal leg.
So far so good...until I try a call transfer. I make an outbound call, get it connected, hit the transfer button on the phone and... nothing. The phone sort of freezes for a few seconds and the Transfer softkey is greyed out. A few seconds later the Transfer softkey returns to its previous state, and the call appears like its resumed (off hold) but there is now no voice traffic in either direction.
its very odd - and probably somthing I dont understand. The odd thing is that inbound calls (via another trunk but different provider) are fine, and I can transfer or hold or whatever without issue.
I watched the SIP messages on the CUBE when I hit the transfer and all I got was:
we have had a similar issue with SIP Calls using CUBE and CUCM 7.1 not sure if it will help but....
Issue: In a bad call, Phone A talks to Phone B and tries to conference in Phone C [PSTN]. While Phone C is ringing, Phone A presses the conference soft key (Phone C is not connected right now, it is still ringing). This is not an issue when the conference call softkey is pressed after the PSTN phone answers. Since our migration to CUBE,
The Fix: In order to resolve the issue with calls dropping when conferencing a PSTN person before answer, we would need to check/enable "MTP Required" on the SIP trunk. In doing so, CUCM has the ability to control and change the RTP connection when the call is conferenced and not rely on SIP messaging to the CUBE and SIP provider. This will result in fewer SIP messages being sent through the CUBE since the MTP will be able to handle the media changes using SCCP messaging. TAC recommends that we utilize IOS software MTP on the CUBE. This is something that is already set up on our CUBE. These are software only resources and this won’t utilize any DSP hardware resources. To facilitate this change, we should change the MRGL on the SIP trunk, such that only the MTPs are in the first MRG and the transcoders are in another MRG further down the list. This will prevent CUCM from using a transcoder as a possible MTP resource and will mitigate unnecessarily wasting of DSP resources.
Technical issue - SIP Early offer: As we know, Verizon [and most providers now] require SIP Early Offer as the means of quickly setting up media for calls. With “early offer” the calling party sends the SDP within the SIP Invite message. SDP contains codec, IP address, port # and dtmf parameters. Early offer insures no delay in the SIP call setup. When the original SDP parameters are changed as a result of a conference call being invoked the “conferenced PSTN” leg of the call fails/drops. MTP is a means of addressing this issue. With MTP configured, the SDP contains the MTP information and this fixes the conference call issue.
**CUCM version** - With UCM versions 8.0 and prior, MTP must be invoked for ALL calls regardless of the need if the “MTP Required” box is checked on the SIP trunk. Call Manager version 8.5 and beyond address this limitation. Cisco added an option in the UCM “SIP profile” which is applied to the VZ SIP trunk via a check box “Early Offer support for voice and video calls (insert MTP if needed)”
Unexpected impact: We believe that CPU on the CUBE router may not be an issue as currently CPU does not go above 30% on JSQ CUBE but we don’t know for sure if this may be an issue. Also, the IOS MTP resources of the CUBE will be utilized and we are confident this will not be an issue but cannot be 100% sure about this.
Expected Impact: As we know, when making a change to a SIP trunk, a reset of the trunk is needed. A SIP trunk reset will disconnect/drop all active calls. I suggest that we make this change on our JSQ SIP Trunk first.
Lab 1: Cisco Meeting Server Standalone CertificatesLab 2: Cisco Meeting Server Cluster Certificates with Multi-SANLab 3: Multiple Certificates with Multiple CA ServersLab 4: Cisco Meeting Server Cluster Certificates Advanced ScenarioLab 5: Streamer Servic...
Certificates are the first step to deploy Cisco Meeting Server, preparing certificate are very important to enable different services. As a VOIP administrator, mastering the concept of certificates is unavoidable
Using multiple CA servers, instead of a si...
I just finished to write a comprehensive certificates preparation for Cisco Meeting Server Clustering. Through 60 pages I explained in detail, how to create certificates for database cluster, callbridge cluster, certificate chain for webbridge3, certifica...
Translation Pattern is the most important tool in the Call Routing Process for Cisco Unified Communication manager. Largely used in the Globalized Dial Plan, inter-site and intra-site dialing, and a powerful tool to solve the problem of overlapping direct...