[rtcweb] We are moving beyond the assumptions on which O/A is based

[Paul Kyzivat <[e-mail]>]

I found what Stefan said below to be interesting:

On 5/11/13 8:20 AM, Stefan Håkansson LK wrote:

> Absolutely. The API (as of now) is aligned towards sending media. You'd
> construct a PC-stream containing PC-tracks which in turn corresponds to
> microphones and cameras. If you want to send that PC-stream to a peer
> you do "addStream" with it on a PeerConnection. If you want to add or
> remove a PC-track, there are operations for that - and it would be
> reflected on the far end.
>
> The point is that the API is about sending - not about setting up a
> session with a certain amount of ougoing and incoming PC-tracks, and to
> me that harmonizes very well with the handshake in
> draft-uberti-rtcweb-plan-00 which has separate O/A exchanges for media
> A->B and B->A respectively. An additional benefit seems to be that those
> two exchanges are somewhat independent and would not cause glare. This
> is denoted as a 3-way handshake in the draft, that is a bit misleading
> perhaps.

A very similar situation holds for CLUE.

Maybe this is a more fundamental change than we have been thinking.

O/A works best when both sides have similar capabilities and desires. 
(It makes sense to set up to receive what I hope to receive, because it 
is likely that you will want to send that.) It works poorly when you and 
I might have a highly eclectic set of stuff we could send, and 
unpredictable interests for what we are interested in receiving.

In clue we are addressing that by exchanging (in a separate channel) 
advertisements of what the endpoints are willing to send, and only doing 
O/A to set up the media that is of interest.

In rtcweb it isn't so structured, but I suspect something is happening 
implicitly, though it may be more hard-wired per application.

In clue we may still end up negotiating separate one-way streams in each 
direction, similar to what Stefan mentions below. With bundling there 
isn't a big penalty for that (e.g., in ports and RTCP traffic) though 
there is an extra O/A required.

But for both RTCWEB and CLUE there are cases where we must negotiate 
bidirectional streams for compatibility with legacy devices. So there 
must be a way to do that.

I don't have a specific action to recommend here. This just seems like a 
somewhat fundamental shift that out to be recognized. It probably isn't 
just RTCWEB and CLUE, it is really related to more complex communication 
scenarios. ISTM that CLUE is addressing this by building a layer on top 
of O/A, while RTCWEB is *battling* with O/A.

	Thanks,
	Paul