[cisco-voip] DTMF tone

[Anthony Holloway]

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, 2014 at 4:26 AM, costas georgiou <ckos1976 at hotmail.com>wrote:

> Hi all,
>
> I have a customer who says a handfull of users are having difficulties
> accessing an IVR externally.  When they dial the number, they get the
> message "press 1 for this etc" but the DTMF tone does not always work so
> they use their mobiles.  They are running on an H323 gateway.  It already
> has the voice rtp send-recv command globally.  Below is aa liat of the
> dial-peers.  Will the DTMF command need to be on the outgoing Dial-peers?
>
> dial-peer voice 1 pots
>  description *** Default inbound Dial-peer ***
>  incoming called-number .T
>  direct-inward-dial
> !
> dial-peer voice 100 pots
>  description *** Outbound PSTN Dial Peer ***
>  preference 1
>  destination-pattern 9T
>  progress_ind setup enable 3
>  progress_ind alert enable 8
>  progress_ind progress enable 8
>  progress_ind disconnect enable 8
>  port 0/0/0:15
> !
> dial-peer voice 200 voip
>  description *** Inbound VOIP Dial peer to CUCM ***
>  preference 1
>  destination-pattern 272..
>  session target ipv4:x.x.x.x
>  voice-class codec 1
>  voice-class h323 1
>  dtmf-relay h245-alphanumeric rtp-nte
>  ip qos dscp cs3 signaling
>  no vad
> !
> dial-peer voice 201 voip
>  description *** Inbound VOIP Dial peer to CUCM ***
>  preference 2
>  destination-pattern 272..
>  session target ipv4:x.x.x.x
>  voice-class codec 1
>  voice-class h323 1
>  dtmf-relay h245-alphanumeric rtp-nte
>  ip qos dscp cs3 signaling
>  no vad
> !
> dial-peer voice 202 voip
>  description *** Inbound VOIP Dial peer to CUCM ***
>  preference 3
>  destination-pattern 272..
>  session target ipv4:x.x.x.x
>  voice-class codec 1
>  voice-class h323 1
>  dtmf-relay h245-alphanumeric rtp-nte
>  ip qos dscp cs3 signaling
>  no vad
> !
> dial-peer voice 2 voip
>  description *** Inbound VOIP Dial peer FROM CUCM ***
>  incoming called-number .T
>  voice-class codec 1
>  voice-class h323 1
>  dtmf-relay h245-alphanumeric rtp-nte
>  ip qos dscp cs3 signaling
>  no vad
> !
> Thanks
>
> Cos
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140514/658efc4d/attachment.html>