W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2011

Re: Flows vs Sessions (was Re: Mozilla/Cisco API Proposal)

From: Randell Jesup <randell-ietf@jesup.org>
Date: Mon, 18 Jul 2011 23:31:39 -0400
Message-ID: <4E24FA9B.4000504@jesup.org>
To: public-webrtc@w3.org
On 7/18/2011 10:26 PM, tom wrote:
>>> And, Could you please express: How does MFP punch hole of NAT/FW,
>>> especially when both peers are Symmetric NAT´╝č
>>>
>> MFP and RTMFP both are able to go through a "symmetric" NAT if it is possible to provide correct candidate UDP address+port pairs to each end. As that is often impossible, it fails in these cases. Inside Flash Player, RTMFP relies on the fact that every Flash Player can also speak RTMP over TCP and even RTMPT over HTTP in order to bypass every other type of NAT or firewall using a Flash Media Server as a relay.
> the key point is How to get the candidate UDP address+port pairs,
> because UDP punching hole doesn't work, if both peers are Symmetric
> NAT. Guess that Skype has the special algorithm for it.

Previous data on the Skype protocol indicates that data is never sent 
peer-to-peer directly;
it uses super-nodes as relays.  That's not to say it *couldn't* go 
peer-to-peer in some cases,
but last I knew it didn't.  This also avoids legal issues with CALEA, 
for example.  Supernodes
can be other users (not on symmetric NAT), or servers owned by Skype, or 
cloud
(amazon ec2, etc) servers.

Sometimes you can anticipate the mapping a symmetric NAT will use (if 
they're consecutive),
but in most cases it's impossible, and for symmetric-NAT to 
symmetric-NAT a relay server of
some type MUST be used.  This is all standard ICE stuff.

-- 
Randell Jesup
randell-ietf@jesup.org
Received on Wednesday, 20 July 2011 07:20:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 20 July 2011 07:21:00 GMT