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

[Sergio Garcia Murillo <[e-mail]>]

On 23/04/2015 13:07, Colin Perkins wrote:
> On 23 Apr 2015, at 10:53, Sergio Garcia Murillo <[e-mail]> wrote:
>> On 23/04/2015 11:38, Emil Ivov wrote:
>>> I am claiming that we don't have sufficient evidence that they work
>>> and am concerned that they would trigger in situations where common
>>> sense dictates they shouldn't.
>> +1
>>
>> I completely agree with Emil.
> What scenarios are you concerned with? I keep hearing claims that the circuit breaker is problematic, but have been given no examples.
>
>> In fact, as a WebRTC service providers, what we are going to do in case of CB is to re-establish the connection immediately (maybe disabling video),
> As described in Section 4.3 of the circuit breaker draft, you mean?
>

 From the draft:


      4.6
      <https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-10#section-4.6>.
      Ceasing Transmission



    What it means to cease transmission depends on the application, but
    the intention is that the application will stop sending RTP data
    packets to a particular destination 3-tuple (transport protocol,
    destination port, IP address), until the user makes an explicit
    attempt to restart the call.


I think it is a matter of deciding who is the "application", it it is 
the browser or the HTML/JS app running on it. If the congestion detected 
by the CB is signaled in the WebRTC API to the JS, so my application can 
choose what they want to do, then I am completely fine. If we the 
application is the browser and decides by itself what to do, then that's 
where I have the problem.

If the media stops flowing, they are going to blame my service, not the 
network, not chrome/firefox.

Best regards
Sergio