Re: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt

[Simon Perreault <[e-mail]>]

Le 2013-09-13 22:26, Sergio Garcia Murillo a écrit :
> So, at the end, the ChannelData message is just another TURN message, so
> it will be encapsulated inside a websocket frame. If you feel it is not
> clear, we can add more details about it in next draft.

You're right, I was mistaken about this. Thanks for the detailed 
explanation. No need for more details.

> Regarding RFC 6062, we had some internal discussion regarding if we
> should add websocket support at all to it or not. Mainly, because AFAIK,
> webrtc will use RFC 5766 and not 6062. Anyone please correct me if I am
> wrong.

I think a better justification would be "because WebRTC data channel 
will use SCTP over DTLS".

> I agree with you that this has not been well covered in the draft. In
> order to make the minimun changes possible, and align it with the
> general view of changing just the turn client to turn server
> encapsulation protocol, I would propose to extend websockets usage only
> for the turn control connection in RFC 6062 but keep turn data
> connections on TCP.

So with an HTTP proxy the control would be over websockets and the data 
would be through the CONNECT method? Yuck...

> That, or drop RFC 6062 extension altogether and just
> focus on 5766. What do you feel it would be best?

I say focus on 5766.

I have a new question: what does the TURN server put in the 
XOR-MAPPED-ADDRESS attribute? The proxy's address or the client's 
address? Can TURN over WebSockets be used to gather server-reflexive 
candidates?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca