Subject: [MMUSIC] comments on draft-ietf-mmusic-capability-negotiation

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Mar 2007 14:31:26 -0400

I haven't had the cycles to participate in this effort at all, so here
is a 'cold' review of this document. Overall, I think its pretty good,
but I find the complexity level high, and I think that there is a
conceptual model of how it works that is missing from the document.

Specific comments:

Abstract: it reads as if its a solution just for negotiating transports
but its more than that. Maybe state the security case as just an
example. Also abstract is a bit too long, rfc-ed may bounce.

> Such restrictions are not generally acceptable to multimedia session
>  invitations, where two or more entities attempt to establish a media
>  session that uses a set of media stream parameters acceptable to all
>  participants.

I take issue with the 'not generally acceptable'. The fact is that basic
offer/answer works for most cases, and this draft is trying to address
those cases where it has known weaknesses. THis paragraph makes it sound
like rfc3264 just doesnt work, but it does.

> o  A set of capabilities for the session and its associated media 
> stream components, supported by each side.
> 
> o  A set of potential configurations indicating which combinations of
>  those capabilities can be used for the session and its associated 
> media stream components.
> 
> o  An actual configuration for the session and its associated media 
> stream components, which specifies which combinations of session 
> parameters and media stream components to use and with what 
> parameters.
> 
> o  A negotiation process that takes the set of potential 
> configurations (combinations of capabilities) as input and provides
> the actual configurations as output.

examples of a capability, a potential config and an actual config would
help.

> Other relevant extensions have been defined. Simple capability 
> declarations, which define how to provide a simple and limited set of
>  capability descriptions in SDP was defined in RFC 3407.

add reference

> semantics than the traditional "simultaneous media streams" 
> semantics, was defined in RFC 3388, etc.

add reference

> capability negotiation was initiated [SDPng].  SDPng however has not
>  gained traction and has remained as work in progress for an extended
>  period of time.

beacuse it requires a forklift, both sides must support it. Worth noting
that, and that we need something which can be made backwards compatible,
falling back to something sensible when the other side doesnt do it.

> o  A new attribute ("a=csup") that lists the supported base and 
> extension options to the framework.

why do you have to say whether you support the base?

> 3.1. Solution Overview  
> 
>    The solution consists of the following: 

The solution overview dived into details on the attributes and I felt
was missing a conceptual model of what was going on. In my head,I had
this picture which perhaps will be useful in the document:

      Please view in a fixed-width font such as Courier.

       +---------+    +---------+   +---------+
     ............................................
      .|1: RTP/  |    |1: alg1, |.  |1: G711, | .Potential
     . |   AVP   |    |   key1  | . |   G729  | .Config 1
     ............................................
       |         |    |        .|  .|         |
       |         |    |         .   .............
       |         |    |         .   |         | .
       |2: RTP/  |    |2. alg2, |.  |2.G711.  | .Potential
       |   SAVP  |    |   key2  | . |  G.723  | .Config 2
       |         |    |         |  ..............
       |         |    |         |   |         |
       |         |    |         |   |         |
       |         |    |         |   |         |
     .............................................
     . |3. RTP/  |    |         |   |3.ilBC   |  .Potential
     . |   AVPF  |    |         |   |         |  .Config 3
     .............................................
       |         |    |         |   |         |
       |         |    |         |   |         |
       +---------+    +---------+   +---------+

        Transport     Crypto         Codec
        Caps          Attribute      Caps
                      Caps

So the idea is that there are a set of orthogonal capabilities - one
orthogonal axis for transport capabilities, one for crypto attributes,
one for other attributes, and you can add more in future specs, like
codecs, IP address, etc. Then, a potential config is a slice through eah
of these orthogonal sets, describing a specific value for each
capability, taking zero or one values from each orthogonal cap, and
giving that potential config a number. Each potential config is almost
like an alternate offer as defined in rfc3264; it represents something
else you could have sent that would have been a valid offer.

If thats correct, I suggest including something along those lines.

>     v=0 
>       o=- 25678 753849 IN IP4 192.0.2.1 
>       s=  
>       c=IN IP4 192.0.2.1 
>       t=0 0 
>       m=audio 53456 RTP/AVP 0 18  
> 
>  
>  
> Andreasen             Expires September 4, 2007                [Page 7] 
> 
> Internet-Draft        SDP Capability Negotiation             March 2007 
>     
> 
>       a=tcap:1 RTP/SAVP  
>       a=acap:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32    
>          inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32  
>       a=pcfg:1 t=1 a=1   

from the description text it sounded like you always needed an a=csup
attribute listing the base framework but maybe I have misunderstood.

Also, in terms of naming, 'tcap' has another well-defined meaning in our
world. SOmeone might interpret this to mean that your phone can tunnel
tcap messages in sdp....

>  a=crypto:1 AES_CM_128_HMAC_SHA1_80 
>             inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
>       a=acfg:1 t=1 a=1 

hmm, the fact that you have to include the t=1 and a=1 tells me that my
view on the model is wrong. If a potential config each had a number
which represented what could have been a valid offer, then I would only
need to indicate the potential config number in the acfg attribute. So
I'm missing something fundamental here.

>   att-value         = option-tag-list 
>       option-tag-list   = option-tag *(COMMA option-tag) 
>       option-tag        = token    ; defined in [RFC4566] 
>       COMMA             = ","      ; defined in [RFC4234] 
> 
>    Implementers familiar with the Session Initiation Protocol (SIP) 
>    should note that the above definition of COMMA differs from the one 
>    in [RFC3261].  

suggest just:

option-tag-list = option-tag *("," option-tag)

so there is no confusion.

>  The "a=csup" attribute can be provided at the session and the media-
>    level. When provided at the session-level, it applies to the entire 
>    SDP. When provided at the media-level, it applies to the media 
>    description in question only (option-tags provided at the session 
>    level apply as well). 

so does this mean you can use this on some media streams in a session,
but not others?

>  supports at the session and/or media-level, unless those option tags 
>    are already provided in one or more "a=creq" attribute (see Section 
>    3.3.2. ) at the relevant levels. The base option tag MAY be included.  

why only MAY? Maybe I don't understand how you expect to use these. If
this is like SUpported/Require then it needs to be much stronger.

>  implied by the presence of an "a=pcfg" attribute (see Section 3.5.1. 
>    ) and hence there is no need to include the "a=creq" attribute with 
>    the base option-tag ("cap-v0"). Still, it is allowed to do so.  

so if there is no use case for it, drop it. If you have a case where its
needed, explain it. Seems like you could have some 3pcc cases for this,
similar ones showed up in ICE.

>  When an entity generates an SDP and it requires the recipient of that 
>    SDP to support one or more SDP capability negotiation extensions in 
>    order to properly process the SDP Capability negotiation, the 
>    "a=creq" attribute MUST be included with option-tags that identify 
>    the required extensions at the session and/or media level, unless it 
>    is already known that the receiving entity supports those option-tags 
>    at the relevant levels (in which case their inclusion is OPTIONAL).  

we don't have this exclusion for REquire in SIP - seems dangerous given
3pcc can do odd things to your knowledge about what the recipient is doing.

> A recipient that receives an SDP and does not support one or more of 
>    the required extensions listed in a "creq" attribute, MUST NOT 
>    perform the SDP capability negotiation defined in this document. 

Worth pointing out that this mechanism assumes that the recipient
supports the capability negotiation in the first place; if it doesn't
you'll fall back to no capability negotiation at all of course.

>     This ensures that introduction of the SDP capability negotiation 
>      mechanism does not introduce any new failure scenarios.  

There are always new failure scenarios. THis just allows for fallback
mechanisms to be put into place.

>  The <att-cap-num> values provided are independent of similar <cap-
>    num> values provided for other types of capabilities, i.e., they form 
>    a separate name-space for attribute capabilities.  

I disagree with this. I think this makes it confusing about how one
cosnstructs a potential capability, since now this becomes one or more
combinations of acap values. It then introduces error cases where a
potential configuration includes a set of attributes that could not
themselves appear standalone in an offer. Per my picture above, I think
it makes sense to view each capability as an orthogonal axis, and that
you always pick one value from each axis - just one. So then for each
attribute name you'd have a separate namespace.

> The "tcap" attribute can be provided at the session- and media-level. 
>    There can be multiple "tcap" attributes at the session-level as well 
>    as within each media description. Each occurrence of the "tcap" 
>    attribute in the entire session description MUST use a different 
>    value of <trpr-cap-num>.  When multiple <proto> values are provided, 
>    the first one is associated with the value <trpr-cap-num>, the second 
>    one with the value one higher, etc. 

SO, what is the difference between:

a=tcap:1 RTP/AVP
a=tacp:2 RTP/AVPF

and

a=tcap:1 RTP/AVP RTP/AVPF

and why do you need both.

>     This may seem redundant (and indeed it is from the offerer's point 
>      of view), however it is done to protect against middle-boxes that 
>      may modify "m=" lines while passing unknown attributes through. If 
>      an implicit transport capability were used instead (e.g. a reserved 
>      transport capability number could be used to refer to the transport 
>      protocol in the "m=" line), and a middle-box were to modify the 
>      transport protocol in the "m=" line (e.g. to translate between 
>      plain RTP and secure RTP), then the potential configuration 
>      referencing that implicit transport capability may no longer be 
>      correct. With explicit capabilities, we avoid this pitfall, 
>      although the potential configuration preference (see Section 3.5.1. 
>      ) may not reflect that of the middle-box (which some may view as a 
>      feature). 

what happens if an offer shows up with a value in the m line that
doesn't match a capability, due to a middlebox that doesn't understand
capability negotiation?

> 3.4.3. Extension Capability Attributes 
> 
>    The SDP Capability Negotiation framework allows for new capabilities 
>    to be defined as extensions and used with the general capability 
>    negotiation framework. The syntax and semantics of such new 
>    capability attributes are not defined here, however in order to be 
>    used with potential configurations, they SHOULD allow for a numeric 
>    handle to be associated with each capability. This handle can be used 
>    as a reference within the potential and actual configuration 
>    attributes (see Section 3.5.1. and 3.5.2. ). The definition of such 
>    extension capability attributes MUST also state whether they can be 
>    applied at the session-level, media-level, or both.  

I think you need more here. Per my comments above, there is a conceptual
model missing, and you need to clearly state that model independent of
any particular capability type. I'm still fuzzy on what the model is.

> The potential configuration attribute can be provided at the media-
>    level only and there can be multiple instances of it within a given 
>    media description. The attribute includes a configuration number, 
>    which is an integer between 1 and 2^31-1 (both included). The 
>    configuration number MUST be unique within the media description 
>    (i.e. it has media level scope only). The configuration number also 
>    indicates the relative preference of

so capability numbers have a scope that is SDP-wide, but potential
configs have a scope that is media wide only? Why not the same?

>  Each potential attribute configuration list can optionally begin with 
>    instructions for how to handle attributes that are part of the actual 
>    configuration (i.e. the "a=" lines present in the original SDP). By 
>    default, such attributes will remain as part of the configuration in 
>    question. However, if delete-attributes indicates "-m", then all 
>    attribute lines within the media description in question will be 
>    deleted (i.e. all "a=" lines under the "m=" line in question). If 
>    delete-attributes indicates "-s", then all attribute lines at the 
>    session-level will be deleted (i.e. all "a=" lines before the first 
>    "m=" line). If delete-attributes indicates "-ms", then all attribute 
>    lines within this media description ("m=" line) and all attribute 
>    lines at the session-level will be deleted.  

so this is all ornothing? what is the use case?

>   Alternative attribute capability instruction lists are separated by a 
>    vertical bar ("|"), the scope of which extends to the next 
>    alternative (i.e. "," has higher precedence than "|").

So is the | notation there to more compactly represent potential
capabilities? In other words, is:

a=pcfg: 1 a=1|2

the same as:

a=pcfg: 1 a=1
a=pcfg: 2 a=2

if so, why do we have two ways of doing this? Or is this meant to deal
with the fact that the attribute capabilities aren't orthogonal? Seems
you would simplify this if you made them orthogonal.

>  alternatives are ordered by preference with the most preferred listed 
>    first. Exactly one of the alternative lists MUST be selected in its 
>    entirety in order to use this potential configuration attribute.  

selected by whom? Use in what way? THis section is discussion
construction of the offer, these words seem to talk about how its
processed at teh answerer.

> The ext-cap-name refers to the type of extension capability and the 
>    ext-cap-list is here merely defined as a sequence of visible 
>    characters. The actual extension supported MUST refine both of these 
>    further. For extension capabilities that merely need to be referenced 
>    by a capability number, it is RECOMMENDED to follow a structure 
>    similar to what has been specified above. 

hmm, This worries me. Is there a reason why the you couldn't make this
totally regular for all extension attributes? Its that general model
again that I'm looking for here...

> A (media level) potential configuration attribute in a given media 
>    description MUST NOT reference a media-level capability provided in a 
>    different media description; doing so invalidates that potential 
>    configuration (note that a potential configuration attribute can 
>    contain more than one potential configuration by use of 
>    alternatives). A potential configuration attribute can however 
>    reference a session-level capability. The semantics of doing so 
>    depends on the type of capability. In the case of transport protocol 
>    capabilities it has no particular implication. In the case of 
>    attribute capabilities however, it does. More specifically, the 
>    attribute name and value (provided within that attribute capability) 
>    will be considered part of the resulting SDP for that particular 
>    configuration at the *session* level. In other words, it will be as-
>    if that attribute was simply provided with that value at the session-
>    level in the first place. Note that individual media streams perform 
>    capability negotiation individually, and hence it is possible that 
>    another media stream (where the attribute was part of a potential 
>    configuration) chose a configuration without that session level 
>  
>  
> Andreasen             Expires September 4, 2007               [Page 21] 
> 
> Internet-Draft        SDP Capability Negotiation             March 2007 
>     
> 
>    attribute. The session-level attribute however remains "active" and 
>    hence applies to the entire resulting potential configuration SDP. It 

Can't this produce conflicts also? Where one potential config for one
media stream results in a session attribute being included, and another
potential config for a different media stream picks a different session
attribute and they are mutually exclusive?

This seems really complicated and looks like it will easily produce
errors. Why is this feature in here?

>  The session-level operation of extension capabilities is undefined: 
>    Consequently, each new session-level extension capability defined 
>    MUST specify the implication of making it part of a configuration at 
>    the media level.  

why should this vary?

>   a=pcfg:1 t=4|3 a=1 
>       a=pcfg:8 t=1|2 
> 
>    We have two potential configuration attributes listed here. The first 
>    one (and most preferred, since its configuration number is "1") 
>    indicates that either of the profiles RTP/SAVPF or RTP/SAVP 

So this is what bugs me. pcfg does NOT specify a potential config, it
specifies a large number of potential configs.

>   The answer may for example include capabilities as well. The actual 
>      configuration attribute does not refer to any of those.  

what does it mean in an answer?

> Per [RFC3264], once the offerer generates the offer, he must be 
>    prepared to receive incoming media in accordance with that offer. 
>    That rule applies here as well, but for the actual configurations 
>    provided in the offer only: Media received by the offerer according 
>    to one of the potential configurations MAY be discarded, until the 
>    offerer receives an answer indicating what the actual selected 
>    configuration is. Once that answer is received, incoming media MUST 
>    be processed in accordance with the actual selected configuration 
>    indicated and the answer received (provided the offer/answer exchange 
>    completed successfully).   

hmm, the problem is that the offerer won't know whether the received
media is based on the actual or potential configs. For example if you
are using different codecs in each one.

>  The most preferred valid potential configuration in a media 
>    description is the valid potential configuration with the lowest 
>    configuration number.

somehow missing from here is any consideration of the capabilities of
the answere. An SRTP potential config may be valid and most preferred,
but it shouldn't be used if the avpf capability isn't supported by the
answerer.

Also each potential config has multiple choices to; so how do you search
through those?

>   o  If a transport protocol capability is included in the potential 
>       configuration, then it replaces the transport protocol provided in 
>       the "m=" line for that media description.  

and if there were more than one in the capability?

>  o  If attribute capabilities are present with a delete-attributes 
>       indication, then session-level attributes and/or media-level 
>       attributes for this media description MUST be deleted in 
>       accordance with the delete-attributes provided per the procedures 
>       in Section 3.5.1.  

is this the global one or the per-attribute ones? Both have the same
name so I am totally confused on this one.

>   If the answerer is not able to support the most preferred valid 
>    potential configuration for the media description, the answerer MUST 
>    proceed to the second-most preferred valid potential configuration 
>    for the media description, etc.

What does this mean for attributes? In particular an SDP is valid and
supported even if the attributes are unknown. So is this requiring you
to understand all of the attributes in the SDP in the constructed SDP?

>  The offerer's originally provided actual configuration is contained 
>    in the media description's "m=" line (and associated parameters). The 
>    answerer can send media to the offerer in accordance with that actual 
>    configuration as soon as it receives the offer, however it MUST NOT 
>    send media based on that actual configuration if it selects an 
>    alternative potential configuration. If the answerer selects one of 
>    the potential configurations, then the answerer MAY start to send 
>    media to the offerer in accordance with the selected potential 
>    configuration, however the offerer MAY discard such media until the 
>    offerer receives the answer.   

when would it switch? Seems like you are needing a 3-way handshake here.
ICE anyone?

>  If the offer/answer exchange was successful, and if the answerer 
>    selected one of the potential configurations from the offer as the 
>    actual configuration, then the offerer MAY perform another 
>    offer/answer exchange:

this is like the ICE fixup. In ICE thisis a MUST, not a MAY. Same
considerations apply here, so why isnt the strength the same? Indeed
this could be your other leg of the three way handshake.

>   were actually negotiated. If it is known or suspected that one or 
>    more such intermediaries exist, then this second offer/answer SHOULD 
>    be performed (this is already done when using Interactive 
>    Connectivity Establishment [ICE]). Note that, per normal offer/answer 

sure, but ice always does it not just if it suspects intermediareies.

> 3.7. Interactions with ICE 

There are other interactions.

One you allude to above, is that ICE will ask for an updating offer to
do SDP fixup, and so does cap-negotiation. It should be clear that those
SHOULD be the same updated offer; don't do a separte one for ICE and
then one for cap-neg.

Another I point above is that you could use ICE to synchronize the
media. Since ICE provides a form of preconditions, you can syncrhonize
off of completion of the stun checks to decide when to send media using
the selected potential config. Lots of ways to do this, easiest one is
that the offerer, on receiving the stun check, doesn't respond to it
until it got the answer. Indeed I don't think it can anyway since it
doesn't know which of its potential configs was selected by the answerer
to generate the check.

> he SDP capability negotiation framework does not define such an 
>    alternative, however extensions may do so. For example, one technique 
>  
>  
> Andreasen             Expires September 4, 2007               [Page 36] 
> 
> Internet-Draft        SDP Capability Negotiation             March 2007 
>     
> 
>    proposed for best-effort SRTP in [BESRTP] is to provide different RTP 

I believe ICE provides an easy way to solve this.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 19 Mar 2007 01:12:24 -0400

Thanks for the review and comments Jonathan - responses below...

> example. Also abstract is a bit too long, rfc-ed may bounce.
ok
> like rfc3264 just doesnt work, but it does.
I will rephrase.
>> parameters and media stream components to use and with what parameters.
>>
I can add some textual examples of these to the respective descriptions.

>>  capability descriptions in SDP was defined in RFC 3407.
ok
>> semantics, was defined in RFC 3388, etc.
ok
> falling back to something sensible when the other side doesnt do it.
ok
> why do you have to say whether you support the base?
Future extensibility. Let's assume that we define a version 1 of this 
framework and a version 0 endpoint reveives an offer that requires 
support for version 1. He can then indicate that he supports only 
version 1. It may be useful in a SIP OPTIONS message as well.

>      Please view in a fixed-width font such as Courier.
The basic principle is correct, however there are a couple of important 
clarifications to be made:
1. Attribute capabilities are capabilies for all kinds of attributes. 
Within the context of this framework, we don't have a specific attribute 
capability for say "crypto" attributes, another one "key-mgmt", yet 
another one for say "rtpmap", etc. The reason for this is to provide a 
general solution that can be used for existing as well as future 
attributes. It is the responsibility of the entity that generates the 
offer SDP, to select and combine these attribute capabilities in 
individual potential configurations in a meaningful matter. This way, we 
avoid a requirement to understand attribute semantics inside the core 
capability negotiation framework itself.
2. We don't actually have a number assigned to each potential 
configuration but rather one to each potential configuration attribute. 
The "alternative" operator inside transport capabilities and attribute 
capabilities imply can be used to effectively encode multiple potential 
configurations inside each "pcfg" attribute. The reason for this is to 
limit the message size.

Having said that, your point is well taken. I'll add some description of 
the conceptual model.

>
>>     v=0       o=- 25678 753849 IN IP4 192.0.2.1       s=        c=IN 
>> IP4 192.0.2.1       t=0 0       m=audio 53456 RTP/AVP 0 18 
>>  
>>  
>>       a=tcap:1 RTP/SAVP        a=acap:1 a=crypto:1 
>> AES_CM_128_HMAC_SHA1_32             
As of -05, it's not required. It's possible the text is not entirely 
clear on this since previous versions of the document did require it to 
be included. I'll look out for that in the next revision.

> world. SOmeone might interpret this to mean that your phone can tunnel
Yeah - I noted that too. Would people prefer say "tpcap" (for transport 
protocol capability) ?

> I'm missing something fundamental here.
See above. Again, a "pcfg" attribute can include alternatives, and hence 
it's not always enough to just reference the "pcfg" number. For 
simplicity and consistency, we said to always require the capability 
indicators that were actually used.
>
>>   att-value         = option-tag-list       option-tag-list   = 
>> option-tag *(COMMA option-tag)       option-tag        = token    ; 
>> defined in [RFC4566]       COMMA             = ","      ; defined in 
>> [RFC4234]
>>    should note that the above definition of COMMA differs from the 
>> one    in [RFC3261].  
>
> suggest just:
>
ok

>>    level. When provided at the session-level, it applies to the 
>> entire    SDP. When provided at the media-level, it applies to the 
>> media    description in question only (option-tags provided at the 
>> session    level apply as well). 
>
Yes. Also, you may have some extensions that are supported by some media 
streams but not others (and similarly for required).

>>    are already provided in one or more "a=creq" attribute (see 
>> Section    3.3.2. ) at the relevant levels. The base option tag MAY 
>> be included.  
>
Support for version 0 is implied by the presence of the "pcfg" 
attribute. As long as we have version 0 only, there is no reason to 
include it in regular offers or answers. If we ever have a version 1, 
that may not be the case, thus we are trying to future-proof ourselves a 
bit. Also, if you use SIP OPTIONS, it might be useful to include the 
option-tag.

>>    ) and hence there is no need to include the "a=creq" attribute 
>> with    the base option-tag ("cap-v0"). Still, it is allowed to do so.  
>
> needed, explain it. 
See above.
> Seems like you could have some 3pcc cases for this,
I tend to agree but have trouble thinking of good use cases at the 
moment. It would seem to be useful only if the 3pcc controller somehow 
knows that the second entity supports these extensions. Media feature 
tags (similar to draft-ietf-sip-ice-option-tag-01.txt) would be useful 
for that (and perhaps more importantly, other non 3pcc cases), however I 
don't think we need to introduce a dependency on that. Similarly, you 
could define a SIP option tag, although I'm somewhat hesitant to doing 
so given our desire to be completely (and seamlessly) backwards 
compatible. In either case, I'd prefer to deal with these separately 
(ala draft-ietf-sip-ice-option-tag-01.txt) and would not want to have 
any normative references to it.

>>  When an entity generates an SDP and it requires the recipient of 
>> that    SDP to support one or more SDP capability negotiation 
>> extensions in    order to properly process the SDP Capability 
>> negotiation, the    "a=creq" attribute MUST be included with 
>> option-tags that identify    the required extensions at the session 
>> and/or media level, unless it    is already known that the receiving 
>> entity supports those option-tags    at the relevant levels (in which 
>> case their inclusion is OPTIONAL).  
>
I agree. We should change this.

> you'll fall back to no capability negotiation at all of course.
Right - will do.
> mechanisms to be put into place.
OK. How about:

"This ensure that introduction of the SDP capability negotiation 
mechanism by itself does not lead to session failures."

>>    num> values provided for other types of capabilities, i.e., they 
>> form    a separate name-space for attribute capabilities.  
>

No - this would be a mistake for several reasons:
1. Would not provide a generally extensible solution because we can only 
address attributes we understand today.
2. You assume that an there can only be a a single attribute with name 
"foo" that you want. The "rtpmap" and "fmtp" attributes are 
counter-examples, and probably not the only ones.
3. In some cases, we have a need to select a single attribute bases on 
choices between different attribute names. The various SRTP keying 
mechanisms are examples of that.

Also, what you propose would be a fairly fundamental design change. In 
the absence of specific problems with the current solution, as well as 
solutions to the problems with your suggested alternative, I'd be 
opposed to this.

>>    There can be multiple "tcap" attributes at the session-level as 
>> well    as within each media description. Each occurrence of the 
>> "tcap"    attribute in the entire session description MUST use a 
>> different    value of <trpr-cap-num>.  When multiple <proto> values 
>> are provided,    the first one is associated with the value 
>> <trpr-cap-num>, the second    one with the value one higher, etc. 
>
Syntactic sugar. Not unreasonable in a text-based protocol IMO, but then 
again, I've already lost the white-space debate (which is not to suggest 
that two wrongs make a right :-)

>>     This may seem redundant (and indeed it is from the offerer's 
>> point      of view), however it is done to protect against 
>> middle-boxes that      may modify "m=" lines while passing unknown 
>> attributes through. If      an implicit transport capability were 
>> used instead (e.g. a reserved      transport capability number could 
>> be used to refer to the transport      protocol in the "m=" line), 
>> and a middle-box were to modify the      transport protocol in the 
>> "m=" line (e.g. to translate between      plain RTP and secure RTP), 
>> then the potential configuration      referencing that implicit 
>> transport capability may no longer be      correct. With explicit 
>> capabilities, we avoid this pitfall,      although the potential 
>> configuration preference (see Section 3.5.1.      ) may not reflect 
>> that of the middle-box (which some may view as a      feature). 
>
There is no requirement to have capabilities or potential configurations 
that match the actual configuration provided in the "m=" line, so that 
works. Whether it reflects the intent of the original offer or the 
middle-box imposed its policy on the exchange is another matter. There 
is nothing we can do about that.

>>    The SDP Capability Negotiation framework allows for new 
>> capabilities    to be defined as extensions and used with the general 
>> capability    negotiation framework. The syntax and semantics of such 
>> new    capability attributes are not defined here, however in order 
>> to be    used with potential configurations, they SHOULD allow for a 
>> numeric    handle to be associated with each capability. This handle 
>> can be used    as a reference within the potential and actual 
>> configuration    attributes (see Section 3.5.1. and 3.5.2. ). The 
>> definition of such    extension capability attributes MUST also state 
>> whether they can be    applied at the session-level, media-level, or 
>> both.  
>
We had a little bit more originally (basically matching attribute 
structure), however we already came up with an example where we wanted 
to do something slightly differently inside those parameters. I believe 
what is in there currently is about as much as we can say without unduly 
restricting the possible operation of extensions while still providing 
for a general core capability negotiation solution that can actually use 
such extensions.

>>    level only and there can be multiple instances of it within a 
>> given    media description. The attribute includes a configuration 
>> number,    which is an integer between 1 and 2^31-1 (both included). 
>> The    configuration number MUST be unique within the media 
>> description    (i.e. it has media level scope only). The 
>> configuration number also    indicates the relative preference of
>
There is no need to. Attribute capabilities can be at both the session 
and media-level and hence we needed to ensure uniqueness between the 
two. For simplicity, we just chose a global numbering space inside the 
entire SDP. The "pcfg" attribute however can only be inside a media 
description.

>>  Each potential attribute configuration list can optionally begin 
>> with    instructions for how to handle attributes that are part of 
>> the actual    configuration (i.e. the "a=" lines present in the 
>> original SDP). By    default, such attributes will remain as part of 
>> the configuration in    question. However, if delete-attributes 
>> indicates "-m", then all    attribute lines within the media 
>> description in question will be    deleted (i.e. all "a=" lines under 
>> the "m=" line in question). If    delete-attributes indicates "-s", 
>> then all attribute lines at the    session-level will be deleted 
>> (i.e. all "a=" lines before the first    "m=" line). If 
>> delete-attributes indicates "-ms", then all attribute    lines within 
>> this media description ("m=" line) and all attribute    lines at the 
>> session-level will be deleted.  
>
Efficiency and ensuring you start with a clean plate when things 
otherwise get too complicated. Once you get into all of this selective 
deletion of individual attributes (or all attributes of a given name), 
it's a very small step to add the ability to just sweep all attributes 
from the session and/or media-level.

>
>>   Alternative attribute capability instruction lists are separated by 
>> a    vertical bar ("|"), the scope of which extends to the next    
Yes, except that your second example now has an explicit number 
associated with each potential configuration.
> you would simplify this if you made them orthogonal.
You could simplify at the expense of added message size. One of our 
requirements is to try and be reasonably efficient in terms of overall 
message size. Since the algorithm to use for the above two cases is 
exactly the same, all we are arguing here is syntax.

>
>>  alternatives are ordered by preference with the most preferred 
>> listed    first. Exactly one of the alternative lists MUST be 
>> selected in its    entirety in order to use this potential 
>> configuration attribute.  
>
Right. Given that, we should probably not have a normative MUST, but 
rather explain how these potential configurations are being used on the 
answering side, since that does guide their construction in the offer.

>>    further. For extension capabilities that merely need to be 
>> referenced    by a capability number, it is RECOMMENDED to follow a 
>> structure    similar to what has been specified above. 
>
See above.

>>    level in the first place. Note that individual media streams 
>> perform    capability negotiation individually, and hence it is 
>> possible that    another media stream (where the attribute was part 
>> of a potential    configuration) chose a configuration without that 
>> session level  
>>  
>>    attribute. The session-level attribute however remains "active" 
>> and    hence applies to the entire resulting potential configuration 
>> SDP. It 
>
I agree it is possible to produce conflicts this way, however I'm not 
sure what do do about it without introducing more complexity. You 
essentially need some form of cross-media description synchronization 
when selecting potential configurations inside a media description.  One 
option might be to (at the session-level) introduce constraints on 
allowable combinations of session-level capabilities (e.g. "attribute 
capability 1 cannot be selected at the same time as attribute capabily 
2"). Still, I'm fairly confident this is not a total solution. What if 
you have similar issues between a session-level attribute and a 
media-level attribute, or constraints are on a combination of 
capabilities (which may or may not be of the same type). It gets 
complicated very quickly.

I'm open to suggestions here, but want to stress the need for something 
relatively simple. One option is to explain the issue and recommend that 
people avoid using session-level capabilities for cases where such 
inconsistencies may occur.

>>    MUST specify the implication of making it part of a configuration 
>> at    the media level.  
>
> why should this vary?
Only experience will tell if it does. Just trying to not unduly 
constrain what we can do in the future here. Since you will need to add 
support in your implementation for the extensions you want to support 
anyway, it doesn't seem harmful.
>
>>   a=pcfg:1 t=4|3 a=1       a=pcfg:8 t=1|2
>>    We have two potential configuration attributes listed here. The 
>> first    one (and most preferred, since its configuration number is 
>> "1")    indicates that either of the profiles RTP/SAVPF or RTP/SAVP 
>
Correct.
> what does it mean in an answer?
They are capabilities that indicate things supported by the answerer 
(above and beyond what was negotiated to be used in the answer)

>>    indicated and the answer received (provided the offer/answer 
>> exchange    completed successfully).   
>
Right. Is your point that if we remap payload types and then start 
sending media, then the offerer has no way of knowing that this happened 
? If so, I agree but would say that it is the answerers responsibility 
to either not generate such media until it (somehow) knows that the 
offer has been received or accept the fact that garbage may be produced 
until such time.

> but it shouldn't be used if the avpf capability isn't supported by the
Sure - I can state that explicitly.
> Also each potential config has multiple choices to; so how do you search
See above.
>>       configuration, then it replaces the transport protocol provided 
>> in       the "m=" line for that media description.  
>
See above.
> name so I am totally confused on this one.
I'll rephrase. It is referring to "pot-attribute-config-list" inside the 
"pcfg" attribute, which contains the relevant attribute capabilities 
(referenced by number) optionally prefixed with delete-attributes. Thus, 
it is an instruction to delete one or more attributes from the session 
and/or media-level when using this particular potential configuration. 
The attributes to be deleted are specified in the delete-attributes. It 
can be all session level attributs, all media-level attributes, or 
select attributes from the session and/or media-level.

> to understand all of the attributes in the SDP in the constructed SDP?
No. However, let's say a potential configuration uses SRTP, but there is 
no support keying mechanism provided (e.g. because this one uses 
"key-mgmt" whereas you only support "crypto"). In that case, the 
configuration is not valid and you proceed to the next one.

>>    in the media description's "m=" line (and associated parameters). 
>> The    answerer can send media to the offerer in accordance with that 
>> actual    configuration as soon as it receives the offer, however it 
>> MUST NOT    send media based on that actual configuration if it 
>> selects an    alternative potential configuration. If the answerer 
>> selects one of    the potential configurations, then the answerer MAY 
>> start to send    media to the offerer in accordance with the selected 
>> potential    configuration, however the offerer MAY discard such 
>> media until the    offerer receives the answer.   
>
ICE is an option, or you just send media and let the offerer deal with 
it until he receives the the answer.

> this could be your other leg of the three way handshake.
I'm not sure why it differs. We had it at SHOULD strength at first. The 
design team felt it shouldn't be a MUST (since ultimately, the mechanism 
itself doesn't need this updated exchange, only some middle-box which 
may or may not be present and may or may not need to see this exchange) 
and there were people asking for MAY strength. Why is it MUST in ICE ?

>>    more such intermediaries exist, then this second offer/answer 
>> SHOULD    be performed (this is already done when using Interactive 
Is there an endpoint reason to do so, or is it strictly for the benefit 
of intermediaries ?

> SHOULD be the same updated offer; don't do a separte one for ICE and
Agreed. Will add text to that effect.
> until it got the answer.
Is it a good idea to delay ICE processing this way ?
> Indeed I don't think it can anyway since it
Not sure I understand the problem - are you assuming the potential 
configuration includes "different" ICE configurations that are somehow 
incompatible ?

> I believe ICE provides an easy way to solve this.
It's certainly one option. Preconditions is another (albeit probably not 
terribly popular).

Thanks for comments.

-- Flemming