[Standards-JIG] : Jingle: DTMF
brian.raymond at je.jfcom.mil
Fri Feb 17 15:51:13 UTC 2006
On 2/17/06 4:05 AM, "Jean-Louis Seguineau"
<jean-louis.seguineau at laposte.net> wrote:
> Hey Thomas, where did you READ that "some people in other threads want to
> insert rfc2833 directly into the Jingle JEP" ?
> Sure you can't 'have any clue' if you just let you imagination take over ;)
> Maybe after all is it just a matter of wording. In the context of JEP-166
> (jingle session/signaling) and JEP-167(jingle audio over RTP) I maintain
> that including direct DTMF support (using tones) in JEP-166 is not the right
> way to 'signal'. It is better off mentioned in JEP-167 using the proper
> payload (I do not really care what the payload is called as long as it is
In the spirit of standards I would follow RFC2833 if you are doing signaling
in the same RTP session, that means a defined payload for DTMF and another
for trunk control and signaling data. I would not use the term in-band
though because that means encoding the tone with the audio codec and not
indicating it in a separate payload as RFC2833 does.
In SIP and H.323 you have to advertise you support RFC2833 because you
really shouldn't just send arbitrary payloads down the wire. The "mention"
should include how to advertise that capability since I do not think it
should be a hard requirement.
> If tomorrow somebody comes up with a JEP for an IAX media session instead of
> RTP, then it will also need to mention the way to do in-band DTMF over IAX.
> I have been saying all along that doing DTMF out-of-band is just a hack.
> Some vendor uses it in their own proprietary extension to SIP. I'm telling
> you Jingle needs a signaling that achieve the same results as in-band DTMF
> and MORE.
As a developer who has written to RFC2833 and what you are referring to as
out-of-band I can tell you it is not a hack and a valuable option to have
when implementing solutions. When I want to send DTMF down the wire without
active media streams or when I need reliable delivery I can do that with
H.245 and Q.931 in H.323
> We are better off creating (or adapting) a richer signaling and describe it
> in a separate JEP. Using the 'info' action from JEP-167 is certainly a good
> fit, and I can bet whatever you wish this action was put here in the first
> place because it was in SIP (and this is perfectly logical)
> In term of signaling and call control, there are 36 verbs in the Asterisk
> AGI that can be invoked remotely; there are over 250 verbs in CSTA to choose
> from and begin building CTI applications. Don't you think this a good
> starting point for a proper out-of-band signaling?
I agree that a richer signaling should be supported, since it provides the
capability to do a number of more advanced features above and beyond DTMF.
One important one I would use is for gateways which I would hop to MGCP for
control along with other robust data.
> P.S. 10 years ago, XMPP a.k.a Jabber was not even in the making ;) Wake up
> to reality.
> -----Original Message-----
> Message: 1
> Date: Thu, 16 Feb 2006 15:38:09 -0500
> From: Thomas Charron <twaffle at gmail.com>
> Subject: Re: [Standards-JIG] Jingle: DTMF - Zoep
> To: Jabber protocol discussion list <standards-jig at jabber.org>
> <30dfe2a80602161238n2e98c45crbd3e87f70ca855cd at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> On 2/16/06, Joe Beda <jbeda at google.com> wrote:
>> I would think that any data could be sent in an 'info'. If the other side
>> doesn't understand it then it can just ignore it or return an error.
>> Similarly, I would assume that extra elements could be included in other
>> jingle stanzas. If you want to signal the ability to do other types of
>> signalling in the context of a session it seems reasonable to do so in the
>> A DTMF protocol could be negotiated (and renegotiated) in this way without
>> impacting the core jingle-audio spec. That being said, it may still make
>> sense to include DTMF over XMPP in jingle-audio anyway.
> *cheer* Exactly. Why some people in other threads want to insert rfc2833
> directly into the JEP I have no clue.
>> As for rfc2833, the ability to send/receive RTP in this format should be
>> specified with a payload-type of 'audio/telephone-event'.
> Hrm. Good point.
More information about the Standards