Hi,
Just for clarification, in Appendix A.7 of RFC 1889 bis Internet draft have the following changes been agreed to (or are these changes not required per the agreed changes to the RTCP bandwidth modifier Internet draft)?
(1) "RTCP_RCVR_BW_FRACTION = 0.25"
changed to
"RTCP_RCVR_BW_FRACTION = rtcp_bw_senders/(rtcp_bw_senders + rtcp_bw_receivers)"
and
(2) "senders > 0" removed?
Thanks.
Regards,
Pete
-----Original Message-----
From: Jose Rey [mailto:rey@panasonic.de]
Sent: Monday, June 16, 2003 6:32 AM
To: Stephen Casner; Magnus Westerlund
Cc: IETF AVT WG
Subject: RE: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt
Hi,
> -----Original Message-----
> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Stephen
> Casner
> Sent: Monday, June 16, 2003 8:47 AM
> To: Magnus Westerlund; Jose Rey
> Cc: IETF AVT WG
> Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt
>
>
> Some more thoughts on this:
>
> To simplify the unicast streaming application, we could specify that
> when RTCP bw is specified with RS and RR those values are used
> separately for senders and non-senders without any consideration of
> treating senders and receivers together when the number of senders is
> greater than RS/(RS+RR).
I think this is the best and easiest solution. In 3GPP unicast streaming it is
the server that sets the RS and RR values, that means the server should consider
well how much bandwidth it is needed for own reporting and for the sender's.
There's no case where the algorithm must adapt, the scenario is rather static.
>
> However, that would not be good for conversational applications
> (unicast or multicast) because the classification as sender changes
> over time. At times when both ends have sent within two intervals,
> they would be using the RS bw only and ignoring the RR bw. To get
> around this we could set RS to be the total, and RR zero, but then if
> one was sending and the other just listening for a long time, the
> listener would get nothing. For these applications, you need the
> smooth transision that the existing algorithm was intended to
> provide.
>
I see. I was referring more to the streaming unicast scenario. I guess my
characterization was not accure enough.
cheers,
Jose
> -- Steve
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt