[cisco-voip] dtmf from cucm to 2821 cube to sip trunk

Tue Nov 17 09:35:59 EST 2009

Each call uses 2 dial peers.  A quick google for "understand inbound
and outbound dial peers" will give you some more information.

For a CUBE, you really want to configure 4 dial peers (although they
can be condensed as 2):

Incoming SIP provider call:
-Incoming dial peer for SIP from provider
-Outgoing dial peer to CUCM for H323/SIP

Outgoing call from CUCM:
-Incoming dial peer for CUCM
-Outgoing dial peer to SIP provider

There are a number of settings that do not make a difference for
incoming dial peers.  For instance, these variables don't play any
effect for an incoming dial peer:
session protocol
destination-pattern
translation-profile outgoing
prefix-digits
voice-class sip profile

These are settings that don't make a difference for outgoing dial peers:
incoming called-number
direct-inward-dial
incoming called-number
answer-address

Hope that clarifies a bit.

-nick

On Mon, Nov 16, 2009 at 6:20 PM, STEVEN CASPER <SCASPER at mtb.com> wrote:
> This has been a very interesting thread .....quick question does a call
> through a CUBE use a total of 2 or 4 dialpeers per call?
>
> Steve
>
>>>> Nick Matthews <matthnick at gmail.com> 10/27/2009 8:49 PM >>>
> So you have a H323-SIP CUBE, and your DTMF isn't working.  This is
> probably the most common problem with CUBE users.
>
> For this #1 problem, the number one cause is 'incoming called-number .'
>
> Most people don't really understand inbound dial peer matching, and
> have used this for ages on normal TDM gateways that were
> single-protocol.  The best way to fix this is to read the 'Understand
> Incoming and Outgoing Dial-Peers" document on Cisco.com, and figuring
> out the best way to match dial peers for both your incoming/outgoing
> SIP/H323 legs.  You can prefix digits and match on incoming called
> number, or ditch incoming called-numbers completely and use
> answer-address.
>
> I like using 'debug voip ccapi inout' to determine this.  You can do a
> search for peer= after you've got the debug to find out which dial
> peers you're hitting for each case, plus what the numbers look like
> after translations, etc.  'debug voip dialpeer' is an alternative, but
> I personally find it more confusing.
>
> For h323-SIP your dial peers should look something like this:
>
> incoming h323 dial peer for outgoing call:  dtmf-relay h245-alpha or
> h245-signal
> outgoing sip dial peer for outgoing call: dtmf-relay rtp-nte
> digit-drop (plus any payload commands required)
> incoming sip dial peer for incoming call: same as sip option above
> outgoing h323 dial peer for incoming call: same as h323 option above
>
> My best guess is that if you look at your incoming/outgoing dial peers
> something isn't matched correctly.
>
> -nick
>
> On Tue, Oct 27, 2009 at 8:17 PM, Dane Newman <dane.newman at gmail.com> wrote:
>> I have a cisco 7975 phone connected to a cucm 7.x --> h323 gateway cisco
>> 2821 --> ITSP sip trunk
>>
>> I am using the CUBE feature on the gateway...DTMF works calling internally
>> to my cisco unity connection voice mail so it is able to be sent.
>>
>> Does anyone have any ideas how I could go about troubleshooting this?
>>
>> Dane
>>
>> On Tue, Oct 27, 2009 at 8:14 PM, Nick Matthews <matthnick at gmail.com>
>> wrote:
>>>
>>> Yes, as long as your debugs are setup correctly (they show output).
>>>
>>> -nick
>>>
>>> On Tue, Oct 27, 2009 at 7:23 PM, Dane Newman <dane.newman at gmail.com>
>>> wrote:
>>> > Thanks for the reply Nick
>>> >
>>> > I debugged voip rtp named-event and when I tried to hit 1 in the call
>>> > for
>>> > dtmf nothing came out of the debug.  Could this possibly mean on my
>>> > side
>>> > Im
>>> > not sending dtmf to the service provider?
>>> > Dane
>>> >
>>> > On Tue, Oct 27, 2009 at 4:30 PM, Nick Matthews <matthnick at gmail.com>
>>> > wrote:
>>> >>
>>> >> That shows up in the debugs in working scenarios too.  Not sure what
>>> >> the importance of those statements are, but it's the type of thing you
>>> >> see when you add 'all' to a debug.
>>> >>
>>> >> It's not the 183 you want to look at, but the 200 OK with the CSeq of
>>> >> your INVITE.  And you want a 200 OK.  I've seen it where the debugs
>>> >> will show that we're sending DTMF but the provider won't use it, which
>>> >> is a conversation you would need to have with the provider.
>>> >>
>>> >> -nick
>>> >>
>>> >> On Tue, Oct 27, 2009 at 3:45 PM, Dane Newman <dane.newman at gmail.com>
>>> >> wrote:
>>> >> > Hmm that does not sound good
>>> >> >
>>> >> > This is with the default settings
>>> >> >
>>> >> > rtp payload-type nte 101
>>> >> > rtp payload-type nse 100
>>> >> >
>>> >> > which don't show up in the config.  Could there be any reason why
>>> >> > the
>>> >> > router
>>> >> > is not able to use 101 below are my dial peers
>>> >> >
>>> >> > dial-peer voice 100 voip
>>> >> >  description AA Publisher
>>> >> >  preference 1
>>> >> >  destination-pattern 1..
>>> >> >  voice-class h323 50
>>> >> >  session target ipv4:10.1.80.10
>>> >> >  dtmf-relay h245-alphanumeric
>>> >> >  codec g711ulaw
>>> >> >  no vad
>>> >> > !
>>> >> > dial-peer voice 1000 voip
>>> >> >  description incoming Call
>>> >> >  translation-profile incoming aa
>>> >> >  preference 1
>>> >> >
>>> >> >  incoming called-number 6784442454
>>> >> >
>>> >> >  dtmf-relay rtp-nte
>>> >> >  codec g711ulaw
>>> >> >  ip qos dscp cs5 media
>>> >> >  ip qos dscp cs5 signaling
>>> >> >  no vad
>>> >> > !
>>> >> > dial-peer voice 101 voip
>>> >> >  description AA Subscriber
>>> >> >  preference 2
>>> >> >  destination-pattern 1..
>>> >> >  voice-class h323 50
>>> >> >  session target ipv4:10.1.80.11
>>> >> >  dtmf-relay h245-alphanumeric
>>> >> >  codec g711ulaw
>>> >> >  no vad
>>> >> > !
>>> >> > dial-peer voice 2000 voip
>>> >> >  description outbound
>>> >> >  translation-profile outgoing addone
>>> >> >  preference 1
>>> >> >  destination-pattern .T
>>> >> >
>>> >> >  progress_ind setup enable 3
>>> >> >  progress_ind progress enable 8
>>> >> >  session protocol sipv2
>>> >> >  session target dns:did.voip.les.net
>>> >> >
>>> >> >  dtmf-relay rtp-nte
>>> >> >  codec g711ulaw
>>> >> >
>>> >> > !
>>> >
>>> >
>>
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> ************************************
> This email may contain privileged and/or confidential information that is
> intended solely for the use of the addressee.  If you are not the intended
> recipient or entity, you are strictly prohibited from disclosing, copying,
> distributing or using any of the information contained in the transmission.
> If you received this communication in error, please contact the sender
> immediately and destroy the material in its entirety, whether electronic or
> hard copy.  This communication may contain nonpublic personal information
> about consumers subject to the restrictions of the Gramm-Leach-Bliley Act
> and the Sarbanes-Oxley Act.  You may not directly or indirectly reuse or
> disclose such information for any purpose other than to provide the services
> for which you are receiving the information.
> There are risks associated with the use of electronic transmission.  The
> sender of this information does not control the method of transmittal or
> service providers and assumes no duty or obligation for the security,
> receipt, or third party interception of this transmission.
> ************************************
>