Re: [MMUSIC] Making b=CT session level only - draft-ietf-mmusic-rfc4566bis
"Ali C. Begen" <acbegen@gmail.com> Mon, 05 October 2015 15:15 UTC
Return-Path: <acbegen@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95CA1ACF08 for <mmusic@ietfa.amsl.com>; Mon, 5 Oct 2015 08:15:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, J_CHICKENPOX_12=0.6, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqEPShdX4Igr for <mmusic@ietfa.amsl.com>; Mon, 5 Oct 2015 08:15:23 -0700 (PDT)
Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F092E1ACF09 for <mmusic@ietf.org>; Mon, 5 Oct 2015 08:15:22 -0700 (PDT)
Received: by obcgx8 with SMTP id gx8so130793855obc.3 for <mmusic@ietf.org>; Mon, 05 Oct 2015 08:15:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=M+hytprOXjGHtUxnRQExTqRu7TcQRY8aTx/NQ/6U9P4=; b=ze98nxdRJQ5Ixuw7KNy94zQimr647k5naYtOWq6+rma3Cw1GVIxIHzUQaONc/SV7pq hjrVSeFOEVRHZZR4MecxWwIKyHIA0bhlbKjNS3ecywJo9iAlSru9ehmEEK/SLFp0csZS ABlJwfUDhov3maBSb2HxnTcPSXO7xzfq6BMaYKCKXt3FRpQmj8PtcP3sQpHcqVzo+l15 1rKg005my3hhO5sWTq7KIZV6Hjt/Z79qWQAqL5tBay65Tv841d5Hl+9O2OmvphOz0Ku0 PKntbyNK1ccKC99Uh4eTNPsUf9s7VKc/0LnbUJ0sDvDVAgCtHy3DIOFUjQq4PwWzVWZd V0bg==
MIME-Version: 1.0
X-Received: by 10.60.23.73 with SMTP id k9mr17016089oef.25.1444058122361; Mon, 05 Oct 2015 08:15:22 -0700 (PDT)
Received: by 10.202.213.83 with HTTP; Mon, 5 Oct 2015 08:15:22 -0700 (PDT)
In-Reply-To: <56095160.3040709@alum.mit.edu>
References: <55F15276.4030308@ericsson.com> <CAG371noODCX7Y7Thiyy9HK4XeOxJ4iqp89GsSkBV7oWspmeEmw@mail.gmail.com> <56095160.3040709@alum.mit.edu>
Date: Mon, 05 Oct 2015 18:15:22 +0300
Message-ID: <CAG371noDJDbR_=KeAD=ZVmNRn1i_Ps9-T092eBGB0g0xdAFzQw@mail.gmail.com>
From: "Ali C. Begen" <acbegen@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/QZ3WLEPw2R4N3n9KLLK3xNAkgxQ>
Cc: "mmusic (E-mail)" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Making b=CT session level only - draft-ietf-mmusic-rfc4566bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Oct 2015 15:15:30 -0000
Hi Paul Yes the phrase is used twice but they are for different levels (session and media). I think explicit text is the most straightforward approach. Or is the part that says "from the scope" not clear to you? On Mon, Sep 28, 2015 at 5:40 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote: > On 9/28/15 9:19 AM, Ali C. Begen wrote: >> >> 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. > > > The following phrase is used twice: "... is different from the implicit > value from the scope ...". > > I don't understand what this is trying to tell me. Can it be clarified? (I > realize this is also used in the old text, but still it is a problem to me.) > > Thanks, > Paul > > >> -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 >> <magnus.westerlund@ericsson.com> 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 +46 10 7148287 >>> Färögatan 6 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] Making b=CT session level only - draft-i… Magnus Westerlund
- Re: [MMUSIC] Making b=CT session level only - dra… Ali C. Begen
- Re: [MMUSIC] Making b=CT session level only - dra… Paul Kyzivat
- Re: [MMUSIC] Making b=CT session level only - dra… Ali C. Begen
- Re: [MMUSIC] Making b=CT session level only - dra… Paul Kyzivat
- Re: [MMUSIC] Making b=CT session level only - dra… Suhas Nandakumar