if video is working one way, then most likely it is a coding problem in VideoPhoneLabs somehow, since the underlying connection is bidirectional.
Its not a coding problem. It works on some connections and not on others.
when you say "his video/audio does not transmit to me. He can however see and hear me just fine", i assume that means that in the bad call, he receives your video/audio but you do not receive his video/audio. there is only one network connection between the two of you, over which the video/audio would flow in both directions. if it's working in one direction, then the network connection is up, and if there was video/audio from the other side would also be able to flow over the same connection.
given your description of the symptoms, the only conclusion is a coding error in the VideoPhoneLabs application. if there was some kind of NAT/firewall issue that prevented the network connection from working properly, then the call couldn't work at all in either direction.
No, there are other possibilities. I was just looking for confirmation.
For instance, it may be the case that his firewall only permits *established* UDP traffic, rather than *unsolicited* UDP traffic.
If his Flash client peers with mine first, his firewall then knows that this is OK, whereas if my client tries to peer with his first, I get blocked, as his firewall doesn't know anything about my source ip address.
I don't know if this is the case, or if there are other potential issues re. security, NAT etc, but I do know that it is not a coding problem.
RTMFP is a two-way connection-oriented transport protocol, with a handshake and acknowledgements and stuff, and the video streaming protocol requires a "play" command to be received P2P from the subscriber for the publisher to start sending the video data in the first place. if video/audio flows in one direction, that requires bidirectional network connectivity, over which the video/audio from the other end could also flow.
a direction-sensitive NAT/firewall network issue can exist, but that would block any video/audio from flowing in *either* direction during the call.
My application works as follows:
User1 (me) askes User2 (friend) if they would like to speak via AJAX text chat system
When User2 confirms that they would like to do this:
User1 browser loads Flash app
Flash app connects and obtains session key from cirrus
Flash app writes that session key to database
User2 browser loads Flash app
Flash app checks DB to see if session key exists
If not, it waits, and check again in 10 secs
When session key is finally found, Flash app connects to cirrus
Cirrus now exchanges network data between clients, and P2P connection is established
Call is placed from User2 to User1
Video and audio transmission starts from User1, and is received by User2
No Video and audio transmission is received by User1 from User2 (text chat over Cirrus is however possible)
All of this works in the majority of cases with other users, and when the roles are reversed, it also works.
The only time it doesn't work, it when I try to call my friend.
The behaviour described above can be seen in both my app, and the sample provided by Adobe at:
I hear what you are saying about RTMFP, but it really doesn't look like a coding problem, unless that problem also exists in the Adobe demo.
have you verified (by debug traces or similar), in the scenario that you describe above, that User1 is specifying the correct peer ID when subscribing to User2's stream? and by "verified", i mean printing out User2's NetConnection.nearID on User2, and printing out the peer ID that User1 is using to get User2's stream on User1, and making sure they are identical?