Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-media-capabilities-09

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 04 Mar 2010 15:46:43 -0600

Page 4:
>    The [SDPCapNeg] document lists some of the issues with the current
>    SDP capability negotiation process.  An additional real life case is
>    to be able to offer one media stream (e.g. audio) but list the
>    capability to support another media stream (e.g. video) without
>    actually offering it currently.

This is fairly nit-picky, but if the last word of this paragraph was
'concurrently' it would make a bit more sense.

Page 6:
>    REQ-03:   Retain backward compatibility with conventional SDP.
>       Insure that each and every offered configuration can be easily
>       translated into a corresponding SDP media block expressed with
>       conventional SDP lines.
> 
>    REQ-04:   Insure the scheme operates within the offer/answer model in
>       such a way that media formats and parameters can be agreed upon
>       with a single exchange.

Both instances of 'Insure' should be 'Ensure'.

Page 11:
>    The "a=mfcap:1" line specifies the fmtp formatting parameters for
>    capability 1 (no comfort noise packets).
> 
>    The "a=mfcap:4" line specifies the fmtp formatting parameters for
>    capability 4 (G.729B).

More nit-pickiness: both of these are providing the 'annexb' format
parameter, so I'd suggest the description of the results should be
"offerer will not/will accept G.729 Annex B packets" respectively.

Page 13:

There are a number of references to <med-cap-num>. but in the ABNF it is
<media-cap-num>. The same is true for <med-cap-num-list>. The referenced
items are defined later, where media capability number ranges are not
supported, so this causes a bit of confusion. Even in 3.3.4.1, it says
that <med-cap-list> is composed of <media-cap-num> entries, but it's
not, it is composed of <med-cap-num> entries, which don't allow ranges.

I tried to come up with a better way to name the ABNF productions, but
failed :-)

Page 15:
>    the type of codec.  The mfcap lines map to a single traditional SDP
>    fmtp attribute line (one per <media-caps>) of the form

I suggest changing the parenthetical comment to "one for each entry in
<media-caps>".

Page 19:
>            med-map = med-cap-num ":" payload-type-number
>                          ; med-cap-num is defined in section 3.4.1

<med-cap-num> is actually defined in 3.3.4.1 (probably a typo).

Page 22:
>    actual configuration.  [Editors note: it could simplify processing if
>    all capabilities referenced by latent or potential configurations
>    became media-level attributes/capabilities when transformed into
>    media configurations.  Are there examples where session-level
>    attributes must be negotiated at the media level?  Perhaps we need
>    some sort of "session configuration" or "scfg=" to handle the
>    session-level fields.  Perhaps that could be somehow added to the
>    sescap attribute defined below.]

I agree that this is potentially confusing and damaging; should it be
considered to just remove the SDPCapNeg support for media-level
attributes defined at session-level staying at session-level when
included in a configuration? As SDPCapNeg already notes, this could be
very problematic, and introduces interference between potential
configuration in separate media blocks.

Section 3.3.5 (latent configurations)

This section states that each latent configuration offered represents an
additional media stream to those specified in the media blocks in the
offer or answer; later it specifies that latent configurations have a
preference order based on the numbers assigned to them. The latter would
indicate that if multiple latent configurations are offered they are
considered alternatives for each other (for which a preference order
would make sense), but the previous statement would imply that they are
not, that each latent configuration offered is independent of the
others. I'm thinking of an example where the offer includes an audio
stream, and also includes a latent configuration for a video stream
*and* a latent configuration for a FAX stream. It seems likely that the
offerer is not intending that both of these latent configurations can be
used at the same time, but there really is no preference between them,
as they serve different purposes. On the other hand, if the offerer
wants to offer a video stream over either RTP/SAVP or RTP/AVP *and*
express a preference for one over the other, that can already be done in
the transport-protocol-config-list itself. I'm struggling to come up
with a use case for preference order between latent configurations and
looking over the list archives via Google isn't providing much
discussion to reference. Since the most likely (and possibly only) use
for the config numbers assigned to latent configurations is in the
sescap attribute, which already provides adequate preference control (by
reusing the SDPCapNeg rules that state that config numbers that appear
earlier in a list have higher preference), another level of preference
control seems unnecessary.

It could be that I'm just daft and cross-eyed after spending two days
reading I-D documents :-)

Page 23:
>    When potential configurations are returned in an answer, all
>    numbering MUST refer to the configuration and capability attribute
>    numbering of the offer.  The referenced capability attributes MUST

"When potential and/or latent configurations are returned..."

Page 31:
>    When an endpoint generates an initial offer and wants to use the
>    functionality described in the current document, it should identify

How about "in this document"?

Page 32:
> 3.4.3.  Offerer Processing of the Answer
> 
>    When the offeror receives the answer, it should make note of any

The document is inconsistent in its use of 'offerer' and 'offeror'. This
obviously makes no difference in terms of the likelihood of proper
implementation... but it's inconsistent :-)

>    preference configurations that were not chosen.  Note that the base
>    specification [SDPCapNeg] requires the answerer to choose the highest
>    preference configuration it can support.

", subject to any local policies."

-- 
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: Sun, 07 Mar 2010 15:35:35 -0700

Kevin-
Thanks for your comments.  My responses are embedded below.
-Bob

> 'concurrently' it would make a bit more sense.
[rrg]: I agree.
> Both instances of 'Insure' should be 'Ensure'.
[rrg]: Indeed - we're not in the insurance business :-)
> "offerer will not/will accept G.729 Annex B packets" respectively.
[rrg]: I have no objection to this change.
> I suggest changing the parenthetical comment to "one for each entry in
[rrg]: I agree.
> <med-cap-num> is actually defined in 3.3.4.1 (probably a typo).
[rrg]: Yes.
> configuration in separate media blocks.
[rrg]: I would prefer that all capability attributes referred to in a
        configuration attribute (pcfg or lcfg) become media-level lines
        in the resulting SDP for that configuration, whether or not those
        'cap' attributes are declared at the media level.  This certainly
        affects the capability attributes used by latent configurations,
        since they don't necessarily belong to any of the current media
        descriptions and hence may appear at the session level.
        Whereas the pcfg attribute just describes a modification (however
        radical) to the current media declaration, the lcfg attribute
        is more like an m-line, in that it starts a new media
        declaration.  Would it be more visually suggestive if the
        capability attributes referenced by the lcfg attribute were to
        follow it?  All our examples have shown the capability attributes
        before the configurations that use them, but I don't remember
        that this was actually required in SDPCapNeg (although it might
        make processing easier). All the lines following the lcfg
        attribute would have to be capability attributes (otherwise,
        a non-CapNeg answerer would associate them with the preceeding
        media block (I don't think this restriction would be a problem.)
        I'd like to hear others' feedback on these issues.
> control seems unnecessary.
[rrg]: I think the preference interpretation would prove useful only if
        one didn't use the sescap attribute.  Using your audio + latent
        video + latent FAX example, the preference ordering is sufficient
        to say "If I can only have one, I'd prefer video over FAX",
        whereas the sescap attribute is needed to say "I can support
        video or FAX, but not both".  Clearly, as you point out, the
        sescap attribute can be used to express the former as well as the
        latter (in a less-compact way), so preference ordering of lcfg
        attributes is not necessary.  We can take it out if no one
        objects.
> reading I-D documents :-)
[rrg]: Welcome to the club :-)  Seriously, I appreciate your pointing
        out these problems and raising these questions.
> "When potential and/or latent configurations are returned..."
[rrg]: Good Point.
> How about "in this document"?
[rrg]: OK.
> implementation... but it's inconsistent :-)
[rrg]: This is entirely my fault :-(  I can't seem to spell "offerer"
        correctly.
> ", subject to any local policies."
[rrg]: OK.

Thanks again for your comments.
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780