I am really excited about the progress Cirrus has made till now. So I started building an application around it for voice communication, but I am encountering some problems around the road that I'd love to get some comments or even better some solutions on.
The first thing I noticd is that a direct RTMFP connection between two clients that show a red dot at "Source UDP port number is preserved from original connection" at http://cc.rtmfp.net/ won't work ever. As far as I am concerned this is about the UDP port that communicates with the ICE/TURN/STUN server and the problem is that the remote NAT changes the UDP port instead of preserving it when connecting to another host. Is this correct so far?
If it is, I know that Skype for example just tries a range of possible ports to still establish the connection. Of course, this is some kind of a hack, but it seems to work out. Are there any plans to add such a work around to flash p2p clients as well or is there already such a mechanism implemented and just not working in my case?
For the moment, this blocks some peers of communicating with each other via direct connections. So I tried to publish the same stream a second time via multicast to a NetGroup and hoped that another client inside the group would just relay the stream to a client behind a bad NAT. However, this seems not to happen. What I am doing currently is to publish the stream to the NetGroup nearly the same like the direct connection, giveing it (another) unique name inside the group and let a peer who failed to open the direct stream try the group stream instead. My question: Am I missing some point? Do I need to explicity call some method to enable a "good" client in the group to relay another client's multicast stream? Currently all clients are just joining the netgroup and successfully receive the PublishNotify for all of that multicast relay streams.
I also took a deep look at the docs and there I found a paragraph that claims that it's better "to build the network from direct connections only not using netgroups". So, I also tried to re-publish an incoming peer netstream with another unique relay name to build a relay feature from this but it uses to throw a "NetStream.Publish.Failed" event when I call publish(...) on the stream I received via onPeerconnect(...). I am pretty sure that this is not the right way to re-publish a stream, so: How do I do this correctly just from within a flash client? Is it possible at all? Or will I need a FMS relay server to get this working?
Thanks in advance,