Re: [AVT] RTP: When to turn off RTCP reception reports

I concur.

-Jonathan R.

David R. Oran wrote:
> I believe the new wording is an improvement and support including it in 
> the RFC.
> 
> Dave.
> 
> --On Tuesday, January 07, 2003 4:04 PM -0800 Stephen Casner 
> <casner@acm.org> wrote:
> 
>> Numerous times we have had discussions on this mailing list regarding
>> whether sending RTCP is "required".  We've answered with the reasons
>> behind both SR for data senders and RR for receivers.
>>
>> Igor Curcio cited the specific paragraph that appears both in Section
>> 6.2 of the RTP spec and in Section 1 of draft-ietf-avt-rtcp-bw-05.txt
>> regarding the ability to turn off RTCP RRs by allocating zero
>> bandwidth for them, and asked that we clarify there that, in general,
>> RTCP reports should not be turned off.  I've added text in the RTP
>> spec to do this.  If you all agree that this is a good addition, I
>> will ask the RFC Editor to insert it into rtcp-bw as well.
>>
>>                                                         -- Steve
>>
>> OLD:
>>
>>    Using
>>    two parameters allows RTCP reception reports to be turned off
>>    entirely for a particular session by setting the RTCP bandwidth for
>>    non-data-senders to zero while keeping the RTCP bandwidth for data
>>    senders non-zero so that sender reports can still be sent for inter-
>>    media synchronization. This may be appropriate for systems operating
>>    on unidirectional links or for sessions that don't require feedback
>>    on the quality of reception.
>>
>> NEW:
>>
>>    Using
>>    two parameters allows RTCP reception reports to be turned off
>>    entirely for a particular session by setting the RTCP bandwidth for
>>    non-data-senders to zero while keeping the RTCP bandwidth for data
>>    senders non-zero so that sender reports can still be sent for inter-
>>    media synchronization.  Turning off RTCP reception reports is NOT
>>    RECOMMENDED because they are needed for the functions listed at the
>>    beginning of Section 6, particularly reception quality feedback and
>>    congestion control.  However, doing so may be appropriate for systems
>>    operating on unidirectional links or for sessions that don't require
>>    feedback on the quality of reception or liveness of receivers and
>>    that have other means to avoid congestion.
>>
>> _______________________________________________
>> Audio/Video Transport Working Group
>> avt@ietf.org
>> https://www1.ietf.org/mailman/listinfo/avt
> 
> 
> ------------------------
> David R. Oran
> Cisco Systems
> 7 Ladyslipper Lane
> Acton, MA 01720
> Office: +1 978 264 2048
> VoIP: +1 408 571 4576
> Email: oran@cisco.com
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
> 

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt