06-16-2014 05:14 AM - edited 03-16-2019 11:07 PM
Hi Community,
need some help regarding an issue related with transfer of sip calls.
Normal calls are working fine.
Call Flow:
CUCM PBX (SIP Interface) <-- SIP g711 --> (mpls) <-- SIP g711 --> cube11/12 <-- SIP --> CUCM <<- SCCP g722 ->> CP7965
> Incoming call from A to B working fine.
> B transfer the call to C
> the call will be disconnected.
Anybody has an hint ?How I can proceed with troubleshooting ? I collect logs debug ccsip messages on the cube.
But I only find the "update" message and then the "bye" without any causes.
Thanks,
Stefan
06-16-2014 05:37 AM
can you try disabling G.722 codec and check the behaviour?
Phones B & C are in same CUCM?
If the issue persists, you could please collect debug voice ccapi inout & debug ccsip message together for a test call? Also please include the phone numbers involved.
06-16-2014 08:19 AM
Can you post the logs? It may be one side isn't responding to the Update resulting in the BYE being sent after a certain amount of time. Which side sent the Update and which side sent the Bye?
06-18-2014 12:50 AM
06-18-2014 12:52 AM
sorry some missunderstands from myside.
we received the update message -> send 200 okay with cs 104 for the update -> and then receive the bye message.
any hints ?
06-18-2014 07:05 AM
I only see one of the call legs in the logs. It's just the leg between CUBE and CUCM, not CUBE and the carrier.
This log also doesn't contain the full call as the first message is a Re-Invite.
One issue I see is that CUCM is setting the call to inactive as part of the transfer process. CUCM sends the UPDATE to CUBE once the transfer is completed to update the Remote-Party-ID. After this, CUCM sends a delayed-offer Invite to reset media up. However, CUBE sends a 200OK with a=inactive still set. It probably got this from the other SIP leg of the call. Some carriers do not like it when the media is set to inactive. You should be able to force MTP Required on the SIP Trunk in CUCM so that this inactive media exchange never happens and that will probably fix your problem. The other way people fix this problem is using sip-profiles on the CUBE to strip out the a=inactive line of the SDP from all messages.
06-18-2014 08:05 AM
Hi,
thanks for your feedback. To enable MTP is not possible because there is a big traffic.
I will attached the full logfiles of the testcall.
Can you give me an hint to create an SIP Profile to strip out the a=inactive line ?
Also be noticed that the call will be routed over mpls. There is no carrier.
Thanks,
Stefan
06-18-2014 08:27 AM
Can you pull CallManager traces from both clusters?
06-18-2014 12:47 PM
Here's where the first problem occurs. CUBE sends a Delayed Offer Re-Invite:
Jun 16 13:01:51.295: //2701152/2CD7A4A89CF7/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:172.24.14.76:5060 SIP/2.0
Via: SIP/2.0/UDP 172.25.32.12:5060;branch=z9hG4bK1A9DA81EF1
Remote-Party-ID: "I. Juergensmann HQ" <sip:8512@172.25.32.12>;party=calling;screen=no;privacy=off
From: <sip:8512@172.25.32.12;user=phone>;tag=8AACC428-1C34
To: "5247" <sip:5247@172.25.32.12;user=phone>;tag=abd58dfd
Date: Mon, 16 Jun 2014 13:01:51 GMT
Call-ID: f40b96d1@172.24.14.76
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 0752329896-4102885859-2633487303-0468260992
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 103 INVITE
Max-Forwards: 70
Timestamp: 1402923711
Contact: <sip:8512@172.25.32.12:5060>
Expires: 180
Allow-Events: kpml, telephone-event
Content-Length: 0
The other side sends back a 200OK with a=inactive in response:
Jun 16 13:01:51.335: //2701152/2CD7A4A89CF7/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.25.32.12:5060;branch=z9hG4bK1A9DA81EF1
From: <sip:8512@172.25.32.12;user=phone>;tag=8AACC428-1C34
To: "5247" <sip:5247@172.25.32.12;user=phone>;tag=abd58dfd
Call-ID: f40b96d1@172.24.14.76
CSeq: 103 INVITE
Contact: <sip:172.24.14.76:5060>
Supported: 100rel,replaces
Allow: INVITE, ACK, BYE, CANCEL, PRACK, UPDATE, REFER, NOTIFY
Content-Type: application/sdp
Content-Length: 204
v=0
o=- 38093 38094 IN IP4 172.24.14.76
s=-
c=IN IP4 172.24.14.76
t=0 0
m=audio 50014 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=inactive
What is 172.24.14.76? It's the device that's not responding correctly. You can probably work around it by doing this on the CUBE though:
voice class sip-profiles 300
request any sdp-header Audio-Attribute modify "inactive" "sendrecv"
request any sdp-header Audio-Attribute modify "sendonly" "sendrecv"
request any sdp-header Audio-Attribute modify "recvonly" "sendrecv"
response any sdp-header Audio-Attribute modify "inactive" "sendrecv"
response any sdp-header Audio-Attribute modify "sendonly" "sendrecv"
response any sdp-header Audio-Attribute modify "recvonly" "sendrecv"
voice service voip
sip
sip-profiles 300
09-15-2015 12:48 PM
This helped me out big time with an issue I was having on CME....
Calls would come in from ITSP to a SIP 9951 phone. That user would transfer these calls to different SCCP 8945 phones. When the call arrived at the SCCP phones, it didn't appear that the call was dropping or disconnecting, but there was no way audio and no SIP Call Legs existed on the router running CME.... I looked through the debugs and noticed I was receiving the a=inactive from the SIP Provider after the SIP phone pressed the transfer button. I added the mentioned SIP profile and applied that to the voice service voip sip section and it worked!
Keep in mind that this customer had been using CME with the exact same setup for over three years and they just called about this no audio when transferring issue and nothing was changed on the CME Router. So I called the SIP service provider to ask them about the issue and they kind of laughed at me saying that it was an issue that I needed to take up with the "PBX vendor"... That didn't sit very well with me since I am the "PBX vendor" and I hadn't changed a thing.
I opened a TAC case and worked with a few different engineers over the period of a few months. Then today while doing some Googling I ran across this post and voila!
Thanks for the great comment, Brian!
09-15-2015 12:53 PM
Do you have a Redirecting CSS assigned on the SIP trunk?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide