[cisco-voip] DTMF tone

[Anthony Holloway]

Ok so it looks like I was mistaken. TranslatorX is not showing what was
negotiated, rather what was advertised. However, in this case, your H323
side does have both OOB and IB and your SIP side has OOB. That should mean
no MTP.

What do you see for a good call? I wonder if it will be RFC2833 for the end
point side or not. Which, if it is, the DTMF would go directly between the
two end points of the call, just as the RTP media does. Land that's because
RFC2833 is RTP, just with a payload type of 101 as opposed to G711 with a
payload type of 0 and G729 is 18.

Whether that's the case or not, did you consider the SRND and H245
signaling as your relay? That could be there for inter working reasons just
like this one: SIP to H323.

On Thursday, May 15, 2014, costas georgiou <ckos1976 at hotmail.com> wrote:

> Hi Anthony,
>
> I have installed I took CUCM trace and used Translator X, when  I scroll
> down to the bottom, under DTMF Method Originator details i see: (3) Out of
> Band and RFC2833.
> Under Destination details i see:(1) Out of Band (KPML / NOTIFY)
>
> This is on a call that did not work when being asked to press 1 for etc..
>
> Regards
>
> Costas
>
> ------------------------------
> Date: Wed, 14 May 2014 10:38:24 -0500
> Subject: Re: [cisco-voip] DTMF tone
> From: avholloway+cisco-voip at gmail.com<javascript:_e(%7B%7D,'cvml','avholloway%2Bcisco-voip at gmail.com');>
> To: ckos1976 at hotmail.com<javascript:_e(%7B%7D,'cvml','ckos1976 at hotmail.com');>
> CC: cisco-voip at puck.nether.net<javascript:_e(%7B%7D,'cvml','cisco-voip at puck.nether.net');>
>
> First and foremost, you cannot have DTMF relay on a POTS dial peer.  DTMF
> relay is for IP networks.  On the POTS side, the DSP will turn the DTMF
> relay from CUCM (H.245 alphanumeric) or the endpoint (RTP-NTE) into actual
> audio.
>
> Source:
> http://www.cisco.com/c/en/us/td/docs/ios/voice/command/reference/vr_book/vr_d2.html#wp1449003
>
> The command voice rtp send-recv command only helps for calls to the PSTN
> where the IVR is in the cloud and occurs before the ISDN connect message.
>  This is also referred to as early media.  Is that what's happening on your
> bad IVR calls?
>
> Source:
> http://docwiki.cisco.com/wiki/Cisco_IOS_Voice_Troubleshooting_and_Monitoring_--_H.323_Gateway_Troubleshooting#No_DTMF_Digits_or_Audio_Passed_on_VoIP_Calls_to_PSTN_or_PBX
>
> I see that your incoming dial peer from CUCM (incoming called-number .T)
> has a voice-class h323 1 on it, but you did not include the details for it.
>  Also, you don't need .T you only need . for the incoming called-number
> command.  Could you show us your h323 class config?
>
> Source:
> http://docwiki.cisco.com/wiki/Cisco_IOS_Voice_Troubleshooting_and_Monitoring_--_Call_Flow_Overview#Inbound_Dial_Peer_Matching
>
> Also, consider pulling CallManager traces to see which DTMF relay was
> negotiated on both good and bad calls, since you have both out of band and
> in band specified.  This will help to determine where the problem could be,
> because out of band DTMF relay takes a different path and has different
> device dependencies than does in band.  If you haven't used TranslatorX
> yet, it's awesome and you should.  Drag and drop your trace files in to it,
> click the Call List button, filter and find your bad call, double click it,
> and then scroll to the bottom of the summary page and it will tell you the
> DTMF negotiation.
>
> Source: http://translatorx.cisco.com/
>
> Since you do have both out of band and in band, I would suspect MTP's are
> being inserted to correct DTMF relay, but your traces would confirm if good
> calls are using MTPs and bad calls are not.  CUCM will save a call which
> failed to allocate an MTP by default, but you run the risk of diminished
> supplementary services such as DTMF.
>
> This is from the CUCM 8x SRND (you didn't say which version of CUCM you
> have):
>
> FYI The reference to NTE is the same as rtp-nte
>
> DTMF Relay on H.323 Gateways and Cisco Unified Border Element
>
> H.323 gateways support DTMF relay via H.245 Alphanumeric, H.245 Signal,
> NTE, and audio in the media stream. The NTE option must not be used because
> it is not supported on Unified CM for H.323 gateways at this time. The
> preferred option is H.245 Signal. MTPs are required for establishing calls
> to an H.323 gateway if the other endpoint does not have signaling
> capability in common with Unified CM. For example, a Cisco Unified IP Phone
> 7960 running the SIP stack supports only NTEs, so an MTP is needed with an
> H.323 gateway.
>
>
> Source:
> http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/8x/uc8x/media.html#wpmkr1130352
>
> Summary:
>
>    1. No DTMF relay on POTS dial peers
>    2. incoming called-number .
>    3. show run | section h323 1
>    4. CCM Traces to confirm DTMF relay negoatiation
>    5. CCM Traces to confirm MTP (or XCODER) allocation
>    6. Should use H.245 signaling and not H245 alphanumeric and no rtp-nte
>    according to SRND
>
> I hope that was helpful.  Sorry there wasn't an easy answer to your query,
> but DTMF relay, if not designed for, can be a roll of the dice.
>
>
> On Wed, May 14, 201
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140515/112a1b0c/attachment.html>