- From: tom <zs68j2ee@gmail.com>
- Date: Tue, 19 Jul 2011 10:26:51 +0800
- To: Matthew Kaufman <matthew.kaufman@skype.net>
- Cc: public-webrtc@w3.org, xiong.jaguar@gmail.com
On Tue, Jul 19, 2011 at 2:47 AM, Matthew Kaufman <matthew.kaufman@skype.net> wrote: > > On Jul 16, 2011, at 7:49 PM, tom wrote: > >> Hi Matthew Kaufman: >> >> Good thoughts to reuse one session to carray may flows of services >> between the same peers. > > My real point was that not only is there value in reusing the "session setup" work (ICE, key negotiation, etc.) but there is significant value in having the API hide the details of this, so that opening a flow that needs a new session is exactly the same API as opening a flow that reuses an existing session, if one is present. > >> >> 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. > > Matthew Kaufman > >
Received on Tuesday, 19 July 2011 02:27:18 UTC