RE: [SIP] DTMF discussion from WG meeting

I'm happy with the AVT tone format for transport of DTMF.  I can request
that media type and direct it independently from other media.  I also expect
to be able to use this media format independently and in addition to any
other method for transporting DTMF or other "user input".  If an endpoint
supports both RTP-DTMF and some event reporting mechanism (SUBSCRIBE/NOTIFY)
then I expect I can request either or both.  The associated IDs and RFCs do
not place any limitations on this that I can see.  If there are additional
mechanisms - great.  I like choices.

I do look forward to seeing support for draft-camarillo-sip-sdp-00.txt.  I
think this will encourage support for the transmission of multiple copies of
a media "stream" to different destinations.  And I look forward to support
for terminal events using SUBSCRIBE/NOTIFY.  I think this can help in
addressing concerns with reliable delivery of user input.  Hopefully work in
both of these areas moves along to completion.

Regards,
Bert

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Wednesday, August 23, 2000 7:24 PM
To: Jonathan Rosenberg
Cc: Culpepper, Bert; sip@lists.bell-labs.com
Subject: Re: [SIP] DTMF discussion from WG meeting

At 09:46 PM 8/3/00 , Jonathan Rosenberg wrote:
>Rohan Mahy wrote:
> >
> > Hi,
> >
> > I think we may have a slightly different definition of first and
third
> > party.  I'd say that the moment an app switches from first to
third, it
> > becomes third party and can subscribe to DTMF events.  Perhaps I 
> should > that a first-party cannot *take action* on DTMF events, but
a 
> thrid party
> > should.
> >
> > If a 1st party app subscribes to DTMF events, there is a danger
that it can
> > count the same DTMF event twice (once from RTP, and once from the
event).
>
>Sounds like the kind of nasty things that happen when there are two
>completely different ways to do the same thing. As I suspect you will
>not be able to cleanly define a role as either 1st or 3rd, with a
clean
>changeover during which you would never receive events

I think the definition is crystal clear, and most apps will always be
one 
or the other.  maybe you will like this better:

         If your app will *ever* terminate audio,
         then it must be ready to receive DTMF via AVT tones,
         and must never subscribe to "keypress events"

This leaves "pure" 3rd party apps (of which there are still plenty),
which 
will never, ever terminate any media.  I think that something like
VoXML is 
a good model here.  Send the endpoint a script or document to run.  If
the 
end user does something interesting (press some keys, say something 
intelligable, etc), then execute a URL.  The URL may fetch a new
script, 
contain a REFER, an INVITE, a BYE, a REGISTER, etc...

>sounds like one
>mechanism is the right way to go.

Lots of folks will want a VoXML-like model.  Only ever sending DTMF as
AVT 
tones is limiting and short-sighted IMHO.

thanks,
-rohan

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip