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

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> 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
> https://www.ietf.org/mailman/listinfo/rtcweb
>