DTMF failing inbound for UC560 from SIP provider

[Bart Saling]

Recently our customer's UC560 stop receiving DTMF inbound from SIP trunk.  DTMF works find outbound and on-net.  UC560 has been in production for 5 years.  The SIP provider is asking that Re-Invite be enabled and inbound set to auto.  How do I configure?  Related dial peer is below.

dial-peer voice 3035 voip
description 1703-AA
translation-profile incoming 1703-AA_Called_39
session protocol sipv2
session target sip-server
incoming called-number 6505911703
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
dtmf-relay rtp-nte
ip qos dscp cs5 media
ip qos dscp cs4 signaling
no vad

Thanks.

[Dan Lukes]

I have no experience with UC5xx at all. But according your description of issue and provider's response I assume it's because of codec and/or DTMF method configuration change on provider's side.

A assume he is asking for re-INVITE to be able to re-negotiate codec to an uncompressed one. "Automatic DTMF method" seems to be requested in attempt to support all methods possible.

As far as I know, incoming re-INVITE is accepted, thus there's no configuration change required. I don't know how to configure DTMF method accepted, check Administrator's guide for the appropriate firmware version (you decided to keep secret the version you are using).

Generally, you should consider to configure G.711 codec as the only codec accepted for incoming call. It will allow both RTP and in-band DTMF to pass not distorted to you.

[ADAM CRISP]

DTMF has a tendancy to fail on cisco ios devices if payload 96 is used by the service provider. This is because payload 96 is already used by a cisco fax service.

To fix, move the fax service from 96 to something different

add this to your dial-peer

rtp payload-type cisco-codec-fax-ind 124

just a guess...