Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt

From: [email-masked]
Date: Wed, 21 Feb 2007 10:50:02 -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 media capabilities Negotiation
	Author(s)	: F. Andreasen, et al.
	Filename	: draft-ietf-mmusic-sdp-media-capabilities-01.txt
	Pages		: 22
	Date		: 2007-2-21
	
Session Description Protocol (SDP) capability negotiation provides a
   general framework for negotiating capabilities in SDP.  The base
   framework defines only capabilities for negotiating transport
   protocols and attributes.  In this document, we extend the framework
   by defining media capabilities that can be used to negotiate media
   types and their associated parameters.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-01.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-media-capabilities-01.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-media-capabilities-01.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: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Fri, 23 Feb 2007 15:17:14 +0100

Hi

Reading the draft I have the following simple question 
Would it be possible, based on all the possible attributes given in 
http://tools.ietf.org/id/draft-ietf-avt-rtp-amr-bis-06.txt
to formulate an SDP offer like the one below. 
I am not sure that it is possible to combine several cmft's in the pcfg
in the f=x,y,z.. way that I written below, it is possible that it is
sematically incorrect, anyway comments welcome.
Regards
Ingemar
======================== 
a=creq:v1
a=cmed:1 AMR
a=cfmt:1 mode-change-capability=1;
a=cfmt:2 mode-change-capability=2;
a=cfmt:3 max-red=220;
a=cfmt:4 octet-align=1;
a=cfmt:5 mode-change-neighbor=1; 
a=cfmt:6 mode-change-period=2;
a=cfmt:7 mode-set=0,2,4,7;
a=cfmt:8 mode-set=0,3,5,6;
a=cenc:1 16000/1
a=cenc:2 8000/1
m=audio 49152 RTP/AVP 97
a=rtpmap:97 AMR/16000/1
a=fmtp:97 mode-change-capability=2; max-red=220
pcfg:1 m=(1 f=1,3,7 e=1 pt=98)|(1 f=1,3,8 e=2 pt=99)
pcfg:2 m=(1 f=1,3,4,7 e=1 pt=98)|(1 f=1,3,4,8 e=2 pt=99)
pcfg:3 m=(1 f=2,4,7 e=1 pt=98)|(1 f=2,4,8 e=2 pt=99)
======================== 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: den 21 februari 2007 16:50
> To: [email-masked]
> Cc: [email-masked]
> Subject: [MMUSIC] I-D 
> ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.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-media-capabilities-01.txt
> 	Pages		: 22
> 	Date		: 2007-2-21
> 	
> 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-media-capabilities-01.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: "Robert R. Gilman" <[email-masked]>
Date: Fri, 23 Feb 2007 16:20:58 -0700

Ingemar-
Thanks for your comments.  Let me try to explain the approach we took.
Our intent was to associate each cfmt attribute with a codec in a cmed
attribute, in just the same way that the fmtp attribute is associated
with a codec (via payload type) in the media line.  We didn't consider
a mix-and-match at the codec level within the pcfg attribute.  I'll
most likely mess this up, but I believe the following is equivalent to
your SDP (you didn't seem to use the cmft:5 and cfmt:6 lines in your
description; doing so would cause the following example to perhaps be
even larger):

a=creq:1
a=cmed:1 AMR AMR AMR AMR AMR AMR
a=cmft:1 mode-change-capability=1; max-red-220; mode-set=0,2,4,7
a=cfmt:2 mode-change-capability=1; max-red=220; mode-set=0,3,5,6
a=cfmt:3 mode-change-capability=1; max-red-220; octet-align=1; mode-set=0,2,4,7
a=cfmt:4 mode-change-capability=1; max-red=220; octet-align=1; mode-set=0,3,5,6
a=cfmt:5 mode-change-capability=2; octet-align=1; mode-set=0,2,4,7
a=cfmt:6 mode-change-capability=2; octet-align=1; mode-set=0,3,5,6
a=cenc:1 16000/1
a=cenc:2 8000/1
a=cenc:3 16000/1
a=cenc:4 8000/1
a=cenc:5 16000/1
a=cenc:6 8000/1
m=audio 49152 RTP/AVP 97
a=rtpmap:97 AMR/16000/1
a=fmtp:97 mode-change-capability=2; max-red=220
pcfg:1 m=1|2 pt=1:98,2:99
pcfg:2 m=3|4 pt=3:98,4:99
pcfg:3 m=5|6 pt=5:98,5:99

My version takes about half again as many characters as yours.  There might
be a third way to do this as well - suppose the cfmt and cenc attributes
were applicable to multiple codecs, and multiple lines were applicable to
one codec (equivalent to your assumption).  Then we might say something like:

a=creq:1
a=cmed:1 AMR AMR AMR AMR AMR AMR
a=cenc:1,3,5 16000/1
a=cenc:2,4,6 8000/1
a=cfmt:1,2,3,4 mode-change-capability=1
a=cfmt:5,6 mode-change-capability=2
a=cfmt:1,2,3,5 max-red=220
a=cfmt:3,4,5,6 octet-align=1
a=cfmt:???? mode-change-neighbor=1
a=cfmt:???? mode-change-period=2
a=cfmt:1,3,5 mode-set=0,2,4,7
a=cfmt:2,4,6 mode-set=0,3,5,6
m=audio 49152 RTP/AVP 97
a=rtpmap:97 AMR/16000/1
a=fmtp:97 mode-change-capability=2; max-red=220
pcfg:1 m=1|2 pt=1:98,2:99
pcfg:2 m=3|4 pt=3:98,4:99
pcfg:3 m=5|6 pt=5:98,5:99

This form takes slightly fewer characters than yours (I left in the
two format parameters you didn't seem to use), but I'm not sure which
one is more useful or readable.  Both permit the SDP generator to code
format parameters on multiple lines, rather than force one long line,
but still permit it if desired.  Codecs with lots of formatting parameters
and options are always problematic in capability announcements - unless
you can declare lot of "don't-care" values or use popular defaults.
It seems almost any method will do if there is little reuse of parameters.
What do you think?
-Bob
----------------------------------------------------
Bob Gilman       [email-masked]      +1 303 538 3868

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Mon, 26 Feb 2007 14:54:37 +0100

Hi

And thanks for the reply, in my opinion alternative 2 below is the most
attractive although I must admit that at first glance I did not
understand it at all :-), is it possible to have such an example in a
future version of draft-ietf-mmusic-sdp-media-capabilities or do you
believe that it is too much of a special case ?

I am not sure if I am driving a non-issue her, reason why is simply put
as you point out below that many codecs have an abundance of possible
parameters and in order to offer all permutations can easily produce
really large SDP's esp. if the attributes are not mutually exclusive.

Using SIP compression there is always a possibility that one don't gain
that much by trying to squeeze down the SDP's in this way but this
assumes that the compressor is loaded with the correct glossary. So I
believe that there are benefits from trying to keep the SDP's reasonably
small.

Ingemar

> From: Robert R. Gilman [mailto:[email-masked]] 
> Sent: den 24 februari 2007 00:21
> To: Ingemar Johansson S (LU/EAB)
> Cc: [email-masked]
> Subject: Re: [MMUSIC] I-D 
> Our intent was to associate each cfmt attribute with a codec 
> in a cmed attribute, in just the same way that the fmtp 
> attribute is associated with a codec (via payload type) in 
> the media line.  We didn't consider a mix-and-match at the 
> codec level within the pcfg attribute.  I'll most likely mess 
> this up, but I believe the following is equivalent to your 
> SDP (you didn't seem to use the cmft:5 and cfmt:6 lines in 
> your description; doing so would cause the following example 
> to perhaps be even larger):
> 
> a=creq:1
> My version takes about half again as many characters as 
> yours.  There might be a third way to do this as well - 
> suppose the cfmt and cenc attributes were applicable to 
> multiple codecs, and multiple lines were applicable to one 
> codec (equivalent to your assumption).  Then we might say 
> something like:
> 
> a=creq:1
> This form takes slightly fewer characters than yours (I left 
> in the two format parameters you didn't seem to use), but I'm 
> not sure which one is more useful or readable.  Both permit 
> the SDP generator to code format parameters on multiple 
> lines, rather than force one long line, but still permit it 
> if desired.  Codecs with lots of formatting parameters and 
> options are always problematic in capability announcements - 
> unless you can declare lot of "don't-care" values or use 
> popular defaults.
> > Reading the draft I have the following simple question Would it be 
> > possible, based on all the possible attributes given in 
> > I am not sure that it is possible to combine several cmft's in the 
> > pcfg in the f=x,y,z.. way that I written below, it is 
> possible that it 
> > is sematically incorrect, anyway comments welcome.
> > Regards
> > Ingemar
> > ========================
> > a=creq:v1
> > a=cmed:1 AMR
> message to 
> >>You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> >>logging in, type "cd internet-drafts" and then "get 
> >>draft-ietf-mmusic-sdp-media-capabilities-01.txt".
> >>

---

From: "Robert R. Gilman" <[email-masked]>
Date: Mon, 26 Feb 2007 09:51:49 -0700

Ingemar-
I think it's very likely that we'll adopt one or the other of the
schemes we've been discussing.  We'll certainly have to incorporate
examples in future versions of the media capabilities draft.
I think it's important to minimize bloat in the SDP, insofar as
possible, without the need to resort to compression.
-Bob
----------------------------------------------------
Bob Gilman       [email-masked]      +1 303 538 3868

Ingemar Johansson S (LU/EAB) wrote:
>>Session Control 
>>>>Working Group of the IETF.
>>>>
>>>>  by defining media capabilities that can be used to 
>>
>>negotiate media
>>
>>>>[email-masked] with the word unsubscribe in 
>>
>>the body of 
>>
>>>>the message.
>>>>You can also visit 
>>
>>>>	a MIME-compliant mail reader.  Different MIME-compliant 
>>
>>mail readers
>>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 27 Feb 2007 14:20:51 +0000

> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media- 

My main concern reading this draft is that there is little discussion  
of the requirements, which makes it difficult to evaluate the  
solution. I think the introduction should be greatly expanded to  
include an explicit statement of what is, and is not, in scope.

The introduction states that the document updates RFC 3407. I'm not  
sure that's accurate: surely the base capability negotiation draft  
obsoletes RFC 3407, and this updates the base draft?

In Section 3.2.2 there is an editors note that it might be better to  
combine the a=cmed: and a=cenc: attributes into one, or to add them  
to the a=pcfg: line. I'm not sure this makes sense: remember that  
<fmt> values in an m= line don't necessarily refer to RTP payload  
formats, and may not have meaningful clock rates or encoding parameters.

In Section 3.2.3, what is the rationale for a=cfmt: rather than an  
a=acap: line with an fmtp attribute inside it? That is, rather than:

	a=cmed:1 video h263-1998 h263-2000
	a=cfmt:1 CIF=4;QCIF=2;F=1;K=1
	a=cfmt:2 profile=2;level=2.2
	a=pcfg:1 m=1 pt=1:99
	a=pcfg:2 m=2 pt=2:100

why not use:

	a=mcap:1 video 99 100
	a=acap:1 rtpmap:99 h263-1998
	a=acap:2 fmtp:99 CIF=4;QCIF=2;F=1;K=1
	a=acap:3 rtpmap:99 h263-2000
	a=acap:4 fmtp:100 profile=2;level=2.2
	a=pcfg:1 m=1 a=1,2
	a=pcfg:2 m=2 a=3,4

which introduces only a single new attribute (a=mcap: which takes an  
m= line media type and list of <fmt> values)? Whether or not this  
changes, the rationale should be documented in the draft somewhere.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 27 Feb 2007 16:52:28 +0200

Colin,
Thanks, see inline
Roni

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Tuesday, February 27, 2007 4:21 PM
> To: mmusic WG
> Subject: Re: [MMUSIC]
I-DACTION:draft-ietf-mmusic-sdp-media-capabilities-
> 01.txt
> include an explicit statement of what is, and is not, in scope.

[RE:] There is
draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00.txt that
covers the requirements. This draft addresses the both the base and the
codec negotiation requirements. I am looking at adding some text for the
scope.

> obsoletes RFC 3407, and this updates the base draft?

[RE:] We have it here since RFC3407 addresses the codecs declaration. I
think that until we finish this work we do not have a full update to
RFC3407. 

> formats, and may not have meaningful clock rates or encoding
parameters.

[RE:] We tried to reduce the size of the SDP. I think that Bob suggested
to have both cenc with multiple sequence number for each cenc line so it
can be used for multiple cmed line codecs. Look at the thread with
Ingemar Johansson
 
> changes, the rationale should be documented in the draft somewhere.

[RE:] We can go this way also but I think that we will have more
flexibility with a separate parameter. As an example look at the Ingemar
Johansson email thread, Bob propose to be able to use the cfmt for
multiple codecs parameters. In your example you already assign a payload
type to the fmtp while we wanted to assign the number only in the pcfg
line so we can reuse for multiple streams.

---

From: "Xavier Marjou" <[email-masked]>
Date: Tue, 27 Feb 2007 16:37:29 +0100

> We'll certainly have to incorporate examples in future versions
> of the media capabilities draft.

I agree that examples should be provided either in the draft itself,
or in a companion draft similar to RFC4317, as it may be difficult to
realize all the usages made possible by these extensions.

One example of usage I find important concerns the ptime attibute per
media format (eg: ptime of 20 for PCMU and ptime of 30 for g729). With
sdp-capability-negotiation-03 and sdp-media-capabilities-00.txt, I
understood that it would look like the following lines. (I haven't
check with the latest versions)

a=creq:v1
a=cmed:1 audio PCMU g729
m=audio 3456 RTP/AVP 0 18
a=capar:1 ptime=20
a=capar:2 ptime=30
a=pcfg:1 m=1 a=1 pt=1:0
a=pcfg:2 m=1 a=2 pt=2:18

Xavier