SIP calls will be disconnect after transfer

[Stefan Walter]

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

[Suresh Subramanian]

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.

[Brian Meade]

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?

[Stefan Walter]

Hi,

attached you'll find the logfiles.

Seems that the other side send the update and also the bye message.

> also I tried to disable g722 without success.

[Stefan Walter]

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 ?

[Brian Meade]

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.

[Stefan Walter]

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

[Brian Meade]

Can you pull CallManager traces from both clusters?

[Brian Meade]

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

[Ellen Kennedy]

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!
 

[DonweinerCO]

Do you have a Redirecting CSS assigned on the SIP trunk?