Subject: [AVT] Usage of RFC 3556 to turn of RTCP?

From: Belling Thomas <[email-masked]>
Date: Thu, 2 Oct 2003 16:45:53 +0200

Dear all,

Is it possible to turn off RTCP with the help of RFC 3556?

(I am aware that RFC 3550 recommends the usage of RTCP. However, turning off RTCP may possibly be beneficial for a conversational point-to-point voice communication over limited bandwidth with low delay requirements. Here, large RTCP packages may delay the transmission of RTP packages too much and result in audible distortions.)

RFC 3556 seems to be designed with other applications in mind
(e.g., streaming services - one sender, many only-listeners).
Only the suppression of receiver reports is mentioned as an application:
"  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 in
   the RTP specification, particularly reception quality feedback and
   congestion control.  However, doing so may be appropriate for systems
   operating on unidirectional links or for sessions that do not require
   feedback on the quality of reception or liveness of receivers and
   that have other means to avoid congestion."
The possibility of turning off RTCP bandwidth for data-senders is not 
explicitly considered.

Nevertheless, I do not find anything in RFC 3556 that forbids setting both bandwidth modifiers to zero:
"
b:RR:0
b:RS:0
"

The only explicit explanation about this parameter combination in RFC 3556 I find is
"If RS and RR are both zero, it would be unwise to attempt calculation of the fraction RS/(RS+RR)."

However, RFC 3556 also states:
"  The bandwidth allocation specified by the RS and RR modifiers applies
   to the total bandwidth consumed by all RTCP packet types, including
   SR, RR, SDES, BYE, APP and any new types defined in the future."

I derive that no bandwidth is granted for RTCP, if RS and RR are both zero.

Do you agree that the setting of both RS and RR to zero is allowed?

Do you agree that the implied semantics are: "RTCP is not used"   ??

Thanks for your help, Thomas Belling

----------------------------------
Dr. Thomas Belling
Siemens AG           
Sankt-Martinsstr. 76 
D-81542 München Germany
ICM N PG SP ST N1
MCH M 34 307
Tel     +49 89 636 75207
Fax     +49 89 636 75577
Mobile  +49 172 2974678
Email   [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 02 Oct 2003 10:58:03 -0400

My 2 centi-Euros below:
Dave.

--On Thursday, October 02, 2003 4:45 PM +0200 Belling Thomas 
<[email-masked]> wrote:

> (I am aware that RFC 3550 recommends the usage of RTCP. However, turning
> off RTCP may possibly be beneficial for a conversational point-to-point
> voice communication over limited bandwidth with low delay requirements.
> Here, large RTCP packages may delay the transmission of RTP packages too
> much and result in audible distortions.)
>
Huh? You're kidding right? Send RTP with DSCP=EF and RTCP with DSCP=BE.
If an occasional RTCP BE packet can introduce enough delay to matter, I 
sure hope you don't allow even a single TLS startup exchange to go over the 
link while you're talking!

> Nevertheless, I do not find anything in RFC 3556 that forbids setting
> both bandwidth modifiers to zero: "
> b:RR:0
> b:RS:0
> "
>
I believe that is correct. Caveat emptor.

> The only explicit explanation about this parameter combination in RFC
> 3556 I find is "If RS and RR are both zero, it would be unwise to attempt
> calculation of the fraction RS/(RS+RR)."
>
Note that these SDP parameters will be carried in an SDP offer-answer 
exchange, so I believe that *both* ends need to agree that this is OK. This 
means that while on a given call you can negotiate RTCP transmission 
essentially off, you can't use this as a sleazeball way to avoid 
implementing it and using it when one side or the other wants to.

Note also that setting this bandwidth to zero has the potential to break 
SRTP, which relies on RTCP for crypto resynchronization under cwertain 
failure conditions.

All in all, I would encourage you to reconsider the assumptions which lead 
you to think turning off RTCP is a good idea.

> Thanks for your help, Thomas Belling

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 02 Oct 2003 17:29:15 +0200

Hi Thomas,

Yes, setting both RTCP bandwidths to 0 will turn of RTCP.

However this is strongly recommened not to do for a number of reasons:

- Loss of receiver feedback giving congestion control information.
- Loss of synchronization information between multiple media streams, 
either different SSRC or between RTP sessions live audio and video.
- Loss of liveness information of the other end-point.
- Loss of information to bind different SSRC in different sessions to 
come from the same entity.
- Loss of possibility to use RTCP based extensions.
- Loss of possibility to use RTP payload formats requiring use of RTCP, 
for example the MIDI and its recover journal.

For more text on this see, section 6 of RFC 3550.

AVT Chair hat off:

I assume this is in relation to the proposal for conversational IMS 
based service's optimized radio bearer in 3GPP. I strongly recommend 
against removing RTCP of the following reasons that I think apply in 
this use case.

1. Loss of synchronization if combined with another media, like audio 
and video.
2. Loss of liveness information from the other party.
3. If the conversational IMS system becomes used over networks which are 
best effort and not using reserved resources the RTCP will be needed for 
congestion control.

That is my view on this issue.

Best Regards

Magnus

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]