[Standards-JIG] Jingle: DTMF

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Fri Feb 17 01:12:00 UTC 2006

Hello Simon,

What a pleasure dealing with civilized posts ;)

You are perfectly right in saying that Jingle is a session setup and
signaling protocol. JEP-167 provide a definition set to establish audio
session using RTP. All the use cases I provided are only related to this
particular context, where the session is a voice session compliant with
There was no assumption, or any intention to 'limit' Jingle to this context
only. Going back to signaling. It can either be in-band (as in IAX or
RTP/RFC2833 or other media transports supporting in-band signaling) or it
can be out-of-band in a dedicated signaling protocol such as Jingle, SIP,
SS7, etc...

In a scenario where we have a party supporting a proper out-of-band
signaling protocol, bridging this advanced protocol to Jingle makes perfect
sense. In the case of Asterisk, I would definitively see something on the
signaling path to map to AGI commands. On the SIP side, I would see
something like CSTA-XML in INFO requests. This is the kind of advanced out
of band signaling I am referring to.

In short, I am 100% with you when you say that it is best to try use the
in-band DTMF whenever possible. And in the case of a client able to do IAX
audio directly, then DTMF will be handled by IAX. 

In the SIP world, the only out-of-band extension to simulate DTMF is
provided by the application/dtmf mime-type transported over INFO requests.
This is mainly a Cisco extension, and this mime type is not registered by
IANA. That said the same Cisco gateways that use this extension, also
support RFC2833. All other drafts related to this subject are expired.

So the real question is more about what kind of out-of-band signaling we
want in Jingle. I believe we need a little more than just simulating the key
press of a phone pad. And I am also saying we should not call this
out-of-band signaling DTMF, because it is misleading and confusing.

Take care


P.S. Your use cases are perfectly valid cases for a native IAX client.
Although the second one describes a complex situation.

-----Original Message-----
Message: 3
Date: Thu, 16 Feb 2006 10:02:11 -0500
From: "Simon Guindon" <simon.guindon at tomahawk.ca>
Subject: RE: [Standards-JIG] RE: Jingle: DTMF 
To: "Jabber protocol discussion list" <standards-jig at jabber.org>
Message-ID: <3E6F9E04F4CF864DBCC3EECB90FDFB502DA2A5 at BART>
Content-Type: text/plain;	charset="us-ascii"

Good morning Jean,

There is 2 real important cases I believe your missing here. Your
assuming the client end is always Jingle (RTP) and it can always do
RFC2833. The client end most definitely may not be a RTP protocol at
all. Jingle in my understanding is meant for media connections in

Let's take into account:
--------    JINGLE     --------            -------  
|IAX   |---------------| GW   |            |      |
|      |---|           --------            | ASTE |
--------   |            IAX                | RISK |
           |-------------------------------|      |---------
(*Please keep in mind JINGLE above is simply signalling for negotiation
not audio)                    

I'm not sure if I've drawn this out properly but your client might be
(in future perhaps) Jingle IAX instead of Jingle Audio. You would send a
Jingle negotiation through XMPP to a gateway that might be a gateway to
asterisk. This gateway might tell you, you can connect to asterisk/peer
direct with IAX. So in this scenario we have no RTP and no Jingle Audio.
IAX has built in DTMF, there is no reason here why we should use

The 2nd possibility I can think of is:
Let's take into account:
--------    JINGLE     --------            -------  
|IAX   |---------------| GW   |            |      |
|      |---|           |      |            | ASTE |
--------   |           |      |            | RISK |
           |-----------|      |------------|      |---------
               IAX     --------    SIP     --------   
(*Please keep in mind JINGLE above is simply signalling for negotiation
not audio) 

Similar case but the Gateway/Asterisk has perhaps told us to call
through the gateway because theres no direct route/compatible format.

Here's basically my case. When *possible* the protocol uses its native
DTMF (which I assume will be 99% of the case) because A. you are either
connecting to the same protocol on the other end, or B. you are being
gatewayed (translated) anyways so the gateway can make the translation
of DTMF.

Where jabber:x:data comes into play is for enhanced feature set.

The only problem I see here is, since I am told SIP has multiple methods
for DTMF it may be a good option to solidify what we choose for this or
else you end up with perhaps what Matt is saying where your now forcing
clients/gateways to support both because you never know what to expect.
Perhaps this is where RFC2833 comes into play?

Thanks and take care,

More information about the Standards mailing list