Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes

"Miguel A. Garcia" <> Tue, 28 August 2012 08:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3A4121F84A5 for <>; Tue, 28 Aug 2012 01:41:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.713
X-Spam-Status: No, score=-3.713 tagged_above=-999 required=5 tests=[AWL=-2.464, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QJodaSJPfW0X for <>; Tue, 28 Aug 2012 01:41:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EBF8621F844E for <>; Tue, 28 Aug 2012 01:40:59 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-26-503c841af440
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 72.8F.25676.A148C305; Tue, 28 Aug 2012 10:40:59 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Tue, 28 Aug 2012 10:40:59 +0200
Message-ID: <>
Date: Tue, 28 Aug 2012 10:40:57 +0200
From: "Miguel A. Garcia" <>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Paul Kyzivat <>
References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E1CF526@EXMBXCLUS01.citservers.local> <> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E2F6654@EXMBXCLUS01.citservers.local> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+Jvra50i02AQdNMRoupyx+zWKzYcIDV gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4MpY3vKQteAWb8Xu39/ZGxgvcHUxcnJICJhI 3Pq+ngnCFpO4cG89WxcjF4eQwClGiT//djNDOGsYJS6f/cUIUsUroC1x6NNNNhCbRUBV4vqv 32BxNgFzidaNG9lBbFGBQInns7ewQ9QLSpyc+YSli5GDQ0RAQ2LSVjWQMLNAsMTlA5NZQGxh AX+Jf0+OMELs2s0k8errDLCLOAW0JK48W88I0WArcWHOdRYIW15i+9s5zCC2kICmxOSbS5kn MArOQrJuFpKWWUhaFjAyr2IUzk3MzEkvN9JLLcpMLi7Oz9MrTt3ECAzWg1t+q+5gvHNO5BCj NAeLkjiv9dY9/kIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYearvLmA5nnlJf8Yq6z1Li4yF /P6cC3IMm9ol/GXX6baWZP+K+8+iDLkZSw9/zjjMHr5L41q0+dv/D2e9NuAqfBiZOm/HLrmv 73uU9Q3jVj0sTG5QXP6g+oxbg1SmWu5xzhP7s3cKXBF20+P6zL5tfXzsn45TDb/tg/h2qXxc Oenncc01TduElFiKMxINtZiLihMBM5tauyQCAAA=
Cc: Alicia Moran <>, "" <>
Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Aug 2012 08:41:00 -0000

Hi Paul,

perhaps you are thinking of the Bandwidth modifier for SDP, RFC 3890. 
Section 6.2.2. says:

    A new session and media level bandwidth modifier is defined:

       b=TIAS:<bandwidth-value> ; see section 6.6 for ABNF definition.

    The Transport Independent Application Specific Maximum (TIAS)
    bandwidth modifier has an integer bit-rate value in bits per second.
    A fractional bandwidth value SHALL always be rounded up to the next
    integer.  The bandwidth value is the maximum needed by the
    application (SDP session level) or media stream (SDP media level)
    without counting IP or other transport layers like TCP or UDP.

    At the SDP session level, the TIAS value is the maximal amount of
    bandwidth needed when all declared media streams are used.  This MAY
    be less than the sum of all the individual media streams values.
    This is due to the possibility that not all streams have their
    maximum at the same point in time.  This can normally only be
    verified for stored media streams.

Is this the example you were looking for?


On 27/08/2012 19:03, Paul Kyzivat wrote:
> I've always thought this should be the way things work, for all
> attributes. But somewhere I came across an attribute (sorry, don't
> remember which one) where the attribute at session level means something
> different than the attribute at media level, and so can't be treated as
> a default for media level. (E.g. the session level is an aggregate limit
> for something, while the media level is a limit for a single m-line.)
> Am I just dreaming this? Or can someone identify specific attributes
> that behave this way?

Miguel A. Garcia
Ericsson Spain