draft-camarillo-sip-sdp-00.txt WAS [Re: [SIP] DTMF discussion from WG meeting]

[Gonzalo Camarillo <[e-mail]>]

Hi,

In the last MMUSIC WG meeting the following draft was presented:
http://search.ietf.org/internet-drafts/draft-camarillo-sip-sdp-00.txt
The slides can be found at:
http://www2.ietf.org/proceedings/00jul/slides/mmusic-sdp-media-alignment.ppt

There were people expresing different opinions and the conclusion was
that further discussion was needed in the mailing list. I believe that
the competence needed to undertake these discussions can be found in
both, MMUSIC and SIP WGs. That's why this mail is sent to both mailing
lists.

A mechanism to allow a single RTP flow to be sent to different UDP ports
was found useful in general, but there were people who did not feel
comfortable about it.

I would like to hear all the problems that this might cause in order to
find the best possible solution.

If finally it is agreed that such as mechanism is needed, we will have
to agree also upon the format to be used. This draft outlines two
possible approaches, one more general and the other "more" backwards
compatible. 

Feedback is very much appreciated,

Thanks,

Gonzalo



"Culpepper, Bert" wrote:
> 
> 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:[e-mail]]
> Sent: Wednesday, August 23, 2000 7:24 PM
> To: Jonathan Rosenberg
> Cc: Culpepper, Bert; [e-mail]
> 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
> [e-mail]
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Gonzalo Camarillo         Phone :  [phone]
Oy L M Ericsson Ab        Mobile:  [phone]
Telecom R&D               Fax   :  [phone]
FIN-02420 Jorvas          Email :  [e-mail]
Finland                   http://www.hut.fi/~gonzalo

_______________________________________________
SIP mailing list
[e-mail]
http://lists.bell-labs.com/mailman/listinfo/sip