[Standards-JIG] Jingle: DTMF - Zoep

dirk.griffioen@voipster.com dgriffioen at voipster.com
Thu Feb 16 07:50:41 UTC 2006

Hi All,

At danger of going over past the whole Jingle-DTMF discussion, I would 
like to share how Zoep does this.

First I have a remark of Max (one of my collegues):


Complication is in complexity of choosing optimal methods for DTMF
transfer. Currently we are using "inband" approach for DTMF (which is
fine wile working over PCMU or PCMA). There are also another
approaches exists: one transfer signals within signaling protocol
(like SIP), another transferees DTMF in RTP stream while using special
"DTMF codec". In jabber list there is a discussion about DTMF
signaling over Jabber (in context of Jingle) and people thinking of
most convenient and interoperabilitable way for working with DTMF. But
IMHO there is no ideal solution each has own advantages while for
interoperability purposes it is batter to support them all.


We add dtmf tones to the audiostream, thus permitting our client to 
'talk' to dtmf enabled/requiring services. The user command (he/she 
presses a button in the UI) is translated to an XMPP stanza and sent to 
the Zoep engine (the voice subsystem, we have a modular system where 
dlls are loaded dynamically, and toplevel stanzas map to a dll: hence 
the 'voice' tag in the example below: it maps to 'subsystem_voice.dll') 
it is then unpacked, and tones are generated and mixed in.

It looks like this:


      DTMF generation ¶

Generate DTMF tones and sends it to the user specified in the 'to' field.


<voice id='random_id' to='test1002 at jabber.voipster.com/Zoep' type='dtmf' [direction='network|speakers|both']>

The tone_id is selected from the set { 123A456B789C*0#D }.
The tone_duration is the duration of a tone in milliseconds.
The delay in the <tone> is optional and defaults to 0 The (optional) 
delay_duration is the time to wait in milliseconds before starting the 
next tone.
The direction attribute defines where to send generated sound (default - 
to network)


Maybe we could use this for dtmf in the signal traffic? I am not sure. 
Any way, this is what we do now, hopefully this is beneficial ...

Regards, Dirk

Joe Beda wrote:

> I'm not a fan of this proposal but I'm okay with this as long as it 
> isn't required.  The result would be two ways to get DTMF to a client: 
> XMPP and embedded in RTP.  I'd prefer that we only have one way.
> I would be strongly against *requiring* DTMF to be handled in the XMPP 
> because:
> * When gatewaying to other protocols, this would require the media to 
> be proxied/relayed in order to put the DTMF onto the signalling 
> channel. This could raise the bandwidth cost of doing gatewaying 
> dramatically.
> * Keep in mind that the latencies on the XMPP connection could be much 
> higher than the latency on the RTP/P2P channel.  In situations where 
> the timing of the DTMF is critical this could cause problems.
> Joe
> On 2/14/06, *Peter Saint-Andre* <stpeter at jabber.org 
> <mailto:stpeter at jabber.org>> wrote:
>     Hash: SHA1
>     I just read through the older thread on Jingle with PBX etc. My sense
>     right now is that including DTMF [1] as part of the Jingle audio media
>     description format (JEP-0167) would be best. So to send DTMF codes to
>     the other party (which might be an Asterisk server, a voicemail
>     box, an
>     IVR system, or what have you), we'd send Jingle "info" messages with a
>     special Jingle audio payload. Here's an example:
>     <iq from=' juliet at capulet.com <mailto:juliet at capulet.com>'
>     to='voicemail.shakespeare.lit' type='set'>
>       <jingle xmlns='http://jabber.org/protocol/jingle'
>               action='info'
>               initiator='romeo at montague.net/orchard
>     <http://romeo@montague.net/orchard>'
>               sid='a73sjjvkla37jfea'>
>         <dtmf xmlns='http://jabber.org/protocol/jingle/info/audio
>     <http://jabber.org/protocol/jingle/info/audio>'
>               code='1234'/>
>       </jingle>
>     </iq>
>     If a gateway needs to convert that into audio tones or whatever (e.g.,
>     RFC 2833 format for RTP), it could do so, but we'd never send
>     those as
>     audio tones over XMPP.
>     Thoughts?
>     Peter
>     [1] http://margo.student.utwente.nl/el/phone/dtmf.htm is a nice page
>     about DTMF if you're wondering what it is. :-)
>     -----BEGIN PGP SIGNATURE-----
>     Version: GnuPG v1.4.1 (Darwin)
>     Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>     iD8DBQFD8j82NF1RSzyt3NURAgL2AJ91Xw6SZFKSzX/h34/LPNU29wo/ZgCaAok1
>     kB4QMSsnH624WSVydOGCPA0=
>     =zT9M
>     -----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060216/a64be895/attachment.html>

More information about the Standards mailing list