Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12

["Parthasarathi R" <[e-mail]>]

Simon,

Please note that when non-IETFers read this requirement document, they come
to the conclusion that IETF RTCWeb WG recommends TURN and not other
mechanisms. I'm saying that requirement document should not be used as the
mechanism to eliminate the other alternatives when there is a discussion
going-on in PNTAW alias. So, I'm asking for the change. 

Let us discuss in PNTAW alias which Firewall/NAT mechanisms have to be used
by WebRTC client, WebRTC gateway/server (Sec 4.3 of
draft-ietf-rtcweb-use-cases-and-requirements-12) and not as part of the
requirement draft.

Thanks
Partha    

> -----Original Message-----
> From: Simon Perreault [mailto:[e-mail]]
> Sent: Friday, January 24, 2014 10:01 PM
> To: Parthasarathi R; [e-mail]
> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-
> requirements-12
> 
> Le 2014-01-24 11:23, Parthasarathi R a écrit :
> > I could not understand how does it make sense for you to refer "TURN"
> in the
> > requirement whereas it implies "PCP" or "ICE-TCP" or "TURN over
> WebSocket"
> > in the solution.
> 
> I understand the text you're suggesting to mean that WebRTC clients
> would be required support at least one in the set { TURN, ICE-TCP, TURN
> over WebSocket, PCP }. This would be broken. A client that chooses to
> support, for example, only PCP would be ridiculously broken. All
> clients
> MUST support TURN as a base traversal mechanism. Other mechanisms are
> icing on the cake.
> 
> I'm fairly sure this is not what you were suggesting though, since that
> would be so obviously broken. That's why I said that your suggestion
> makes no sense to me.
> 
> 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