Subject: Re: [MMUSIC] Liaison Statement from 3GPP SA4 on RTCP Bandwidth Negotiation

From: "Leung, Nikolai" <[email-masked]>
Date: Wed, 4 Jul 2012 01:21:36 +0000

Hi,

Thanks for the feedback.

A key concern we have in 3GPP is the amount of bandwidth used for real-time applications as the traffic uses a considerable amount of the resources shared among the mobile terminals in a cell.  In our specifications we provide options and recommendations for terminals to minimize the RTCP bandwidth used for a session (in some cases turning off RTCP).  

The option for an Answering terminal to answer with smaller RR and RS values was for the case where a terminal wants to reduce the RTCP bandwidth below what was offered.  Perhaps we could add a clarification that the Answer may respond with a lower RTCP bandwidth due to  available bandwidth restrictions?

Best Regards,

-Nikolai

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Friday, June 01, 2012 12:03 PM
To: 'Miguel A. Garcia'; 'mmusic'
Cc: 'Flemming Andreasen'; Leung, Nikolai
Subject: RE: [MMUSIC] Liaison Statement from 3GPP SA4 on RTCP Bandwidth Negotiation

Hi,
In general it is good to add some text about this case since it is not addressed in RFC3556 or RFC3264. I do not see any text that claims that
RFC3556 should be used for multicast or broadcast only and not to negotiate for point to point calls.

I am not sure about the proposed recommendations. My understanding is that since RTCP unlike RTP is bidirectional channel than the RS and RR values specify the bw required for all endpoints. If the offer had a value for RS and RR, I believe that in a point to point call when we have two sender and two receivers each will get half of the RS and RR bandwidth. 
The offerer in this case will offer what he believes is needed for him to send RTCP RRs and SRs reports multiply by two so if the answerer thinks he need less bandwidth he should allow for the offerer to have enough RTCP bandwidth at least for his sender reports. So I think that answerer should respond with the same value or possibly higher. otherwise we may need to define that the RR and RS values in the offer represent the bw that offerer wants to use and the values in the answer would be the value the answerer like to use, the total RTCP bw will be the sum of the two values.

Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Miguel A. Garcia
> Sent: Friday, June 01, 2012 2:46 PM
> To: mmusic
> Cc: Flemming Andreasen; [email-masked]
> Subject: [MMUSIC] Liaison Statement from 3GPP SA4 on RTCP Bandwidth 
> Negotiation
> 
> 3GPP SA4 has sent us an LS on RTCP Bandwidth Negotiation. I copy below 
> the text.
> 
> We should be able to provide them an answer in a reasonable time 
> frame, so please, review it and provide with comments to the list. The 
> chairs will compile a reply text.
> 
> The original document can be found at the 3GPP web site:
> http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_69/Docs/S4-120810.zip
> 
> /Miguel and Flemming
> -------
> 
> 3GPP SA4 uses the RTCP bandwidth modifiers (b=RS and b=RR) to control 
> the amount of RTCP bandwidth used in point-to-point VoIP and video 
> telephony sessions.  As these parameters were primarily designed for 
> multicast sessions, the calculations in section 2 of RFC 3556 apply to 
> the total RTCP bandwidth for the session, i.e., total bandwidth for 
> all clients sending/receiving RTCP traffic. However, there are no SDP 
> Offer/Answer models defined that use these parameters for the 
> negotiation of the total RTCP bandwidth for point-to-point sessions.
> 
> To clarify this, SA4 is planning to make the following recommendations 
> in our specifications:
> 
> 1.	The RS and RR values included in the SDP offer should be treated
> as
> proposed values for the session and may be modified by the answerer 
> during session negotiation.
> 
> 2.	When generating the SDP answer, the answerer should include the
> RR and
> RS values proposed in the SDP offer. The answerer may instead choose 
> to include RR and RS values lower than those proposed in the SDP Offer.
> 
> 3.	The RS and RR values included in the SDP answer should be treated
> as
> the negotiated values for the session and should be used to calculate 
> the total RTCP bandwidth for all terminals in the session.
> 
> 
> 
> Actions:
> To IETF MMUSIC WG
> 
> ACTION: 	SA4 asks MMUSIC WG to review the above recommendations and
> identify if there are any discrepancies with the practices or 
> understanding in the IETF.
> 
> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic