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

From: [email-masked]
Date: Wed, 14 Feb 2007 15:50:01 -0500

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-02.txt
	Pages		: 29
	Date		: 2007-2-14
	
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. SDP and its current extensions however do not have 
   the ability to negotiate one or more alternative transport protocols    (e.g. RTP profiles) which makes it particularly difficult to deploy 
   new RTP profiles such as secure RTP or RTP with RTCP-based feedback. 
   The purpose of this document is to address that and other real-life 
   limitations by extending SDP with capability negotiation parameters 
   and associated offer/answer procedures to use those parameters in a 
   backwards compatible manner.  

   The solution provided in this document provides a general SDP 
   capability negotiation framework. It also defines specifically 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 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-02.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-02.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-02.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: "Stach, Thomas" <[email-masked]>
Date: Wed, 28 Feb 2007 17:39:09 +0100

Fleming,

this looks quite mature.

Just a nit-picking(?) comment on the last paragraph of 3.5.3. 
I propose to explicitly clarify details of the second offer/answer
cycle.
The text in 04 says: "This second offer/answer exchange will not modify
the session in any way".
However the second offer deviates from the previous one. 
Now RFC3264 says in section 8, 3rd para:
   When issuing an offer that modifies the session,
   the "o=" line of the new SDP MUST be identical to that in the
   previous SDP, except that the version in the origin field MUST
   increment by one from the previous SDP.  If the version in the origin
   line does not increment, the SDP MUST be identical to the SDP with
   that version number. ...
   However, the answerer MUST generate a valid
   answer (which MAY be the same as the previous SDP from the answerer,
   or MAY be different), ...

I think its pretty clear that an incremented SDP version number is
required for the offer, but the answer could be the same. Nevertheless
I'd like to spell it out again in draft.

Another small issue is about keying matrial in the SDP. Should it be
repeated in the second offer/answer cycle? 
Well, in case of Sdescription and forking the key(s) from the offer are
distributed to multiple targets. 
This would merit re-keying once the INVITE received a 200OK. Without
forking re-keying wouldn't be necessary.

The added text could look like:
-------------------------------
The second offer/answer cycle MUST be in accordance with RFC3264, this
includes e.g. incrementation of the version number in the offer, but not
necessarily in the answer.
Attribute lines carrying keying material SHOULD repeat the keys from the
previous offer, unless re-keying is necessary for e.g. a previously
forked SIP INVITE request.
-------------------------------

Some nits (from a quick review):
page 17 4th para from the bottom last sentence replace "configs" with
"configurations".
In the examples of 3.5.2.1 I found 4 occurrence of the line
"a=tool:foo". 
Is this intentional? If yes, what does it mean?

Regards
Thomas

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, February 14, 2007 9:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [MMUSIC] 
> I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-02.txt 
> 
> This draft is a work item of the Multiparty Multimedia 
> Session Control Working Group of the IETF.
> 
> 	Filename	: 
> draft-ietf-mmusic-sdp-capability-negotiation-02.txt
> 	Pages		: 29
> 	Date		: 2007-2-14
> 	
>    the ability to negotiate one or more alternative transport 
> protocols    (e.g. RTP profiles) which makes it particularly 
> difficult to deploy 
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> 	"FILE 
> /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-02.txt".
>