<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<META content="MSHTML 6.00.2900.3603" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px">
<DIV>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?</DIV>
<DIV> </DIV>
<DIV>Steve<BR><BR>>>> Nick Matthews <matthnick@gmail.com> 10/27/2009 8:49 PM >>><BR>So you have a H323-SIP CUBE, and your DTMF isn't working. This is<BR>probably the most common problem with CUBE users.<BR><BR>For this #1 problem, the number one cause is 'incoming called-number .'<BR><BR>Most people don't really understand inbound dial peer matching, and<BR>have used this for ages on normal TDM gateways that were<BR>single-protocol. The best way to fix this is to read the 'Understand<BR>Incoming and Outgoing Dial-Peers" document on Cisco.com, and figuring<BR>out the best way to match dial peers for both your incoming/outgoing<BR>SIP/H323 legs. You can prefix digits and match on incoming called<BR>number, or ditch incoming called-numbers completely and use<BR>answer-address.<BR><BR>I like using 'debug voip ccapi inout' to determine this. You can do a<BR>search for peer= after you've got the debug to find out which dial<BR>peers you're hitting for each case, plus what the numbers look like<BR>after translations, etc. 'debug voip dialpeer' is an alternative, but<BR>I personally find it more confusing.<BR><BR>For h323-SIP your dial peers should look something like this:<BR><BR>incoming h323 dial peer for outgoing call: dtmf-relay h245-alpha or h245-signal<BR>outgoing sip dial peer for outgoing call: dtmf-relay rtp-nte<BR>digit-drop (plus any payload commands required)<BR>incoming sip dial peer for incoming call: same as sip option above<BR>outgoing h323 dial peer for incoming call: same as h323 option above<BR><BR>My best guess is that if you look at your incoming/outgoing dial peers<BR>something isn't matched correctly.<BR><BR>-nick<BR><BR>On Tue, Oct 27, 2009 at 8:17 PM, Dane Newman <dane.newman@gmail.com> wrote:<BR>> I have a cisco 7975 phone connected to a cucm 7.x --> h323 gateway cisco<BR>> 2821 --> ITSP sip trunk<BR>><BR>> I am using the CUBE feature on the gateway...DTMF works calling internally<BR>> to my cisco unity connection voice mail so it is able to be sent.<BR>><BR>> Does anyone have any ideas how I could go about troubleshooting this?<BR>><BR>> Dane<BR>><BR>> On Tue, Oct 27, 2009 at 8:14 PM, Nick Matthews <matthnick@gmail.com> wrote:<BR>>><BR>>> Yes, as long as your debugs are setup correctly (they show output).<BR>>><BR>>> -nick<BR>>><BR>>> On Tue, Oct 27, 2009 at 7:23 PM, Dane Newman <dane.newman@gmail.com><BR>>> wrote:<BR>>> > Thanks for the reply Nick<BR>>> ><BR>>> > I debugged voip rtp named-event and when I tried to hit 1 in the call<BR>>> > for<BR>>> > dtmf nothing came out of the debug. Could this possibly mean on my side<BR>>> > Im<BR>>> > not sending dtmf to the service provider?<BR>>> > Dane<BR>>> ><BR>>> > On Tue, Oct 27, 2009 at 4:30 PM, Nick Matthews <matthnick@gmail.com><BR>>> > wrote:<BR>>> >><BR>>> >> That shows up in the debugs in working scenarios too. Not sure what<BR>>> >> the importance of those statements are, but it's the type of thing you<BR>>> >> see when you add 'all' to a debug.<BR>>> >><BR>>> >> It's not the 183 you want to look at, but the 200 OK with the CSeq of<BR>>> >> your INVITE. And you want a 200 OK. I've seen it where the debugs<BR>>> >> will show that we're sending DTMF but the provider won't use it, which<BR>>> >> is a conversation you would need to have with the provider.<BR>>> >><BR>>> >> -nick<BR>>> >><BR>>> >> On Tue, Oct 27, 2009 at 3:45 PM, Dane Newman <dane.newman@gmail.com><BR>>> >> wrote:<BR>>> >> > Hmm that does not sound good<BR>>> >> ><BR>>> >> > This is with the default settings<BR>>> >> ><BR>>> >> > rtp payload-type nte 101<BR>>> >> > rtp payload-type nse 100<BR>>> >> ><BR>>> >> > which don't show up in the config. Could there be any reason why the<BR>>> >> > router<BR>>> >> > is not able to use 101 below are my dial peers<BR>>> >> ><BR>>> >> > dial-peer voice 100 voip<BR>>> >> > description AA Publisher<BR>>> >> > preference 1<BR>>> >> > destination-pattern 1..<BR>>> >> > voice-class h323 50<BR>>> >> > session target ipv4:10.1.80.10<BR>>> >> > dtmf-relay h245-alphanumeric<BR>>> >> > codec g711ulaw<BR>>> >> > no vad<BR>>> >> > !<BR>>> >> > dial-peer voice 1000 voip<BR>>> >> > description incoming Call<BR>>> >> > translation-profile incoming aa<BR>>> >> > preference 1<BR>>> >> ><BR>>> >> > incoming called-number 6784442454<BR>>> >> ><BR>>> >> > dtmf-relay rtp-nte<BR>>> >> > codec g711ulaw<BR>>> >> > ip qos dscp cs5 media<BR>>> >> > ip qos dscp cs5 signaling<BR>>> >> > no vad<BR>>> >> > !<BR>>> >> > dial-peer voice 101 voip<BR>>> >> > description AA Subscriber<BR>>> >> > preference 2<BR>>> >> > destination-pattern 1..<BR>>> >> > voice-class h323 50<BR>>> >> > session target ipv4:10.1.80.11<BR>>> >> > dtmf-relay h245-alphanumeric<BR>>> >> > codec g711ulaw<BR>>> >> > no vad<BR>>> >> > !<BR>>> >> > dial-peer voice 2000 voip<BR>>> >> > description outbound<BR>>> >> > translation-profile outgoing addone<BR>>> >> > preference 1<BR>>> >> > destination-pattern .T<BR>>> >> ><BR>>> >> > progress_ind setup enable 3<BR>>> >> > progress_ind progress enable 8<BR>>> >> > session protocol sipv2<BR>>> >> > session target dns:did.voip.les.net<BR>>> >> ><BR>>> >> > dtmf-relay rtp-nte<BR>>> >> > codec g711ulaw<BR>>> >> ><BR>>> >> > !<BR>>> ><BR>>> ><BR>><BR>><BR>_______________________________________________<BR>cisco-voip mailing list<BR>cisco-voip@puck.nether.net<BR><A href="https://puck.nether.net/mailman/listinfo/cisco">https://puck.nether.net/mailman/listinfo/cisco</A>-voip<BR><BR></DIV><pre>************************************
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.
************************************
</pre></BODY></HTML>