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

From: [email-masked]
Date: Tue, 06 Mar 2007 15:50:03 -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-05.txt
	Pages		: 63
	Date		: 2007-3-6
	
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-05.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-05.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-05.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, 14 Mar 2007 15:39:25 +0100

Fleming, 

thanks for addressing in draft-05 the issue about 
replacement semantics versus additive semantics for the a=acap attribute

that the design team discussed in the last telco before the Prague IETF.

A short recapitulation for those not involved in the telco:
The issue evolved since SDP capability negotiation does not restrict
what a=acap can transport. 
E.g. and offer like the following would be allowed in draft-04
      v=0
      o=- 25678 753849 IN IP4 192.0.2.1
      s=
      t=0 0
      c=IN IP4 lost.example.com
      m=audio 49230 RTP/AVP 96 97
      a=rtpmap:96 L8/8000
      a=rtpmap:97 L16/8000
      a=acap:1 a=rtpmap:97 ILBC
      a=pcfg:1 a=1

Here, the a=acap line repeats the rtpmap attribute from the actual
configuration for payload type 97.
It is not clear whether the m-line  for pcfg:1 includes the rtpmap
attributes
      m=audio 49230 RTP/AVP 96 97
      a=rtpmap:96 L8/8000
      a=rtpmap:97 L16/8000
      a=rtpmap:97 ILBC
or 
      m=audio 49230 RTP/AVP 96 97
      a=rtpmap:96 L8/8000
      a=rtpmap:97 ILBC
Of course the first alternative is ambiguous and something must be done.

I had some problems to understand how draft-05, resolves this.
I believe just replacing the a=pcfg from above with a=pcfg:1 a=/1 is not
correct.
As I understand it, the / operator removes all a=rtpmap lines and the
offer for the potential configuration would get the following m-line 
      m=audio 49230 RTP/AVP 96 97
      a=rtpmap:97 ILBC
Payload type 96 is no longer defined.

Thus the offer must repeat ALL a=rtpmap lines and would have to look
like 
      m=audio 49230 RTP/AVP 96 97
      a=rtpmap:96 L8/8000
      a=rtpmap:97 L16/8000
      a=acap:1 a=rtpmap:97 ILBC
      a=acap:2 a=rtpmap:96 L8/8000
      a=pcfg:1 a=/1,2
or somewhat longer
      m=audio 49230 RTP/AVP 96 97
      a=rtpmap:96 L8/8000
      a=rtpmap:97 L16/8000
      a=acap:1 a=rtpmap
      a=acap:2 a=rtpmap:96 L8/8000
      a=acap:3 a=rtpmap:97 ILBC
      a=pcfg:1 a=-1,2,3

In the end, I think that the replace and delete operators just adds
complexity and do not gain much here.
The whole issue could be resolved if the spec says something like:
"If attributes are common to the actual config and a potential config
all of that attributes in the actual config are deleted. The potential
config must take care that all necessary attributes are restored again."

We would then get back the same syntax from draft-04 and following SDP
offer would a have to be sent
      m=audio 49230 RTP/AVP 96 97
      a=rtpmap:96 L8/8000
      a=rtpmap:97 L16/8000
      a=acap:1 a=rtpmap:96 L8/8000
      a=acap:2 a=rtpmap:97 ILBC
      a=pcfg:1 a=1,2

I doubt as well that the delete operators (-m:, -s:, -1) are necessary.
I can't remember an issue and haven't found an example yet, where the
need arises to explicitly delete an attribute line from the actual offer
from an offer based on a potential configuration. If necessary at all
that could be done as well by an extension to the capability negotiation
framework. The base spec should just mention the potential problem of
conflicting attribute in order to provide some guidance that care must
be taken in this respect.

Kind regards
Thomas 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, March 06, 2007 9:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [MMUSIC] 
> I-DACTION:draft-ietf-mmusic-sdp-capability-negotiation-05.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-05.txt
> 	Pages		: 63
> 	Date		: 2007-3-6
> 	
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> 	"FILE 
> /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-05.txt".
>

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 15 Mar 2007 17:23:13 -0400

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D833210921-15032007><FONT face=3DArial size=3D2>I=20
have&nbsp;two&nbsp;questions for clarification on ICE-14 (an excellent=20
document).</FONT></SPAN></DIV>
<DIV><SPAN class=3D833210921-15032007><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D833210921-15032007><FONT face=3DArial size=3D2>I must =
be missing=20
something about how the base is generated. In 4.1.1.2 (Server Reflexive =
and=20
Relayed Candidates), it concludes by stating that proper operation of =
ICE=20
depends on each base being unique. Section 4.1.1.1 (Host Candidates) =
indicates=20
that the base for each host candidate is set to the candidate itself. =
Section=20
4.1.2.1 (Server Reflexive and Relayed Candidates) states that the base =
of the=20
server reflexive candidate is the host candidate from which the allocate =
or=20
binding request was sent. Would this not result in the same base for the =
host=20
and server reflexive candidates?</FONT></SPAN></DIV>
<DIV><SPAN class=3D833210921-15032007><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D833210921-15032007><FONT face=3DArial size=3D2>The =
second is around=20
the relationship between ICE and ICE Lite. I noticed that ICE has many =
sections=20
devoted to describing ICE Lite operation. These seem to be very similar =
to the=20
procedures defined in ICE Lite. Is the expectation that the ICE Lite =
procedures=20
are removed from ICE once ICE Lite has fully documented=20
them?</FONT></SPAN></DIV>
<DIV><SPAN class=3D833210921-15032007><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D833210921-15032007><FONT face=3DArial=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D833210921-15032007>Kevin=20
Johns</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C76748.327B8310--

--===============0437906264==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============0437906264==--

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 15 Mar 2007 17:23:13 -0400

> Payload type 96 is no longer defined.
Correct.
>       a=acap:3 a=rtpmap:97 ILBC
Or, in this particular case:

      a=pcfg:1 a=-m:1,2

> complexity and do not gain much [email-masked]>
Cc: [email-masked]
Subject: [MMUSIC] Re: draft-ietf-mmusic-sdp-capability-negotiation-05.txt -
 replace/delete operators

> Payload type 96 is no longer defined.
Correct.
>       a=acap:3 a=rtpmap:97 ILBC
Or, in this particular case:

      a=pcfg:1 a=-m:1,2

> config must take care that all necessary attributes are restored again."
For the common case, I don't see much difference between what you 
propose above and what is currently in the spec. You are effectively 
arguing that the REPLACE and DELETE operators should be removed and 
instead, the implementation is responsible for detecting that there are 
rtpmap (or other) attributes in both the actual and potential 
configuration and the implementation is now responsible for deleting 
them, whereas the potential configuration still have to explicitly add 
all necessary rtpmap (or other) attributes to the actual configuration 
that is being selected.

Loosing the DELETE operator would mean that we are no longer able to 
remove attributes with a different name. One example where that is 
needed is when we have different key-management schemes, or the original 
actual configuration is secure RTP and hence uses a keying mechanism, 
whereas the selected one does not (and hence the keying mechanism should 
really be removed).

Loosing the REPLACE operator means that we will now *always* have to 
replace attributes that have the same name. Not necessarily a huge loss, 
but you could have scenarios where that is less than optimal (for 
example if the actual configuration included candidate attributes for 
UDP only, and a potential configuration wanted to add attributes for TCP 
on top of that).

If we want to do something here, then I think we should rather consider 
whether we want to provide more extended replacement semantics for 
"fmtp" and "rtpmap" attributes and effectively say, that only rtpmap and 
fmtp attributes that have the same media format (e.g. payload type) will 
actually be replaced.

> from an offer based on a potential configuration. 
key-mgmt and crypto attributes are examples of those (see e.g. the 
example in Section 4.4). The "global" delete (at either session or 
media-level) is just to make it simpler.

> If necessary at all
Per the above, I think we need these abilities in the base spec. Biggest 
question in my mind is whether we want to make some of them more 
fine-grained, e.g. for rtpmap and fmtp attributes.

-- Flemming

> config must take care that all necessary attributes are restored again."
For the common case, I don't see much difference between what you 
propose above and what is currently in the spec. You are effectively 
arguing that the REPLACE and DELETE operators should be removed and 
instead, the implementation is responsible for detecting that there are 
rtpmap (or other) attributes in both the actual and potential 
configuration and the implementation is now responsible for deleting 
them, whereas the potential configuration still have to explicitly add 
all necessary rtpmap (or other) attributes to the actual configuration 
that is being selected.

Loosing the DELETE operator would mean that we are no longer able to 
remove attributes with a different name. One example where that is 
needed is when we have different key-management schemes, or the original 
actual configuration is secure RTP and hence uses a keying mechanism, 
whereas the selected one does not (and hence the keying mechanism should 
really be removed).

Loosing the REPLACE operator means that we will now *always* have to 
replace attributes that have the same name. Not necessarily a huge loss, 
but you could have scenarios where that is less than optimal (for 
example if the actual configuration included candidate attributes for 
UDP only, and a potential configuration wanted to add attributes for TCP 
on top of that).

If we want to do something here, then I think we should rather consider 
whether we want to provide more extended replacement semantics for 
"fmtp" and "rtpmap" attributes and effectively say, that only rtpmap and 
fmtp attributes that have the same media format (e.g. payload type) will 
actually be replaced.

> from an offer based on a potential configuration. 
key-mgmt and crypto attributes are examples of those (see e.g. the 
example in Section 4.4). The "global" delete (at either session or 
media-level) is just to make it simpler.

> If necessary at all
Per the above, I think we need these abilities in the base spec. Biggest 
question in my mind is whether we want to make some of them more 
fine-grained, e.g. for rtpmap and fmtp attributes.

-- Flemming