Liaison statement
Reply regarding On RTCP Bandwidth Negotiation

Source: IETF MMUSIC WG
To: 3GPP TSG SA WG4 (SA4)

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
+34-91-339-3608
Ericsson Spain