Solved: SIP Trunk & MTP

mightyking · ‎09-11-2017

Hi Everyone,

Our inbound and outbound calls fail when the MTP in the CUCM SIP Trunk configuration page is disabled. As soon as the MTP is enabled everything works well. I don't believe it's a good practice to use MTP for each and every inbound and outbound call. Please find attached the entire output of debug ccsip message. Need help to make calls work without MTP resources.

Sep 11 17:04:28.350: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

BYE sip:6132604848;tgrp=CUST7_6132604848_01A;trunk-context=siptrunking.bell.ca@192.197.135.179:5060 SIP/2.0

Via: SIP/2.0/UDP 207.236.237.219:5060;branch=z9hG4bK5t15v72080mheoet80e0sdo9s39m0.1

From: <sip:5146027093@siptrunking.bell.ca>;tag=1104162318-1505149266890

To: "SIP Trunk Test Phone1" <sip:6132604848@lab.internetvoice.ca;user=phone>;tag=457499-2377

Call-ID: 12A725CF-964A11E7-84ECBE12-38114A35@lab.internetvoice.ca

CSeq: 955355436 BYE

Max-Forwards: 19

Content-Length: 0

Sep 11 17:04:28.352: //1169/3BAE80800000/SIP/Msg/ccsipDisplayMsg:

Sent:

BYE sip:6132604848@10.9.0.14:5060 SIP/2.0

Via: SIP/2.0/UDP 192.168.2.179:5060;branch=z9hG4bK441F4D

From: <sip:5146027093@192.168.2.179>;tag=457E42-45C

To: "SIP Trunk Test Phone1" <sip:6132604848@10.9.0.14>;tag=20043195~c95be849-4c79-4ab9-b071-5968a9cb676e-73609906

Date: Mon, 11 Sep 2017 17:04:23 GMT

Call-ID: 3bae8080-9b61c20e-36a0e-e00090a@10.9.0.14

User-Agent: Cisco-SIPGateway/IOS-15.4.3.S4

Max-Forwards: 70

Timestamp: 1505149468

CSeq: 101 BYE

Reason: Q.850;cause=16

Content-Length: 0

Sep 11 17:04:28.352: //1170/3BAE80800000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 207.236.237.219:5060;branch=z9hG4bK5t15v72080mheoet80e0sdo9s39m0.1

From: <sip:5146027093@siptrunking.bell.ca>;tag=1104162318-1505149266890

To: "SIP Trunk Test Phone1" <sip:6132604848@lab.internetvoice.ca>;tag=457499-2377

Date: Mon, 11 Sep 2017 17:04:28 GMT

Call-ID: 12A725CF-964A11E7-84ECBE12-38114A35@lab.internetvoice.ca

Server: Cisco-SIPGateway/IOS-15.4.3.S4

CSeq: 955355436 BYE

Reason: Q.850;cause=16

Content-Length: 0

Sep 11 17:04:28.355: //1169/3BAE80800000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.2.179:5060;branch=z9hG4bK441F4D

From: <sip:5146027093@192.168.2.179>;tag=457E42-45C

To: "SIP Trunk Test Phone1" <sip:6132604848@10.9.0.14>;tag=20043195~c95be849-4c79-4ab9-b071-5968a9cb676e-73609906

Date: Mon, 11 Sep 2017 17:04:28 GMT

Call-ID: 3bae8080-9b61c20e-36a0e-e00090a@10.9.0.14

Server: Cisco-CUCM10.5

CSeq: 101 BYE

Content-Length: 0

Ayodeji Okanlawon · ‎09-19-2017

Here is another thing to check. Is there IP connectivity between the cube gateway and the IP subnet of the phones. Or is there a firewall between the gateway and the phone subnet? When you use IP communicator, the IP the gateway sends media to is different. This is also the case when you use MTP on the sip trunk.

My thinking is that BELL is terminating the call because they are not getting any RTP stream or media after the session is established.

This is why I asked you to verify from them why they are disconnecting the call.

Check your end. Check firewalls, check that nothing is blocking rtp ports between the gateway and the phones

Please rate all useful posts

View solution in original post

Dennis Mink · ‎09-11-2017

I would start with using Early Offer on your trunk between CUCM and your CUBE, becuase this is what you are using on your outgoing call leg towards your provider.

please rate if helpful

Please remember to rate useful posts, by clicking on the stars below.

mightyking · ‎09-14-2017

Hi Dennis,

Thank you for taking the time and replying to my post.

The early offer is forced in the CUBE and Early Offer support for voice and video calls is set to Mandatory (insert MTP if needed) in the trunk SIP Profile.

Please find attaced the output of the debugs for a call without MTP and a working call with MTP. The call without MTP gets terminated 5 seconds after being answered.

Thanks,

MK

Ayodeji Okanlawon · ‎09-16-2017

Hi MK,

I have compared the logs and here are my observations

1. ++ working with MTP ++

The working call usinbg MTP only advertised G711ulaw to Bell..Here is the INVITE

Sep 14 13:45:04.427: //42083/E82A75800000/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:5146027093@siptrunking.bell.ca:5060 SIP/2.0
Via: SIP/2.0/UDP 192.197.135.179:5060;branch=z9hG4bK381860
From: "SIP Trunk Test Phone1" <sip:6132604848@lab.internetvoice.ca>;tag=A23045B-77E
To: <sip:5146027093@siptrunking.bell.ca>
---
v=0
o=CiscoSystemsSIP-GW-UserAgent 2446 7496 IN IP4 192.197.135.179
s=SIP Call
c=IN IP4 192.197.135.179
t=0 0
m=audio 16426 RTP/AVP 0 100 101
c=IN IP4 192.197.135.179
a=rtpmap:0 PCMU/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

++ The call without MTP sends multiple codecs to Bell ++

++ Call without MTP ++

Sent:
INVITE sip:5146027093@siptrunking.bell.ca:5060 SIP/2.0
Via: SIP/2.0/UDP 192.197.135.179:5060;branch=z9hG4bK3313FB
From: "SIP Trunk Test Phone1" <sip:6132604848@lab.internetvoice.ca>;tag=A189E28-1EAF
To: <sip:5146027093@siptrunking.bell.ca>
--
c=IN IP4 192.197.135.179
t=0 0
m=audio 16422 RTP/AVP 0 18 100 101
c=IN IP4 192.197.135.179
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

++ Now for some reason Bell keeps ending the call after 5sec for this call +++

++ BYE from Bell ++

Sep 14 13:33:57.027: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
BYE sip:6132604848;tgrp=CUST7_6132604848_01A;trunk-context=siptrunking.bell.ca@192.197.135.179:5060 SIP/2.0
Via: SIP/2.0/UDP 207.236.237.219:5060;branch=z9hG4bK5b76us204o7scn6v63m0sd0giqr93.1
From: <sip:5146027093@siptrunking.bell.ca>;tag=969293210-1505395835982
To: "SIP Trunk Test Phone1" <sip:6132604848@lab.internetvoice.ca>;tag=A189E28-1EAF
Call-ID: 2901869B-988811E7-A3D6A050-9B8FA5D1@lab.internetvoice.ca
CSeq: 4898259 BYE
Max-Forwards: 19
Content-Length: 0

++ Suggestions ++

1. Configure G711ulaw only as the codec on the outbound dial-peer to Bell and test to see if calls without MTP stay up

2. Speak to Bell find out why they are disconnecting the call

Please rate all useful posts

mightyking · ‎09-18-2017

Hi Ayodeji,

Thank you VERY much for taking the time and helping me out. Your help is very mush appreciated.

I forced the dial-peer to use G711ulaw but as you can see in the attached debug output the provider still receives multiple codecs. Here's what the provider responded regarding the codec setting.

"Generally our SBCs are configured to accept either G729 or G711ulaw so when you offer either we’ll go with it". I am pretty sure the problem is in my end but don't seem to be able to locate it.

Here's the dial peer config for outbound local calls:

dial-peer voice 201 voip
description WAN Outgoing local Calls to Bell
translation-profile outgoing Remove_9
destination-pattern 5146027093
rtp payload-type comfort-noise 13
session protocol sipv2
session target ipv4:207.236.237.219:5060
voice-class sip asserted-id pai
voice-class sip privacy-policy passthru
voice-class sip early-offer forced
voice-class sip profiles 101
voice-class sip options-keepalive down-interval 20
voice-class sip bind control source-interface GigabitEthernet0/0/1
voice-class sip bind media source-interface GigabitEthernet0/0/1
dtmf-relay rtp-nte
codec g711ulaw
fax rate 14400
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
no vad

Ayodeji Okanlawon · ‎09-18-2017

While this may sound strange to you but the problem is bot your end. You should have sent BELL the logs that showed that they are terminating the call..

Here is another thing you can do...

Disable early offer on the dial-peer towards bell and test again

dial-peer voice 201

no voice-class sip early-offer forced

Please rate all useful posts

mightyking · ‎09-19-2017

Hi Ayodehi,

I disabled early offer in the dialpeer as well as in the SIP Profile but nothing changed!!!

The strangest thing is that everything works perfectely well when I make the same call using my IP Communicator and fails when I use the actual phone. I haven't received any reply from the provider but to be honest with you I strongly believe the problem is in my end. If it was the probvider why the call works when it is made using IP Communicator?

Thanks,

MK

Ayodeji Okanlawon · ‎09-19-2017

Here is another thing to check. Is there IP connectivity between the cube gateway and the IP subnet of the phones. Or is there a firewall between the gateway and the phone subnet? When you use IP communicator, the IP the gateway sends media to is different. This is also the case when you use MTP on the sip trunk.

My thinking is that BELL is terminating the call because they are not getting any RTP stream or media after the session is established.

This is why I asked you to verify from them why they are disconnecting the call.

Check your end. Check firewalls, check that nothing is blocking rtp ports between the gateway and the phones

Please rate all useful posts

lukasz.banka · ‎09-20-2017

I agree with the person stating this is due to media-activity detection on operator side which strongly suggest routing issue.

Please take a look here:

http://docwiki.cisco.com/wiki/Cisco_IOS_Voice_Troubleshooting_and_Monitoring_--_Media_Inactive_Call_Detection

You should be able to verify if there is an actual RTP flow in this call.

Another test I would suggest is to:

- place the call (without MTP);

- Immediately (before 5 sec) put the call on hold (RTP streams should be renegotiated to MoH server between CUCM & CUBE);

- wait 15 seconds;

- resume the call;

- if call is disconnected after 5 sec again then it probably is routing (maybe firewall).

mightyking · ‎09-20-2017

BINGOOOOOOOOO!!!!

Thank you Ayodeji and Lukasz.

As you both mentioned, the issue has been resolved after reviewing the routing btw the CUBE and phone. The test phone was not visible by the CUBE and was blocked by an access list.

I am glad that we can move forward with our SIP trunk testing now.

Thank you agin, you guys are amazing :-)

MK

Ayodeji Okanlawon · ‎09-12-2017

MK,

I did reply to your original post. To understand what is going on..Please collect logs for a working call and attach here too. Also collect logs for CUCM for failed and working calls.

Thanks

Please rate all useful posts

pqueued · ‎09-18-2017

Sounds like a capabilities miss-match to me based on this

a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no

From RFC 7261

   However, a problem arises when the value of the annexa or annexb
   parameter does not match in the SDP [RFC4566] offer and answer.

   For example, if the offer has G729 with annexb=yes and the answer has
   G729 with annexb=no, it can be interpreted in two different ways:

   o  The offerer and answerer proceed as if G729 is negotiated with
      annexb=yes, or

   o  The offerer and answerer proceed as if G729 is negotiated with
      annexb=no.

Can you set "Strip G.729 Annex B (Silence Suppression) from Capabilities" in CM Service Parames to "True" and attempt again?

mightyking · ‎09-18-2017

Hi Bakerthjosh,

Thank your for repling.

Changing the value of "Strip G.729 Annex B (Silence Suppression) from Capabilities" to true did not help. I am still having the call termination issue after 5 seconds.

Thanks,

MK