Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

I don't think it makes sense to lump TURN functionality (e.g. TURN over TCP, TLS or WS) in the same bucket as transport over HTTP/HTTPS or WS, since the former involves the PeerConnection API but the latter need not. 

If ICE fails, an application can try alternatives. As long as those alternatives don't involve peer to peer transport of media over http/https or WS, it isn't clear to me that we need a standard encapsulation. And if we are talking about peer-to-peer then this implies an http/https or WS server in the browser, which seems like it is out of scope, at least in this discussion.

On May 24, 2013, at 3:26, "Chenxin (Xin)" <hangzhou.chenxin@huawei.com> wrote:

>   I agree that we should not try to battle with network administrator, and we are not doing that. We just supply some technical tools to rtcweb implementer, to make the users could get benefit and convenience when using rtcweb. Fallback methods and proposals are for this purpose.  We could not decide that how will a kind of technique be used. Every technique could be used in a good way and a bad way.  I believe that rtcweb is a good and trustworthy technique which is different with the some harmful things which should be blocked by the administers. So let us back to the technical aspect: should we need to support a fallback method in rtcweb now? Which one should we support to MTI? Which one should we support to be a option? I think now there is three method to solve the fallback requirement：TURN/TLS, HTTP channel , TURN/WS or HTTP. I am willing to write a mail these days to make a simple conclusion and comparison between these methods, which will provide a material to WG for future discussion and decision.
> 
> Best Regards,
>     Xin 
> 
> 
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
>> Simon Perreault
>> Sent: Wednesday, May 22, 2013 5:31 PM
>> To: Karl Stahl
>> Cc: rtcweb@ietf.org; behave@ietf.org
>> Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for
>> draft-chenxin-behave-turn-websocket-00.txt
>> 
>> Le 2013-05-22 11:04, Karl Stahl a écrit :
>>>> Firewall traversal is a completely different beast.
>>> 
>>> Not really. There are always firewall functions included in "a NAT" (e.g.
>>> open for traffic from inside to outside and you can then get traffic back
>>> the same path - with some timeout), even if the RFCs only call the box "a
>>> NAT". I prefer to say NAT/Firewall.
>> 
>> You're focusing on the technical aspect. The difference I'm considering
>> is not technical.
>> 
>> NAT traversal is performed with the agreement of everyone involved,
>> whereas firewall traversal is a battle between the client implementer
>> and the firewall administrator. There's also a potential arms race:
>> firewalls will evolve with the ability to block whatever we standardize,
>> so we will need a newer traversal method, which firewalls will end up
>> blocking as well, etc. etc. etc. We don't want to play that game.
>> 
>> NAT traversal: ok
>> Firewall traversal: not for the IETF
>> 
>> Simon
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb