Re: [rtcweb] Data Channel Negotiation and reopening of decisions

[Paul Kyzivat <[e-mail]>]

On 2/19/13 3:50 AM, Stefan Håkansson LK wrote:
> On 2013-02-19 00:25, Paul Kyzivat wrote:
>> On 2/18/13 6:45 AM, Tim Panton wrote:
>>>
>>> On 15 Feb 2013, at 21:15, Martin Thomson wrote:
>>>
>>>> On 15 February 2013 12:55, Michael Tuexen
>>>> <[e-mail]> wrote:
>>>>> I think I understand what you are proposing. But what happens, if
>>>>> both sides at about the same time open want to open a data channel.
>>>>> For both sides outgoing stream X is free, so they use this. So the
>>>>> endpoints end up with one data channel instead of two.
>>>>
>>>> Actually, I'd go further than that.  I'd require that browser
>>>> implement the same algorithm for selecting the stream to use.  That
>>>> implies that in all cases other than the rarest race conditions, you
>>>> get the same data channel.
>>>
>>> I'd remind everyone that in the case of the data-channel there are _no_
>>> cases where the endpoints don't know what the other end is supposed to
>>> be doing.
>>>
>>> There are no statically programmed legacy devices which support the
>>> data channel.
>>>
>>> Endpoints can be assumed to be dynamic javascript clients programmed
>>> to interoperate with each other,
>>> most often with the same javascript loaded from the same source and
>>> sharing a signalling channel.
>>
>> I disagree.
>>
>> For the cases RTCWEB cares about, presumably at last one end is a
>> javascript client. But the other end may not be. There can be many cases
>> where one end is a server.
>
> The normal way for a web application to communicate with a server is
> using http. Recently, more optimized means have been defined, WebSocket
> and Server-Sent Events.
>
> Of course you could terminate a rtcweb data channel in a server, but I'm
> not sure how much that really buys you over using WebSockets in practice
> (sure, WebSockets only support reliable delivery, so perhaps for low
> latency needs there could be a gain).
>
> But that said, why couldn't the server do the same things the client
> would do in JS over the currently defined data channel if you really
> want to use the rtcweb data channel for client-server communication?

The case I am thinking about is CLUE.

Ignoring RTCWEB, a clue session is a specialized sip session.
There could be two endpoints connected by SIP, or there could be two or 
more endpoints in a star configuration with an MCU, each having a SIP 
session.

Those sessions, endpoint-endpoint, or endpoint-mcu, need clue-specific 
data channel.

Now lets introduce RTCWEB into that picture. For simplicity, lets just 
consider the MCU case, where *one* of the endpoints is a browser. How 
will that work?

Clearly there must be a web server, that is only needed for the RTCWEB 
endpoints. It may or may not be collocated with the MCU.

Then we have two choices:

1) we implement clue endpoint code in javascript to run in the browser. 
The webserver acts as a source of the javascript, and as a gateway to 
sip. The javascript implements the clue protocol over the data channel, 
selects and establishes media streams, etc.

2) we implement clue endpoint code in the webserver on behalf of the 
endpoint. It implements the the clue protocol over a data channel, etc. 
It then uses proprietary signaling between itself and the browser to 
manipulate all the streams and displays.

I see (1) as the preferred path. IIUC what you are suggesting looks more 
like (2). In (2) the web server must be much more knowledgeable about 
CLUE. It also could be slow if things start happening in the data 
channel that must be mapped to http to be communicated to the browser.

	Thanks,
	Paul