Subject: Re: [Sipping] Media Description Methodology

From: "Fred Robinson" <[email-masked]>
Date: Mon, 06 Aug 2001 13:52:34 -0600

Thanks!

>From: Gonzalo Camarillo <[email-masked]>
>To: Fred Robinson <[email-masked]>
>CC: [email-masked]
>Subject: Re: [Sipping] Media Description Methodology
>Date: Mon, 06 Aug 2001 18:42:11 +0300
>
>Hello,
>
>You can find information about MMUSIC at:
>http://www.ietf.org/html.charters/mmusic-charter.html
>
>Regarding the mailing list (SDPng is discussed there):
>General Discussion:[email-masked]
>To Subscribe: [email-masked]
>Archive: ftp://ftp.isi.edu/confctrl/confctrl.mail
>
>Regards,
>
>Gonzalo
>
>Fred Robinson wrote:
> >
> > Thanks for the input!  Can you give me the subscribe address for either
> > MMUSIC or SDPng?
> >
> > >From: Gonzalo Camarillo <[email-masked]>
> > >To: Fred Robinson <[email-masked]>
> > >CC: [email-masked]
> > >Subject: Re: [Sipping] Media Description Methodology
> > >Date: Mon, 30 Jul 2001 19:28:36 +0300
> > >
> > >Hello,
> > >
> > >The problem you are pointing out is caused by the limited funcionality
> > >of SDP. With a richer session description format, a SIP entity would be
> > >able to send a message indicating that it wants to send media using 
>RTP,
> > >send certain commands using HTTP and use RTSP to control the playout of
> > >messages, for instance.
> > >
> > >However, SDP does not allow this. In the first place, when there are
> > >several m lines in an SDP session description, it is impossible to know
> > >how they relate to each other. (The FID draft in MMUSIC resolves this
> > >problem in a small number of scenarios, but is is not a general 
>solution
> > >that would resolve all the exisint problems related to grouping).
> > >
> > >Therefore, what applications do right now is to assume that the other
> > >party knows what this session is about and what to do with it. For
> > >example, an application server might assume that when it receives an
> > >INVITE, an additional side channel using HTTP will be established.
> > >However, the INVITE did not carry any information about this side
> > >channel. The same way, a TTS device can assume that if it receives an
> > >SDP session with two m lines, one for voice and one for text, it should
> > >translate one into the other.
> > >
> > >I believe that the discussion you are proposing could be very useful,
> > >but it might be more related to SDPng that to SIPPING.
> > >
> > >Best regards,
> > >
> > >Gonzalo
> > >
> > >Fred Robinson wrote:
> > > >
> > > > After reviewing the SIP archives, and the recent post from van Wijk
> > > > regarding "SIP Support for Hearing and Speech Impaired Users,"
> > > > draft-vanwijk-sipping-deaf-req-00.txt, I would like to stir a
> > >discussion, if
> > > > I may, on the carriage of media description in SIP.
> > > >
> > > > >From the archives, I noted that in "An Application Server Component
> > > > Architecture for SIP," draft-rosenberg-sip-app-components-01.txt,
> > >Rosenberg,
> > > > et. al., the use of http GET is suggested as the method to request
> > >scipted
> > > > responses, eg., IVR Prompt Playing, and/or services to be executed, 
>eg.,
> > >TTS
> > > > translation.  In "SIP Support for...," van Wijk, et. al., the 
>examples
> > >seem
> > > > to suggest that IVR and/or TTS instructions shall be passed in the 
>SDP.
> > > > However, in Rosenberg, et. al., the latter method is not 
>recommended.
> > > >
> > > > Fishing for clarity;
> > > >         - Are there changing attitudes about the proper/acceptable
> > >manner to pass
> > > > media descriptions in SIP, since Rosenberg, et. al., March 2001?
> > > >         - Is SDP the proper MIME body to carry media descriptions 
>for
> > >services such
> > > > as IVR, TTS, Conferencing, Speech Recognition, etc.?
> > > >
> > > > This is a subject of utmost importance to work I am currently 
>involved
> > >in,
> > > > your candor is tremendously appreciated!
> > > >
> > > > Fred Robinson
> > > > Sr. Systems Engineer
> > > > SandCherry networks
> > > > 2845 Wilderness Pl.
> > > > Boulder, CO 80301
> > > > 720.562.4523
> > > > [email-masked]
> > > > http://www.sandcherry.com/
> > > >
> > > > _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at http://explorer.msn.com
> > > >
> > > > _______________________________________________
> > > > Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP
> > > > Use [email-masked] for questions on current sip
> > > > Use [email-masked] for new developments of core SIP
> > >
> > >--
> > >Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> > >Columbia University                  Mobile:  +358 40 702 35 35
> > >472 Computer Science Building        Fax   :  +358  9 299 30 52
> > >1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> > >New York, NY 10027
> > >USA                              [email-masked]
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
>
>--
>Gonzalo Camarillo                    Phone :   +1 212 939 71 71
>Columbia University                  Mobile:  +358 40 702 35 35
>472 Computer Science Building        Fax   :  +358  9 299 30 52
>1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
>New York, NY 10027
>USA                              [email-masked]
>
>_______________________________________________
>Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments of core SIP

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP