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

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 8 Mar 2010 22:03:16 +0100

Hi

Not 100% sure that I follow so please bear..
IMHO actual configuratons should not change session level attributes as this can easliy cause contradictions in the answer SDP. 

I don't however see a reason to forbid specification of capabilities at the session level. For instance one may have the exotic case where one wish to specify a number capabilities for audio codecs (e.g different bitrates) on the sesion leve. Then two m lines are defined (one sendonly and one recvonly) for an asymmetric codec setup, optionally a set of latent configurations can be specified to enable more asymmetry in terms of N streams in one direction and 1 stream in the other.  If the capabilities are specified on the session level we avoid duplication. 

Also I don't see a big reason to specify where the capabilities are defined for the latent configurations. Some alterantives are easier to read for the human eye but a parser should be designed to understand any alternative, for instance by making the parser run in two passes, one that collects the capabilities and one that deals with the potential configurations. 

/Ingemar

> 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.
[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.

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 09 Mar 2010 10:48:15 -0600

> Also I don't see a big reason to specify where the capabilities are defined for the latent configurations. Some alterantives are easier to read for the human eye but a parser should be designed to…

OK, I understand where a bit of my confusion arose from here. I'll try
to explain.

SDPCapNeg defines 'acap', which can be used for any SDP attribute,
including those used for defining media streams. In SDPCapNeg, if an
'acap' is specified at the session level, any potential configuration
that references it (and is chosen) will cause that attribute to appear
in the resulting SDP at the *session* level, and there is various
language in the draft about the problems this can cause.

SDPMediaCap defines 'mcap', 'mfcap', and 'mscap', which are more
fine-grained ways of defining media stream attributes than 'acap'
allows. SDPMediaCap *explicitly* states that regardless of where these
attributes appear in the offer, any configuration that selects them will
place them into the resulting SDP at the media level.

So.. my concerns were unfounded, and caused by the (well defined)
difference in behavior when handling 'acap' vs. 'mcap/mfcap/mscap'.

-- 
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