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

["Miguel A. Garcia" <[e-mail]>]

A reminder to the WG.

We indicated earlier in the meeting that we have only 2 additional days 
for commenting Magnus'es proposed answer to this LS. We are aiming to get 
an agreed response by this Friday August 3rd.

/Miguel

On 01/08/2012 3:35, Magnus Westerlund wrote:
> MMUSIC WG,
>
> Below you find my proposal for a reply to the LS we received from 3GPP
> SA4 WG.
> https://datatracker.ietf.org/liaison/1159/
>
> 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.
>
> ===
> 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. 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 --
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
Miguel A. Garcia
[phone]
Ericsson Spain