Subject: [Sipping] Media Description Methodology

From: "Fred Robinson" <[email-masked]>
Date: Mon, 16 Jul 2001 13:28:02 -0600

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

---

From: Gonzalo Camarillo <[email-masked]>
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

-- 
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]