i just installed a new version of the Codename Cirrus software on the cluster. unfortunately there were incompatible back-end data format changes in this new version which required a complete shutdown before restart (usually we can do a non-disruptive soft restart that's invisible to end-users). as a result, the system was completely unavailable from 22:54:04 UTC to 22:54:57 UTC (for 53 seconds at 2:54 PM pacific time).
the last restart was in june of 2010.
the new server software has two interesting new features.
1) you can now place your developer key as the second parameter to NetConnection.connect() instead of appending it to the connect URI. this improves security by not having your developer key transmitted (effectively) in the clear as part of the RTMFP Initiator Hello message (which is encrypted with the well-known default session key).
example: if your developer key is "000000000000000000000000-000000000000", you used to do
var nc:NetConnection = new NetConnection();
but now you can instead do
var nc:NetConnection = new NetConnection();
we haven't yet updated the developer key signup page or samples to indicate this new method, but it is the preferred way.
2) Codename Cirrus now supports a very simple message relay service, which is intended for sending a short message to another peer connected to the system. the intention is to simplify the signaling problem for setting up 1:1 P2P communications. this relay service is not intended to take the place of P2P communication, and we may disable or rate limit it if is used excessively (providing this service consumes a large amount of server resources compared to P2P introduction). please limit your use of this facility to sending no more than one or two short messages to another peer, hopefully to signal the peer to set up a 1:1 P2P channel.
to use this facility, you must know the peerID of the peer to which you want to send a message.
the sender requests a relay as follows:
// nc is a NetConnection connected to the Codename Cirrus service
nc.call("relay", null, destPeerID, ...); // "..." is zero or more AMF serializable objects
the receiver (destPeerID) receives this message on its NetConnection's client object's "onRelay" method:
public function onRelay(senderPeerID:String, ... args):void
// on sender peerID 9876 sending to peerID 1234
nc.call("relay", null, "1234", "INVITE");
// on receiver peerID 1234, this callback happens
we're working on incorporating both of these new features into our sample material.
our p2p software was working fine and today can't connect to the stratus/cirrus server.
so we resigned up. same problem.
we used to connect to rtmfp://stratus.adobe.com/blah
and we connect to rtmfp://p2p.rtmfp.net/blah
but still fails.
are things still down?
the service was only down for 53 seconds yesterday.
if your devkey begins with "8b8c..." then i think you might have something in the second parameter to NetConnection.connect(), perhaps a blank string or otherwise something that doesn't look like a developer key. if you're putting your developer key in the connect URI, make sure there is no second (or more) parameter to NetConnection.connect().
if your devkey begins with "3b91...", then you're putting the entire URI as both the first *and* second parameters to NetConnection.connect(). in other words, you're saying
but you should be doing one of the following:
i also can see a developer key beginning with "9a20..." in the same boat as the first case i described.
developer keys "8b8c..." and "9a20..." are using "stratus.adobe.com" as the hostname for the service. you should change to "p2p.rtmfp.net".
our developer key starts with 5c...
and we haven't changed anything since it started working 6months ago. didn't realize a change was required... (?)
will try the changes you sugged but those keys u mention are not ours.
I've built an application using Cirrus as a testing platform. I'd like to deploy it on my own FMS, but the example code seems to be missing the FMS server side code that implements the 'very simple message relay service' (i.e. nc.call(...) functionality). Can you please provide this so that I can deploy my tested application without being bound to the cirrus server TOS.
This answer is not very satisfying, especially since Cirrus is not commercially available. I'm a paying customer who wants a turn key baseline p2p video chat implementation that works with FMS. I haven't been able to find one. Cirrus is the closest, but you are expecting your customers to reverse engineer the server code to get it to work with FMS. That just seems wrong. On top of that, Adobe engineers claim that the cirrus samples should work with FMS (see the comments in this article: http://www.adobe.com/devnet/flashplayer/articles/rtmfp_cirrus_app.html)
The sample app is by no means a turn-key commercial video chat app. First of all, it lacks user authentication. It uses a web-service for user registration and lookup. Second, it does not have any failover for firewall blocking.
Please see http://www.adobe.com/devnet/flashmediaserver/articles/real-time-collab oration.html, which describes issues that you need to solve for a commercial video chat application.
Nevertheless, here is some SSAS that performs the relay operation that is used in the sample application:
function relay(id, command, data)
for (i = 0; i < application.clients.length; i++)
if (application.clients[i].farID == id)
application.clients[i].call("onRelay", null, this.farID, command, data);
trace("User not found: " + id);
I believe the relay solution is for the Video Phone Labs sample app. Can I get this to work on Flash Media Server ( FMS ) on Amazon Web Services ( AWS )?
From what I understand from the below link Flash Media Server on Amazon Web Services supports peer-assisted multicast streaming. It does not support IP multicast or fusion multicast.
Could you tell me if Video Phone Labs depends on IP multicast or fusion multicast?
Europe, Middle East and Africa