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

정경훈 <> Wed, 01 August 2012 08:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6364321F86BD for <>; Wed, 1 Aug 2012 01:47:41 -0700 (PDT)
X-Quarantine-ID: <gHTXhmV-AJnd>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -2.05
X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_HI=-8, RELAY_IS_203=0.994]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gHTXhmV-AJnd for <>; Wed, 1 Aug 2012 01:47:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0DD1E21F8699 for <>; Wed, 1 Aug 2012 01:47:39 -0700 (PDT)
Received: from ( []) by (Oracle Communications Messaging Server 7u4-24.01( 64bit (built Nov 17 2011)) with ESMTP id <> for; Wed, 01 Aug 2012 17:47:37 +0900 (KST)
Message-id: <>
X-AuditID: cbfee60d-b7f4f6d000006353-32-5018ed299f08
Received: from epextmailer01 ( []) by (EPCPMTA) with SMTP id 00.3B.25427.92DE8105; Wed, 01 Aug 2012 17:47:37 +0900 (KST)
Date: Wed, 01 Aug 2012 08:47:37 +0000
From: 정경훈 <>
To: "mmusic (E-mail)" <>
MIME-version: 1.0
X-MTR: 20120801082551437@kyunghun.jung
Msgkey: 20120801082551437@kyunghun.jung
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPHeader: ML
X-RootMTR: 20120801082551437@kyunghun.jung
MIME-version: 1.0
Content-type: text/html; charset="euc-kr"
Content-transfer-encoding: base64
X-Generator: Namo ActiveSquare 7
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsVy+t/t6bqabyUCDH60cVtMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGU1vrrEV3PKp+PLoBnsD4w2vLkZODiEBDYnGZROZQWwJAROJ s3OPsULYYhIX7q1n62LkAqqZzyjRvnoLI0iCRUBFYuuvCSwgNpuAhUTPzUXsILawQIDEtJWr wGpEBNQlWjf3sYI0Mwv8Y5RYeW4jI8Q2ZYnWSdfANvAKCEqcnPmEBWKbmsTeffNZIOLqEq8W H2KEiEtIzJp+AeoiXokZ7U+h6uUkpn1dA3W1tMT5WRsYYa5e/P0xVJxf4tjtHUxdjBxgvU/u B8OM2b35CxuELSAx9cxBqFZtidMLTkC18kmsWfiWBWbMrlPLmWF672+Zy4TufGag3tY3H5kg bEWJKd0P2SHqNSVeH37MMoFRbhaSFnQ2TPssJO0LGFlWMYqmFiQXFCelpxrrFSfmFpfmpesl 5+duYgTH+jPeHYxzGywOMQpwMCrx8L4+IxEgxJpYVlyZe4hRgoNZSYS34CZQiDclsbIqtSg/ vqg0J7X4EKM0B4uSOO8Xr6/+QgLpiSWp2ampBalFMFkmDk6pBka7D6Y8jrf5qk/2rGtQbZjk 8Zk7vp7jzpHDH688Osp/fuvHaTu/6HV/WJLfV6RdbvhoId+qzV0PFtnn/0pNvbScW1TxSrLM ZIe1x8+4LPBpP5rQd3rRcWlXhpJzgU92nnF78+Jc3OX/M94G35hsnONSWDs1ufP8n+8Mi+Iy MqbaJE/0WbrnPm+EEktxRqKhFnNRcSIAMP86BfECAAA=
Cc: Magnus Westerlund <>, 최성호 <>, "nleung@QUALCOMM.COM" <nleung@QUALCOMM.COM>, 최종수 <>
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 08:47:41 -0000

Samsung Enterprise Portal mySingle

Dear Magnus and MMUSIC colleagues:


Thank you for drafting the reply LS to 3GPP.


Although the need for such a negotiation capability originally started to setup a voice-only session

without RTCP at an earliest opportunity, in services such as Voice over LTE (VoLTE), to save a few kbps,

things can get serious if w consider the RTCP bit-rate for high-quality video. If the 5 % rules accepted

in some industries are applied, RTCP bit-rate for a video session can consume more than a few voice sessions.

If the received RTCP bit-rate is considered unnecessarily high, the session might noe be set up

if the answerer had no other means to reduce the RTCP bit-rate.


We are o.k. if MMUSIC also allows the answerer to raise up RTCP bit-rate.

Implementations, in fact, product requirements from service providers, will trade delay for accuracy in

session negotiation and the capability will be used where such feature is essential, for example, a very tight

bit-rate control has a higher priority than delay. Current implementations usually use non-zero RR values

which is negligible, 2-3 kbps, and fixed during session negotiation of course.


Best regards,

Kyunghun Jung

Samsung Electronics Co., Ltd.


------- Original Message -------

Sender : Magnus Westerlund<>

Date : 2012-08-01 10:35 (GMT+09:00)

Title : [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

Actions: None

-- end of proposed LS reply --


Magnus Westerlund

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

mmusic mailing list