[Standards-JIG] Jingle: DTMF

Thomas Charron twaffle at gmail.com
Thu Feb 16 03:16:43 UTC 2006


On 2/15/06, Simon <simon at nureality.ca> wrote:
>
> 1. People want to maintain using p2p if possible, and not tie all calls to
> go through a gateway simply to translate XMPP INFO to legacy DTMF formats
> (so not all calls/bandwidth go through the server).
> 2. Concern over 2 "methods" thus meaning a split and the community being
> worse off.
> I'm not sure the proper term but this system is proposing the protocol in
> use to use its existing DTMF support as a base requirement.
> This means hooking into legacy systems you can never need to worry about
> ever having to handle jabber:x:data support.
> If your an IAX or SIP client this means you use your existing protocols
> DTMF method, but you have the OPTION of using jabber:x:data for a more
> feature rich experience.
> Let's say your calling 12345 at pstn.jabber.org which goes to PSTN. your
> response back might look like:
> <feature var='http://jabber.org/protocol/jingle/media/rtp'/ <http://>>
> <feature var='http://jabber.org/protocol/jingle/media/dtmf'/ <http://>>
> <feature var='http://jabber.org/protocol/jingle/media/dtmf'/ <http://>>
> will be a baseline support for DTMF on jingle platform. This means if your
> connecting via SIP you use SIP's method of DTMF, if your on IAX you use
> IAX's built in DTMF.
>


  Hrm, I hadn't thought about it this way.  I don't think assumption would
work.  You couldn't differentiate when talking with Simons super cool
advanced client when it reported:

<feature var='http://jabber.org/protocol/jingle/media/rtp'/ <http:///>>
 <feature var='http://jabber.org/protocol/jingle/media/iax'/ <http:///>>
 <feature var='http://jabber.org/protocol/jingle/media/dtmf'/ <http:///>>

  This is why I wrote them as:

 <feature var='http://jabber.org/protocol/jingle/media/rtp'/ <http:///>>
<feature var='http://jabber.org/protocol/jingle/media/stp'/ <http:///>>
 <feature var='http://jabber.org/protocol/jingle/media/iax'/ <http:///>>
  <feature var='http://jabber.org/protocol/jingle/media/dtmf'/ <http:///>>

  In a way, the current reference to <feature var='
http://jabber.org/protocol/jingle/media/audio'/ <http:///>> could simply
infer 'rtp' as well.  But, as there are no current clients with DTMF support
to my knowledge, just:

<feature var='http://jabber.org/protocol/jingle/media/audio'/ <http:///>>

  means that no sort of intraction is supported.  Now, Google decides to
add, say, IAX support to their client:

<feature var='http://jabber.org/protocol/jingle/media/audio'/ <http:///>>
<feature var='http://jabber.org/protocol/jingle/media/iax'/ <http:///>>

  Or perhaps sending DTMF over XMPP:

<feature var='http://jabber.org/protocol/jingle/media/audio'/ <http:///>>
<feature var='http://jabber.org/protocol/jingle/media/dtmf'/ <http:///>>
<feature var='http://jabber.org/protocol/jingle/media/iax'/ <http:///>>

 Basically, the dtmf namespace is current 'undefined', but would basically
be very simplistic to say 'I can send you 0-9, *, or #.'  One would assume
it would also include some sort of sequence information as well, just in
case.  ;-)

If you are IAX you may receive:
> <feature var='http://jabber.org/protocol/jingle/media/iax'/ <http://>>
>  <feature var='http://jabber.org/protocol/jingle/media/dtmf'/ <http://>>
> In the case I connect to a gateway to translate to say Jingle Audio or SIP
> etc its the gateways responsibility to translate IAX's DTMF to SIP or Jingle
> Audio DTMF.
>

  I think the only place where we seperate is the inference of the dtmf
namespace to infer that it use whatever signaling goes 'hand in hand' with
the given audio type.

Now in the case of fancy jim bob's voicemail server component, say
> voicemail at jabber.org, it might support jabber:x:data so you can represent
> your voicemail box via gui to listen/delete voice messages, when you send a
> jingle request to voicemail at jabber.org you may get a response such as:
>
>  <feature var='http://jabber.org/protocol/jingle/media/iax'/ <http://>>
>  <feature var='http://jabber.org/protocol/jingle/media/dtmf'/ <http://>>
> <feature var='jabber:x:data'/>
> Now we got something here. The voicemail service supports jabber:x:data.
> Now we can do so much more!
>

  That's what sounds really nice.  Being able to present much richer
content.  0123456789*# is NOT rich content..  ;-)

Now what does everyone think of this?
>

  I think that the sky is blue becouse it isn't green.

One other issue after speaking to Matt. Now that we have a way to detect to
> use a protocols "built in DTMF" or enhanced jabber:x:data, from what I
> understand Jingle Audio/SIP actually don't have 1 set way to do DTMF. The
> concern here is if we support both, everyone will have to implement both
> because you never know what you might get. So what do we do about this?
>

  The baseline of the dtmf namespace, which, as I said, provides a simple,
but obviously lacking interface.  In most cases, I suspect SIP centric
individuals with use their RTPish solution.


> This means when you recieve:
> <feature var='http://jabber.org/protocol/jingle/media/dtmf'/ <http://>>
> with SIP or Jingle Audio specified, which DTMF method do they use as their
> "built in DTMF" for that identified feature?
>

  Dunno if we agree on that, but I see where you're getting the idea,
becouse IAX contains DTMF along with audio data, right there.  I would
assume on receipt of

<feature var='http://jabber.org/protocol/jingle/media/iax'/ <http:///>>

  and I decided to use it, DTMF usage within iax is infered.  The same
assumption can't be made with RTP, becouse it could be done with audio
encoding directly into the stream (OMFG, Blechblechblech), or using the so
often mentioned rfc (I dont have the number in front of me.  Sue me).

I want to thank Thomas and Matt for their time spent with me today on this
> topic.
>

  That's ok, I'm keeping track.  Are we gonna 1099 this, or W2?  ;-)

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


More information about the Standards mailing list