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

[STEVEN CASPER]

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.
************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091116/bd0fbbc7/attachment.html>