DTMF settings on extension?

What is the meaning of DTMF setting on extension, given that any hardware SIP agent has its own DTMF setting?

Should they always match?

How DTMF affected by having PBXes on "signal path"? Or by "audio bypass"?

Thanks!

This post has been edited 1 time(s), it was last edited by dor on 31.07.2008 at 03:24.

RE: DTMF settings on extension?

In general, there are 3 DTMF transmission methods: In-Band, RFC2833, SIP Info, which I will try to briefly analyze below.

• In-Band transmits the DTMF as an acoustical tone, for which the vocoder should be G.711 in VoIP telephony, otherwise the tones will be distorted or garbled.

Zitat:

If you choose to use the In-Band DTMF signaling method and experience problems with sending DTMF tones you can try to solve this by choosing G.711 as your preferred/default codec. This way your signals will be sent but won't be as compressed as when they are sent with G.729, or more highly compressed codecs. Originally posted at http://www.callcentric.com/faq.php?s_go=...c&go=Search#174

• RFC2833 is one of the two out-of-band transmission methods, and is documented on with its' own RFC. It is a very reliable method, and it should be used any time a compressed vocoder is employed. i.e. G.729, G.723.1, G.726 etc. I recommend using this method for DTMF transmission even when using the G.711 vocoder, since there will most probably be some packet loss on the RTP stream. In Sipura's (Linksys') lingo RFC2833 is called AVT, and only AVT or Info should be activated on these ATAs, otherwise the UA will be producing double digits, which wrecks havoc with IVRs. Unfortunately, it is not currently possible to turn off one or the other on the SPA-9xx phones, and as a result you can't use IVRs from these IP phones.

Zitat:

We recommend sending DTMF through the RFC2833 standard since it provides a more reliable way of transmitting DTMF signals compared to In-Band where compression, especially with highly compressed codecs such as G.729, in combination with poor connection quality can distort DTMF signals and make them unrecognizable. Originally posted at http://www.callcentric.com/faq.php?s_go=...c&go=Search#174

• SIP Info is the second out-of-band transmission method, defined in RFC2976 and its' main drawback is the multiple flavors created by Nortel and Cisco. So when using it for DTMF transmission, there is an ambiguity which flavor is supported on which network element. (i.e. SIP User Agent, SIP Proxy, B2B User Agent, etc.) The following links illustrate the existence of both options in a PSTN gateway, and at least one issue in the Nortel flavor of SIP Info with Asterisk.

Zitat:

This allows you to select whether the Tenor sends a Nortel or Cisco formatted INFO message on outgoing calls. Originally posted at http://www.quintum.com/support/products/...pinfoformat.htm

Zitat:

This SIP INFO message is Nortel proprietary "ping" message that the MCS5xxx uses to check whether or not a call is still active. This message is sent periodically every 5-10 minutes. There is currently no way to disable this "feature" in the MCSes, so the handling of this message must be implemented on the client side. Originally posted at http://bugs.digium.com/view.php?id=5747

In general here are Callcentric's guidelines concerning DTMF transmission:

Zitat:

Here is a short list which explains Callcentric DTMF support for SIP communications: 1 - In-Band: Requires a stable connection and works best with a less compressed codec such as G.711. An unstable connection can still affect DTMF signaling however. 2 - RFC2833/Out of band: Works with any codec, as long as your connection does not suffer from high packet loss/ poor quality 3 - SIP-Info: Not supported at this time. Originally posted at http://www.callcentric.com/faq.php?s_go=...c&go=Search#174

Regarding your questions, ideally the settings on the Extension and the SIP User Agent should match. But Asterisk is also pretty reliable on Auto mode, as long as the DTMF mode is set to a single format on the SIP User Agent. It is also very important to set the DTMF mode properly on the Trunk side, for each and every trunk on your PBXes account.

• If the DTMF mode is set to RFC2833 and the Audio Bypass setting is set to Yes on both the extension & the trunk, since RFC2833 is an out-of-band method of DTMF transmission, the digits should be recognized by the PBXes' SIP Proxy and the trunk's provider's SIP Proxy without any issues, while the RTP packets carrying the voice part will go between the extension & the SIP Proxy of the trunk provider.

• If the DTMF mode is set to In-Band and the Audio Bypass setting is set to No on either the extension or the trunk, since In-Band is an in-band method of DTMF transmission, the digits will be transmitted via the RTP packets carrying the voice part, which will pass through PBXes SIP Proxy & the trunk's provider's SIP Proxy, and will probably be recognized by both if they were not distorted in transit.

• On the other hand, if the DTMF mode is set to In-Band on either the extension or trunk, and the Audio Bypass setting is set to Yes on both the extension & trunk, with In-Band being an in-band method of DTMF transmission, the digits should fail to be recognized by the PBXes' SIP Proxy, since they will be transmitted via the RTP packets carrying the voice part, which will go between the extension & the SIP Proxy of the trunk provider. They should however be recognized by the trunk's provider's SIP Proxy and delivered to the PSTN.

I am sorry for the lengthy post, but to discuss this issue properly, I felt some background notes were required.

RE: DTMF settings on extension?

Thanks for so informative answer. I finally could set it up right.

What's the point to have separate DTMF options on extension and trunks? I'd expect trunk to pass DTMF in a form defined at extension, or vice versa, to set it at trunk, and pass any DTMF from all extensions according to trunk settings...

This post has been edited 1 time(s), it was last edited by dor on 04.08.2008 at 05:40.

RE: DTMF settings on extension?

The short answer to your question is Flexibility.

Each SIP User Agent, might not properly support every method of DTMF transmission. The same applies for every trunk.

So for maximum flexibility you can set the DTMF transmission method on every extension, since DTMF is also needed for calls from the extensions to IVRs, Queues, the Digital Receptionist etc.