Re: [clue] AD Review: draft-ietf-clue-signaling-11

[Paul Kyzivat <[e-mail]>]

On 8/24/17 8:29 PM, Adam Roach wrote:

> The reason this seems counter-intuitve to me is that it is backwards 
> from how RTCWEB (JSEP) works in the general case. To be clear, for 
> datachannels, the TLS client is selected by the "a=setup" attribute; and 
> JSEP implementations are required (MUST) to put "a=setup:actpass" in 
> their offers, and expected (SHOULD) to put "a=setup:active" in their 
> answers. The rationale here is: the way ICE ends up working, the 
> answerer will have the first opportunity to send a packet, so this 
> reduces overall setup time by ~1/2-RTT.
> 
> Of course, CLUE is free to do this however it wants [1]; but doing it 
> opposite from RTCWEB is likely to confuse people beyond just me. I think 
> you'd also need a reasonably good rationale, as a naïve analysis of CLUE 
> is that doing it the way you currently have in your examples is 
> generally going to impose an additional 1/2-RTT delay on datachannel 
> establishment. But I freely admit that I haven't spent a lot of time 
> thinking about the low-level details, and could be overlooking something.

It does seem to me that this needs to be carefully aligned with RTCWEB 
because one of our goals was that interoperation with RTCWEB be 
possible. (That is why we chose data channels in the first place.)

	Thanks,
	Paul