Re: [MMUSIC] Proposal for LS reply regarding RTCP bandwidth negotiation

"Roni Even" <> Wed, 01 August 2012 17:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78DD211E83B3 for <>; Wed, 1 Aug 2012 10:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CAa-XENshLRY for <>; Wed, 1 Aug 2012 10:51:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 74C4F11E83B2 for <>; Wed, 1 Aug 2012 10:51:30 -0700 (PDT)
Received: by pbbjt11 with SMTP id jt11so1464810pbb.31 for <>; Wed, 01 Aug 2012 10:51:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=qt+cae3R83mZ7iFUqYrt387ygvdrTouxqOZKYDe5Vhw=; b=F134VnLP7rOPogk3pCUOQ8LbcKDmKN/Fem3RXMtv7K1e1yvDd6OQ4fu6od6B1IKSVo l0zLHqGL0FtJq24kzrnsM+s5YaOoDhC9IRj7t+6ABg91qepkN0mbezYD0aZiG1fRyzhq 6VWIjM5RR/mvLp7Yw/X4/2ew0/cRcBAU6frHpK2zjN562affuNKhnKKAJHBmISxilorY ur4twFBMss0vfzIucVefHFjXSTunW/E2YSHUd331C/Bvfi51co6wDYBlrwVzGEV9TWMH buBeb6gv0tbezNQS6WUNv/+95yVZrkbumhIoI+SUO8HT3Uoyxg7YSZ3VdN2Oo2MV1beQ JlsA==
Received: by with SMTP id gj2mr53496913pbc.153.1343843490169; Wed, 01 Aug 2012 10:51:30 -0700 (PDT)
Received: from RoniE ([2001:df8:0:16:3424:a76a:4bd6:e1bf]) by with ESMTPS id qx9sm3005721pbc.8.2012. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 10:51:29 -0700 (PDT)
From: Roni Even <>
To: 'Magnus Westerlund' <>, "'mmusic (E-mail)'" <>
References: <>
In-Reply-To: <>
Date: Wed, 01 Aug 2012 20:50:21 +0200
Message-ID: <004f01cd7016$83580e70$8a082b50$>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQD8I46QGr1zZSaKGiBCtHZbX0DPa5jn3+jw
Content-Language: en-us
Subject: Re: [MMUSIC] Proposal for LS reply regarding RTCP bandwidth negotiation
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: Wed, 01 Aug 2012 17:51:31 -0000

The liaison looks OK to me.
I agree with using option B in the first comment and to allow increasing BW
in the answer. 
As for comment 2 I assume that you are saying that the tradeoffs between
increasing RTCP and reducing RTP bw using same session bw, or increasing the
total session bw can be used to provide more RTCP bw with or without chaning
RTP bw. These options should be documented.

On the RR and SR value 0 are you suggesting to change RFC 3556.  I am not
sure it is a good question to ask 3GPP if they did not mention it
themselves; I am not supportive of the topic of negotiation of the use of
RTCP. So suggest to remove this comment

-----Original Message-----
From: [] On Behalf Of
Magnus Westerlund
Sent: 01 August, 2012 3:36 AM
To: mmusic (E-mail)
Subject: [MMUSIC] Proposal for LS reply regarding RTCP bandwidth negotiation


Below you find my proposal for a reply to the LS we received from 3GPP

This is intended as a starting point for a discussion of what reply we as WG
want to send. So please review it and send comments on this.

I would highly appreciate any insights how this issues is currently dealt
with in any implementations. If we have knowledge of multiple different
solutions then that is something we should indicate. Also if any existing
solution clashes with SA4's proposed solution.

I also raise the question if we should initiate any update of RFC 3556.
And if we can come to such an agreement and have volunteers we may be able
to strengthen the language in the last paragraph. Otherwise that language is
intended to signal a preference for the driving parties in
SA4 to come help us update the RFC in MMUSIC WG.


Title: Reply regarding On RTCP Bandwidth Negotiation

MMUSIC WG thanks SA4 for seeking our input on this topic. We agree with
SA4's identification that there exist no well defined behavior for the
negotiation of the RTCP bandwidth parameters RR and RS when used in
Offer/Answer context to negotiate a unicast transported RTP session. It is
clear that the RTP session participating end-points do need to agree on
common values or there exist a potential for interoperability failures.

Regarding the proposed recommendations for negotiation MMUSIC WG has the
following comments.

1. Based on the limitations of Offer/Answer and the requirement on arriving
at a common RTCP bandwidth value for RR and RS respectively there exist only
two possible choices. A. that the Offerer dictates the bandwidth values
without any possibilities for B to change the values, or B. as proposed in
the LS that the Offerer suggest a value that the Answerer may modify. On
that high level MMUSIC WG considers the proposed solution appropriate

2. However, we do consider the limitation that the answerer only can keep or
reduce the bandwidth values to a be a potential issue in the proposed
recommendation. The reason is that the answering party then have no way of
increasing the value if the peer agent is not willing to accept the higher
suggested values in a subsequent Offer. This may appear a reasonable
behavior in many cases and considering limited total bandwidth on the path
between the agents. However, when an agent requires a higher RTCP bandwidth
due to its usage of some RTCP based extensions this could prevent such
functionality from being used. And the bandwidth usage could be addressed by
having the answering party to reduce the total RTP session bandwidth in its
answer and be forced to reduce the bit-rate delivered to the other agent in
proportion to the increase of the RTCP bandwidth.

3. Has any special consideration been taken around the usage of RR or RS
parameter values of 0. If either offerer or answerer intended to turn off
RTCP completely or for receivers only, it is questionable that this should
have precedence over the other agents desire to use RTCP.

MMUSIC may consider to update RFC 3556 to amend the lack of Offer/Answer
rules for the RR and RS bandwidth parameters. This would be to provide all
users of the RTCP bandwidth parameter with guidance on this issue.
If the participants in SA4 WG considers that appropriate, MMUSIC WG would
highly appreciate any engagement from the SA4 participants in the MMUSIC WG.

Actions: None

-- end of proposed LS reply --


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto:

mmusic mailing list