Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07

[Paul Kyzivat <[e-mail]>]

On 7/23/14 9:19 AM, Justin Uberti wrote:
>
>
>
> On Wed, Jul 23, 2014 at 8:23 AM, Paul Kyzivat <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On 7/22/14 7:56 PM, Christian Groves wrote:
>
>         The browser would delay the establishment of media that are part
>         of the
>         "a=group:clue" group until a CLUE exchange has taken place and those
>         media have been selected via a CLUE configure message. I'm not
>         sure if
>         that fits your criteria for acting differently?
>
>
>     I haven't thought about it much, but I think there are a couple of
>     ways to deal with that. One is to simply hide those from the browser
>     until the desired time. Another is to mark them as inactive for the
>     browser until configured.
>
>     A more difficult problem is that CLUE uses one-way media streams,
>     while jsep forces opposite direction ones to be merged into a single
>     sendrecv m-line. I don't know how to fix that.
>
>
> If you can demonstrate a specific problem that this causes, we can
> re-evaluate this. But we need to ensure that a simple phone call ends up
> with a single m=audio line.

The fundamental problem with this is that AFAICT it makes it impossible 
to build a WebRTC client that can interop with a CLUE server. I guess it 
would be possible with a special purpose media gateway that demuxed the 
clue media from sendrecv m-lines to sendonly & recvonly m-lines.

As another clue person said today, CLUE chose to use sendonly and 
recvonly m-lines so we could use the sendonly ones to provide SDP 
descriptions of what is available to be *sent*. (With sendrecv m-lines 
this describes only what is desired to be received.) Clue use cases are 
likely to be highly asymmetric, so it is essential to be able to do this.

Clue does have a solution for the simple phone, but it probably isn't a 
solution that would be satisfactory to rtcweb. The first O/A on a CLUE 
session assumes it doesn't know what it might be connecting to, and so 
makes an offer that is likely to work with "legacy" devices. Generally 
this would be one sendrecv audio and one sendrecv video, though YMMV. 
There are a few other things in there that allow the two ends to 
discover if they both can do clue after the first O/A.

If both do clue, then there is another O/A that provides sendonly 
m-lines for the offerer. And there will be a 3rd that provides sendonly 
m-lines by the other end. We consider this tolerable for telepresence.

The first O/A will also include DTLS/SCTP m-line that is intended to 
carry the CLUE data channel. (Assumed to be rejected by a "legacy" 
device.) While we don't require it, bundling is very attractive for 
clue. So if ICE has succeeded for that m-line, the subsequent O/As can 
add all those sendonly m-lines in the same bundle, so no new ice will be 
required.

	Thanks,
	Paul