[Standards-JIG] Jingle: DTMF

Thomas Charron twaffle at gmail.com
Wed Feb 15 23:57:05 UTC 2006


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'
    id='disco1'
    to='romeo at montague.net/orchard'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='http://jabber.org/protocol/jingle'/>
    <feature var='http://jabber.org/protocol/jingle/media/audio'/>
    ...
  </query>
</iq>

  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:

  <feature var='http://jabber.org/protocol/jingle/media/stp'/>

  A placeholder for inline DTMF (Inline as in, within jingle info messages):

   <feature var='http://jabber.org/protocol/jingle/media/dtmf'/>

  Or (To make Simon happy):

   <feature var='http://jabber.org/protocol/jingle/media/iax'/>

  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'.

  Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060215/2fadf421/attachment.html>


More information about the Standards mailing list