CallForwardAll only works with MTP Required under SIP Trunk

[Mohamed Shameer Fareed]

Hello

Call flow:

External Call Mobile1 -> SIP Provider -> CUBE (4431) -> CUCM (10.5) -> IPPhone (7841) which is set to forward all the call to a Mobile2 -> Same CUBE -> External Mobile2

Without MTP:

When both Parties connect there is no audio, both-ways

With MTP:

All good

Buy if you do a call transfer it works fine. Only issue is with CallForwardAll, to a mobile or to a fixed line

CallForwardAll to an Internal seems fine as well

I have some logs which I could share in private as it contains sensitive data to the client

Need help

Thanks 

Shameer

[R0g22]

How do you enforce MTP for a call ? EO or DTMF pref ?

Take the following logs for a working and non-working call -

debug ccsip message
debug voice ccapi inout

Do you know what MTP CUCM might be allocating ? Check the SIP trunk MRGL.

[Mohamed Shameer Fareed]

Hi Nipun

Thanks for getting back to me

Please see attached both working and non working logs

Deskphone is extension ending 2175

MRGL is assigned on the SIP trunk as well with both Hardware and Software MTP

But the calls use CUCM software MTP on successful calls. when I try only hardware MTP from the CUBE it didn't work.

Regards

Shameer

[Dennis Mink]

Are you using media flow through or flow around on the CUBE?  try flow through and turn MTP required off off the sip trunk

[Mohamed Shameer Fareed]

Hi Dennis

Thanks for the reply

i tested the call yesterday without MTP, and I cannot see the command under voice service voip. so is that mean by default it is media flow through?

Also I tried media flow around without MTP. But with media flow-around it kind of fixed the CallFwdAll audio issue, but when we do a consult transfer call drop/or no audio. also we tried 'media anti-trombone' with media flow around as well.

we checked with the telco and they confirmed they don't support media anti-trombone feature as well.

Now the case is with the Telco, but as you know they are not providing any solution.

The CUCMs are remote to the site over VPN, when we ticket the MTP for every call we see audio issue on random calls. so that's why we need this CFWDAll working without CUCM MTP.

[Ayodeji Okanlawon]

Hi,

This issue is a little strange and here is my reason for saying this.

1. When you do a cfwdall (without MTP) media is terminated for both call legs on the CUBE. So your RTP flow looks like this

1. Call without MTP, CUBE terminates media to itself as follows:

pstn caller1----rtp---cube---rtp--------cube---rtp---pstn called (diverted)

++ With MTP, CUBE terminates media to MTP. +++

2. pstn caller1----rtp---cube---rtp--------MTP
cube--rtp----pstn called (diverted)

As you can see the only time you are experiencing issues is when CUBE terminates media back to itself and this is normal for call forwarding scenarios because in cfwdall to an external number, the original called party never gets involved in the media flow.

This is a pretty standard feature of CUBE, hence why I said the issue is strange. 

I don't know why this is happening but try this command ( its a long shot)

conf t

voice rtp send-recv

My guess it wont work, but try it. Will keep investigating why this is happening.

Can you also send your sh run please

[Mohamed Shameer Fareed]

Hi Ayodeji

Thank you very much for your response on this. the command voice rtp send-recv is already on the config
I managed to get some packet capture on both Internal and External interfaces for both Working and Non-working scenario yesterday

Please have a look and let me know if you see anything strange. to me it look like a provider issue where they not sending RTP when the call forwarded to the final mobile.

Test 1: Working scenario with MTP enabled on CUCM

CAP3-0-0-0-Audio.pcap - internal

CAP4-0-0-1-Audio.pcap - external

Test 2: Not Working Scenario, where MTP disabled on CUCM

CAP5-0-0-0-No-Audio.pcap - internal

CAP6-0-0-0-No-Audio.pcap - external

Really appreciate the help

Regards

Shameer

[Ayodeji Okanlawon]

The packet capture for the call without MTP doesnt contain the call we are looking at. I dont any call that is diverted on that capture.

[Mohamed Shameer Fareed]

Hi Ayodeji

hmm, that's strange

Can you please check this one, this is captured using wireshark connected to a switch port and span the internal port connected to the CUBE

Thanks

Shameer

[Mohamed Shameer Fareed]

Hi Ayodeji

I did another test without MTP and captured the call on both interfaces

We made 3 test calls, 2 using the user mobile and the last on from my desk phone. dialling the user desk phone ending 2175 which is forwarded to another land line

Please check them and let me know if you could see anything strange on this

Also attached the debug ccsip message/debug dial-peer/debug voice ccapi inout for the same call

Many Thanks

Shameer

[Ayodeji Okanlawon]

Hi,

The issue is exactly what I thought. There is no RTP flowing on the internal interface when the call is call forwarded without MTP. 

++ here is the packet capture for the external interface ++

You can see the SIP traffic and after that the RTP flow

However for the internal interface, ie where media should connect on both side to the same CUBE-IP, here is what we see..

Here is the INVITE from CUCM to CUBE for the forwarded call and CUCM telling CUBE to use its ip 10.199.238.50 for media

But we never see any RTP media between flowing. 

I am not sure why this is happening.

[Ayodeji Okanlawon]

Mohammed,

What is this IP address? 10.143.156.191?

[Mohamed Shameer Fareed]

Hi Ayodeji

Thanks you very much for the checking the captures and appreciate your analysis on this.

Yes, it's very strange that the RTP is not flowing on the forwarded calls, I believe by ticking the MTP on CUCM on working scenario, CUCM MTP is generate dummy RTP, so audio will flow through both external phones. I provided the same logs to Telco for analysis yesterday and waiting to hear back from them. could it be the provider?

The IP address 10.143.156.191 is belong to an IPPhone (0076.86ec.ba6f), but not the device we did the forward and it belong to someone else. may be the call coming on to that one when we were doing the test.

The test phone is on IP address - 10.143.156.49 (0008.32c7.d479)

Hope this helps

Regards

Shameer

[Ayodeji Okanlawon]

Can you attach your sh run of the cube please

[Mohamed Shameer Fareed]

Hi

Please see attached sh run, I masked some IP addresses and sensitive details. let me know if there is anything else.

Appreciate your help

Many thanks

Shameer