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

["Ali C. Begen" <[e-mail]>]

Hi Magnus

Here is my suggested text based on your input. Changes are in the CT
and AS definitions. Let me know if you are happy with this text.

-acbegen

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 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).  Similarly, if
      the bandwidth of bundled media streams in an m line is different from
      the implicit value from the scope, a "b=CT:..." line SHOULD be supplied
      in the media level. The primary purpose of this is to give an
approximate idea as to
      whether two or more sessions (or bundled media streams) can
coexist simultaneously.
   Note that CT gives a total bandwidth figure for all the media at all
   endpoints.

   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 AS gives a bandwidth figure for a single
media at a single
   endpoint, although there may be many endpoints 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).

On Thu, Sep 10, 2015 at 12:50 PM, Magnus Westerlund
<[e-mail]> wrote:
> 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]
> ----------------------------------------------------------------------
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic