I think this is not the correct behavior, given that the remote/answer SDP has video disabled (or set to recvonly).
I have a slightly different problem, perhaps with the same underlying cause, where an asymmetric call is made between two FF instances. If the caller has both audio and video, and callee has only audio in their respective local stream, and an offer is made with both OfferToReceiveAudio/Video set to true, then the onaddstream is not fired on caller side after setRemoteDescription is called with the answer SDP (which correctly has a=recvonly for the video m-line). The remote audio wouldn't be played on the caller, as the app wouldn't attach the remote stream to the video element in this case. I use a workaround for this issue, however - on setRemoteDescription success callback, I still get and attach the remote stream to the video element, and audio is played fine. Thanks, Uma _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
