[MMUSIC] Making b=CT session level only - draft-ietf-mmusic-rfc4566bis

[Magnus Westerlund <[e-mail]>]

Hi,

The chairs have been nagging me about some action points that I got 
assigned in my absence at the IETF92 MMUSIC session. So lets try to 
settle them.

The main question for one of them is if SDPbis should make the b=CT 
bandwidth modifier into a session level only parameter?

So, it is clear that session level CT value is the total upper limit for 
bandwidth consumption, independent on direction incoming or outgoing 
from an endpoint for this Multimedia session.

Note that I believe it to be Multi-media session rather than 
communication session. This is due to that SDP is used to describe a 
multi-media session.

I would also note that for Offer/Answer it is not clear if the offer 
applies to the offerer or the answerer. This is due to the 
non-directionality declaration of CT. My personal interpretation is that 
the offer applies to the answerer and the answer applies to the offerer. 
But, this is one thing that should be clarified if anyone dares revise 
RFC 3264.

Regarding CT on media level (m=) I think the interpretation of it also 
here is not that unclear. It is just that it has no meaning in the 
pre-bundle Offer/Answer context, where one had only one Media source in 
that RTP session the m= created. But if one looks at SDP/SAP usage then 
CT do make much more sense. In multi-party usages like multicast, 
defining an AS for one media source a CT value for the aggregate across 
all session endpoints do make sense.

Which leads me to want to clarify that CT on media level is possible and 
has meaning but only in contexts where one m= line (or a bundle group of 
m= lines) may contain multiple media sources and thus media streams and 
therefore an aggregate limitation makes sense.

If people agree with this I think we need to make some amendment both to 
SDPbis and to Mux-attributes to make this clear.

SDPbis (-15) says:

5.8.  Bandwidth ("b=")

       b=<bwtype>:<bandwidth>

    This OPTIONAL line denotes the proposed bandwidth to be used by the
    session or media.  The <bwtype> is an alphanumeric modifier giving
    the meaning of the <bandwidth> figure.  Two values are defined in
    this specification, but other values MAY be registered in the future
    (see Section 8 and [RFC3556], [RFC3890]):

    CT If the bandwidth of a session or media in a session is different
       from the bandwidth implicit from the scope, a "b=CT:..." line
       SHOULD be supplied for the session giving the proposed upper limit
       to the bandwidth used (the "conference total" bandwidth).  The
       primary purpose of this is to give an approximate idea as to
       whether two or more sessions can coexist simultaneously.

    AS The bandwidth is interpreted to be application specific (it will
       be the application's concept of maximum bandwidth).  Normally,
       this will coincide with what is set on the application's "maximum
       bandwidth" control if applicable.  For RTP-based applications, AS
       gives the RTP "session bandwidth" as defined in Section 6.2 of
       [RFC3550].

    Note that CT gives a total bandwidth figure for all the media at all
    sites.  AS gives a bandwidth figure for a single media at a single
    site, although there may be many sites sending simultaneously.

    A prefix "X-" is defined for <bwtype> names.  This is intended for
    experimental purposes only.  For example:

       b=X-YZ:128

    Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers
    SHOULD be registered with IANA in the standard namespace.  SDP
    parsers MUST ignore bandwidth fields with unknown modifiers.
    Modifiers MUST be alphanumeric and, although no length limit is
    given, it is recommended that they be short.

    The <bandwidth> is interpreted as kilobits per second by default.
    The definition of a new <bwtype> modifier MAY specify that the
    bandwidth is to be interpreted in some alternative unit (the "CT" and
    "AS" modifiers defined in this memo use the default units).


I think this needs to be modified in a couple of different places.

First I think the CT explanation text should be expanded to discuss this 
context of possible multiple streams in the context of one m= line, and 
that in that and only that case does media level make sense.

Then I would like to move up the text in the note about CT into the main 
definition and change "sites" to "endpoints".


And Mux-attributes (-10) says:

6.1.  RFC4566 - SDP: Session Description Protocol

    [RFC4566] defines the Session Description Protocol (SDP) that is
    intended for describing multimedia sessions for the purposes of
    session announcement, session invitation, and other forms of
    multimedia session initiation.

    +------------+-----------------------------------+-------+----------+
    | Name       | Notes                             | Level | Mux      |
    |            |                                   |       | Category |
    +------------+-----------------------------------+-------+----------+
    | bwtype:CT  | Not Impacted                      | S     | NORMAL   |
    |            |                                   |       |          |
    | bwtype:AS  | For the media level usage, the    | B     | SUM      |
    |            | aggregate of individual bandwidth |       |          |
    |            | values is considered              |       |          |
    |            |                                   |       |          |
    +------------+-----------------------------------+-------+----------+

                           RFC4566 bwtype Analysis


So here Level needs to be changed to B (Both). Then I would state that 
the Category should be IDENTICAL. I don't know what it would mean to 
have different CT values for different media sources in a bundle group.

It might be worth adding a Note about CT, and why CT is much more useful 
in a bundle-group than on a non-bundled m= line.

Comments on this?

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------