[Standards-JIG] Jingle: DTMF
twaffle at gmail.com
Wed Feb 15 19:49:25 UTC 2006
On 2/15/06, Matthew O'Gorman <ogorman at gmail.com> wrote:
> i can tell you thomas that the majority of sip devices only support inband
> in ulaw or rfc2833 , info digits is the lame duck. and I agree doing inband
> would be very stupid is well. I think the only two reasonable candidates
> are rfc2833 or some xmpp solution. Like I have said before both are fine,
> doing it in rfc2833 is more in tune with sip and makes it easier for
> connecting to sip gateways esp. if your routing traffic like google is,
> however, it is not the jabber way, or at least thats what i think. I don't
> think it really matters which is chosen as they both will work well. I
> think it will put more work on the client developers as they will have to
> implement that part using an rtp stack where as before it is simple xmpp.
> But seriously please just pick one. ^_^
I'm aware. ;-) Personally, I find I mostly use the STP method. In most
telephony environments, this would the the method of choice. However, I can
see how it MAY NOT be the method of choice in other cases.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards