i'm not familiar with Influxis' offering. however, if you're publishing on a NetStream that was created as
var ns:NetStream = new NetStream(netConnection, NetStream.DIRECT_CONNECTIONS);
then, assuming netConnection is an RTMFP NetConnection, the server has nothing to do with the publishing part and there's no way for it to keep you from publishing.
the Cirrus servers silently ignore any client-server NetStreams that are created. if you are creating any client-server NetStreams with the Influxis server and publishing on it, then it's very likely the Influxis server is sending you an error that you wouldn't've seen with the Cirrus servers (the Cirrus servers are not FMS).
So, I basically took the VideoPhoneLabs example found here: labs.adobe.com/technologies/cirrus/samples/
and simply replaced the code 'netConnection.connect(connectUrl, DeveloperKey);' to a call netConnection.connect(<influxis server url");
I put a main.asc file in the myApp folder, but basically it doesn't do anything.
Correct me if I am wrong, but I believe you are saying that the main.asc file is not relevent in an RTMFP connection, and that the 2 peers
should function as they do when I am connected to Cirrus without any special coding.
If this is true, then what I am thinking is that FMS is not providing me a true RTMFP, even though I am using the "rtmfp://<influxis server url>" address.
Thanks and I appreciate your response on this thread. I would like to build this thread up with more discussion as I meander my way through this
as I am sure others will find this very useful and I would be glad if they could benefit as well.
Thanks Michael and look forward to more comments, as will supply the same.
if you have an RTMFP connection to a server, then there is nothing the server should be able to do to keep you from making a DIRECT_CONNECTIONS NetStream and saying "publish" on it. the server is not involved.
are you sure that your NetConnection is still open when you issue your publish()? VideoPhoneLabs uses the Cirrus "relay" server method, which you must supply yourself on FMS. perhaps FMS is closing the NetConnection on receipt of this unknown command or something.
So, I read these threads. I added Jozsef's relay method to my main.asc
file. In fact, this is the ONLY method I have in my main.asc file on
the FMS server.
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,
trace("User not found: " + id);
When I press the call button, I see the following in the status window
of the calling client:
ID event: lookupSuccess
Calling email@example.com, id:
Outgoing stream event: NetStream.Publish.Start
NetConnection event: NetConnection.Call.Failed
Nothing on the callee status window appears after the connected message
(Nothing happens on the callee side at all after the caller presses
the call button).
So, I looked at the code and found the below segment and now have the
1) In the netConnection.call method below there are 5 parameters, the
first one is the name of the remote method "Relay", but note the next 4.
They don't line up with the Relay method signature in the main.asc
2) How does the callee know about this stream named "media-caller"?
3) It is obvious that the o.OnPeerConnect() function is not being called
on the callee side, since the message:
Callee connecting to media stream.... is never seen there.
Any help to connect these dots would be greatly appreciated. Since
Jozsef wrote the VideoPhoneLabs Cirrus app, can you ask him
to weigh in on this, if necessary?
The goal here is simply to get the VideoPhoneLabs app. that Jozsef wrote
and have it work on FMS
with some real clear explanation of what needs to be added to the
original code that was published in the article.
The main.asc file would be included in this explanation as well as any
changes to the client side code.
Thanks for your help Mike. I hope to get this to work and I know others
will appreciate the complete working adaptation of the excellent
VideoPhoneLabs app that Jozsef had earlier put together!
private function placeCall(user:String, identity:String):void
status("Calling " + user + ", id: " + identity + "\n");
if (identity.length != 64)
status("Invalid remote ID, call failed\n");
currentState = CallFailed;
netConnection.call(Relay, null, identity, Invite,
// caller publishes media stream
outgoingStream = new NetStream(netConnection,
var o:Object = new Object
o.onPeerConnect = function(caller:NetStream):Boolean
status("Callee connecting to media stream: " +
caller.farID + "\n");
I haven't found any other references (other than the ones you specified above) than this one here http://forums.adobe.com/message/3768213#3768213?
At the end, Denis_Nazarov states that he has solved his problem, but I am still at a loss. Can you please specify the references to the two pages of Jozsef's original article that might correct
the issue I'm having?
Jozsef's article is here:
go to the bottom of the page (where the comments are), and click the "2" to go to the second page. then search for "FMS" in the comments section. there are numerous comments and replies from Jozsef regarding getting VideoPhoneLabs to work with FMS.
I ran into this issue in the past and managed to solve it. Create a new main.asc and open it with a text editor of your choice. Then paste in this:
Client.prototype.relay = function( 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'm not sure if it still works it has been a while but give it a go and let me know.
The provided solution allows to establish RTMFP connections between peers, but some functionalities still not work such as Object Replication. Does anyone have a hint on how to debug calls to the RTMFP server to see what methods are being triggered and not found when using Object Replication or any documentation that might shine some light on the problem. I believe Object Replication has some more server specific logic besides the Client.Relay function. NetGroup join works OK, but peer pairs do not connect in a NetGroup.
i assume that you're using a group specification string, and not a bare peer ID, when making the new NetGroup (otherwise you wouldn't get the NetGroup.Connect.Success). and i assume you've set GroupSpecifier.serverChannelEnabled=true to get the server to bootstrap your group, or it wouldn't work with Cirrus.
other than peer introductions and group bootstrap, the server is not involved in any way with Object Replication. and note the Client.relay function is only necessary for compatibility with applications written for Cirrus; it's not a standard thing.
there is a setting in FMS for whether it will do group bootstrapping completely automatically or if it will be percolated up to server-side script. if your FMS isn't doing automatic group bootstrap for clients that have set serverChannelEnabled=true for their groups, then you might have the server set to not-totally-automatic mode. i'm not 100% sure of the settings for that -- i'm not an FMS expert. the best place to ask is the FMS forums. i *believe* the setting is in the Application.xml file, and in the "GroupControl" section, there should be a setting that should be
the "None" setting should cause the server to handle bootstrapping automatically. other settings send events to server-side script. i think at least one of the sample applications that comes with FMS may handle those events, but i don't know for sure. again, asking in FMS forums should yield better results.
Thank you for the hint. I came across the FMS configuration PDF that explains in detail the different options that can be configured in the application.xml file. Nevertheless, it still will not work. The NetGroup connects succesfully but connections between peers in a group are not established (no NeighbourConnect Event) even thoug all peers correctly see the Connect.Success event on the NetGroup. The application perfectly works when using the Adobe developer Server so it must be some configuration issue with my FMS server.