Subject: [rtcweb] Support for RFC7728 pause indication

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 19 Oct 2017 20:48:26 +0200

Hi all,

According to the rtp usage draft, it is allowed to pause and resume 
transmissions at any time. There are several scenarios in which it would 
make sense to signal when a webrtc sender decides to pause one stream to 
the receiving side.

One of them, (as described in detail in 
https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=5207) is be 
when the webrtc endpoints decides to stop sending one simulcast stream 
in order to adapt the sent bandwidth to the bandwidth estimation. In 
that case the SFU would benefit from having that indication before 
having to wait for a timeout on media reception before switching to a 
different simulcast stream. Note that in this case, the stream is paused 
from inside the webrtc stack, so there is no event triggered to be able 
to signal this to the js app so it could notify it off band to the 
receiving side.

 From the solutions discussed, IMHO, the cleanest one would be to 
support the PAUSE indication from RFC7728. Do you think it could be 
considered to support it in webrtc?

Best regards

Sergio

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 30 Oct 2017 09:02:58 -0600

I think this is a bit late to add something like 7728 as MTI to in the sort of "1.0" specs. Of course any browser could add support that that and it would work fine with WebRTC and it could be added to future specs.  Long ago when this was discussed, some people had concerns about 

https://datatracker.ietf.org/ipr/1641/

and

https://datatracker.ietf.org/ipr/1935/

> On Oct 19, 2017, at 12:48 PM, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> Hi all,
> 
> According to the rtp usage draft, it is allowed to pause and resume transmissions at any time. There are several scenarios in which it would make sense to signal when a webrtc sender decides to pause one stream to the receiving side.
> 
> One of them, (as described in detail in https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=5207) is be when the webrtc endpoints decides to stop sending one simulcast stream in order to adapt the sent bandwidth to the bandwidth estimation. In that case the SFU would benefit from having that indication before having to wait for a timeout on media reception before switching to a different simulcast stream. Note that in this case, the stream is paused from inside the webrtc stack, so there is no event triggered to be able to signal this to the js app so it could notify it off band to the receiving side.
> 
> From the solutions discussed, IMHO, the cleanest one would be to support the PAUSE indication from RFC7728. Do you think it could be considered to support it in webrtc?
> 
> Best regards
> 
> Sergio
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 30 Oct 2017 11:20:31 -0700

To consider support for PAUSE/PAUSED, it would be first be necessary to
have implementations of TMMBR/TMMBN, since the PAUSE/PAUSED mechanism is
based on that.

However, although TMMBR/TMMBN is required in RTP-Usage, it has not been
widely implemented in WebRTC browsers. Part of the reason may have been
that REMB was used for both bandwidth estimation as well as control, so
TMMBR/TMMBN seemed like overlapping functionality. Although that argument
would be less valid after the transition from REMB to transport-cc,
experience tells us that "late blooming" protocol proposals are relatively
rare.

On Mon, Oct 30, 2017 at 8:02 AM, Cullen Jennings <[email-masked]> wrote:

>
> I think this is a bit late to add something like 7728 as MTI to in the
> sort of "1.0" specs. Of course any browser could add support that that and
> it would work fine with WebRTC and it could be added to future specs.  Long
> ago when this was discussed, some people had concerns about
>
> > One of them, (as described in detail in https://monorail-prod.appspot.
> com/p/webrtc/issues/detail?id=5207) is be when the webrtc endpoints
> decides to stop sending one simulcast stream in order to adapt the sent
> bandwidth to the bandwidth estimation. In that case the SFU would benefit
> from having that indication before having to wait for a timeout on media
> reception before switching to a different simulcast stream. Note that in
> this case, the stream is paused from inside the webrtc stack, so there is
> no event triggered to be able to signal this to the js app so it could
> notify it off band to the receiving side.
> >
> > From the solutions discussed, IMHO, the cleanest one would be to support
> the PAUSE indication from RFC7728. Do you think it could be considered to
> support it in webrtc?
> >
> > Best regards
> >
> > Sergio
> >

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 31 Oct 2017 10:22:28 +0100

Hi Bernard,

I agree that late blooming is relatively rare, but I have to try.. ;)

Indeed RFC 7728 provides to different implementation for the PAUSE/PAUSED:

    This solution reuses CCM TMMBR and TMMBN [RFC5104 <https://tools.ietf.org/html/rfc5104>] to the extent
    possible and defines a small set of new RTCP feedback messages where
    new semantics is needed.

But it also states that:

    As stated above, TMMBR/TMMBN may be used to provide pause and resume
    functionality for the point-to-point case.  If the topology is not
    point to point, TMMBR/TMMBN cannot safely be used for pause or
    resume.

So, at least for the SFU case, the RFC 7728 recommends the usage of the 
new RTCP messages, which does not require implementation of TMMBR/TMMBN.

While I agree, that the PAUSE request could be more difficult to 
implement and the use case could also be done "out off band", the PAUSED 
indication is relatively trivial to implement and it is not possible to 
be implemented any other way with current APIs.

Best regards
Sergio

On 30/10/2017 19:20, Bernard Aboba wrote:
> To consider support for PAUSE/PAUSED, it would be first be necessary 
> to have implementations of TMMBR/TMMBN, since the PAUSE/PAUSED 
> mechanism is based on that.
>
> However, although TMMBR/TMMBN is required in RTP-Usage, it has not 
> been widely implemented in WebRTC browsers. Part of the reason may 
> have been that REMB was used for both bandwidth estimation as well as 
> control, so TMMBR/TMMBN seemed like overlapping functionality. 
> Although that argument would be less valid after the transition from 
> REMB to transport-cc, experience tells us that "late blooming" 
> protocol proposals are relatively rare.
>
> On Mon, Oct 30, 2017 at 8:02 AM, Cullen Jennings <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     I think this is a bit late to add something like 7728 as MTI to in
>     the sort of "1.0" specs. Of course any browser could add support
>     that that and it would work fine with WebRTC and it could be added
>     to future specs.  Long ago when this was discussed, some people
>     had concerns about
>
>     <https://datatracker.ietf.org/ipr/1641/>
>
>     and
>
>     <https://datatracker.ietf.org/ipr/1935/>
>
>
>     > On Oct 19, 2017, at 12:48 PM, Sergio Garcia Murillo
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > Hi all,
>     >
>     > According to the rtp usage draft, it is allowed to pause and
>     resume transmissions at any time. There are several scenarios in
>     which it would make sense to signal when a webrtc sender decides
>     to pause one stream to the receiving side.
>     >
>     https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=5207
>     <https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=5207>)
>     is be when the webrtc endpoints decides to stop sending one
>     simulcast stream in order to adapt the sent bandwidth to the
>     bandwidth estimation. In that case the SFU would benefit from
>     having that indication before having to wait for a timeout on
>     media reception before switching to a different simulcast stream.
>     Note that in this case, the stream is paused from inside the
>     webrtc stack, so there is no event triggered to be able to signal
>     this to the js app so it could notify it off band to the receiving
>     side.
>     >
>     support the PAUSE indication from RFC7728. Do you think it could
>     be considered to support it in webrtc?
>     >
>     > Best regards
>     >
>     > Sergio
>     >
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 31 Oct 2017 10:34:27 +0100

I don't know how PAUSE could be implemented "out of band". In fact, the
problem is that, currently, browsers stop a simulcast stream at any time
without any indication at media or API layers. This is, I see RTCP PAUSE
useful for that use case rather than for the app to programmagically pause
a sending track (which can be indeed done via track.enabled = false +
signaling).

El 31 oct. 2017 10:22, "Sergio Garcia Murillo" <
[email-masked]> escribió:

> While I agree, that the PAUSE request could be more difficult to implement
> and the use case could also be done "out off band", the PAUSED indication
> is relatively trivial to implement and it is not possible to be implemented
> any other way with current APIs.
>
> Best regards
> Sergio
>

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 31 Oct 2017 10:40:53 +0100

On Tue, 31 Oct 2017 10:34:27 +0100
Iñaki Baz Castillo <[email-masked]> wrote:

> I don't know how PAUSE could be implemented "out of band". In fact,
> the problem is that, currently, browsers stop a simulcast stream at
> any time without any indication at media or API layers. This is, I
> see RTCP PAUSE useful for that use case rather than for the app to
> programmagically pause a sending track (which can be indeed done via
> track.enabled = false + signaling).
> 

100% agree on this. What's missing is not how to do the action, but the
notification that the action occurred. Besides, a PAUSED event is all
that would be needed, as a RESUMED is implicitly inferred from seeing
traffic for an SSRC again.

L.

> >    This solution reuses CCM TMMBR and TMMBN [RFC5104
> > <https://tools.ietf.org/html/rfc5104>] to the extent possible and
> > defines a small set of new RTCP feedback messages where new
> > semantics is needed.
> >
> >
> > But it also states that:
> >
> >    As stated above, TMMBR/TMMBN may be used to provide pause and
> > resume functionality for the point-to-point case.  If the topology
> > is not point to point, TMMBR/TMMBN cannot safely be used for pause
> > or resume.
> >
> >
> > So, at least for the SFU case, the RFC 7728 recommends the usage of
> > the new RTCP messages, which does not require implementation of
> > TMMBR/TMMBN.
> >
> > implement and the use case could also be done "out off band", the
> > PAUSED indication is relatively trivial to implement and it is not
> > possible to be implemented any other way with current APIs.
> >
> > Best regards
> > Sergio
> >
> > To consider support for PAUSE/PAUSED, it would be first be
> > necessary to have implementations of TMMBR/TMMBN, since the
> > PAUSE/PAUSED mechanism is based on that.
> >
> > have been that REMB was used for both bandwidth estimation as well
> > as control, so TMMBR/TMMBN seemed like overlapping functionality.
> > Although that argument would be less valid after the transition
> > from REMB to transport-cc, experience tells us that "late blooming"
> >> > resume  
> >> transmissions at any time. There are several scenarios in which it
> >> would make sense to signal when a webrtc sender decides to pause
> >> one stream to the receiving side.  
> >> >
> >> > https://monorail-prod.appspot.  
> >> decides to stop sending one simulcast stream in order to adapt the
> >> sent bandwidth to the bandwidth estimation. In that case the SFU
> >> would benefit from having that indication before having to wait
> >> for a timeout on media reception before switching to a different
> >> simulcast stream. Note that in this case, the stream is paused
> >> from inside the webrtc stack, so there is no event triggered to be
> >> able to signal this to the js app so it could notify it off band
> >> to the receiving side.  
> >> >

-- 
I'm getting older but, unlike whisky, I'm not getting any better
https://twitter.com/elminiero

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 31 Oct 2017 10:59:36 +0100

Please, re-read my email, as I am basically saying what you are stating.

PAUSE request can be done out of band (track.enabled = false + 
signaling), PAUSED indication of simulcast layers can't be done with 
current APIs.

BR
Sergio

On 31/10/2017 10:34, Iñaki Baz Castillo wrote:
> any time without any indication at media or API layers. This is, I see 
> RTCP PAUSE useful for that use case rather than for the app to 
> El 31 oct. 2017 10:22, "Sergio Garcia Murillo" 
> <mailto:[email-masked]>> escribió:
>
>     Hi Bernard,
>
>     So, at least for the SFU case, the RFC 7728 recommends the usage
>     of the new RTCP messages, which does not require implementation of
>     TMMBR/TMMBN.
>
>>     However, although TMMBR/TMMBN is required in RTP-Usage, it has
>>     not been widely implemented in WebRTC browsers. Part of the
>>     reason may have been that REMB was used for both bandwidth
>>     estimation as well as control, so TMMBR/TMMBN seemed like
>>     overlapping functionality. Although that argument would be less
>>     valid after the transition from REMB to transport-cc, experience
>>     tells us that "late blooming" protocol proposals are relatively
>>     rare.
>>
>>         I think this is a bit late to add something like 7728 as MTI
>>         to in the sort of "1.0" specs. Of course any browser could
>>         add support that that and it would work fine with WebRTC and
>>         it could be added to future specs.  Long ago when this was
>>         discussed, some people had concerns about
>>
>>         > According to the rtp usage draft, it is allowed to pause
>>         and resume transmissions at any time. There are several
>>         scenarios in which it would make sense to signal when a
>>         webrtc sender decides to pause one stream to the receiving side.
>>         >
>>         media reception before switching to a different simulcast
>>         stream. Note that in this case, the stream is paused from
>>         inside the webrtc stack, so there is no event triggered to be
>>         able to signal this to the js app so it could notify it off
>>         band to the receiving side.
>>         >
>>         > From the solutions discussed, IMHO, the cleanest one would
>>         be to support the PAUSE indication from RFC7728. Do you think
>>         it could be considered to support it in webrtc?
>>         >
>>         > Best regards
>>         >
>>         > Sergio
>>         >

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 31 Oct 2017 11:07:11 +0100

I am trying to focus on the use case in which the browser decides to pause
a simulcast stream (typically the highest one) under changing CPU or
network conditions. The client side app does nothing to trigger that and
it's not even notified in any way, so this is not the "track.enabled=false
+ signaling" usecase.

The use case I mean happens transparently and we need a RTCP PAUSE sent by
the browser to tell the receiver (SFU) about it.

El 31 oct. 2017 10:59, "Sergio Garcia Murillo" <
[email-masked]> escribió:

> PAUSE request can be done out of band (track.enabled = false + signaling),
> PAUSED indication of simulcast layers can't be done with current APIs.
>
> BR
> Sergio
>
>> indication is relatively trivial to implement and it is not possible to be
>> implemented any other way with current APIs.
>>
>> Best regards
>> Sergio
>>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 31 Oct 2017 11:10:58 +0100

No, you need a rtcp PAUSED indication, not an rtcp PAUSE request:

    An RTP stream sender can choose to pause the stream at any time.
    This can be either a result of receiving a PAUSE or based on some
    local sender consideration.  When it does, it sends a PAUSED
    indication, containing the current PauseID.  Note that the current
    PauseID in an unsolicited PAUSED (without having received a PAUSE) is
    incremented compared to a previously sent PAUSED.  It also sends the
    PAUSED indication in the next two regular RTCP reports, given that
    the pause condition is then still effective.

Best regards
Sergio

On 31/10/2017 11:07, Iñaki Baz Castillo wrote:
> I am trying to focus on the use case in which the browser decides to 
> pause a simulcast stream (typically the highest one) under changing 
> CPU or network conditions. The client side app does nothing to trigger 
> that and it's not even notified in any way, so this is not the 
> "track.enabled=false + signaling" usecase.
>
> The use case I mean happens transparently and we need a RTCP PAUSE 
> sent by the browser to tell the receiver (SFU) about it.
>
> El 31 oct. 2017 10:59, "Sergio Garcia Murillo" 
>     signaling), PAUSED indication of simulcast layers can't be done
>     with current APIs.
>
>     BR
>     Sergio
>
>>     I don't know how PAUSE could be implemented "out of band". In
>>     fact, the problem is that, currently, browsers stop a simulcast
>>     stream at any time without any indication at media or API layers.
>>     This is, I see RTCP PAUSE useful for that use case rather than
>>     for the app to programmagically pause a sending track (which can
>>     be indeed done via track.enabled = false + signaling).
>>
>>         So, at least for the SFU case, the RFC 7728 recommends the
>>         usage of the new RTCP messages, which does not require
>>         implementation of TMMBR/TMMBN.
>>
>>         While I agree, that the PAUSE request could be more difficult
>>         to implement and the use case could also be done "out off
>>         band", the PAUSED indication is relatively trivial to
>>         implement and it is not possible to be implemented any other
>>         way with current APIs.
>>
>>         Best regards
>>         Sergio
>>
>>>         However, although TMMBR/TMMBN is required in RTP-Usage, it
>>>         has not been widely implemented in WebRTC browsers. Part of
>>>         the reason may have been that REMB was used for both
>>>         bandwidth estimation as well as control, so TMMBR/TMMBN
>>>         seemed like overlapping functionality. Although that
>>>         argument would be less valid after the transition from REMB
>>>         to transport-cc, experience tells us that "late blooming"
>>>         On Mon, Oct 30, 2017 at 8:02 AM, Cullen Jennings
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>
>>>             I think this is a bit late to add something like 7728 as
>>>             MTI to in the sort of "1.0" specs. Of course any browser
>>>             could add support that that and it would work fine with
>>>             WebRTC and it could be added to future specs.  Long ago
>>>             when this was discussed, some people had concerns about
>>>
>>>             > According to the rtp usage draft, it is allowed to
>>>             pause and resume transmissions at any time. There are
>>>             several scenarios in which it would make sense to signal
>>>             when a webrtc sender decides to pause one stream to the
>>>             receiving side.
>>>             >
>>>             is be when the webrtc endpoints decides to stop sending
>>>             one simulcast stream in order to adapt the sent
>>>             bandwidth to the bandwidth estimation. In that case the
>>>             SFU would benefit from having that indication before
>>>             having to wait for a timeout on media reception before
>>>             switching to a different simulcast stream. Note that in
>>>             this case, the stream is paused from inside the webrtc
>>>             stack, so there is no event triggered to be able to
>>>             signal this to the js app so it could notify it off band
>>>             to the receiving side.
>>>             >
>>>             > From the solutions discussed, IMHO, the cleanest one
>>>             would be to support the PAUSE indication from RFC7728.
>>>             Do you think it could be considered to support it in webrtc?
>>>             >
>>>             > Best regards
>>>             >
>>>             > Sergio
>>>             >

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 31 Oct 2017 11:21:34 +0100

Oh yes, wording issue here, sorry.

So we all mean the unsolicited PAUSED sent by the browser.

El 31 oct. 2017 11:10, "Sergio Garcia Murillo" <
[email-masked]> escribió:

>>>> https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=5207) is
>>>> be when the webrtc endpoints decides to stop sending one simulcast stream
>>>> in order to adapt the sent bandwidth to the bandwidth estimation. In that
>>>> case the SFU would benefit from having that indication before having to
>>>> wait for a timeout on media reception before switching to a different
>>>> simulcast stream. Note that in this case, the stream is paused from inside
>>>> the webrtc stack, so there is no event triggered to be able to signal this
>>>> to the js app so it could notify it off band to the receiving side.
>>>> >

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 31 Oct 2017 11:29:02 +0100

Said that, I'm afraid we enter into a transactional PAUSE/RESUME game with
increasing ids and so on for just this simple usecase/need...

- Glare when PAUSE and PAUSED sent at the same time.
- RTP after PAUSED but before RESUMED.
- etc

I assume the RFC provides solutions for these potential issues, but I'm
afraid anyway.

El 31 oct. 2017 11:21, "Iñaki Baz Castillo" <[email-masked]> escribió:

>> pause a simulcast stream (typically the highest one) under changing CPU or
>> The use case I mean happens transparently and we need a RTCP PAUSE sent
>> by the browser to tell the receiver (SFU) about it.
>>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 31 Oct 2017 11:55:04 +0100

Couple of things:

  *   there is not a RESUMED indication, you just start sending media.
  * PAUSE/PAUSED glare is solved on the RFC
  * We only need the unsolicited PAUSED indication for the simulcast use
    case, not the whole PAUSE/RESUME mechanism.

Best regards
Sergio
On 31/10/2017 11:29, Iñaki Baz Castillo wrote:
> Said that, I'm afraid we enter into a transactional PAUSE/RESUME game 
> with increasing ids and so on for just this simple usecase/need...
>
> I assume the RFC provides solutions for these potential issues, but 
> I'm afraid anyway.
>
> El 31 oct. 2017 11:21, "Iñaki Baz Castillo" <[email-masked] 
> <mailto:[email-masked]>> escribió:
>
>     El 31 oct. 2017 11:10, "Sergio Garcia Murillo"
>>         I am trying to focus on the use case in which the browser
>>         decides to pause a simulcast stream (typically the highest
>>         one) under changing CPU or network conditions. The client
>>         side app does nothing to trigger that and it's not even
>>         notified in any way, so this is not the "track.enabled=false
>>         + signaling" usecase.
>>
>>         The use case I mean happens transparently and we need a RTCP
>>         PAUSE sent by the browser to tell the receiver (SFU) about it.
>>
>>             PAUSE request can be done out of band (track.enabled =
>>             false + signaling), PAUSED indication of simulcast layers
>>             can't be done with current APIs.
>>
>>             BR
>>             Sergio
>>
>>>             I don't know how PAUSE could be implemented "out of
>>>             band". In fact, the problem is that, currently, browsers
>>>             stop a simulcast stream at any time without any
>>>             indication at media or API layers. This is, I see RTCP
>>>             PAUSE useful for that use case rather than for the app
>>>             to programmagically pause a sending track (which can be
>>>             indeed done via track.enabled = false + signaling).
>>>
>>>                 So, at least for the SFU case, the RFC 7728
>>>                 recommends the usage of the new RTCP messages, which
>>>                 does not require implementation of TMMBR/TMMBN.
>>>
>>>                 While I agree, that the PAUSE request could be more
>>>                 difficult to implement and the use case could also
>>>                 be done "out off band", the PAUSED indication is
>>>                 relatively trivial to implement and it is not
>>>>                 To consider support for PAUSE/PAUSED, it would be
>>>>                 first be necessary to have implementations of
>>>>                 TMMBR/TMMBN, since the PAUSE/PAUSED mechanism is
>>>>                 based on that.
>>>>
>>>>                 However, although TMMBR/TMMBN is required in
>>>>                 RTP-Usage, it has not been widely implemented in
>>>>                 WebRTC browsers. Part of the reason may have been
>>>>                 that REMB was used for both bandwidth estimation as
>>>>                 well as control, so TMMBR/TMMBN seemed like
>>>>                 overlapping functionality. Although that argument
>>>>                 would be less valid after the transition from REMB
>>>>                 to transport-cc, experience tells us that "late
>>>>                 blooming" protocol proposals are relatively rare.
>>>>
>>>>                     I think this is a bit late to add something
>>>>                     like 7728 as MTI to in the sort of "1.0" specs.
>>>>                     Of course any browser could add support that
>>>>                     that and it would work fine with WebRTC and it
>>>>                     could be added to future specs.  Long ago when
>>>>                     this was discussed, some people had concerns about
>>>>
>>>>                     > On Oct 19, 2017, at 12:48 PM, Sergio Garcia
>>>>                     Murillo <[email-masked]
>>>>                     > According to the rtp usage draft, it is
>>>>                     allowed to pause and resume transmissions at
>>>>                     any time. There are several scenarios in which
>>>>                     it would make sense to signal when a webrtc
>>>>                     sender decides to pause one stream to the
>>>>                     receiving side.
>>>>                     >
>>>>                     is be when the webrtc endpoints decides to stop
>>>>                     sending one simulcast stream in order to adapt
>>>>                     the sent bandwidth to the bandwidth estimation.
>>>>                     In that case the SFU would benefit from having
>>>>                     that indication before having to wait for a
>>>>                     timeout on media reception before switching to
>>>>                     a different simulcast stream. Note that in this
>>>>                     case, the stream is paused from inside the
>>>>                     webrtc stack, so there is no event triggered to
>>>>                     be able to signal this to the js app so it
>>>>                     could notify it off band to the receiving side.
>>>>                     >
>>>>                     > From the solutions discussed, IMHO, the
>>>>                     cleanest one would be to support the PAUSE
>>>>                     indication from RFC7728. Do you think it could

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 31 Oct 2017 12:00:18 +0100

On 31 October 2017 at 11:55, Sergio Garcia Murillo
<[email-masked]> wrote:
> Couple of things:
>
>  - there is not a RESUMED indication, you just start sending media.

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...

> - PAUSE/PAUSED glare is solved on the RFC

Sure, but this involves more state in the RTCP agent. Loadable anyway.

> We only need the unsolicited PAUSED indication for the simulcast use case,
> not the whole PAUSE/RESUME mechanism.

And that's the problem. In order to solve a real and specific problem
we have today, browsers need to implement a whole RFC. I don't think
WebRTC X.Y will mandate implementing just a subset of a RFC...

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 31 Oct 2017 12:16:40 +0100

> 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.

> WebRTC X.Y will mandate implementing just a subset of a RFC...
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.

Best regards

Sergio

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 31 Oct 2017 12:27:19 +0100

>    PAUSED in the next two regular RTCP reports, as long as it is then

Should be enough to mitigate the issue.

>          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.

-- 
Iñaki Baz Castillo
<[email-masked]>