[Standards-JIG] : Jingle: DTMF
twaffle at gmail.com
Fri Feb 17 01:24:08 UTC 2006
On 2/16/06, Jean-Louis Seguineau <jean-louis.seguineau at laposte.net> wrote:
> Hey man cool down! What have you been smoking? Can't you just properly
> 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
> n&q=define:DTMF and read the definitions for DTMF.
> Unless I am mistaking DTMF is using tones transmitted within the media
In the realm of voice, honestly, DTMF means alot more then the technical
definition. DTMF = getting feedback, in the form of 0-9, *, and #.
Therefore, I would argue that DTMF is different from any other
> enhanced signaling carried over XMPP/Jingle.
No, it isn't. I fail to see how it's any different, honestly? The data
it provides is simply limited to 12 individual entries. ;-)
> This is what I have been saying
> all along: there is a need for advanced signaling within Jingle, but this
> NOT DTMF. DTMF is in the media path, NOT the signaling path.
And why is DTMF input in the media path? Becouse, telephony didn't
provide any other way for a user to submit feedback. I'm not saying you are
wrong. I'm saying, using it as the 'insinuated standard method' within a
JEP or RFC.. Well honestly, it doesn't belong there.
> 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 --------
This is true. And I'm not saying it needs a DTMF tag at all. I haven't
said that. As a matter of fact, I've stated just the opposite.
I've said that perhaps there should be an additional mini-JEP for
transmitting the DTMF data in XML form, yes. Face it, higher level
developers are not going to always find libraries to use that can handle
rfc2833 alongside their RTP libraries. Does this mean you lock them out of
handling it at all? Why?
You've documented a possible *implementation*, which I agree, many people
who want to talk to PSTN will end up using.
But we're talking about how this all relates to the documented standard,
and there has to be SOME sort of indication that you want to do what you
diagram above. Just declaring it the default doesn't help foster future
ideas and possibilities, such as using xdata IN PLACE of where, in the past,
you'd use DTMF input.
XMPP = Xml *MESSAGING* and Presence protocol.
SIP = Session Init Protocol.
XMPP 'media' vs 'signaling' is not directly compariable to SIP.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards