Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-capability-negotiation-12.txt

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 03 Mar 2010 17:41:52 -0600

Near the bottom of page 14, 'is she wanted to' should be 'if she wanted to'.

Page 25:
> This document defines attribute configuration lists and transport 
>    protocol configuration lists.  Each of these MUST NOT be present 
>    more than once in a particular potential configuration attribute.

I think the second sentence could be more clearly stated as "A potential
configuration attribute MUST include at most one of each of these lists."

> There can be more than one extension 
>    configuration list, however each particular extension MUST NOT be 
>    present more than once in a given "a=pcfg" attribute.

Similar comment: "however a potential configuration attribute MUST
include at most one of each extension configuration list."

Page 28:
> Each referenced attribute capability in the potential configuration 
>    will result in the corresponding attribute name and its associated 
>    value (contained inside the attribute capability) being added to the 
>    resulting potential configuration SDP session description.

Should there be a restriction that no att-cap-num should be included
more than once in an alternative in a potential configuration? For example:

	a=acap:1 rtpmap:99 G7291/16000
	a=acap:2 fmtp:99 maxbitrate=12000
	a=pcfg:1 a=1,1,2

Since the resulting SDP is supposed to be created by literally adding
the requested attribute capabilities via textual substitution, this
would result in 'a=rtpmap:99 G7291/16000' appearing twice in the SDP.

Page 35:
> Transport protocol capabilities that apply to multiple media 
>       descriptions SHOULD be provided at the session-level whereas 
>       transport protocol capabilities that apply only to a specific 
>       media description ("m=" line), SHOULD be provided within that 
>       particular media description.

Since a potential configuration in a media description cannot refer to
capabilities defined in another media description (only those defined in
its own description and at the session level), unless I'm mistaken the
first SHOULD has to be MUST. Step 4 of Section 3.6.2 reiterates this point.

Page 44:
>    If the offerer selected a potential configuration instead of the 
>    actual configuration, then it is RECOMMENDED that the answerer sends 
>    back an answer SDP session description as soon as possible.

Should be "If the answerer selected..."

Page 73:
> The SDP Capability Negotiation preserves 
>    that behavior for the actual configuration in the offer, however the 
>    offerer has no way of knowing which configuration (actual or 
>    potential) configuration was selected by the offerer, until an 
>    answer indication is received.

"was selected by the answerer"

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: Bob Gilman <[email-masked]>
Date: Fri, 05 Mar 2010 10:34:56 -0700

Kevin-
Thanks for your comments.  My responses are noted below; I'm sure
Flemming will have his own comments as well.
-Bob

> configuration attribute MUST include at most one of each of these lists."
[rrg]: I prefer the MUST NOT form because I think your suggestion may be
        misinterpreted as requiring the presence of each list.  Perhaps
        it would be better to say "A potential configuration attribute
        MUST NOT include more than one of each type of list."
> include at most one of each extension configuration list."
[rrg]: same comment as above.
> would result in 'a=rtpmap:99 G7291/16000' appearing twice in the SDP.
[rrg]: I'd make this restriction only if the resulting SDP is invalid.
        Does the duplicated SDP attribute cause a problem?  I didn't
        find any prohibition about it in RFC4566 after a modest search.
        Generally, I think we should avoid rules in the capability
        framework that prevent creating invalid SDP - we should let the
        SDP rules handle that.  What we do need are rules that prevent
        capability expressions that confuse the generation of SDP from
        a particular potential or latent configuration.
        Folks have suggested that automated generation of media
        description blocks might lead to some redundancies (c.f. the
        discussion of session-level transport attributes below), and
        we should not impose rules that prevent this if the resulting
        SDP is valid.
> first SHOULD has to be MUST. Step 4 of Section 3.6.2 reiterates this point.
[rrg]: I don't think this is a MUST - after all, one can include
        the same transport capability within each media description and
        produce the same result.  Is there any need for session-level
        caps other than for compactness?
> "was selected by the answerer"

-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 04 Mar 2010 15:12:35 -0500

Hi Kevin

Thanks for your review and comments - responses below.

> configuration attribute MUST include at most one of each of these lists."
No - you can in fact have both an attribute configuration list and a 
transport protocol configuration list.

> include at most one of each extension configuration list."
Similar answer.
> would result in 'a=rtpmap:99 G7291/16000' appearing twice in the SDP.
There are many different ways in which you can use capability 
negotiation parameters to construct either invalid or somewhat redundant 
SDPs, and I'm not sure we can do much about that. While I cannot think 
of any example of why you would want to include the same attribute value 
twice in an SDP, you never know, and hence I'm a bit reluctant to 
introduce SDP restrictions that do not exist in RFC 4566. You get what 
you indicate, and if you chose to indicate something meaningless or 
invalid, then that's what you will get (at which point you have an 
invalid potential configuration, which the framework addresses).

> first SHOULD has to be MUST. Step 4 of Section 3.6.2 reiterates this 
No. The SHOULD recommendation is merely for compactness (don't repeat 
the same transport indication if you don't have to). You are correct 
that a potential configuration in media description 1 cannot refer to 
capabilities in media description 2, however it is possible to reference 
capabilities outside any media description, i.e. at the session level, 
and hence the SHOULDs are correct.

> Should be "If the answerer selected..."
Good catch - will fix.
> "was selected by the answerer"
Will fix as well.

Thanks

-- Flemming

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 05 Mar 2010 13:56:22 -0600

> Thanks for your review and comments - responses below.

Sorry for the delay in responding... for some reason your message just
now appeared in my inbox. Let me also say that I'm very happy to see
this moving ahead, it will allow us to define new specifications for how
FAX over IP is negotiated that we've been needing for quite some time :-)

> transport protocol configuration list.

Yes... Bob's suggestion in the other reply fits the situation better.

> invalid potential configuration, which the framework addresses).

If you break it, you can keep the pieces. Understood :-)

> and hence the SHOULDs are correct.

Well, I'll try to describe where my confusion arose from. In this
document, the term 'transport protocol capability' is not equivalent to
'transport protocol', it's properly a "a transport protocol that has
been assigned a capability number by having been included in a 'tcap'
attribute". Given that transport protocol capability numbers must be
unique across the body of the SDP, a 'transport protocol capability'
cannot be repeated in multiple media descriptions, although a transport
protocol can (assuming it is given a unique number at each occurrence).
So, if the builder of the SDP has a transport protocol capability (a
number assigned to a transport protocol), if they wish to use that
transport protocol capability in multiple media descriptions, it must be
defined at the session level.

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 05 Mar 2010 14:01:19 -0600

>        MUST NOT include more than one of each type of list."

Yes, this better expresses the intent.

>>
>>> There can be more than one extension    configuration list, however
>>> each particular extension MUST NOT be    present more than once in a
>>> given "a=pcfg" attribute.
>>
>>>    value (contained inside the attribute capability) being added to
>>> the    resulting potential configuration SDP session description.
>>

Yes, Flemming replied in a similar fashion. I'll retract my suggestion
as it's not really needed.

>        caps other than for compactness?

See my reply to Flemming's comments on this item.

>>>    actual configuration, then it is RECOMMENDED that the answerer
>>> sends    back an answer SDP session description as soon as possible.
>>
>>> The SDP Capability Negotiation preserves    that behavior for the
>>> actual configuration in the offer, however the    offerer has no way
>>> of knowing which configuration (actual or    potential) configuration
>>> was selected by the offerer, until an    answer indication is received.
>>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 10 Mar 2010 10:43:52 -0500

> defined at the session level.
I understand your point now, however I think it relies on a subtle 
distinction around the use of the term "capability". In some cases, we 
talk about about a specific instance of a capability in the SDP, e.g. a 
"tcap" attribute which includes a capability number and a transport 
protocol as you note. In other cases, we talk about the general notion 
of a capability, e.g. a transport protocol capability such as "RTP/AVP". 
The above is an example of the more general latter notion (generally 
recognized by omission of references to the specific attribute or an 
instance of it) which seems consistent with the rest of the document. If 
we were to make a change here, then I think we should text a few words 
as well, e.g. to the following:

<quote>
Transport protocols that apply to multiple media
       descriptions SHOULD be provided as transport protocol 
capabilities at the session-level whereas
       transport protocols that apply only to a specific
       media description ("m=" line), SHOULD be provided as transport 
protocol capabilities within that
       particular media description. In either case, there MUST NOT be
       more than a single "a=tcap" attribute at the session-level and a
       single "a=tcap" attribute in each media description.
</quote>

Does that make it clearer ?

Thanks

-- Flemming

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 10 Mar 2010 10:45:52 -0600

Flemming Andreasen wrote:
>       descriptions SHOULD be provided as transport protocol capabilities
> at the session-level whereas

Absolutely, this is perfectly clear to me.

---

From: Bob Gilman <[email-masked]>
Date: Thu, 11 Mar 2010 14:25:34 -0700

Flemming-
The session-level/media-level invocation of attributes still
bothers me as it's presently defined in your draft on page 30:

    ............. 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 provided with that value at the session-level
    in the first place. As a result, the base SDP Capability Negotiation
    framework REQUIRES that potential configurations do not reference
    any session-level attribute capabilities that contain media-level
    attributes (since that would place a media-level attribute at the
    session level). Extensions may modify this behavior, as long as it
    is fully backwards compatible with the base specification.

As you know, we tried to avoid the problem in the MediaCaps and MiscCaps
documents by just declaring those new caps as media-level only.  It's
tempting to ask you to do the same with the acap attribute, but I think
there may be cases in which that's not sufficient (I'm not worried so
much about compactness here.)  We had to make that restriction for
the latent configuration (lcfg) attribute because all its capability
attributes must appear at the session level so it can reference them
as media-level attributes.

If we consider an arbitrary attribute, there are three cases:
1. The attribute is session-level only.
2. The attribute is media-level only.
3. The attribute can appear at the session level and/or the media level.
Case 2 is handled by the media-level rule for configuration invocation.
Case 3 is handled by the media-level rule if only one such attribute
        is invoked, or if multiple such attributes are permitted.  But
        we still have the case where there may be different meanings
        attached to an attribute line if it appears at the session
        level or at the media level.  Such is the case for the key-mgmt
        attribute of your example on page 44: do we invoke the attribute
        at the session level, do one negotiation, and derive keys for
        each stream, or do we repeat the key derivation for each stream?
Case 1 is also problematic: one can specify that session-only attributes
        appear at the session level when invoked by a configuration,
        but this requires that capability processing must be aware of
        the session-only nature of each attribute it encounters when
        building candidate SDP descriptions.
I would suggest that Case 1, and the problematic parts of case 3,
can be handled by defining a new session-level attribute, call it
"sacap" for "session level capability", to look something like:

     a=scap [attribute-config-list]

Then your example of page 44 might look like

       v=0
       o=alice 2891092738 2891092738 IN IP4 lost.example.com
       s=
       t=0 0
       c=IN IP4 lost.example.com
       a=tool:foo
       a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
       a=scap a=1
       a=tcap:1 RTP/SAVP RTP/AVP
       m=audio 59000 RTP/AVP 98
       a=rtpmap:98 AMR/8000
       a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32
          inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
       a=pcfg:1 t=1 a=1|2
       m=video 52000 RTP/AVP 31
       a=rtpmap:31 H261/90000
       a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
          inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
       a=pcfg:1 t=1 a=1|3

Now the CapNeg processing can know exactly where to put the
attribute(s) in the SDP.  Given the default to media level,
scap would only need to be used when an attribute must, or
should be, placed at the session level.  I'd suggest that
scap should be a session-level-only attribute (and, perhaps,
might be extensible to other SDP line types, but I have no
good example at hand.)

The major advantages I see for the addition of scap are:
1. CapNeg doesn't need to know whether an attribute should
    appear at the session or media level; the offerer will
    specify that, and SDP will decide if the resulting
    configuration(s) is(are) valid or invalid.
2. Attribute capabilities can be declared at the session level
    and invoked at the media level in one or more media
    comfigurations.
3. This eliminates the need for a statement like that at the
    top of page 20:
    "......................................................  The base
    SDP Capability Negotiation framework however only defines procedures
    for use of media-level attribute capabilities at the media level.
    Implementations that conform only to the base framework MUST NOT
    generate media-level attribute capabilities at the session-level,
    however extensions may change this (see, e.g., [SDPMedCap] for one
    such extension) and hence all implementations MUST still be prepared
    to receive such capabilities (see Section 3.6.2. for processing
    rules)."
    and removes the need for CapNeg processing knowledge of each
    attribute, as implied by step 3 of section 3.6.2 on page 39.

Is this a reasonable solution?
-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 11 Mar 2010 16:15:00 -0600

>    attribute, as implied by step 3 of section 3.6.2 on page 39.

I think this would be great; it removes the need for the receiver of the
offer to have to *know* where any particular attribute should land in
the resulting SDP, because it will be told. Granted, it's supposed to
already exclude attributes it does not 'understand', but explicit
behavior is always better than implicit behavior in my book :-)

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 23 Mar 2010 12:35:10 -0700

Hi Bob

I don't see much difference between having semantic rules requiring you 
to adhere to certain principles or syntactic rules trying to encode 
those semantic rules when adherence to those syntactic rules are still 
driven by semantics. To be more concrete, your suggestion of requiring a 
session-level attribute to be put in a new session-level "a=scap" 
attribute still relies on the offerer to actually do this correctly as 
well as the answerer processing the resulting potential configuration 
per rules that apply to that configuration.

What hapens if somebody puts a media-level attribute in this new "scap" 
attribute ? SDPCapNeg negotiation still needs to deal with such issues 
to determine if a potential configuration is valid or not and hence the 
basic issue remains. Taking the key-mgmt example you provided, the 
resulting potential configuration SDP is exactly the same whether we use 
"a=scap" or "a=acap" at the session-level, and hence the potential 
ambiguity you are concerned with remains here as well. In summary, I 
don't see much benefit to the change proposed here.

Thanks

-- Flemming

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 23 Mar 2010 16:16:14 -0500

> per rules that apply to that configuration.

After re-reading the relevant parts of SDPCapNeg-09, I agree with
Flemming here. The language already puts the proper restrictions on
specifying media-level attributes as session-level attribute
capabilities. If an attribute that can be used at the session-level or
media-level (with differing results, as key-mgmt does) is specified as a
capability at the session level, then it must be interpreted in its
session-level usage, because it will appear in the resulting candidate
SDP at the session level.

---

From: Bob Gilman <[email-masked]>
Date: Tue, 23 Mar 2010 21:25:07 -0600

Flemming-
Insofar as possible, I've wanted to define things in such a way that
processing of offers could be done in two stages: CapNeg processing
to build possible "conventional" SDP sessions, and "conventional"
SDP processing to validate and choose one of those sessions.  In the
particular case of acap, one can still put a media-level cap at the
session level, then invoke it in a potential configuration.  Do we
expect CapNeg processing to recognize this and ignore the configuration,
or do we expect conventional SDP processing to recognize this and
invalidate the configuration, just as it would do for a non-CapNeg
configuration.  I suppose I'm looking at a particular implementation,
but I think it would be wise to keep detailed attribute knowledge out
of CapNeg and let existing SDP processing handle the problems.  One
advantage with using acap/scap to distinguish is that it puts the
burden on the user to get it right, not on CapNeg to figure out where
things belong.
-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780