[Standards-JIG] : Jingle: DTMF

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


Hey man cool down! What have you been smoking? Can't you just properly read
the post before yelling? Isn't it clearly written: If you feel there are
others, please do not hesitate to add to the use cases.

Now just go to this url
http://www.google.com/search?hl=en&lr=&client=opera&rls=en&oi=defmore&defl=e
n&q=define:DTMF and read the definitions for DTMF.

Unless I am mistaking DTMF is using tones transmitted within the media
stream. Therefore, I would argue that DTMF is different from any other
enhanced signaling carried over XMPP/Jingle. This is what I have been saying
all along: there is a need for advanced signaling within Jingle, but this is
NOT DTMF. DTMF is in the media path, NOT the signaling path.

I agree that the first use case is not correct, and should have made clear
the two different path for signaling and media. And from the early JEP-167
audio specification, RTP was the only transport protocol. And if you want
DTMF over RTP, you need RFC2833. This is all I'm saying. 
Jingle does not need any <dtmf/> element trying to simulate DTMF in the
signaling path, when you can implement a much richer signaling set by
extending Jingle with new definitions. 

1/ P2P use case: we use existing standards
--------     JINGLE    --------
|      |---------------|      |
|Jingle|    RFC2833    |Jingle|
|      |---------------|      |
--------     RTP       --------


Jean-Louis


-----Original Message-----
Message: 2
Date: Thu, 16 Feb 2006 07:33:24 -0500
From: Thomas Charron <twaffle at gmail.com>
Subject: Re: [Standards-JIG] RE: Jingle: DTMF
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID:
	<30dfe2a80602160433i9ee3726r240a41d0139b60aa at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On 2/16/06, Jean-Louis Seguineau <jean-louis.seguineau at laposte.net> wrote:
>
> Just to make sure we are on the same page, let me just illustrate the
> different uses cases. If you feel there are others, please do not hesitate
> to add to the use cases.
>
> 1/ P2P use case: we use existing standards
>
> --------    RFC2833    --------
> |Jingle|---------------|Jingle|
> --------     RTP       --------


    there is no Jingle P2P standard at this moment that uses RFC2833, FYI.

2/ SIP/PSTN GW
> 3/ SIP GW
> 4/ IAX GW
>
> --------    JINGLE     --------    IAX     --------  PSTN
> |Jingle|---------------| GW   |------------|      |---------
> |      |---|           --------            | ASTE |
> --------   |            RFC2833            | RISK |  RTP
>            |-------------------------------|      |---------
>                           RTP              --------
>
> In this use case, we are connected to an Asterisk IPBX which understands
> DTMF. The system needs a GW for converting the signaling between Jingle
> and
> the IAX signaling understood by the IPBX.
> The GW only needs to convert the signaling part, and ensure that the
> Jingle
> client and IPBX establish their media stream with each other. For the
> Jingle
> client, the remote party is the IPBX, not the Jingle/IAX GW.
> Once again, we use existing standard protocol for DTMF.


  The IAX protocol itself passes DTMF information right along with the audio
information.  There is no reason why someone who is, say, implementing call
center functionality in a client may not want to implement IAX directly IN
THE CLIENT.

  Why superglue Jingle to RFC2833 when there is no real reason to do so?


> 4/ CSTA GW
>

Note how in every case, the media stream does not go through the GWs, which
> is actually the way it is done in the SIP world. SIP or Jingle in our case
> is only here to establish the session when dealing with legacy DTMF.


  This is not the SIP working group.  This is the XMPP standards list.

  I have an idea.  Go implement it in SIP using SIMPLE!  Becouse that's all
your proposing.

When the remote party provides separate path for media and signaling, such
> as described above, then we only need to map the Jingle signaling part to
> the remote party signaling part. Once a media stream is established, then
> we
> are back to RFC2833 support. And there is no need to advertise it, we just
> need to mandate it.


  And there is also no way to provide enhanced feedback beyond
'0123456789@#'.  This isn't merely to provide gateway capabilities.  Yes,
Jingle needs to support DTMF signalling for PSTN and SIP gateways.  But why
does THAT implementation require we lock down for ANY other additional
capabilities?

  This entire conversation of mandating rfc2833 reminds me of like 10 years
ago when a bunch of us where actually working and mangling what has evolved
into the XMPP protocol itself.

  I'll tell you one thing I learned.  Mandating the use of a 'given way of
doing it' just locks it down.  Many people did amazing work to make the
protocol open and extensible while working it's way thru the IETF, a feat
which I find amazing in and of itself, given the pace the IETF can work at.
And all that work was primarily based around extensibility by namespace.  If
you want 2833, provide a namespace for it's inclusion and use it.  But don't
lock down Jingle with it.

  Thomas




More information about the Standards mailing list