[Standards-JIG] Jingle: DTMF - Zoep

Joe Beda jbeda at google.com
Thu Feb 16 18:52:55 UTC 2006

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.

As for rfc2833, the ability to send/receive RTP in this format should be
specified with a payload-type of 'audio/telephone-event'.


On 2/16/06, Thomas Charron <twaffle at gmail.com> wrote:
> On 2/16/06, dirk.griffioen at voipster.com <dgriffioen at voipster.com > wrote:
> >
> > 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):
> >
> > Hello,
> > 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.
> >
> >   This is why I'd like to see the 'INFO' messages that the Jingle spec
> refers to as being flushed out, allow a payload of many namespaces.  One of
> the basic, for DTMF, would be a simple DTMF-like payload that you use as an
> example.  Additionally, it could very well contain a xdata form to fill out
> and be returned.
>   Also, for things such as rfc2833, it's simply a feature that a client
> supports.  Figure it out during feature negotiation, and perhaps say
> specifically that it's what you intend to use when you set up the call.
> > Thomas
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060216/c92a8679/attachment.html>

More information about the Standards mailing list