[Standards-JIG] Jingle: DTMF
simon at nureality.ca
Thu Feb 16 01:08:20 UTC 2006
Ok I'm also going to comment on this since Thomas and I just finished hashing this out ;)
I'm just going to rehash in another manner just so people don't misunderstand what this is proposing.
I see 2 issues at the moment with using XMPPP INFO in the ways prior to this email.
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/dtmf'/> 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.
If you are IAX you may receive:
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.
This basically ensures all existing libraries on both ends are compatible.
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:
Now we got something here. The voicemail service supports jabber:x:data. Now we can do so much more!
I guess my bottom line is, this system allows all existing legacy systems to cooperate without having to know any XMPP to handle DTMF. It allows the p2p connections to continue as well without having to gateway.
Now what does everyone think of this?
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?
This means when you recieve:
with SIP or Jingle Audio specified, which DTMF method do they use as their "built in DTMF" for that identified feature?
Anyways hope I was clear.
I want to thank Thomas and Matt for their time spent with me today on this topic.
Thanks and Take care,
----- Original Message -----
From: Thomas Charron
To: Jabber protocol discussion list
Sent: Wednesday, February 15, 2006 6:57 PM
Subject: Re: [Standards-JIG] Jingle: DTMF
On 2/15/06, Thomas Charron <twaffle at gmail.com> wrote:
An example would be when these 'inputs' AREN'T just DTMF content. We're in a situation with Jingle where we can define that it CAN do more then JUST DTMF. I think a better comparison would be grammers within VoiceXML. Why limit it to JUST DTMF? Sure, DTMF is going to be the prefered method for PSTN gateways, SIP gateways, etc, but why limit Jingle based on the notions imposed by other technologies. In the case of a gateway, only 0-9, #, and * would make any sense, but why NOT allow a person contacting, say, a customer service rep over jingle the ability to respond with a string or the such? Granted, this would more then likely occur over the XMPP stream via other JEP documented methods, but why not allow those existing JEP's to function hand in hand WITH Jingle. Why couldn't the equiv of an INFO message contain.... Hold it now.. A reference to another namespace documented by a different JEP.
After having some conversations, let me clarify what I'm talking about here.
During setup of a jingle call, a negotiation takes place. Below is an example:
<iq from='juliet at capulet.com/balcony'
to='romeo at montague.net/orchard'
<feature var='http://jabber.org/protocol/jingle'/ >
Now, this list of 'features', for all practical purposes, states that I can handle Jingle Audio. Perhaps this turns into a new JEP, as done this way, it kind of would be a new JEP. But let me finish while it's fresh in my hear.
Why not <feature var='http://jabber.org/protocol/jingle/media/rtp'/> ?
Bear with me.
If this was the case, you could also say:
A placeholder for inline DTMF (Inline as in, within jingle info messages):
Or (To make Simon happy):
One of the reasons I'm thinking this approach out is this. Perhaps I have a customer service line, that I make accessible via Jingle Perhaps I'm jabbering (no pub intended) with the CS Rep, and I have a question about my account. Typically, an IVR or the such would have requested this data via DTMF. Now, in a 'Brave New World', why couldn't the obviously XMPP aware application, say, send me a Jingle INFO message, with a jabber:x:data request attached?
See, I guess I'm looking at whatever info messages are going to be as basically being iq type packets specifically dealing with the audio session.
So, why can't that contain any number of namespaces?
A 'XMPP rich', say, IVR application, could decide 'Hey, they support data forms!. Instead of making them trudge thu this legacy DTMF menu, I can present a feature rich menu that allows them to nagiate easier!
I guess I'm actually looking at things from a standpoint of a VoiceXML developer, which I've done alot of as of late. Grammers are used in VoiceXML to work hand in hand with ASR platforms to deliver 'voice feature rich' IVR applications. In the context of Jingle, this is simular, but different, as the data isn't just voice, but actualy XML data that can be passed around.
So back to what I suggested earlier. Providing information via DTMF turns into a mini jep. A client simply says it supports it A server simply says it supports it. Or, quite possibly, it says it supports recieving of data in STP. Or, even JEP-0004 forms.
Isn't this method more inline with the 'intent' of XMPP? Why does it need require any sort of customization of jingle itself?
Just allow the jingle messages to use whatever features where negotiated in the first place!
Much of this message is a result of thinking aloud. Please, clear it up and let's talk about it. This method just seems to be in the best intrest of future extensibility without nailing Jingle down to what amounts to a 'DTMF Legacy Protocol'.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards