This content has been marked as final. Show 7 replies
Can you please look into this and drop me a quick note?
Question basically is: does Netstream.Play.Stop event immediately after subscribe sound like a firewall related issue? Are there other possible causes?
NetStream.Play.Stop looks like it can only happen if you say netStream.play(false) (or .play(null)), or in certain connection-drop situations. if there was a NAT or firewall issue, the RTMFP connection would not come up, and it would eventually time out (and you still wouldn't see that event -- you'd see NetStream.Connect.Closed after the timeout).
since you're seeing an immediate event (i assume on the subscriber end, not the publisher end), it appears that it must be either the subscriber stopping the play after a short time, or the publisher stopping play somehow.
if the sample app doesn't work at all, that suggests some kind of NAT or firewall issue. perhaps you have program logic that is time sensitive, so that if the connection doesn't come up soon enough it issues a play(false), which the sample app doesn't do.
I checked the code and found a redundant stream.close() prior to the second and further play() commands. First attempt did not respond and after 12 seconds user decided to close and reopen. This happened three times, each time without response.
Before second and further attempts, each time a stream.close() was issued just prior to creating new stream on received partner peer ID and issue stream.play().
Each such stream.close() generates as NetStream.Play.Stop event, which is handled as void, so we can forget about it.
So you are right that the NetStream.Play.Stop events were application generated.
Conclusion, in combination with Stratus videophone sample app, we have a NAT/firewall issue at hand.
Customer setup on the failing end is a private ADSL config with wireless access. From that location our classical FMS centric solution works fine.
What steps would you recommend to further diagnose and resolve the situation?
i assume that this customer is able to make a connection to Stratus (and that the NetConnection is giving NetConnection.Connect.Success). if that's the case, then UDP and RTMFP in general is working from the customer. this customer should then be able to make an outbound connection to a peer that is not behind a NAT or firewall, at the very least.
there are certain combinations of NATs and firewalls for which it is not possible to make peer-to-peer connections. another developer will be chiming in here shortly with a thorough treatment on this issue.
I posted the following message to the FLASHMEDIA mailing list about a month ago about how to use a server I run in my garage http://cc.rtmfp.net to test NAT/firewall properties:
IF the connection to cc.rtmfp.net has the same properties as the connection to/from the peer, then the results can be used to make a good guess as to whether or not a peer-to-peer connection can be formed. The fact that the connection in some cases does NOT have the same properties is why the results can't be relied upon completely. (As an example, two peers in the same organization behind the same firewall have different properties between each other than they each have to cc.rtmfp.net)
In order to guess, one needs to know that there are different types of NAT behavior. (I'll use the older common terminology below, rather than the new recommended terminology, as most people know the older terminology better):
Some reuse the same address and port when talking to different peers
("cone") and some pick a new address and port ("multiple IP address,
symmetric") or the same address but new port ("single IP address, symmetric"). There is also different filtering behavior of NATs and firewalls. (Note that a firewall may filter and not be a NAT, or a NAT can also act as a firewall and have filtering). The typical kinds of filtering behavior are none (for a cone NAT we would call that "full cone"), restrict to only talking to addresses we have talked to before ("address-restricted"), and restrict to only talking to addresses AND port numbers we have talked to before ("address- and port-restricted").
There are also firewalls that block UDP entirely.
Unfortunately, there are also even more complicated NAT and firewall behaviors that aren't easily characterized. For instance, some act as a symmetric NAT that preserves port numbers at first, then when they run out of resources they switch to being a cone NAT. Some act as one type of NAT for the first client that connects to a server, then a different type if a second client behind the NAT tries to connect to the same server. So this is another case where a simple analysis, like the one performed by cc.rtmfp.net, can fail to properly predict what will happen for the peer-to-peer connection.
But, if the connection to cc.rtmfp.net has the same properties AND the NAT or firewall has predictable behavior, here's what the results mean:
At the top, a successful RTMFP connection will result in "Analysis Complete". If you don't get that, UDP is probably blocked. (Or the cc.rtmfp.net RTMFP server has a problem... it runs on a machine in my garage, with no redundancy)
The for each yes/no answer, there's the following meaning:
"Knows public IP address of self" means that the Flash Player's idea of its local addresses has one address that matches the one that cc.rtmfp.net saw when the connection came in. If that is the case, there's no address translation.
"Public UDP port number same as local UDP port number" means that the Flash Player's idea of which UDP port number it is using matches what cc.rtmfp.net saw when the connection came in. If that is the case, there's no port translation. So if this and the above are "yes", then there's probably no NAT of any kind (but there still might be a firewall)
"Can receive from same IP address, same UDP port number" is always true, because if you couldn't do this you couldn't establish the initial connection.
"Can receive from same IP address, different UDP port number" tells you whether or not your firewall is "port restricted", requiring an outbound connection to the same address AND port number before inbound traffic is permitted from that address and port number, even after traffic was sent to the same address but different port number previously.
"Can receive from different IP address, different UDP port number" tells you whether or not your firewall is "address restricted", requiring an outbound connection to be made to a new IP address before inbound traffic is permitted from that IP address.
"Can send to different IP address after server introduction" should always be true if the initial connection can be made because, unless there is very strange firewall behavior, this is just like opening a new RTMFP connection initially. If this fails then either there's a problem with how the player received or treated the introduction request, or the firewall is totally unpredictable.
"Source IP address is preserved from original connection" means that either you have a cone NAT, or a symmetric NAT with only one IP address, or a symmetric NAT with multiple IP addresses *but* the same address happened to be used this time. If repeated tests cause this to change between yes and no, then you have a symmetric NAT with multiple IP addresses, and sometimes you happen to use the same address.
"Source UDP port number is preserved from original connection" means that you have a cone NAT. If this is "no", then you have a symmetric NAT.
Now, how does this tell you what will and won't work?
Symmetric NATs break peer-to-peer connectivity in some cases. Flash Player can work with almost all cone NAT configurations (though with some caveats if there are multiple layers of NAT and/or lack of "hairpinning" support), and many firewall configurations, but symmetric NAT in combination with certain firewall or NAT cases at the other end blocks the ability to establish a peer-to-peer connection.
If one end is a symmetric NAT with a single IP address, then connections to peers behind other symmetric NATs or behind port-restricted cone NATs (or port-restricted firewalls) are impossible.
If one end is a symmetric NAT with multiple IP addresses, then connections to peers behind other symmetric NATs or behind address-restricted (and likely port-restricted) cone NATs (or address-restricted or port-restricted firewalls) are impossible.
This is because no matter what the Flash Player tries to do to "punch a hole" through the restricted cone NAT or restricted firewall in order to let the other peer through, the other end keeps moving to a new address and/or port number that doesn't match up, so the hole that was created is no longer applicable.
The best choice is to allow UDP traffic through and to use a NAT and/or firewall device that complies with the NAT implementation recommendations of the IETF BEHAVE working group. Alternatively, an organization may choose to use the TURN proxy support in the player to send traffic to a proxy in a DMZ that can comply with those recommendations.
Application developers may also want to create fallbacks to client-server RTMP and/or RTMPT in order to cover the cases where a firewall or NAT blocks a direct peer-to-peer connection. It depends on whether you want your application to always work, or you want to never have to relay media through your server.
I'm building a desktop facebook client in AIR and using Stratus for pieces of it, including text chat over the netstream connections. I had a problem which sounds like it may be the same issue you are dealing with. When you're using a netstream connection without any audio/video being sent/received a call to NetStream.play will time out almost immediately and you'll get stop if the publishing stream on the other end doesn't send a response of some sort immediately.
I can also tell you that 9 times out of 10 my connections would simply fail when I was trying to connect two clients behind the same NAT device. Luckily I found an unprotected wireless connection nearby to test that theory with as it was starting to drive me crazy that it wasn't working when I knew it should be. As soon as I tried from two seperate internet connections it starting working perfectly.
If you want to see this in action the application can be found here: http://apps.facebook.com/desktopcommunicator/ you'll need a Facebook account to use it though. There is also a video chat portion that uses stratus, however that opens it's own separate netconnection and a different set of classes. The text chat piece never has audio or video attached either in or out, so it's pretty much what you're looking to do judging by what you wrote.
Thanks, Matthew, for this excellent coverage of the NAT issue and related test service.
I asked many people to perform the test and to send me their results.
So far I got responses from 10 different network locations.
2 out of 10 show a red signal at the last test (so they don't preserve source port), indicating symmetric NAT, and consistently for them peer-to-peer comms doesn't work.
I have then requested those two to send me details about their local network configuration and internet provider.
They both have their Internet services from KPN ( http://www.kpn.com/internet.htm), using "Thompson KPN Experia Box" and "Siemens KPN Experia Box".
The Thomson one seems to be actually the SpeedTouch ST780.
I have read through the manual and found this paragraph:
UPnP provides NAT-Traversal: UPnP aware applications on a PC will
automatically create Hyper-NAT entries on the SpeedTouch™ for incoming traffic on the protocol ports this type of traffic needs. As a consequence these applications are able to traverse the SpeedTouch™ without the need for extra and manual configuration.
UPnP is an architecture for transparent peer-to-peer connectivity of
computers, intelligent appliances, and (wireless) devices. It enables
seamless operation of a wide range of games and messaging
My questions now are:
(1) Is there a chance to reconfigure such devices as Cone NAT?
(2) Can we somehow exploit this UPnP architecture to reconfigure on-the-fly?
(3) Would it be possible to use just the modem part of such a device and hook a new wireless router that uses Cone NAT to it?
Looking forward to your insights.