[Standards-JIG] RE: Jingle: DTMF
twaffle at gmail.com
Thu Feb 16 12:33:24 UTC 2006
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 --------
> -------- 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
> the IAX signaling understood by the IPBX.
> The GW only needs to convert the signaling part, and ensure that the
> client and IPBX establish their media stream with each other. For the
> 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
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
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
> 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
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.
Hope it helps
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards