Subject: [MMUSIC] Comment on ID-ietf-mmusic-sdp-capability-negotiation-05

From: "Robert R. Gilman" <[email-masked]>
Date: Wed, 21 Mar 2007 10:23:26 -0600

Flemming-
On page 13, section 3.4.1, you say:
" The "acap" attribute can be provided at the session level for
   session-level attributes and the media level for media-level
   attributes. The "acap" attribute MUST NOT be used to provide a media-
   level attribute at the session-level or vice versa."
That works for the base spec, but will conflict with acap: use for
latent configurations in ID-ietf-mmusic-sdp-media-capabilities-01,
where the latent configuration (and its attributes) must appear
at the session level, even if the attributes are media level.
With regard to the appearance of attributes defined in acap:
attributes in the SDP implied by their use in a pcfg: attribute,
why not just interpret those attributes that must be session level
as such, and all others as media level?
-Bob
----------------------------------------------------
Bob Gilman       [email-masked]      +1 303 538 3868

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

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 22 Mar 2007 09:07:39 -0400

> as such, and all others as media level?
That's too simplistic. You have attributes that can be provided at both 
the session-level and the media-level, and their semantics differ based 
on where they are. Session-level attributes generally apply to the 
entire session (all media streams), whereas media-level attributes apply 
to the media description in question only (usually overriding a 
corresponding session-level attribute). Take key-mgmt with MIKEY for 
example. If provided at the session-level, it would convey keying 
material to be used for all the media streams, which obviously is 
different than providing keying material for a single media stream.

Your point with media-level attribute capabilities to be used by latent 
configurations is well taken though. I need to think a little further 
about how to address that.

-- Flemming

---

From: "Robert R. Gilman" <[email-masked]>
Date: Thu, 22 Mar 2007 14:09:17 -0600

> different than providing keying material for a single media stream.
[rrg]: What I had in mind is the idea that, if you wanted a cap (which
        could be either session-level or media level) to be used, in
        effect, at the session level, you could include it in a pcfg
        within each and every media stream.  As things are now defined,
        when the acap: is declared at the session level, we would need
        to use the remove operator in all the other media streams in
        order to confine the capability to one media stream - and that
        would, I think, remove any other attributes of the same type,
        would it not?
        In the MIKEY case, couldn't an endpoint recognize that the same
        keying attribute was included for each stream and only process it
        once?
> about how to address that.
[rrg]: Perhaps we need to embed latent configurations within their own
        media lines, with zero ports if we don't want them to apply to
        any of the media streams in the current offer.  Then no capability
        would need to be declared at the session level unless it belonged
        there.  For example, a latent video configuration could be offered
        in SDP structured like:

	  <session level stuff>
	 m=audio 23456 RTP/AVP 0
	  <audio caps here>
	 a=pcfg:1 .......
	 m=video 0 RTP/AVP 31
	  <video caps go here>
	 lcfg:1 .....

        With this kind of structure, we could even include a latent audio
        configuration within the current audio offer (although I'm not sure
        why we'd want to do this.)