Subject: [rtcweb] Endpoints that don't support RTCP

From: Justin Uberti <[email-masked]>
Date: Thu, 26 Mar 2015 00:24:43 -0500

This is described in rtp-usage, and the need to limit bitrate is explicitly
called out:

7.2 <https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-22#section-7.2>.
Congestion Control Interoperability and Legacy Systems

   There are legacy RTP implementations that do not implement RTCP, and
   hence do not provide any congestion feedback.  Congestion control
   cannot be performed with these end-points.  WebRTC Endpoints that
   need to interwork with such end-points MUST limit their transmission
   to a low rate, equivalent to a VoIP call using a low bandwidth codec,
   that is unlikely to cause any significant congestion.

Note however that this is incompatible with this section that mandates
use of circuit breakers:

7.1 <https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-22#section-7.1>.
Boundary Conditions and Circuit Breakers

   WebRTC Endpoints MUST implement the RTP circuit breaker algorithm
   that is described in [I-D.ietf-avtcore-rtp-circuit-breakers
<https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-22#ref-I-D.ietf-avtcore-rtp-circuit-breakers>].
The
   RTP circuit breaker is designed to enable applications to recognise
   and react to situations of extreme network congestion.  However,
   since the RTP circuit breaker might not be triggered until congestion
   becomes extreme, it cannot be considered a substitute for congestion
   control, and applications MUST also implement congestion control to
   allow them to adapt to changes in network capacity.  Any future RTP
   congestion control algorithms are expected to operate within the
   envelope allowed by the circuit breaker.

I think we need to clarify exactly how WebRTC endpoints need to deal
with legacy gear that doesn't send RTCP (which might just be to say
"no").

---

From: Colin Perkins <[email-masked]>
Date: Thu, 26 Mar 2015 09:18:41 -0500

Can you suggest text that you think would be clearer?

Colin

On 26 Mar 2015, at 00:24, Justin Uberti <[email-masked]> wrote:
> This is described in rtp-usage, and the need to limit bitrate is explicitly called out:
> 
> 7.2.  Congestion Control Interoperability and Legacy Systems
> 
> Note however that this is incompatible with this section that mandates use of circuit breakers:
> 
> 7.1.  Boundary Conditions and Circuit Breakers
> 
>    that is described in [I-D.ietf-avtcore-rtp-circuit-breakers].  The
> I think we need to clarify exactly how WebRTC endpoints need to deal with legacy gear that doesn't send RTCP (which might just be to say "no").
> 
> 
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Colin Perkins
https://csperkins.org/

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 26 Mar 2015 07:23:25 -0700

These are the legacy endpoints that don't do RTCP but do have ICE and DTLS-SRTP?

Matthew Kaufman

(Sent from my iPhone)

> On Mar 25, 2015, at 10:24 PM, Justin Uberti <[email-masked]> wrote:
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 26 Mar 2015 09:41:03 -0500

Right, I think mandating use of RTCP is the correct solution. e.g.

   All endpoints that wish to interwork with WebRTC MUST

   implement RTCP and provide congestion feedback via the defined RTCP

   reporting mechanisms.

   When interworking with legacy implementations that support RTCP using
   the RTP/AVP profile [RFC3551
<https://tools.ietf.org/html/rfc3551>], congestion feedback is
provided in
   RTCP RR packets every few seconds.  Implementations that have to
   interwork with such end-points MUST ensure that they keep within the
   RTP circuit breaker [I-D.ietf-avtcore-rtp-circuit-breakers
<https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-22#ref-I-D.ietf-avtcore-rtp-circuit-breakers>]
   constraints to limit the congestion they can cause.

On Thu, Mar 26, 2015 at 9:23 AM, Matthew Kaufman <[email-masked]> wrote:

> 7.2 <https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-22#section-7.2>.  Congestion Control Interoperability and Legacy Systems
>
> 7.1 <https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-22#section-7.1>.  Boundary Conditions and Circuit Breakers
>
>    that is described in [I-D.ietf-avtcore-rtp-circuit-breakers <https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-22#ref-I-D.ietf-avtcore-rtp-circuit-breakers>].  The

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 26 Mar 2015 15:57:14 +0100

Well, a legacy device that doesn't support RTCP might get ICE and DTLS
support with the help of a WebRTC gateway.

Lorenzo

On Thu, 26 Mar 2015 07:23:25 -0700
Matthew Kaufman <[email-masked]> wrote:

> >    There are legacy RTP implementations that do not implement RTCP,
> > and hence do not provide any congestion feedback.  Congestion
> > control cannot be performed with these end-points.  WebRTC
> > Endpoints that need to interwork with such end-points MUST limit
> > their transmission to a low rate, equivalent to a VoIP call using a
> > low bandwidth codec, that is unlikely to cause any significant
> > congestion.
> > 
> >    that is described in [I-D.ietf-avtcore-rtp-circuit-breakers].
> > The RTP circuit breaker is designed to enable applications to
> > recognise and react to situations of extreme network congestion.
> > However, since the RTP circuit breaker might not be triggered until
> > congestion becomes extreme, it cannot be considered a substitute
> > for congestion control, and applications MUST also implement
> > congestion control to allow them to adapt to changes in network
> > capacity.  Any future RTP congestion control algorithms are
> > expected to operate within the envelope allowed by the circuit
> > breaker.
> > 
> > I think we need to clarify exactly how WebRTC endpoints need to
> > deal with legacy gear that doesn't send RTCP (which might just be
> > to say "no").
> > 
> > 
> > 
> > 
> >

---

From: Justin Uberti <[email-masked]>
Date: Thu, 26 Mar 2015 10:01:16 -0500

Sure, although said gateway could certainly send some minimal RTCP as well.

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 26 Mar 2015 15:25:58 +0000

Your legacy gateway can know definitively (from SDP) whether the peer it’s talking to will do ICE or DTLS-SRTP, but unfortunately devices that don’t do RTCP also typically don’t bother to indicate this fact in any way.

So assuming (as I think we should) that rtp-usage mandates RTCP support, a legacy gateway will need to figure out dynamically whether it can count on receiving RTCP from its media destination, or whether it needs to synthesize RTCP locally.  Perhaps some text can be written for the -gateways draft that can give some guidance on how a gateway can make this decision.

On Mar 26, 2015, at 9:23 AM, Matthew Kaufman <[email-masked]<mailto:[email-masked]>> wrote:

Matthew Kaufman

(Sent from my iPhone)

On Mar 25, 2015, at 10:24 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

7.2<https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-22#section-7.2>.  Congestion Control Interoperability and Legacy Systems

7.1<https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-22#section-7.1>.  Boundary Conditions and Circuit Breakers

   that is described in [I-D.ietf-avtcore-rtp-circuit-breakers<https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-22#ref-I-D.ietf-avtcore-rtp-circuit-breakers>].  The

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Simon Perreault <[email-masked]>
Date: Thu, 26 Mar 2015 13:25:15 -0500

Le 2015-03-26 09:41, Justin Uberti a écrit :
> I think mandating use of RTCP is the correct solution.

That's an easy one. +1

Simon

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 26 Mar 2015 19:52:34 +0000

I agree this should be handled in the gateways draft. Other drafts that only deal with WebRTC endpoints should just expect RTCP as a given just like they expect ICE and DTLS.

For the WebRTC endpoint side of the gateway, it must obey the RTP circuit breaker in both send and receive directions, and synthesize RTCP on behalf of the legacy side when necessary to avoid tripping the breaker in the receive direction.

Mo

On 3/26/15, 11:25 AM, Jonathan Lennox <[email-masked]<mailto:[email-masked]>> wrote:

Matthew Kaufman

(Sent from my iPhone)

---

From: Colin Perkins <[email-masked]>
Date: Mon, 30 Mar 2015 10:45:17 +0100

I see several statements in support of this, so I'll make the change and submit rtp-usage-23.

Colin

On 26 Mar 2015, at 14:41, Justin Uberti <[email-masked]> wrote:

>    the RTP/AVP profile [RFC3551], congestion feedback is provided in
>    RTP circuit breaker [I-D.ietf-avtcore-rtp-circuit-breakers]

-- 
Colin Perkins
https://csperkins.org/

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 30 Mar 2015 15:13:34 +0200

Den 26. mars 2015 20:52, skrev Mo Zanaty (mzanaty):
> I agree this should be handled in the gateways draft. Other drafts that
> only deal with WebRTC endpoints should just expect RTCP as a given just
> like they expect ICE and DTLS.
> 
> For the WebRTC endpoint side of the gateway, it must obey the RTP
> circuit breaker in both send and receive directions, and synthesize RTCP
> on behalf of the legacy side when necessary to avoid tripping the
> breaker in the receive direction.

This seems indeed to be a place where the gateways draft is the right
place for such advice :-)

Would it be appropriate to say something like (after the text saying
that a gateway needs to do ICE and DTLS-SRTP):

A gateway that passes on RTP needs to monitor the RTCP sent by the
non-WebRTC endpoint to see that it is adequate for congestion control
feedback, and if it is not, start synthesizing it.

In particular, if the non-WebRTC endpoint sends no RTCP, the gateway
needs to start sending syntehsized RTCP feedback before the circuit
breaker mechanism <ref> triggers, and keep on sending RTCP feedback at
appropriate intervals.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 30 Mar 2015 09:25:26 -0400

> breaker mechanism <ref> triggers, and keep on sending RTCP feedback at

It should also be fine for an RTP relay to unconditionally generate RTCP
receiver reports using its own SSRC. *If* it does not already do that,
*then* it must do it as you suggest. Otherwise, no modification is
necessary.

Simon

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 30 Mar 2015 19:54:00 +0000

Talked to a few people and it seems that some of the PSTN gateway manufactures do have ICE and DTLS-SRTP but have no plans to add RTCP to calls that are running at G.711 bandwidth or less. Thought I support that IETF wish that RTCP was mandatory, I really doubt yet another document saying MUST will change anything. 

My suggested changes to text below. 

> On Mar 25, 2015, at 11:24 PM, Justin Uberti <[email-masked]> wrote:
> 

I'd might replace "low bandwidth" in above to G.711

> ].  The

I'd prefix this paragraph with something like "When using protocols that provide congestion feedback " then rest of para. And then something at end like "When using protocols that do not provide congestion feedback, the bandwidth used must be limited to the equivalent of a G.711 call as described sion section 7.2"

> I think we need to clarify exactly how WebRTC endpoints need to deal with legacy gear that doesn't send RTCP (which might just be to say "no").

We did talk about this in the meetings that lead up to this text and I don't see any reason to need to go back and reopen the consensus from back then. The text I'm proposing here is pretty much what's need for real world and requiring RTCP puts you into this awful user experience failure mode where the call is fine for awhile then just randomly disconnects after you have been talking for a bit. Users don't like it. 

One of the points that was brought up in previous discussion about this is the following. Imagine a browser (called A)  does webrtc to a media gateway (called B) that terminates ICE and DTLS-SRTP then does SIP / SRTP to a PSTN gateway (called C). We can assume the PSTN GW supports RTCP.  A and B may be in the one country but C is likely to be in the country of the PSTN number being dialed, not collocated with B. So you could make a gateway that terminated the RTP media and only reported the packet loss from A to B. But the RTP from A to B could be perfect and still having huge problems with RTP from B to C. Really what A wants to see is the media quality from A to C. So it is best if the gateway is more of a relay for the RTCP from C to A (and visa versa). But here's the catch, at the time B connects to C, it has no idea if C does RTCP or not and there is no way to find without waiting until the call is well underway then noticing that it never saw any RTCP.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2015 14:56:54 -0500

> Talked to a few people and it seems that some of the PSTN gateway manufactures do have ICE and DTLS-SRTP but have no plans to add RTCP to calls that are running at G.711 bandwidth or less. Thought…

It will in this case, if browsers implement circuit breakers.  Unless
you like really short calls, that is.

---

From: Emil Ivov <[email-masked]>
Date: Mon, 30 Mar 2015 21:59:08 +0200

> you like really short calls, that is.

Because, obviously, having circuit breakers is more important than
having your call continue ;)

Emil

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2015 15:56:27 -0500

> having your call continue ;)

Indeed.  Given the number of actual calls that don't contain RTCP,
allowing an exception at 100kbps or less (pick your own number, but
this seems about right to me) makes sense.  The alternative is to have
gateways synthesize bogus RTCP, but that only wastes bits.

---

From: Emil Ivov <[email-masked]>
Date: Mon, 30 Mar 2015 23:00:04 +0200

On Mon, Mar 30, 2015 at 10:56 PM, Martin Thomson
<[email-masked]> wrote:
> this seems about right to me) makes sense.

Makes sense to me! (and of course, any number would make sense here
given how superfluous circuit breakers are in the presence of consent
checks)

Emil

-- 
https://jitsi.org

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2015 16:06:17 -0500

> given how superfluous circuit breakers are in the presence of consent

I chose 100 only because that includes G.711 and every other voice
codec.  Audio that goes above this is special enough that RTCP is
probably worthwhile; video that is in this region already sucks enough
that I'm inclined to limit any exclusion to audio.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 30 Mar 2015 21:09:42 +0000

> On Mar 30, 2015, at 3:06 PM, Martin Thomson <[email-masked]> wrote:
> 

I agree that 100kbps is plenty for the exception. And I don't think that is going to cause huge congestion problems because if it was going to cause big problems, we would have already seen them with the current usage of VoIP.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2015 16:12:53 -0500

> I agree that 100kbps is plenty for the exception. And I don't think that is going to cause huge congestion problems because if it was going to cause big problems, we would have already seen them wi…

Oh, the other reason is that I don't think that any browser is doing
anything to prevent ICE connectivity checks from being sent at this
rate.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 30 Mar 2015 16:11:25 -0700

In terms of how this is actually implemented, I think it would be simplest
to do something like: "if the circuit breaker fires, ignore it if it is for
an audio stream with a codec bitrate of 64 kbps or less".

I don't think trying to make video without RTCP work makes sense.

On Mon, Mar 30, 2015 at 2:12 PM, Martin Thomson <[email-masked]>
wrote:

> > I agree that 100kbps is plenty for the exception. And I don't think that
> is going to cause huge congestion problems because if it was going to cause
> big problems, we would have already seen them with the current usage of
> VoIP.
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2015 18:16:43 -0500

> an audio stream with a codec bitrate of 64 kbps or less".

Probably.  We can't really use b= as input to a decision to turn off
circuit breakers, can we?

> I don't think trying to make video without RTCP work makes sense.

Yep.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 30 Mar 2015 16:27:20 -0700

> circuit breakers, can we?

If we are generating a 512 kbps Opus stream, we could conceivably make a
different decision than a plain PCMU stream. But as that is a pathological
case, ignoring circuit breakers for all audio streams would probably be
fine.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2015 16:33:55 -0700

> case, ignoring circuit breakers for all audio streams would probably be

I think that I'd be more inclined to use whatever signal we got
telling us that 512kbps was needed to also tell us that circuit
breakers is.  I don't know what that signal is right now, BTW, but we
we are going to be sending at that rate, we presumably need to be told
to do so somehow.  Again, I think that b= is the wrong hook.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 31 Mar 2015 00:33:03 +0000

> On Mar 30, 2015, at 5:11 PM, Justin Uberti <[email-masked]> wrote:
> 
> In terms of how this is actually implemented, I think it would be simplest to do something like: "if the circuit breaker fires, ignore it if it is for an audio stream with a codec bitrate of 64 kbps or less".
> 

That would be fine with me - or the < 100kbps formulation. Practically they end up about the same so either works for me.

---

From: Tim Panton <[email-masked]>
Date: Tue, 31 Mar 2015 11:14:11 +0100

> On 30 Mar 2015, at 22:00, Emil Ivov <[email-masked] <mailto:[email-masked]>> wrote:
> 
> <[email-masked] <mailto:[email-masked]>> wrote:
>> On 30 March 2015 at 14:59, Emil Ivov <[email-masked] <mailto:[email-masked]>> wrote:
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>> On 30 March 2015 at 14:54, Cullen Jennings (fluffy) <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 

It looks to me as if Firefox nightly has stopped doing consent checks, so
we have a way to see how well that turns out - badly so far this morning ;-(

T.

> 
> Emil
> 
> -- 
> https://jitsi.org <https://jitsi.org/>
> 

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk <http://www.westhawk.co.uk/>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 31 Mar 2015 14:16:42 +0200

On 03/31/2015 01:33 AM, Martin Thomson wrote:
> breakers is.

Wouldn't it be simpler to tell that circuit breakers are needed from the
fact that more than 100 kilobits are being sent within 1 second? (or 1
Mbit within 10 seconds?)

I haven't yet seen a high-level API that doesn't offer to count the
outgoing bits.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Mar 2015 09:20:17 -0700

> we have a way to see how well that turns out - badly so far this morning ;-(

Here: https://bugzilla.mozilla.org/

FWIW, Firefox has never done continuous consent.  The initial consent
to send is all it has ever had in that area.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Mar 2015 09:20:38 -0700

> fact that more than 100 kilobits are being sent within 1 second? (or 1

That works too.