Liaison statement
Reply regarding On RTCP Bandwidth Negotiation

Submission date 2012-08-06
From Multiparty Multimedia Session Control (Miguel Garcia)
To 3GPP (Nikolai Leung)
Cc Gonzalo 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
Referenced liaison On RTCP Bandwidth Negotiation
Attachments (None)

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

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