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

[Mohamed Shameer Fareed]

Hi All

I'm still chasing Telco for a solution

They wanted us to use phones from a single network and do the test with and without MTP

Regards

Shameer

[Ayodeji Okanlawon]

I doubt the issue is with ITSP side because I can see RTP packets for the ITSP side in the last captures you took. Lets try again..

Use the following commands to take packet capture on the gateway

Here is the config for this:

1. Enable capture for ITSP interface

ip access-list extended EXT-FILTER

permit ip host X.X.X.X host y.y.y.y ( x.x.x.x = ip of cube that terminates media and y.y.y.y=IP of ITSP)

 permit ip host y.y.y.y host x.x.x.x

 monitor capture CAPEXT access-list EXT-FILTER buffer size 100 interface <interface that connects to ITSP>  both

eg

monitor capture CAPEXT access-list EXT-FILTER buffer size 100 interface GigabitEthernet 0/0/1 both

2. Enable capture for internal interface 

conf t

ip access-list extended INT-FILTER

permit ip host X.X.X.X host y.y.y.y ( x.x.x.x = ip of cube that terminates media and y.y.y.y=IP of CUBE again since call is hair pinned on cube)

  permit ip host y.y.y.y host x.x.x.x

at the exec level:

 monitor capture CAPINT access-list INT-FILTER buffer size 100 interface <interface that connects to CUCM>  both

Next Start both captures

monitor capture CAPEXT start

monitor capture CAPINT start

Do your test call, once test is done,

verify that you have packets been captured

show monito cap CAPEXT buffer

show monito cap CAPINT buffer

Next stop the capture...

monitor capture CAPEXT stop

monitor capture CAPINT stop

Finally export the capture to tftp server

monitor capture CAPINT export tftp://10.0.0.1/CAPINT.pcap

monitor capture CAPEXT export tftp://10.0.0.1/CAPEXT.pcap

Dont forget to remove the access-list once done...

Please refer to this link for help on setting up the capture if the config is not clear

https://cway.cisco.com/tools/CaptureGenAndAnalyse/

[Mohamed Shameer Fareed]

Hi Ayodeji

this is great, I will try to get some captures with this method today.

I did a test call yesterday with single provider but no joy

I collected the logs this way (see attached):

Deskphone with ext ending 2175

monitor capture CAP3 interface GigabitEthernet0/0/0 both
monitor capture CAP3 match ipv4 any any
monitor capture CAP3 start

monitor capture CAP4 interface GigabitEthernet0/0/1 both
monitor capture CAP4 match ipv4 any any
monitor capture CAP4 start

monitor capture CAP3 export flash:CAP3-0-0-0.pcap

monitor capture CAP4 export flash:CAP4-0-0-1.pcap

I will try to collect again using the below method and share the logs tonight

Many Thanks

Shameer

[Mohamed Shameer Fareed]

Hi

I did two test calls and captured the logs

Please check them and let me know

Many Thanks

Shameer

[Mohamed Shameer Fareed]

Hi

Sorry to bother you, did you manage to find anything from the logs to see why the CFWDAll call had no audio without the MTP on SIP trunk.

Regards

Shameer

[Ayodeji Okanlawon]

Apologies, I will take a look later today. I have been quite busy

[Mohamed Shameer Fareed]

No problem. Take your time 

Many thanks

shameer

[Ayodeji Okanlawon]

Hi Mohammed,

I promise that we will resolve this issue one way or another. I wont give up on it.

I looked at the packet captures and the issue I see remains the same. I do not see RTP packets flowing between the CUBE for the forwarded call.

Here is an analysis of how RTP streams should flow when a call is forwarded on the same CUBE

There should be four call legs.

1. ITSP------CUBE ( First leg of call)
2. CUBE----CUBE ( first leg)
3. CUBE--CUBE ( call forward leg
4. CUBE--ITSP ( call forward leg)

My example: You can CUBE sending rtp packets to itself ( highlighted in red)

#show voip rtp conn

5 35256066 35256067 25074 15106 10.119.17.69 50.120.187.88 NO
6 35256067 35256066 24524 25164 192.168.127.107 192.168.127.107 NO 
7 35256068 35256069 25164 24524 192.168.127.107 192.168.127.107 NO
8 35256069 35256068 25092 6842 10.119.17.69 50.120.187.88 NO

External Leg 1:
ITSP: -----------> CUBE:

m=audio 15106 RTP/AVP 8 9 0 18 101
c=IN IP4 50.120.187.88
CUBE (ext)----->ITSP:

c=IN IP4 10.119.17.69
m=audio 25074 RTP/AVP 9 101

CUBE (INT)------------>CUCM:

m=audio 24524 RTP/AVP 9 0 18 101
c=IN IP4 192.168.127.107
CUCM--200 OK--CUBE--->

m=audio 25164 RTP/AVP 9 101
c=IN IP4 192.168.127.107

--Leg 2 FWD call:
CUCM--->CUBE:

c=IN IP4 192.168.127.107
m=audio 24524 RTP/AVP 9 0 18 101

CUBE--------200 OK ---CUCM>

m=audio 25164 RTP/AVP 9 101
c=IN IP4 192.168.127.107

CUBE(EXT)--------->ITSP:

c=IN IP4 10.119.17.69
m=audio 25092 RTP/AVP 9 0 18 101
ITSP----------> CUBE (EXT INT)

c=IN IP4 50.120.187.88
m=audio 6842 RTP/AVP 9 101

As you can see I have rtp packets flowing between CUBE. This is what I dont see in your captures.

So lets do this again..

enable debug ccsip mess ( only this)

Make a test call. once call is connected..

do the following:

#term len 0

#sh voip rtp conn

Please send me the output. ( including call details, calling , called and forwarded call)

[Mohamed Shameer Fareed]

Hi Ayodeji

This is really helpful and thanks for the explanation

I will try to get you the logs today

Many Thanks

Shameer

[Mohamed Shameer Fareed]

Hi Ayodeji

Please see attached debug ccsip message and sh voip rtp conn attached

user ext ending 2175

Thanks

Shameer

[Ayodeji Okanlawon]

There is nothing in the voice rtp file. Did you enable the commands at the same time while the sip message debug is on? Its important that this is done together.

[Mohamed Shameer Fareed]

Sorry, It's my fault

I did the test again, please see attached

Thanks

Shameer

[Ayodeji Okanlawon]

So this is what I have been seeing all the time. Somehow the gateway is not using the rtp ports negotiated in the SDP. Here are the four call legs for the forwarded calls. 

VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP MPSS VRF
1 89196 89197 18070 55144 213.61.197.73 213.23.105.94 NO NA
2 89197 89196 18072 18074 10.199.238.50 10.199.238.50 NO NA
3 89198 89199 18074 18072 10.199.238.50 10.199.238.50 NO NA
4 89199 89198 18076 55186 213.61.197.73 213.23.105.94 NO NA
Found 4 active RTP connections

However here are the media ports negotiated in the SIP SDP. If you observed the ports I dont see any of theses ports used for RTP streaming above. This is what I observed in the packet captures as well. This is not the normal behavior. Can you open a case with Cisco or are you available to work with me, I can open a case with TAC

---------------------------------
1st leg: ITSP---cube

c=IN IP4 213.23.105.94
m=audio 55028 RTP/AVP 8 101 0 18

--

m=audio 18054 RTP/AVP 8 101
c=IN IP4 213.61.197.73

++ cube---cube +++
c=IN IP4 10.199.238.50
m=audio 18056 RTP/AVP 8 0 101
------ answer
c=IN IP4 10.199.238.50
m=audio 18058 RTP/AVP 8 101

-----------------------------------
2nd leg--fwd call ( cube--cube)

c=IN IP4 10.199.238.50
m=audio 18056 RTP/AVP 0 8 101

answer:
c=IN IP4 10.199.238.50
t=0 0
m=audio 18058 RTP/AVP 8 101
c=IN IP4 10.199.238.50

+++ cube to ITSP +++

c=IN IP4 213.61.197.73
t=0 0
m=audio 18060 RTP/AVP 0 8 101

c=IN IP4 213.23.105.94
t=0 0
m=audio 55088 RTP/AVP 8 101