You have to connect via Internet to use Stratus.
When you call another peer, you initialize incoming NetStream this way:
inStream = NetStream(nc, farID);
where "nc" is NetConnection, connected to Stratus.
So, no connection to Stratus (no Internet connection) - no incoming stream.
I am using the Stratus Sample application.
I can make each peer connect, that's no problem.
And I also can make them call and accept calls locally.
But with two separate computers, over the internet, the calls do not reach the other peers.
It is exactly my problem on the thread below.
> inStream = NetStream(nc, farID);
I use neerID, like it was written in Adobe doc.
What's the diffference between neerID and farID?
And how about Flash Player version.
I can't hear an answer.
Is ver. 10.0.45 is enough or we need ver. 10.1
Perhaps Stratus on 10.1 is more stable etc...
m, two computers in the one local network? Are you sure?
If so, there can be a Firewall problem. Search forums, this kinda problem was discussed several times.
>inStream = NetStream(nc, farID);
farID is just a variable, it is a Stratus nearID of the peer.
You need flash player 10.1 and higher.
I don't think it is a firewall problem on my side.
I have 100% Stratus connections on my local network ,
but I have only 1-2% connections over the internet.
The both are on Flash Player 10.0.45.2
I did not try 10.1 yet.
I just installed Flash 10.1
50% connection with the same person on the internet is OK .
But in other 50% I don't see the partner. That is to say no connection, I don't receive his stream.
What a mistery?
I use "nc.nearID" to get my ID and to pass it to the partner via HTTP server.
Of course the partner's Flash program is the same and my computer receives such ID via HTTP.
Frankly I am tired from Stratus.
It does not work stable.
It seems I have to pay for FMS to make a normal service.
does the hosted version (on the Stratus labs web page) of VideoPhoneLabs work over the Internet?
for 1-to-1 P2P communication, there should be no difference between Flash Player 10.0 and 10.1.
NATs and firewalls are the bane of end-to-end communication in the Internet. end-to-end communication is not possible with some combinations of NATs. this subject is covered in detail in this thread:
if you and your counterpart over the Internet each look at http://cc.rtmfp.net/ and both of you have "No" for "Source UDP port number [or IP address] is preserved from original connection", or if one of you has a "No" for that one and one or both of you have "No" for "Can receive from different IP address, different UDP port number", then it's very likely (but not guaranteed) that P2P communication is not possible with your configurations.
Hmm. I have "Can receive from different IP address, different UDP port number" - NO.
But as I said Stratus connection can happen or not with the same partner.
I will try to find out partner 's settings.
Like it or not, Stratus looks me not as an instrument to work with.
"Can receive from different IP address, different UDP port number: No" means at least (probably) "port restricted cone NAT", and if the IP address and/or UDP port number isn't preserved, then you (probably) have a "symmetric NAT".
in most cases, a peer behind a symmetric NAT can't communicate with another peer behind a symmetric NAT or a port restricted cone NAT. that's because those kinds of NAT don't "BEHAVE" (see the documents of the IETF BEHAVE working group).
RTMFP works in nearly all cases in which working is possible. it does not work in cases that are impossible.
> it does not work in cases that are impossible.
It works or not.
I've heard in a different forum,
that in "impossible" cases the stream should go via Stratus server?
Is it true?
Perhaps it should, but does not work.
Or is it a joke?
the Stratus service doesn't provide FMS-like stream relay. you can use RTMP with your own server (such as FMS) when RTMFP doesn't work.
It is easy, but excellent idea!
Sorry to bring up this thread since it seemed a bit negative, but I am having the same issue and doubt its a firewall issue. My source code is provided in another post. But my streams do connect, but only like 10% of the time, however within my local network, things always seem to work. With some people outside my network they never connect. Can someoone perhaps provide source code for flex for a working example where each user would enter the netstream. I've tried working with code I found online but am having some problems. I recognize that my problems may be my coding abilities, but any help would be greatly appreciated.
if your Stratus code is working, then it is written correctly.
So it seems the problem is in Stratus, not in your code.
Sorry for bringing this up again, but seams I have the same problem other people are mentioning in this post.Cirrus is working locally, but many times it does not work via internet. The number is so significant that future development on RTMFP looks unfeasible. Correct me if I am mistaken, but I think there is no RTMFP documentation or RTMFP packet analyzer, and I could not figure out from packets returned from p2p.rtmfp.net where peer address and port number is stored, so I am left working with RTMFP like with black box.
I have variety of network configurations to work with and 8 PC - 6 of them running windows7 1 running Vista and one Ubuntu and one macBook air, so these are results I've collected
* If connection is via LAN - 100% everyday
* Via internet if peer has real IP, I did 5 tests in different days and worked 100%
The awkwardness starts where there is NAT for both peers. One day it is working, but then all of a sudden the another day it is not. If connection can be established, then I can call as many times in the row as I want. It tooks about 10-20 seconds for first connection to make, but after that connection is established within 5 seconds or so. Of course it will depend on network latency, but I am posting my real results here. I am using my developed application, but whenever connection can not be established, I use Adobes provided http://labs.adobe.com/technologies/cirrus/samples/ , but results are also unsatisfactory.
"One day working, another day not" paradigm sounds ridiculous, but it holds true for different network configurations and for different computers in different physical locations. That is what frustrates me the most. I had not made a tests weither there is colleration between "one day working another not working" for all network configurations, because I simply do not so much time.
Really what I need for doing decent investigation is ports and IP's for peer that is returned from p2p.rtmfp.net, because the I could see where the UDP hole punching fails. For the record, Skype works here well.
These are results in the log file for both peers from Adobe's provided sample:
Connecting to rtmfp://stratus.rtmfp.net
NetConnection event: NetConnection.Connect.Success
Connected, my ID: da40688ea976801106558d851be2f1897fa47b849426f3a785019d0e9497839e
ID event: registerSuccess
Listener event: NetStream.Publish.Start
ID event: lookupSuccess
Calling aaa, id: ee4baf220f69d08cdd97b41bee29607b43095cab53d687b52c6a776cf4dd96ee
Outgoing stream event: NetStream.Publish.StartThe other side never receives any incoming connection.So basically:* Is there some kind of steps I shoud take to ensure that RTMFP works, or written requirements that I need to meet to be sure that connection can be made?* is there a way to determine returned address and port number for other peer?
Allright, here basically is the problem. Cirrus is unable to do correct hole punching.
Look at the example.
First I run tshark on my Ubuntu server, that will display all packets comming to port 9900 (Server has real IP)
tshark -f "udp port 9900" -n
Then, on my local PC I run simple AIR application that sends random data to IP and port that I can specify in the application http://rapidshare.com/files/449519265/sock.air
I run also that application on remote PC, that I connect VIA remote desktop.
Then I send some packets to server's port 9900, and sure enough packets are starting to arrive
Now I enter each other's peer IP and peers port seen by server in both applications, and sure enough I can see in my sniffer that packets are starting to arrive
Remote Peer's sniffer
Nothing very impresive - simple hole punching, but http://cc.rtmp.net is showing me that I have symetric NAT
If Cirrus is using the same algorithm that http://cc.rtmfp.net is using, than for many occasional NAT configuration cirrus is not working, because it thinks peer is behind symetric nat, while in reallity it is not. I tested Skype and it was able to do dirrect P2P communication, whilst my application, that relies on Cirrus failed to connect.
Cirrus doesn't do anything different if you look like you're behind a symmetric NAT. the results from CC indicate that you're behind a symmetric NAT, because the source UDP port number of a probe packet sent to CC's listening sentinel (with a different IP address and port number than the main one) is different than the one it observes for your initial connection.
the "remote peer's sniffer" image shows sending a packet out toward the other peer's observed address and port, but doesn't show that being received by the other peer, nor does it show anything being received from that other peer. given the results from CC, it's unlikely that the indicated sent packet will be received by the peer at 220.127.116.11:63063.
there are a few symmetric NAT tricks that Skype tries that RTMFP doesn't, like doing "port prediction" to try to guess at the different translation another endpoint might see. in addition, Skype employs relay peers for when direct P2P doesn't work, and Flash Player won't do that.
Hi Michael, and thanks for a quick response.
You said that there is no evidence that packets are sent to the endpoint, but you are wrong.This is why I posted both sniffer screens. In both screenshots you can see red and green packets. Green color indicates that packets is sent our. Red color indicates that packet is received. In both screens there are red and green color packets, that definitelly prooves that packets travelled correctly.
Also I wrote that Skype was able to make *dirrect* P2P connection. From sniffer I was able to tell, that packets are sent dirrectly, without relaying.
Also I am pretty sure I have no symetric NAT here what is indicated by cc.rtmfp.net.
yes, i see now; i didn't get the "sniffer" displays before.
it does appear that your 18.104.22.168 is re-using its UDP port when talking to 22.214.171.124. however, when CC says "Source UDP port number is preserved from original connection: No", that's because the (one) UDP socket being used by RTMFP sent a packet to a different address/port on CC and it observed a different UDP port number. i examined CC's logs, and of the 7 times it connected, every time the UDP port was not preserved to the different-address sentinel.
this, combined with your packet sniffer observations, suggests a partially-symmetric NAT at 126.96.36.199.
i see in the CC logs that your 188.8.131.52 *does* preserve the UDP port when talking to CC's different-address sentinel. however, the firewall behavior is address and port restricting, meaning an introduction is required ("No" for "Can receive from same IP address, different port number" and "Can receive from different IP address, different port number"). that means 184.108.40.206 is a "port restricted cone NAT".
perhaps the NAT at 220.127.116.11 behaves in a "cone" fashion (re-using the UDP port for other endpoints) if the first packet for that endpoint is inbound, but creates a different translation if the first packet is outbound. an outbound packet would still be required to punch a hole (otherwise CC would have indicated "Yes" for "Can receive from different IP address, different port number"), but perhaps if that outbound packet comes after an inbound one, then the UDP port will be re-used.
if that's the case, then 18.104.22.168's NAT would behave as "port restricted cone", as would 22.214.171.124's, and direct communication would be possible. that would mean 126.96.36.199 was the first end to send a packet P2P, which might have been the case with your packet sniffer experiment.
RTMFP's startup/hole-punch protocol tries to have both ends sending packets toward each other (nearly) simultaneously; that could cause both ends to send outbound packets toward the other before any inbound packets arrive. for 188.8.131.52, that could cause it to be "symmetric" for 184.108.40.206 with RTMFP, and symmetric to port-restricted cone doesn't work with RTMFP. however, depending on timing/packet delays happening at the critical moment, perhaps sometimes the packet from 220.127.116.11 arrives at 18.104.22.168 before it can send an outbound packet, so it behaves as a cone NAT and RTMFP P2P can commence. that could explain your intermittent "works/doesn't work" observation.