Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-capability-negotiation-07.txt

From: [email-masked]
Date: Mon, 29 Oct 2007 15:15:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title		: SDP Capability Negotiation
	Author(s)	: F. Andreasen
	Filename	: draft-ietf-mmusic-sdp-capability-negotiation-07.txt
	Pages		: 79
	Date		: 2007-10-29
	
The Session Description Protocol (SDP) was intended for describing 
   multimedia sessions for the purposes of session announcement, 
   session invitation, and other forms of multimedia session 
   initiation. SDP was not intended to provide capability indication or 
   capability negotiation, however over the years, SDP has seen 
   widespread adoption and as a result it has been gradually extended 
   to provide limited support for these, notably in the form of the 
   offer/answer model defined in RFC 3264. SDP and its current 
   extensions do not define how to negotiate one or more alternative 
   transport protocols (e.g. RTP profiles) or attributes. This makes it 
   difficult to deploy new RTP profiles such as secure RTP or RTP with 
   RTCP-based feedback, negotiate use of different security keying 
   mechanisms, etc. It also presents problems for some forms of media 
   negotiation.  

   The purpose of this document is to address these shortcomings by 
   extending SDP with capability negotiation parameters and associated 
   offer/answer procedures to use those parameters in a backwards 
   compatible manner.  

   The document defines a general SDP Capability Negotiation framework. 
   It also specifies how to provide attributes and transport protocols 
   as capabilities and negotiate them using the framework. Extensions 
   for other types of capabilities (e.g. media types and media formats) 
   may be provided in other documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-mmusic-sdp-capability-negotiation-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 30 Oct 2007 14:31:55 -0500

Hi Flemming,

There seem to be some inconsistencies with the Best-Effort example in
section 3.2
and the one in section 4.1, which appears to be identical.

Most of the text and SDP is the same, but with some key differences:

- In the first example, the tcap includes RTP/SAVP only (the m-line has
RTP/AVP), but
  in the second example, the tcap includes both RTP/SAVP and RTP/AVP
(even if m-line
  is also RTP/AVP). Is this a typo? Which one is correct?

- In the first example, there is only one Offer/Answer exchange. In the
second
  example, there is a second-round of Offer/Answer exchange to "lock-it
down" to
  a plain SAVP offer for the benefits of middle boxes. Again, which one
is correct?
  PS: Personally, I prefer the first one. I don't see why the we would
need a second
  one for middleboxes, and the single offer/answer should work. And from
a philosophical
  perspective, I don't think we should complicate unduly the protocols
just for the 
  benefits of sub-standard middleboxes...

Can you clarify?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, October 29, 2007 12:15
> To: [email-masked]
> Cc: [email-masked]
> Subject: [MMUSIC] I-D 
> ACTION:draft-ietf-mmusic-sdp-capability-negotiation-07.txt
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Multiparty Multimedia 
> Session Control Working Group of the IETF.
> 
> 	Filename	: 
> draft-ietf-mmusic-sdp-capability-negotiation-07.txt
> 	Pages		: 79
> 	Date		: 2007-10-29
> 	
> To remove yourself from the I-D Announcement list, send a 
> message to [email-masked] with the word 
> unsubscribe in the body of the message. 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 	"FILE 
> /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-07.txt".
> 	
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 30 Oct 2007 22:10:34 -0400

>   is also RTP/AVP). Is this a typo? Which one is correct?
They are both correct. The second example (4.1) includes an extra 
transport protocol capability (RTP/AVP), but doesn't use it in any of 
the potential configurations. In either case, if the potential 
configuration cannot be supported, the (least preferred) actual 
configuration, i.e. the RTP/AVP profile will be negotiated.

>   a plain SAVP offer for the benefits of middle boxes. Again, which one
They are both correct. The second offer/answer exchange is not required 
but recommended when you think there might be a middle-box in place.

The reason the two examples differ is that the 3.1. example is a very 
quick introduction that is trying to give an overview of the key 
concepts in the framework. The section 4 examples are a bit more 
elaborate, however they are all valid.

>   PS: Personally, I prefer the first one. 
I know :-)
> I don't see why the we would
> need a second
We've had that discussion before (look for thread titled "SDPCapNeg 
Issue #6: Second Offer/Answer exchange" on 6/25/07), and the consensus 
was that we did not want to require the second offer/answer exchange, 
however it is still useful to address some potential middlebox issues, 
so we wanted to include it as an option. ICE has a second offer/answer 
exchange (REQUIRED if I recall correctly).

Thanks

-- Flemming