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

[Paul Kyzivat <[e-mail]>]

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 case *I* care about right now is where one end is a CLUE server, and 
the other end is an RTCWEB browser client. CLUE needs a data channel, 
and we are aiming at one compatible with RTCWEB, in part precisely to 
make this case a possibility. And while RTCWEB doesn't care, CLUE wants 
to be able to use the same channel machinery with *neither* end is a 
browser.

Obviously this doesn't exist yet, so we are flexible about the details. 
But we need for it not to depend on being javascript to javascript.

	Thanks,
	Paul