Liaison statement
Reply regarding On RTCP Bandwidth Negotiation

State Posted
Posted Date 2012-08-06
From Group mmusic
From Contact Miguel GarcĂ­a
To Group 3GPP
To Contacts Nikolai Leung
CcGonzalo Camarillo
Flemming Andreasen
Miguel Garcia
Robert Sparks
Multiparty Multimedia Session Control Discussion List
Atle Monrad
Nikolai Leung
Paolo Usai
Response Contact Miguel Garcia
Purpose In response
Attachments (None)
Liaisons referred by this one On RTCP Bandwidth Negotiation

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 as specified in RFC 3556? 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.

Dates of the next IETF meetings:

IETF 85: November 4-9, 2012. Atlanta, GA, USA.


Miguel A. Garcia
Ericsson Spain