[cisco-voip] SIP trunk one way audio

Mon Nov 15 13:48:40 EST 2010

Having implemented and designed many systems with SIP to CUCM, there are mainly two reasons that one requires MTP for SIP:

1.       DTMF.   However, today, most items with CUCM support RFC2833 - including phones, Unity, even MGCP gateways have commands to support it.  One also needs to validate that which is configured on CUCM maps to what is configured on the gateway - if using Cisco  VGs.

2.       EO support.  CUCM (this changes in 8.5) requires MTP for Early offers.  Many providers require EO for outbound calls.  Up to this point, the only way to send EO from CUCM has been MTP required.  This also has locked in your codec selection.   Inbound CUCM supports both EO and DO, without MTP required being checked - however you may need an MTP for varying ptimes, codec translation or DTMF conversion.

One way to get around requiring MTP on CUCM is by using CUBE.  If you are in flow through mode, you can make use of the DO to EO conversion.  Simply, one is just tying down the media stream to an IP/port that can be sent.  Think of it as H323 fast start.
Now if one requires MTP or even has it in your MRGL - validate the MTP type being used supports what you are trying to achieve.  Not all MTPs are created equal nor are they recommend in every scenario.

I should mention there is one more reason that we have seen - transfers and conferences sometimes require MTP with SIP based calls.

Lastly, any known bugs need to be dealt with - whether in IOS or CUCM.

Cheers,

Bob

www.dimensiondata.com

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Mark Holloway
Sent: Monday, November 15, 2010 10:27 AM
To: Jason Aarons (US)
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] SIP trunk one way audio

If I remember right, CUCM 7 did not include a payload type in the SDP portion of the SIP Invite when placing a call to the PSTN through the SIP Trunk. I am going to investigate it and if I can gather some good debugs I may even blog about it just so it's documented somewhere.

On Nov 15, 2010, at 8:47 AM, Jason Aarons (US) wrote:

Recent deployment with CUCM 8.0(3a) and IOS 15.1(2)T in almost identical setup (Device > Trunk > 3900e/SIP but with PRIs) I found calls were not setting up without MTP Required checked.  I don't think it should be required, nor did I want it required, I have not had time to look into ccmtraces on why I needed the checkmark.

Maybe I'm missing something, but I agree MTP Required is usually bad and should be avoided where possible, or explained why it was checked in technical detail.

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Bill Riley
Sent: Monday, November 15, 2010 9:08 AM
To: 'Mark Holloway'
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] SIP trunk one way audio

I don't think that's correct. It needs access to an MTP but you shouldn't need to use the MTP required checkbox on the trunk.

From: Mark Holloway [mailto:mh at markholloway.com]
Sent: Friday, November 12, 2010 12:24 PM
To: Bill Riley
Cc: 'Ryan Ratliff'; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] SIP trunk one way audio

CUCM needs it assigned to the trunk for DTMF to work properly for calls egressing the SIP Trunk.

On Nov 12, 2010, at 10:50 AM, Bill Riley wrote:

I don't think that is correct. It should only need to have one available in the MRGL, not one allocated every time a call comes in.

voice service voip
ip address trusted list
  ipv4 x.x.x.x
  ipv4 x.x.x.x
  ipv4 x.x.x.x
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
fax protocol t38 nse force version 0 ls-redundancy 0 hs-redundancy 0 fallback none
h323
modem passthrough nse codec g711ulaw
sip
  bind control source-interface Serial0/0/0:1
  bind media source-interface Serial0/0/0:1
  early-offer forced
  midcall-signaling passthru
!

voice class codec 100
codec preference 1 g711ulaw
codec preference 2 g729r8
!
!
dial-peer voice 201 voip
preference 1
destination-pattern 91[2-9]..[2-9]......
rtp payload-type cisco-codec-fax-ind 98
rtp payload-type comfort-noise 13
session protocol sipv2
session target ipv4: x.x.x.x
dtmf-relay rtp-nte
codec g711ulaw
fax rate 14400
ip qos dscp cs3 signaling
!
dial-peer voice 202 voip
preference 1
destination-pattern 9[2-9]......T
rtp payload-type cisco-codec-fax-ind 98
rtp payload-type comfort-noise 13
session protocol sipv2
session target ipv4: x.x.x.x
dtmf-relay rtp-nte
codec g711ulaw
fax rate 14400
ip qos dscp ef signaling
!
dial-peer voice 203 voip
preference 1
destination-pattern ^9556[2-9]......
rtp payload-type cisco-codec-fax-ind 98
rtp payload-type comfort-noise 13
session protocol sipv2
session target ipv4: x.x.x.x
dtmf-relay rtp-nte
codec g711ulaw
fax rate 14400
ip qos dscp ef signaling
!
dial-peer voice 204 voip
preference 1
destination-pattern 9555[2-9]......
rtp payload-type cisco-codec-fax-ind 98
rtp payload-type comfort-noise 13
session protocol sipv2
session target ipv4: x.x.x.x
dtmf-relay rtp-nte
fax rate 14400
ip qos dscp ef signaling
!
dial-peer voice 411 voip
preference 1
destination-pattern 5555555..
rtp payload-type cisco-codec-fax-ind 98
rtp payload-type comfort-noise 13
session protocol sipv2
session target ipv4: x.x.x.x
dtmf-relay rtp-nte
codec g711ulaw
fax rate 14400
ip qos dscp cs3 signaling
!
dial-peer voice 412 voip
preference 2
destination-pattern 5555555..
rtp payload-type cisco-codec-fax-ind 98
rtp payload-type comfort-noise 13
session protocol sipv2
session target ipv4: x.x.x.x
dtmf-relay rtp-nte
codec g711ulaw
fax rate 14400
ip qos dscp cs3 signaling
!
dial-peer voice 413 voip
preference 3
destination-pattern 5555555..
rtp payload-type cisco-codec-fax-ind 98
rtp payload-type comfort-noise 13
session protocol sipv2
session target ipv4: x.x.x.x
dtmf-relay rtp-nte
codec g711ulaw
fax rate 14400
ip qos dscp cs3 signaling

From: Mark Holloway [mailto:mh at markholloway.com]
Sent: Friday, November 12, 2010 11:32 AM
To: Bill Riley
Cc: 'Ryan Ratliff'; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] SIP trunk one way audio

You should have it on the trunk.

On Nov 12, 2010, at 10:29 AM, Bill Riley wrote:

Your right, but I don't need to have the check box to require one on the trunk. It should allocate one from the MRGL on an as needed basis.

From: Mark Holloway [mailto:mh at markholloway.com]
Sent: Friday, November 12, 2010 11:28 AM
To: Bill Riley
Cc: 'Ryan Ratliff'; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] SIP trunk one way audio

You should be using an MTP for your SIP trunk to support DTMF. It does not need to be a hardware MTP resource.

On Nov 12, 2010, at 10:05 AM, Bill Riley wrote:

When I change it to MTP required on the sip trunk everything works as expected. The point is that I shouldn't need to have this configuration.

From: Ryan Ratliff [mailto:rratliff at cisco.com]
Sent: Friday, November 12, 2010 9:00 AM
To: Bill Riley
Cc: 'Cheng, Karen'; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] SIP trunk one way audio

I see lots of discussion around config and call flow but have you actually done any troubleshooting?  One way audio most of the time comes down to the simple fact that one party is not receiving RTP from the other.   For these one-way audio calls you need to determine what IP addresses are involved.  Next verify this in the signaling via the SDPs in the SIP messages.   You can then use show commands on the router to confirm where it thinks it should be sending and receiving RTP to/from and if in fact packet counters are incrementing.

If no MTP is being used for the call, try forcing it to use one and see if that fixes the issue.
If you are using media flow-through (default) does changing it to flow-around fix the issue?

-Ryan

On Nov 12, 2010, at 8:09 AM, Bill Riley wrote:

I shouldn't need an MTP for this connection. All SIP traffic is sourced from one interface.  I do have SCCP traffic sourced from a different interface but it is only used for a conference bridge, not MTP.

From: Cheng, Karen [mailto:Karen.Cheng at racq.com.au]
Sent: Thursday, November 11, 2010 9:14 PM
To: 'Bill Riley'
Subject: RE: [cisco-voip] SIP trunk one way audio

Not sure if you have checked already but is your SIP trunk using one interface and your MTP/SCCP interface a different interface?

I had one-way audio/no audio problems ages back due to this because our integrator had configured the SIP trunk to point to int gi0/0's IP and then configured the SCCP interface to loopback0.

Regards

Karen Cheng
Voice Network Engineer

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Bill Riley
Sent: Friday, 12 November 2010 2:15 AM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] SIP trunk one way audio

I have a new SIP trunk terminating in a 2921 CUBE bundle. When I call in from the Trunk directly to an IP phone it works correctly. If I call from the trunk to IP phone and the IP phone transfers the call without waiting for the remote party to answer I get one way audio. From reading this looks like and MTP issue but I have an MTP set in the MRGL for the trunk.

75% of inspected vehicle have a defect*. Call 13 1905 and book an RACQ Vehicle Inspection today. *Based on the RACQ Vehicle Defect Report January 2008

Please Note: If you are not the intended recipient, please delete this email as its use is prohibited. RACQ does not warrant or represent that this email is free from viruses or defects. If you do not wish to receive any further commercial electronic messages from RACQ please e-mail unsubscribe at racq.com.au<mailto:unsubscribe at racq.com.au> or contact RACQ on 13 19 05.
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

________________________________

Disclaimer: This e-mail communication and any attachments may contain confidential and privileged information and is for use by the designated addressee(s) named above only. If you are not the intended addressee, you are hereby notified that you have received this communication in error and that any use or reproduction of this email or its contents is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you.

-----------------------------------------
Disclaimer:

This e-mail communication and any attachments may contain
confidential and privileged information and is for use by the
designated addressee(s) named above only.  If you are not the
intended addressee, you are hereby notified that you have received
this communication in error and that any use or reproduction of
this email or its contents is strictly prohibited and may be
unlawful.  If you have received this communication in error, please
notify us immediately by replying to this message and deleting it
from your computer. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20101115/57077a3e/attachment.html>