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

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 12 Mar 2014 18:01:56 +0000

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Mar 2014 12:50:25 -0700

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 <
[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 12 Mar 2014 13:56:08 -0700

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

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.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 14 Mar 2014 11:25:51 +0000

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

> 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 <[email-masked]
> <mailto:[email-masked]>> 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
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hi,
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 14 Mar 2014 09:15:20 -0700

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

> TMMBN 0 way to signal that is mentioned in [1] (and not any of the "new"

OK.

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

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

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 14 Mar 2014 10:56:39 -0700

Justin said:

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

[BA] I agree.

"It's not clear to me what the interactions are between the signaling and
a=recvonly)?"

[BA] A few thoughts:

a. Even though TMMBR/TMMBN is mandatory-to-implement in the RTP usage
document, I don't think we can assume that the pause/resume will be
supported by all mixers.. It therefore probably isn't a good idea for a
browser to automatically send a TMMBN 0 indication when setting
rtpsender.active = false.  Since the application might or might not use SDP
for signaling, this is probably something that needs to be under
application control.  BTW, Section 6.3, isn't clear about the response to
an unsolicited TMMBN (TMMBR 0?).

b. As described in Section 1, pause/resume is for use in scenarios where
signaling might not meet the performance requirements.  Due to the
differing transport characteristics of RTCP and signaling over reliable
transport, trying to use both pause/resume and signaling is quite likely to
result in them being out of sync, so my assumption was that an application
wishing to support pause/resume would not choose to use signaling for the
same purpose.   There is also the potential for conflict between
codec-specific messages (e.g. layer drop in H.264/SVC) and some potential
uses of pause/resume (e.g. unsolicited TMMBN to indicate layer pause in
multi-stream SVC).  Where there are conflicts, my assumption would be that
signaling and codec-specific messages should win.

---

From: Randell Jesup <[email-masked]>
Date: Tue, 18 Mar 2014 18:58:05 -0400

On 3/12/2014 4:56 PM, Justin Uberti wrote:
> replacement would be a app-specific message sent over websockets, 
> which seems like it would work just fine.

Except that WebSockets doesn't work peer2peer, which means both delay 
and issues with signaling configurations without a server sitting 
between the users.

However, an app-specific message sent over a DataChannel should work 
just fine.

The downside would be that everything becomes app-specific, which would 
be a problem for any sort of federation or peering setup, and likely 
gatewaying to legacy.

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 20 Mar 2014 09:15:10 +0000

> be a problem for any sort of federation or peering setup, and likely

I'm of the opinion that we should push a lot of signaling like this 
(pause/resume) to RTP/RTCP for those reasons, and in addition to enable 
the UA to save power/transmission for the user.

But perhaps Bernard and Justin are right, this (v1) is not the right time.

---

From: "Roni Even" <[email-masked]>
Date: Thu, 20 Mar 2014 13:41:47 +0200

Hi,

The pause and resume has the tmmbr=0 option based on RFC5104 (No IPR in the data base for RFC 5104; http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-ietf-avt-avpf-ccm)  . this works well for point to point case.

Roni

From: rtcweb [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 12 March, 2014 10:56 PM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: [rtcweb] Should we reference the pause/resume I-D?

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

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.

On Wed, Mar 12, 2014 at 12:50 PM, Bernard Aboba <[email-masked]> 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 <[email-masked]> wrote:

Hi,

Stefan

[1]

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 20 Mar 2014 20:25:05 +0000

Caveats to be aware of with the tmmbr=0 approach include:

  *   tmmbr=0 implies pause, but it is indistinguishable for tmmbr being set to 0 for other reasons
  *   knowledge of an appropriate value to set for resume is not always available at the RTCP layer (implementation dependent)
  *   theoretically not appropriate to jump directly back to tmmbr=<value prior to pause> even when known

Despite these caveats, I agree with Roni that using tmmbr=0 for pause has worked relatively well in enterprise SIP deployments.

Cheers,
Charles

From: Roni Even <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 20, 2014 at 4:41 AM
To: Justin Uberti <[email-masked]<mailto:[email-masked]>>, 'Bernard Aboba' <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Should we reference the pause/resume I-D?

Hi,

From: rtcweb [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 12 March, 2014 10:56 PM
To: Bernard Aboba
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Should we reference the pause/resume I-D?

On Wed, Mar 12, 2014 at 12:50 PM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Stefan

[1]

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb