DTMF Relay Unrecognized Command in CLI

[aapexisinc]

I'm trying to change the DTMF relay method in a dial-peer and find that the following command is in the dial-peer, but is not recognized by CLI:

voice-class sip dtmf-relay force rtp-nte

CLI goes as far as voice-class sip, but there is no dtmf-relay option.  Is this command actally doing anything, and how do I change it?

[Marcos Hernandez]

To change DTMF relay in a dial peer:

UC520(config)#dial-peer voice 988 voip
UC520(config-dial-peer)#dtmf-relay ?
  cisco-rtp          Cisco Proprietary RTP
  h245-alphanumeric  DTMF Relay via H245 Alphanumeric IE
  h245-signal        DTMF Relay via H245 Signal IE
  rtp-nte            RTP Named Telephone Event RFC 2833
  sip-kpml           DTMF Relay via KPML over SIP SUBCRIBE/NOTIFY
  sip-notify         DTMF Relay via SIP NOTIFY messages

Thanks,

Marcos

[aapexisinc]

I did that, but what if anything, does the other command do?

[Maulik Shah]

voice-class sip dtmf-relay force rtp-nte - this CLI ensure that the UC520 always uses RFC2833 for DTMF even if the provider did not offer RFC2833 in the initial invite. Again this presumes the SIP trunk provider supports RFC2833 which most will as its a fairly common method.

On the question on your provider supporting inband DTMF - inband means different things - can you clarify:

- what is the codec on the SIP trunk side - G711 or G729?

- Does inband mean the digit tone is sent within the voice stream - i.e. as a G711 packet? Or does inband mean the DTMF is sent via RFC2833 which is still an RTP packet but different from a G711 RTP packet

As a general rule using inband DTMF where the digit tone is sent in the voice stream is discouraged on the UC520 and there are certain scenarios where this will not work. The reason is this is a very unreliable mechanism and must use G711 as the voice codec, cannot be G729 - RFC2833 is the strong recommendation.

[aapexisinc]

The codec on the SIP trunk side is G711.  They will pass through the RFC2833 packets, but state that they prefer the G711 packets via the voice stream.  The reason I'm working on this is that the customer periodically will find that DTMF tones are not getting through on a particular call.  Unfortunately, this seems to be random, so I was trying to adjust the DTMF method to agree with the SP.

So, if i wanted to change it to G711 voice-stream packets, what would I do?  And why is that "voice-class sip dtmf-relay force rtp-nte" not recognized in CLI?

[Maulik Shah]

Currently, UC520 cannot take digits from an IP phone and convert that to tones inband on G.711 - this is even more unreliable than RFC2833 as you have any delay etc - the other end may not reliably decode the digit frequencies and cause more issues. The "voice class ...." is a hidden option in CLI. It should work if you type in as is.

[aapexisinc]

Thanks.  Is there anything else I can do to try to isolate and correct the problem?

[Maulik Shah]

Would need some more description of the problem in terms of:

- DTMF failure is intermittent or consistent?

- when the DTMF fails - is it for IP phones outbound or calls inbound to the auto attendant?

- is it for all digits or only specific digits- like if I press 123 - only 12 get sent but 3 does not?

- when this fails we may need to look at debugs - deb voip rtp session named-events / deb ccsip all (log to buffer) and see what digits show up in the log versus what was entered by the user on the phone.

A TAC case maybe more useful if you have not already opened one. Who is the SP by the way?

[aapexisinc]

The SP is IP5280.  Failures are intermittent and unpredictable.  There may be an ocasional failure inbound, although that's much harder to pin down; occasionally someone will report that they pressed a key in response to the autoattendant and nothing happened.  I'm trying to get more info on that.  Outbound the problem is more noticeable; I'm not sure if the problem is specific digits, since it primarily manifests when entering a single-digit response to an autoattendent,  I'll try to get more info on that, though.  Opening a TAC case was next on my list if it couldn't be easily resolved by an obvious configuration change.  Thanks for you help!

[aapexisinc]

More information: the SIP provider claims that they are using inband for DTMF relay, but when I remove the dtmf-relay command (which then supposedly defaults to inband) no tones are sent out at all (although they sound locally).  What's going on here?