[cisco-voip] SIP trunk one way audio

Mon Nov 15 11:00:32 EST 2010

I am not saying you don't need an MTP. I am saying you don't need to use the
MTP required check box. If an MTP is required it should allocate one from
the MRGL. 

From: Mark Holloway [mailto:mh at markholloway.com] 
Sent: Monday, November 15, 2010 9:59 AM
To: Jason Aarons (US)
Cc: Bill Riley; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] SIP trunk one way audio

Assuming you aren't using a SIP phone load, then when generating a DTMF tone
from the SIP trunk towards a SIP provider and using an out of band method,
the trunk needs the resource to generate the out of band tone. In CUCM 7 if
you don't allocated the MTP to the SIP trunk DTMF does not work. I have not
tried to do this by strictly relying on CUBE, which may supplement it, but
it may also depend if you are using SDP transparency.

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

If using RFC2833 (rtp-nte) which both 7900 SIP LOAD and IOS and Unity
support, why is MTP Required checkmark required technically? What's
happening that needs MTP?

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:34 AM
To: Bill Riley
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] SIP trunk one way audio

Unless you are using inband DTMF it will be required.

On Nov 15, 2010, at 7:07 AM, Bill Riley wrote:

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
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
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
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
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] On Behalf Of Bill Riley
Sent: Friday, 12 November 2010 2:15 AM
To: 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 or contact RACQ on 13 19 05.

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

_______________________________________________
cisco-voip mailing list
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20101115/efbed31c/attachment.html>