Subject: RE: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Thu, 1 Feb 2007 11:38:00 +0100

Hi

I am currently reading and trying to understand the draft, as an example
I take a SDP offer taken from 3GPP TS26.114 version 1.20
http://www.3gpp.org/ftp/Specs/html-info/26114.htm

===========================
m=audio 49152 RTP/AVP 97 98 99 100
a=rtpmap:97 AMR-WB/16000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=rtpmap:98 AMR-WB/16000/1
a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1
a=rtpmap:99 AMR/8000/1
a=fmtp:99 mode-change-capability=2; max-red=220
a=rtpmap:100 AMR/8000/1
a=fmtp:100 mode-change-capability=2; max-red=220; octet-align=1
a=ptime:20
a=maxptime:240
===========================

Using the sdp-capability-negotiation draft I manage to get as far as

===========================
m=audio 49152 RTP/AVP 97 98 
a=creq: v0 
a=capar: 1 a=rtpmap:97 AMR-WB/16000/1
a=capar: 2 a=rtpmap:98 AMR-NB/8000/1
a=capar: 3 a=mode-change-capability=2; max-red=220 
a=capar: 4 a=mode-change-capability=2; max-red=220;  octet-align=1
a=ptime:20
a=maxptime:240 
===========================

I know this is wrong, for instance I don't manage to fit the a=fmtp..
line anywhere, can soembody help ?

Also, what would a response look like ?

Regards
Ingemar

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: den 29 januari 2007 21:50
> To: [email-masked]
> Cc: [email-masked]
> Subject: [MMUSIC] 
> I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-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.
> 
> 	Title		: SDP Capability Negotiation
> 	Author(s)	: F. Andreasen
> 	Filename	: 
> draft-ietf-mmusic-sdp-capability-negotiation-01.txt
> 	Pages		: 29
> 	Date		: 2007-1-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. 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.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capa
> bility-negotiation-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-capability-negotiation-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-capability-negotiation-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: "Robert R. Gilman" <[email-masked]>
Date: Thu, 01 Feb 2007 10:40:59 -0700

Ingemar-
The current draft describes version 0 of the capability negotiation, and
is intended only to satisfy the immediate need for a method to offer choices
of STRP or unencrypted transports.  Our intent is to let it stand alone so
that it may be quickly reviewed, approved, and put into practice.
You didn't say what you wanted to do with the cap negotiation, but, if the
existing SDP is sufficient, then you don't have to do anything. However,
if you're looking for a way to propose configurations that select a subset
of the codecs declared on the m-line, the next docuement in the series
(version 1) will include extensions to the pcfg: attribute to handle the
definition of codecs and formats at the session level which can be referenced
at the media level, along with the codecs declared in the media line.  The
syntax is defined along the lines of an earlier proposal I sent to the list.
We hope to have an initial v1 draft available on this list by Monday.
To speak to this example, assuming I want to propose configurations with
only one of the codecs specified, the SDP might look like:

  a=creq:1
  a=pcfg:1 m=1/2/3/4

The m parameter in the pcfg: attribute specifies the codes by ordinal in the
order they are declared.  Commas are used to group codecs for simultaneous use,
and slashes separate alternatives.  This should all look familiar from the
original -00 draft.  BTW, v1 also includes a method to define codecs outside
of the media line if it's desirable to exclude them from the "default"
configuration implied by the media line itself.
-Bob
----------------------------------------------------
Bob Gilman       [email-masked]      +1 303 538 3868

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Fri, 2 Feb 2007 10:44:57 +0100

Hi

The problem that I (and others?) see is that given all the possible
permutation of codec options, payload format options the SDP's easily
become really huge. It is true that it is possible to compress the SDP
e.g using SigComp but still I find it a bit peculiar.

Ideally I would like to have the possibility to select the various
parameters in the response, sort of like selecting from a "smorgasbord".
As it is in the example below you essentially need to specify a payload
type for each permutation while it should in the case below be enough
with just two payload types at the most (one for AMR and one for
AMR-WB).
I don't know of how much use this is, just that find "these specify by
means of permutations" a bit odd.

Ingemar

> From: Robert R. Gilman [mailto:[email-masked]] 
> Sent: den 1 februari 2007 18:41
> To: Ingemar Johansson S (LU/EAB)
> Cc: [email-masked]
> Subject: Re: [MMUSIC] 
> The current draft describes version 0 of the capability 
> negotiation, and is intended only to satisfy the immediate 
> need for a method to offer choices of STRP or unencrypted 
> transports.  Our intent is to let it stand alone so that it 
> may be quickly reviewed, approved, and put into practice.
> You didn't say what you wanted to do with the cap 
> negotiation, but, if the existing SDP is sufficient, then you 
> don't have to do anything. However, if you're looking for a 
> way to propose configurations that select a subset of the 
> codecs declared on the m-line, the next docuement in the 
> series (version 1) will include extensions to the pcfg: 
> attribute to handle the definition of codecs and formats at 
> the session level which can be referenced at the media level, 
> along with the codecs declared in the media line.  The syntax 
> is defined along the lines of an earlier proposal I sent to the list.
> To speak to this example, assuming I want to propose 
> configurations with only one of the codecs specified, the SDP 
> might look like:
> 
>   a=creq:1
> The m parameter in the pcfg: attribute specifies the codes by 
> ordinal in the order they are declared.  Commas are used to 
> group codecs for simultaneous use, and slashes separate 
> alternatives.  This should all look familiar from the 
> original -00 draft.  BTW, v1 also includes a method to define 
> codecs outside of the media line if it's desirable to exclude 
> them from the "default"
> > I am currently reading and trying to understand the draft, as an 
> > example I take a SDP offer taken from 3GPP TS26.114 version 1.20 
> > a=fmtp:99 mode-change-capability=2; max-red=220 a=rtpmap:100 
> > AMR/8000/1 a=fmtp:100 mode-change-capability=2; max-red=220; 
> > octet-align=1 a=ptime:20 a=maxptime:240 ===========================
> > 
> > a=ptime:20 a=maxptime:240 ===========================
> > 
> >>A New Internet-Draft is available from the on-line Internet-Drafts 
> >>directories.
> announcement, 
> >>session
> initiation. 
> >>SDP was
> widespread 
> >>adoption
> >>        and as a result it has been gradually extended to provide 
> >>limited
> however do 
> >>not have
> >>        the ability to negotiate one or more alternative transport 
> >>protocols
> difficult to 
> >>deploy
> >>        new RTP profiles such as secure RTP or RTP with RTCP-based 
> >>feedback.
> >>
> 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
> >>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-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: "Even, Roni" <[email-masked]>
Date: Fri, 2 Feb 2007 14:44:05 +0200

Hi,
In the purposed work you can specify some configurations of capar=a parmeters and only one payload if you wish so, and then use in the pcfg this payload with diferent a= parameter for each alternative.
pcfg:1 m=1 a=1/ m=1 a=2 ....
 
Roni Even

________________________________

מאת: Ingemar Johansson S (LU/EAB) [mailto:[email-masked]]
נשלח: ו 02/02/2007 11:44
אל: Robert R. Gilman
עותק לידיעה: [email-masked]
נושא: RE: [MMUSIC] I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt

Hi

Ingemar

---

From: "Robert R. Gilman" <[email-masked]>
Date: Fri, 02 Feb 2007 10:31:53 -0700

Ingemar-
Now I understand your point (with Roni's help).  Your example, which
applies to both existing SDP and to our proposals, requires that the
same rtpmap: and fmtp: lines be repeated for each coded/payload type
to which they apply.  You'd like some sort of late binding that could
tie the rtpmap: and fmtp: lines in the pcfg: lines.  Roni gave one
example of how this might be done.  We need to figure out how to
group the codec/attribute associations in such a way that we can also
specify multiple codecs in the same line.  For example, we've talked
about defining codecs with a cmed: attribute like
	a=cmed:1 audio PCMU G729 L16 events
This attribute assigns numbers (1,2,3,4 in this case) to the mime subtypes
listed.  Then we define two additional attributes (much like the rtpmap
and fmtp: attributes) to specify the encoding rates, etc. and any unique
formatting parameters.  Those attributes look like:
	a=cenc:3 16000/2
	a=cfmt:2 annexb:no
where we tied them to the subtype numbers.
Your example would become something like
	a=cmed:1 audio AMR AMR AMR AMR
	a=cfmt:1 mode-change-capability=2; max-red=220
	a=cfmt:2 mode-change-capability=2; max-red=220; octet-align=1
        ...
	a=cenc:1 16000/1
	a=cenc:2 16000/1
	...
	m=audio 49152 RTP/AVP 97 98 99 100
	a=pcfg: m=1|2|3|4

which wouldn't save any space for us.  (We could put the cenc: parameters up
on the cenc: attribute with the mime subtype (e.g., AMR/16000/1) so the
cenc: paramters look just like the rtpmap: parameters, but that's not much
help.)  You'd like to see something like:

	a=cmed:1 AMR
	a=cfmt:1 mode-change-capability=2; max-red=220
	a=cfmt:2 mode-change-capability=2; max-red=220; octet-align=1
	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=2 e=1 pt=98)/(1 f=1 e=2 pt=99)/(1 f=2 e=2 pt=100)

where the f= and e= parameters tie cfmt and cenc lines, respectively, to a
media codec specified in a cmed: line, and the pt= parameter is the associated
payload type.  I've include a default case for those endpoints (or middleboxes)
that don't understand the cap negotiation.
Is this more like what you had in mind?
-Bob
----------------------------------------------------
Bob Gilman       [email-masked]      +1 303 538 3868

Ingemar Johansson S (LU/EAB) wrote:
>>>I know this is wrong, for instance I don't manage to fit 
>>
>>the a=fmtp..
>>
>>Session Control 
>>>>Working Group of the IETF.
>>>>
>>>>/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiatio
> 
> n-01.txt".
> 
>>>>

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Tue, 6 Feb 2007 14:25:32 +0100

Hi

I believe that your example below is pretty much in line with what I am
looking for. 
The purpose is to be able to avoid the numerous repeating of  rtpmap and
fmtp. In some cases this may lead to 
One aditional example with the AMR codecs interacting with a media
gateway is that one can select between several mode-sets and the
different mode-sets must be connected to repeated rtpmap/fmtp like in
the example below possibly there are different combinations between
different mode-sets and mode-change-periods and mode-change-neighbor
leading to a bunch of permutations.
==============
m=audio 49152 RTP/AVP 97 98
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2, \
  mode-change-neighbor=1; mode-change-capability=2; max-red=20
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-set=0,3,5,6; mode-change-period=2, \
  mode-change-neighbor=1; mode-change-capability=2; max-red=20
a=ptime:20
a=maxptime:80
==============

That said it is difficult to say how interesting the options below are,
after all one will need to have some backwards compatibility and that
may easily eat up the gain with the "compressed SDP syntax" below.

Regards
Ingemar 

> Sent: den 2 februari 2007 18:32
> Now I understand your point (with Roni's help).  Your 
> example, which applies to both existing SDP and to our 
> proposals, requires that the same rtpmap: and fmtp: lines be 
> repeated for each coded/payload type to which they apply.  
> You'd like some sort of late binding that could tie the 
> rtpmap: and fmtp: lines in the pcfg: lines.  Roni gave one 
> example of how this might be done.  We need to figure out how 
> to group the codec/attribute associations in such a way that 
> we can also specify multiple codecs in the same line.  For 
> example, we've talked about defining codecs with a cmed: 
> attribute like
> This attribute assigns numbers (1,2,3,4 in this case) to the 
> mime subtypes listed.  Then we define two additional 
> attributes (much like the rtpmap and fmtp: attributes) to 
> specify the encoding rates, etc. and any unique formatting 
> parameters.  Those attributes look like:
> 	a=cenc:3 16000/2
> 	a=cfmt:2 annexb:no
> which wouldn't save any space for us.  (We could put the 
> cenc: parameters up on the cenc: attribute with the mime 
> subtype (e.g., AMR/16000/1) so the
> where the f= and e= parameters tie cfmt and cenc lines, 
> respectively, to a media codec specified in a cmed: line, and 
> the pt= parameter is the associated payload type.  I've 
> include a default case for those endpoints (or middleboxes) 
> > As it is in the example below you essentially need to specify a 
> > payload type for each permutation while it should in the 
> case below be 
> > enough with just two payload types at the most (one for AMR and one 
> > for AMR-WB).
> negotiation, 
> >>and is intended only to satisfy the immediate need for a method to 
> >>offer choices of STRP or unencrypted transports.  Our 
> intent is to let 
> >>it stand alone so that it may be quickly reviewed, 
> approved, and put 
> >>into practice.
> negotiation, but, if 
> >>the existing SDP is sufficient, then you don't have to do anything. 
> >>However, if you're looking for a way to propose configurations that 
> >>select a subset of the codecs declared on the m-line, the next 
> >>docuement in the series (version 1) will include extensions to the 
> >>pcfg:
> >>attribute to handle the definition of codecs and formats at the 
> >>session level which can be referenced at the media level, 
> along with 
> >>the codecs declared in the media line.  The syntax is defined along 
> >>the lines of an earlier proposal I sent to the list.
> >>To speak to this example, assuming I want to propose configurations 
> >>with only one of the codecs specified, the SDP might look like:
> >>
> >>  a=creq:1
> >> octet-align=1  a=ptime:20  a=maxptime:240
> >>  a=pcfg:1 m=1/2/3/4
> >>
> >>The m parameter in the pcfg: attribute specifies the codes 
> by ordinal 
> >>in the order they are declared.  Commas are used to group 
> codecs for 
> >>simultaneous use, and slashes separate alternatives.  This 
> should all 
> >>look familiar from the original -00 draft.  BTW, v1 also includes a 
> >>method to define codecs outside of the media line if it's 
> desirable to 
> >>exclude them from the "default"

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 12 Feb 2007 09:46:40 -0500

Thanks for the comments Colin - responses below.

Colin Perkins wrote:
> On 29 Jan 2007, at 20:50, [email-masked] wrote:
>> This draft is a work item of the Multiparty Multimedia Session 
>> Control Working Group of the IETF.
>>
>>     Filename    : draft-ietf-mmusic-sdp-capability-negotiation-01.txt
>>     Pages        : 29
>>     Date        : 2007-1-29
>>     
>>         multimedia sessions for the purposes of session announcement, 
>> session
>>         invitation, and other forms of multimedia session initiation. 
>> SDP was
>>         negotiation, however over the years, SDP has seen widespread 
>> adoption
>>         support for these. SDP and its current extensions however do 
>> not have
>>         (e.g. RTP profiles) which makes it particularly difficult to 
>> deploy
>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-01.txt 
>>
>
> This draft is in very good shape. I do have some minor and editorial 
> comments, though, to follow on from the discussions in the conference 
> call yesterday:
>
> The "Conventions Used in this Document" section needs to be located 
> after the Introduction, before the current Section 2.
>
Fixed.
> As I mentioned in the call, I find "a=ctrpr" difficult to read and 
> remember. It would be easier if all capability attributes had a common 
> style, perhaps "a=capar" for attributes, "a=ctpar" for transport, and 
> "a=cmpar" for media; or maybe "a=acap", "a=tcap", and "a=mcap"?
>
Changed to "acap" and "tcap" ("mcap" should be used in the media 
capabilities document).
> I was surprised white space was permitted before the <option-tag-list> 
> in "a=csup:" and "a=creq". That seems inconsistent with typical SDP 
> practice.
I know, however I've never understood why you should choke on 
white-space in a text-based protocol, so I prefer to leave it as-is.

>
> In Section 2.2.2 the paragraph starting "When an entity generates an 
> SDP..." says the "a=creq" attribute "MUST be included..., unless". 
> Maybe "SHOULD be included..., unless" is intended?
I believe MUST is correct.
>
> In Section 2.3.1, it would be helpful if the grammar for "a=capar:" 
> could be expressed as ABNF, presumably referencing the "attribute" 
> element from RFC 4566. Similar comments apply to Section 2.3.2 and 2.4.1.
Added proper ABNF throughout
>
> In Section 2.3.1, is white space allowed between "a=capar:" and the 
> <att-cap-num> field? I recommend not, for consistency with other SDP 
> attributes. This will mean the examples later in the draft need to be 
> updated. Similar comments apply for the other new attributes, and the 
> later examples.
White space is allowed - I don't understand why you would want to choke 
on that in a text-based protocol (two wrongs don't make a right)
>
> In Section 2.3.1, can we make the range of <att-cap-num> be 1...2^31-1 
> (both included)? That's still more space than we'll need, and it makes 
> things more efficient for users of a certain programming language. 
> Also in Section 2.3.2 and 2.4.1.
Sure - done. Which programming language are we talking about btw ?
>
> In Section 2.3.1, second paragraph on page 12, <app-cap-num> should be 
> <att-cap-num>?
fixed
>
> In Section 2.3.1, note that the lines of the examples have been 
> wrapped to fit the page, and are single lines in SDP.
added note
>
> In Section 2.4.1, the "|" character is invalid ABNF, "/" is used to 
> specify alternatives. Similar in Section 2.4.2.
>
fixed (2.4.2 as well)
> In Section 3.1, I suggest the example omit the second potential 
> configuration, to show the simplest case, and have a second example 
> with both configurations listed. 
ok
> More examples in general would be helpful.
Agreed - will be added.
>
> The idnits tool also finds a number of nits (the boilerplate will 
> presumably need fixing, or the secretariat will bounce the next version).
Most of the nits have been fixed at this point - remaining ones will be 
fixed before final submission.

Thanks

-- Flemming
>
> idnits 1.124
>
> draft-ietf-mmusic-sdp-capability-negotiation-01.txt:
>
>
>   Checking nits according to http://www.ietf.org/ID-Checklist.html:
>
>     Checking conformance with RFC 3978/3979 boilerplate...
>
>   - This document has ISOC Copyright according to RFC 3978, instead of 
> the
>     newer IETF Trust Copyright according to RFC 4748.  You should 
> consider
>     updating it; the new Copyright statement will be required from 
> February 1st,
>     2007
>   - This document has an original RFC 3978 Section 5.5 Disclaimer, 
> instead of
>     the newer disclaimer which includes the IETF Trust according to 
> RFC 4748.
>     You should consider updating it; the new disclaimer will be 
> required from
>     February 1st, 2007
>   * There are 463 instances of too long lines in the document, the 
> longest one
>     being 5 characters in excess of 72.
>   * There are 16 instances of lines with non-RFC3330-compliant IPv4 
> addresses
>     in the document.  If these are example addresses, they should be 
> changed.
>
>   Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
>   - The page length should not exceed 58 lines per page, but there was 29
>     longer pages, the longest (page 1) being 60 lines
>
>   Miscellaneous warnings:
>     None.
>
>   Experimental warnings:
>   - Missing Reference: 'Section 8' is mentioned on line 930, but not 
> defined
>   - Missing Reference: ' doing so is' is mentioned on line 930, but 
> not defined
>   - Unused Reference: 'RFC2234' is defined on line 1138, but not 
> referenced
>   - Unused Reference: 'RFC3407' is defined on line 1146, but not 
> referenced
>   - Unused Reference: 'RFC3605' is defined on line 1149, but not 
> referenced
>   - Unused Reference: 'RFC2046' is defined on line 1161, but not 
> referenced
>   - Unused Reference: 'RFC2327' is defined on line 1165, but not 
> referenced
>   - Unused Reference: 'RFC3388' is defined on line 1172, but not 
> referenced
>   - Unused Reference: 'RFC3851' is defined on line 1184, but not 
> referenced
>   - Unused Reference: 'RFC4091' is defined on line 1188, but not 
> referenced
>   - Unused Reference: 'BESRTP' is defined on line 1212, but not 
> referenced
>   - Unused Reference: 'SDPCapNegRqts' is defined on line 1221, but not
>     referenced
>   - Unused Reference: 'MIKEY' is defined on line 1228, but not referenced
>
>
> --Colin Perkins
> http://csperkins.org/
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 12 Feb 2007 15:40:10 +0000

On 12 Feb 2007, at 14:46, Flemming Andreasen wrote:
...
>> I was surprised white space was permitted before the <option-tag- 
>> list> in "a=csup:" and "a=creq". That seems inconsistent with  
>> typical SDP practice.
> I know, however I've never understood why you should choke on white- 
> space in a text-based protocol, so I prefer to leave it as-is.

Okay, but at least note the inconsistency, otherwise implementations  
will trip up on it.

>> In Section 2.2.2 the paragraph starting "When an entity generates  
>> an SDP..." says the "a=creq" attribute "MUST be included...,  
>> unless". Maybe "SHOULD be included..., unless" is intended?

Maybe we interpret RFC 2119 differently, but I consider MUST is  
unconditional, and a SHOULD is "MUST... unless".

>> In Section 2.3.1, can we make the range of <att-cap-num> be  
>> 1...2^31-1 (both included)? That's still more space than we'll  
>> need, and it makes things more efficient for users of a certain  
>> programming language. Also in Section 2.3.2 and 2.4.1.

int is 32 bit signed in Java, for example.

Cheers,
Colin