[cisco-voip] DTMF relay with Verizon SIP Trunk?

Jason Aarons (US) jason.aarons at us.didata.com
Fri May 29 18:34:19 EDT 2009


This is a collection of feedback from various sources and a 5 hour TAC
case this week and should be peer reviewed and researched further (never
take anything I type as the given final word). More importantly this is
for Google next time I go down this path!

 

1.            This was for a Verizon SIP Trunk to 12.4(24)T CUBE
(SIP-SIP) to  CallManager 7.0(2) to UCCX 7.0(1)SR1 to Cisco Agent
Desktop.  Callers couldn't input DTMF in the UCCX aef scripts, Agents
couldn't Transfer blind were symptoms.

2.            In IOS running-cnfig "dtmf-relay rtp-nte" is actually RFC
2833 which encodes the DTMF key presses and other telephony events as
part of the RTP (audio) stream of the SIP call.  RFC2833 is what Verizon
is sending/using.

3.            Dtmf-relay rtp-nte digit-drop requires a MTP resource when
going to UCCX 7x or Unity 7x, it can be a software MTP resource on a
router.  Without MTP resources the menu input options in a aef script
won't capture caller input. Item 3 isn't 100% accurate in every scenario
as there are plenty of devices that support RFC2833 for DTMF (MGCP
gateways if properly configured, IP phones, etc) and thus no MTP would
be required for DTMF negotiation  between those endpoints.   DTMF
negotiation is much like RTP codec negotiation in that if both parties
do not support the same DTMF method than an MTP (or transcoder) is
required to allow the call to proceed.

4.            A 3845 router should be setup for no more than 500
software MTP resources (remember one call has two legs, so it's two
resources per call) and put it its own MRG above CallManager software
MTP resources in your MRGL. The 500 number is CPU dependant, watch your
show proc cpu history. Issue a show sccp all to verify you aren't using
up all the resources.

5.            Don't put a checkmark under Device > Trunk for MTP
Resource  Required, as CallManager 6x/7x will dynamically allocate MTP
resources without it checked.  Otherwise if checked you are forcing
every call to use MTP whether it needs it or not and you likely don't
have enough resources for that (or you are wasting resources
needlessly).

6.            Use codec-passthrough under dspfarm to reduce router CPU
usage;

                dspfarm profile 11 mtp

                codec pass-through

                maximum sessions software 500

 associate application SCCP

7.            Use RTMT to check for Media Resources Exhausted. Use show
sccp all to see how many MTP resources are available on 3845.  Each call
needing a dynamic MTP would use two resources, one for each leg.  So a
3845 with 500 software MTP resources reserved would support 250 calls if
those calls were determined by CallManager dynamically to need a MTP
resource.

8.            Verizon Business SIP dial-peers being used for Fax
Machines  have to use G711 or they will fail with G729 (which is Verizon
default codec).  Best bet is to use local PRI/FXO resources for faxing
or a T38 service or eFax.com, etc. Lots of complaints on Cisco-voip
mailing list and Asterisk Users mailing list about faxing over Verizon
Business SIP trunks. This customer spent 3 days trying to get faxing to
work over Verizon SIP trunk before they setup a FXO interface and routed
faxes out that.

 

I need to research this further as I understood the recommend method is
SIP to CUBE and then CUBE to CallManager as H323, however I inherited
this and not sure anyone did a design recommendation to customer or if
customer pushed this design without experience or research, etc.

 

 

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Erin Mikelson
Sent: Friday, May 29, 2009 5:38 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] DTMF relay with Verizon SIP Trunk?

 

A collegue of mine spent 32 hours on the phone with TAC and Verzion due
to a similar issue.
 
I don't remember the specifics of what he was running into, but in
short, this is what he required:
 
You need 12.4.22(T2)
You need H.323 faststart which requires MTP
You need to configure MTP resources in the router as software
You need to make sure your MRGs are set to use the above MTP and Not any
other hardware transcoders or software MTPs.
 
Good Luck?
 > 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 28 May 2009 12:02:13 -0400
> From: "Jason Aarons (US)" <jason.aarons at us.didata.com>
> To: <cisco-voip at puck.nether.net>
> Subject: [cisco-voip] DTMF relay with Verizon SIP Trunk?
> Message-ID:
> <C1FE15183DA37645BC0633BC604E44F00EF56C88 at USNAEXCH.na.didata.local>
> Content-Type: text/plain; charset="us-ascii"
> 
> I assume this is the correct DTMF relay for a Verizon SIP trunk.
> 
> 
> 
> Using CallManager 7.0(2), no MTP resources, SIP Trunk to CUBE
12.4(24)T
> with SIP to Verizon.
> 
> 
> 
> At first we had below, then I realized DTMF was working;
> 
> dial-peer voice 797 voip
> 
> no dtmf-relay h245-alphanumeric h245-signal cisco-rtp
> 
> dtmf-relay rtp-nte digit-drop
> 
> 
> 
> 
> 
> Does faxing/VG224 have any dtmf-relay requirements? I understand they
> were using rtp-nte digit-drop but changed it for some unknown reason
to
> h245-alphanumic which I understand is only for H323.
> 
> 
> 
> 
> 

________________________________

Hotmail(r) has a new way to see what's up with your friends. Check it
out.
<http://windowslive.com/Tutorial/Hotmail/WhatsNew?ocid=TXT_TAGLM_WL_HM_T
utorial_WhatsNew1_052009> 




-----------------------------------------
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/20090529/acf023eb/attachment.html>


More information about the cisco-voip mailing list