Subscribe immediately followed by Netstream.Play.Stop

Question

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
shared objects.
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?

Answer 1

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.
Matthew Kaufman