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

[Justin Uberti <[e-mail]>]

On Fri, Mar 14, 2014 at 4:25 AM, Stefan Håkansson LK <
[e-mail]> wrote:

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

It's not clear to me what the interactions are between the signaling and
media plane when this occurs. That is, if I do doohickey.active = false,
should that cause a=recvonly signaling and a TMMBN notification that the
track is paused? I am concerned that things can get out of sync (i.e. what
happens if we get TMMBR indicating resume, but signaling is still
a=recvonly)?


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

OK.


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

Right, the whole thing is an example, but the point is that the new API
directions don't really affect this particular problem.

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

True, if the app doesn't perform the necessary signaling, things are not
going to work, but that applies to a lot of operations on the
PeerConnection.

Overall this feels to me like something that needs some thought to figure
out all the interactions between the API, the signaling plane, and the
media plane. As such I am inclined to leave this out of 1.0.

>
> >
> >
> > On Wed, Mar 12, 2014 at 12:50 PM, Bernard Aboba <[e-mail]
> > <mailto:[e-mail]>> 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
> >     <[e-mail]
> >     <mailto:[e-mail]>> 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
> >         [e-mail] <mailto:[e-mail]>
> >         https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> >
> >     _______________________________________________
> >     rtcweb mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
>
>