An outside caller calls into our CUCM via VGW1 to reach User 1 (registered to CUCM on extension 1111)
User 1 has mobility configured to call their mobile number, so a simultaneous call is established to the ITSP via the CUBE.
After the first initial SIP INVITE is received by the CUBE and sent to the ITSP, a second SIP INVITE is received from CUCM and sent to the ITSP
This SIP INVITE (RE-INVITE?) has no SDP information, so the ITSP sends back a 200 OK message with SDP information
The codecs sent back from the carrier are not supported on the CUBE, hence the CUBE drops the call
CUCM Mobility functionality sees the "drop" as User 1 hanging up on their mobile, therefore CUCM plays Music On Hold, waiting for User 1 to RESUME the call on the Cisco IP Phone.
Normal calls direct from Cisco IP Phones through the CUBE work fine.
Initiating calls from internal Cisco IP Phones to Cisco IP Phones, the mobility functionality through the CUBE works fine
The issue is only apparent when a call comes in from the outside via the VGW.
Initially I thought this was a H323 Gateway to SIP Early Offer interoperatibility issue.
So I changed the Voice Gateway protocol to use SIP and I continue to get the same issue.
I do not want to use an MTP for every call and I only wish to use our preferred codecs (G711ulaw or G711alaw)
I assume the best solution would be for CUCM to send SDP information in the second INVITE?
How can I achieve this?
VGW and CUBE IOS version is: 152-4.M5
CUCM Version is 9.1.212900-11
SIP Profiles:
Trunk Configuration
{Checked} Early Offer support for voice and video calls (insert MTP if needed)
All Trunks have access to Media resources such as hardware and software MTPs.
As far as i know there is no option in CUCM and CUBE to convert DO Re-Invite to EO Re-Invite. Now there are two questions which comes to my mind.
First why Telco sends different codes in different method of offers like G729 and G726 codec in delayed offer and G711 in early offer ? You can ask this to your provider.
Second why CUCM sends delayed offer Re-INVITE ? May be CUCM is receiving DO from its previous call leg. So i think we need to see logs between VGW1 and CUCM to verify it.
I am hoping this will somehow shed some light on why the RE-INVITE received on the CUBE from CUCM is using Delayed Offer (DO), when the initial invite received was Early Offer (EO)
In addition, I have contacted the Telco who confirms that they have an issue with one of their devices not advertising the configured codecs correctly. This causes calls to fail intermittently due to codec mismatch. They have escalated this issue to their hardware vendor.
I don't know the real reason why CUCM sent DO Re-Invite , maybe it require MTP to add SDP parameters in Re-Invite , that's why i asked this question to you "When you check MTP does this issue resolve ?"
As per my knowledge CUCM lacks the option or feature to manage Re-Invite messages (if anyone in this forum have any other view can put it).
This issue is certainly related to Telco as they are not handle their codec properly.
I believe cucm will always send a DO re-INVITE except in cases where it needs to break the media path in which case it needs to make the call inactive. The only way it can do that is to send an inactive attribute in its SDP. In other cases, ie to resume a call, to connect to the transferred destination, cucm will always use DO.
MTP will solve this issue because when MTP is involved a re-INVITE is not used, rather CUCM sends an UPDATE message to the CUBE.
Please rate all useful posts
Getting Started
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
