We are in general successfully using Stratus with our
redesigned, previously fully FMS3(TCP), coaching application.
We still do all non-audio/video comms, including the
signalling for audio/video and chat, the traditional way, using
Now we have one customer with whom we can't get audio/video
going this way. All other things work. We get a peer id from him,
then subscribe to that, but the subscribe is immediately followed
by a Netstream.Play.Stop event.
With the Stratus sample app we get nothing going at all.
Although my suspicion goes to local firewall and NAT issues,
I still would like to hear your interpretation of this sequence of
events. We have lately seen no other firewall/NAT issues, so I
wondered whether NAT is still an issue with Stratus and a potential
cause of this type of behaviour?
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
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
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
("cone") and some pick a new address and port ("multiple IP
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
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
"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
"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
"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
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
If you want to see this in action the application can be
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
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
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 (
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
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
UPnP is an architecture for transparent peer-to-peer
computers, intelligent appliances, and (wireless) devices. It
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
(2) Can we somehow exploit this UPnP architecture to
(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?