Re: [rtcweb] Support for RFC7728 pause indication

[Harald Alvestrand <[e-mail]>]

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.