Re: [rtcweb] Should we reference the pause/resume I-D?

On 2014-03-12 21:56, Justin Uberti wrote:
> Agreed.

I may well be that the pause/resume doc will not be ready in time, so it 
from that aspect is a bad idea. What about just stating that TMMBN/TMMBR 
0 meaning pause should be supported?

> Aren't there also patent declarations against this doc from
> multiple holders?

I've not looked into that, but I deliberately chose to propose the "old" 
TMMBN 0 way to signal that is mentioned in [1] (and not any of the "new" 
signaling in [1]).

>
> While SDP will likely be removed from the API in the future, the
> replacement would be a app-specific message sent over websockets, which
> seems like it would work just fine.

s/would/could/: I don't think this has been discussed or agreed (and 
websocket is of course just an example).

I think it is worthwhile to push this kind of signaling into the media 
plane if possible. For example, this would enable the UA to save 
transmission/battery even if the app is badly written.

As an example: if a MST sent over a PC is not used in any way at the 
receiving end, the receiving end UA could signal TMMBR 0 to tell the 
sending UA to not send. Sure, the receiving UA could also fire a 
"negotiationneeded" event, but maybe the app doesn't listen.

>
>
> On Wed, Mar 12, 2014 at 12:50 PM, Bernard Aboba <bernard.aboba@gmail.com
> <mailto:bernard.aboba@gmail.com>> wrote:
>
>     While I do like the pause/resume draft, having core RTCWEB WG
>     documents (such as RTP Usage) depend on it seems like a bit of a
>     stretch. After all, the document was only adopted last week, and it
>     is a rare IETF WG document that can go from a -00 WG draft to
>     publication as an RFC in under a year.
>
>
>     On Wed, Mar 12, 2014 at 11:01 AM, Stefan Håkansson LK
>     <stefan.lk.hakansson@ericsson.com
>     <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>         Hi,
>
>         at the IETF last week there was consensus in the AVTEXT WG
>         meeting to
>         adopt the pause/resume draft [1] as a WG draft.
>
>         In rtcweb/webrtc we're have the situation that we're discussing so
>         called "doo-hickeys" as an API surface where the web app
>         (amongst other
>         things) can pause and resume the sending of a track. This can
>         be signaled with the direction attribute and a SDP O/A exchange
>         (and the
>         app pausing/resuming sending of a track would presumably lead to a
>         "negotiationneeded" event being fired).
>
>         But I think we should in addition require the browser to signal it
>         according to one of the methods in [1] (e.g. TMMBN = 0), and also
>         understand that signaling (a browser receiving TMMBN = 0 must
>         know that
>         the other end-point will pause sending).
>
>         My argument is that we know that many dislike SDP in rtcweb, and a
>         likely development is that it will be removed in a later version. My
>         speculation is that signaling as outlined in [1] will then be
>         used for
>         pause/resume. If we support this from the beginning earlier
>         implementations could more easily interop with those later versions.
>
>
>         Stefan
>
>         [1]
>         https://tools.ietf.org/id/draft-westerlund-avtext-rtp-stream-pause-05.txt
>
>         _______________________________________________
>         rtcweb mailing list
>         rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>         https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>