Subject: Re: [rtcweb] Support for RFC7728 pause indication

From: Harald Alvestrand <[email-masked]>
Date: Sat, 11 Nov 2017 09:59:47 +0100

On 10/31/2017 12:27 PM, Iñaki Baz Castillo wrote:
>> Nice. However, the last RTP packet sent before PAUSED may arrive after
>> the PAUSED itself. Not sure how to handle that in the receiver side...
>>
>>    When entering the state, the RTP stream sender SHALL send a PAUSED
>>    indication to all known RTP stream receivers, and SHALL also repeat
>>    PAUSED in the next two regular RTCP reports, as long as it is then
>>    still in paused state.
> Should be enough to mitigate the issue.
>
>
>> RFC 7728 allows partial implementation, with fine grained control about
>> sending/receiving PAUSED indication:
>>
>>       "config" allows for partial implementation of this specification
>>       according to the different roles in the use-cases section:
>>
>>       6  The implementation supports sent and received RTP streams being
>>          paused due to local considerations and thus supports sending
>>          and receiving PAUSED indications.
>>
>>       7  The implementation supports and desires to receive PAUSED
>>          indications for received RTP streams but does not pause or send
>>          PAUSED indications for sent RTP streams.  It does not support
>>          any other messages defined in this specification.
>>
>>       8  The implementation supports pausing sent RTP streams and
>>          sending PAUSED indications for them but does not support
>>          receiving PAUSED indications for received RTP streams.  It does
>>          not support any other messages defined in this specification.
> Cool. Let's see how things go. BTW, TMMBR and TMMBN (2008 spec) also
> seem easy to implement but, despite being mandatory, better don't send
> a TMMBR to Chrome in 2017.

Patches welcome.

-- 
Surveillance is pervasive. Go Dark.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 11 Nov 2017 10:29:31 +0100

Sure thing!

But would prefer it to be in the standard, even just as a SHOULD/COULD than
only libwebrtc implementation specific.

Best regards
Sergio

El 11/11/2017 10:00, "Harald Alvestrand" <[email-masked]> escribió:

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

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 12 Nov 2017 00:05:08 +0100

On 11/11/2017 10:29 AM, Sergio Garcia Murillo wrote:
> Sure thing!
>
> But would prefer it to be in the standard, even just as a SHOULD/COULD
> than only libwebrtc implementation specific.

Sorry, I was confused - it's TMMBN that's in the spec (-rtp-usage),
PAUSED is not.

(PAUSE has two RAND IPR declarations against it, which led to some
reluctance to mention it in the past)

>
> Best regards
> Sergio
>
> El 11/11/2017 10:00, "Harald Alvestrand" <[email-masked]
> <mailto:[email-masked]>> escribió:
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 13 Nov 2017 11:58:51 +0100

On 12/11/2017 0:05, Harald Alvestrand wrote:
>> But would prefer it to be in the standard, even just as a 
>> SHOULD/COULD than only libwebrtc implementation specific.
>

Yes, Cullen already warmed about this.

I have been checking and the patent referenced on first RAND 
(https://datatracker.ietf.org/ipr/1641/) seems to cover the PAUSE/RESUME 
request and ACKs for the request, but I fail to find any reference to 
the unsolicited PAUSED indications sent from RTP sender when doing a 
local pause (which they happen to be implemented by same RTCP message 
than PAUSE ACKs). Luckily, I am not a patent expert, so this would have 
to be confirmed by someone which more knowledge than me on the subject.

I can't find any more info on which patents the second one applies to 
(https://datatracker.ietf.org/ipr/1935/) is there a way to find further 
information about it?

Best regards
Sergio