Re: No Audio on call forwarded to extenal number.

givanov · ‎09-18-2019

Hello community,

We have this very odd issue:

Incoming call from external number to internal extension that is forwarded to another external number is connecting, but has no audio.

Phone A (any external number, but in this example +359889610844) dials +496152930142; this goes to our internal number Phone B. If Phone B doesn’t answer in 5 seconds (usually higher value, but we set it to 5 for the test) it is forwarded to Phone C (again any external number, but in the example +359885890203).

While Phone B is ringing Phone A hears the ringback tone. As soon as the 5 seconds expire and the call is sent to Phone C, Phone A stops hearing anything. Phone C can still answer the call, but both Phone A and Phone C don’t hear anything.

If Phone A is internal number and dials the other internal number Phone B, then the call reaches the external Phone C with no problem and call is successful with two-way audio.

We reviewed debugs from CUBE and here is what we see:

1 Initial INVITE comes from ITSP as:

INVITE sip:+496152930142@192.168.178.2:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 217.0.26.35:5060;branch=z9hG4bK6711e1970bb02b8a77b6edf2802e011d.6122ffbd

Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>

Max-Forwards: 60

To: +496152930142 <sip:+496152930142@telekom.de;transport=udp;user=phone>

From: <sip:+359889610844@sip-trunk.telekom.de;transport=udp;user=phone>;tag=c457483f

Call-ID: d51a52cb6d656157@62.156.111.71

Contact: <sip:dbkzX2uNsvwNYjMBqLWmSuVnZlOZZz9HSWX2vNEgXPWahTZ3kAyirEc93UAYofaW@th1>

Supported: 100rel,199,histinfo,timer

Session-Expires: 1800;refresher=uac

CSeq: 317357 INVITE

Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REGISTER, UPDATE

Min-SE: 900

P-Asserted-Identity: <sip:+359889610844@sip-trunk.telekom.de;user=phone>

P-Called-Party-ID: <sip:+496152930142@sip-trunk.telekom.de;user=phone>

Content-Type: application/sdp

Content-Disposition: session

Content-Length: 434

v=0

o=- 1197381055 1197381056 IN IP4 217.0.26.35

s=on transit

c=IN IP4 217.0.132.185

t=0 0

m=audio 16476 RTP/AVP 8 116 0 108 102 18 4 109

a=rtpmap:8 PCMA/8000

a=rtpmap:116 telephone-event/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:108 AMR/8000

a=fmtp:108 mode-change-neighbor=1;mode-change-period=2;mode-change-capability=2

a=rtpmap:102 AMR/8000

a=rtpmap:18 G729/8000

a=rtpmap:4 G723/8000

a=rtpmap:109 G726-16/8000

a=ptime:20

2 The call is sent to our CUCM and the internal extension rings.
At this point the caller hears ringback tone.

3 The call is forwarded after 5 seconds (as seen from the underlined time).

4 We send this INVITE out to ITSP for the forwarded call:

INVITE sip:+359885890203@sip-trunk.telekom.de:5060 SIP/2.0

Via: SIP/2.0/TCP 192.168.178.2:5060;branch=z9hG4bKC8E1025B6

From: <sip:00496152930142@sip-trunk.telekom.de>;tag=E71F3532-1062

To: <sip:+359885890203@sip-trunk.telekom.de>

Date: Tue, 17 Sep 2019 07:34:36 GMT

Call-ID: 6EE9F5BA-D85411E9-9E98E977-7E77540F@192.168.178.2

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

Cisco-Guid: 2550764416-0000065536-0000009094-0197689610

User-Agent: Cisco-SIPGateway/IOS-16.10.1a

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

CSeq: 101 INVITE

Timestamp: 1568705676

Contact: <sip:00496152930142@192.168.178.2:5060;transport=tcp>

Expires: 900

Allow-Events: telephone-event

Max-Forwards: 57

P-Asserted-Identity: <sip:3142@sip-trunk.telekom.de>

Session-Expires: 1800

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 250

v=0

o=CiscoSystemsSIP-GW-UserAgent 4242 3444 IN IP4 192.168.178.2

s=SIP Call

t=0 0

m=audio 22006 RTP/AVP 8 0 101

c=IN IP4 192.168.178.2

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:20

5 When the ringback is expected we receive this 183 SESSION PROGRESS message from ITSP:

SIP/2.0 183 Session Progress

Via: SIP/2.0/TCP 192.168.178.2:5060;received=87.166.21.32;branch=z9hG4bKC8E11144A

Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>

To: <sip:+359885890203@sip-trunk.telekom.de>;tag=9dd94eeb

From: <sip:00496152930142@sip-trunk.telekom.de>;tag=E71F3532-1062

Call-ID: 6EE9F5BA-D85411E9-9E98E977-7E77540F@192.168.178.2

Contact: <sip:V5e8BU/ZdShUM5xuxol6cBsKrAACOtdLLbJxR4hinOuRo8SV1aSW8oljXGHYx5IjyWqI@th1>

Supported: 100rel

CSeq: 102 INVITE

Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, PRACK, REGISTER, UPDATE

Reason: TSSI;cause=0

Session-ID: 3a85beb51b60bf12079678d4dcee3e0a

Content-Type: application/sdp

Content-Disposition: session

Content-Length: 237

v=0

o=- 3560920190817093400 1500643355 IN IP4 217.0.26.35

s=on transit

c=IN IP4 217.0.133.180

t=0 0

m=audio 11370 RTP/AVP 8 101

a=rtpmap:8 PCMA/8000

a=fmtp:8 vad=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=sendrecv

At this point the caller stops hearing anything.

6 The call is answered by the destination of the forwarding, but both parties can’t hear anything.

From here on the two phones wait for 5-10 seconds of the silence and they hang up. The call is disconnected normally.

From signalling point of view everything looks just fine for me. The call reaches the destination, it is answered, then disconnected all normally. But the media portion is lost somewhere along the way.

What I sent as questions to the ITSP is:

The initial INVITE (1) comes from your end with TO field “<sip:+496152930142@de;transport=udp;user=phone>”, where in all other messages + the second INVITE for the forwarded call (4) we send TO field like this “To: <sip:+359885890203@sip-trunk.telekom.de>”. sip-trunk.telekom.de is the destination for out trunk pointing to you and we send everything with this suffix.
Our question is: Is this normal and expected behaviour? Does this work with all your other clients?
The media IP in the initial INVITE (1) and the 183 SESSION PROGRESS for the forwarded (5) call you sent us are different. I assume they both are resolved from sip-trunk.telecom.de.
Our question here is: Is it normal to change the media IP for the same call? Can you keep the same media IP for the entire call?

I am suspecting that the issue might be with one of those things, but I am not sure.

Does anybody have a clue for something in the CUBE, which might be causing the issue? I am attaching the running config and debugs ccsip messages and voice ccapi.

Any help will be greatly appreciated!

Kalisha Adnan · ‎09-25-2019

Hello,

I have same problems. Forward to outside number has no audio. I haven't the debugs.

Please help.Thank you.

JustAnotherNetworkGuy · ‎09-29-2021

It's surprising that nobody who posted here took a few moments out of their day to share their solution. Wish everyone here could be down voted.

This was the answer in my case:

https://community.cisco.com/t5/ip-telephony-and-phones/cisco-cube-call-forward-to-external-no-audio-only-for-external/td-p/3818850

The ITSP's firewall wouldn't setup RTP until we initiated RTP. In the case of a forwarded call, you're in a catch-22 situation. The customer will never send RTP audio to the ITSP since they will never receive any RTP audio from the ITSP for the initial inbound call. You can do a packet capture on the customer interface facing the ITSP to verify this, and send it to your ITSP and have them correct their firewall to handle this situation.

The workarounds are to enable an MTP in CUCM if using CUCM, but this is best to be avoided since now you will have media for all calls flowing through CUCM instead of directly to the gateway, and using MTPs can create another set of issues. The second option is to configure STUN for firewall traversal and have it send some bogus RTP packets.

Roger Kallberg · ‎09-29-2021

As you seem to be using Deutsche Telecom I think that this post might be of help. https://community.cisco.com/t5/unified-communications/cube-config-sip-trunk-to-deutsche-telekom/m-p/4447706/highlight/true#M167984