Reputation: 1
I stream between two browser sites, one is called master and the other is called slave. Master streams video to slave. Master is always active, slave sometimes connects.
I initiate the connection on both sides with this configuration:
{'iceServers': [{'url': 'stun:mystunserveraddress'}]},
{'optional': [{'DtlsSrtpKeyAgreement': true},{'RtpDataChannels': true}]}
Master sends offer for receiving no audio and no video. Slave handles offer and answers with offer for receiving video. Master handles answer.
Ice candidates are processed on both sides. Video is attached to peer connection before sending offer.
I tested it to work with following combination of Master->Slave:
Why is it not working for those combinations? No error is given. Everything looks ordinary as normal, but the video element on slave is blank.
Offering audio and video from both ends, or auto does not change anything.
On Firefox master I have two "connected" states and on Chrome slave I have "checking" state.
I have tested on local server and remote server, behaves the same.
It does not work on AppRTC example either.
Upvotes: 0
Views: 2255
Reputation: 6984
Side-note: Do not use RtpDataChannels. It's old, it's Chrome-only, it's non-standard - it wasn't even proposed to the standards. Chrome now supports standards RTCDataChannels (pc.createDataChannel(...)) which interops with Firefox.
I strongly suspect your video problems are a bug in your JS code, perhaps a dependence on the timing of success callbacks versus other callbacks - or against ICE candidates. If the Success callback of SetRemoteDescription hasn't returned, you shouldn't add ICE candidates yet for example (queue them and add after success).
If you call using apprtc from Chrome on Linux to Chrome on Windows (and vice-versa), does it work? It should; this is something people do all the time (on Chrome and Firefox).
Upvotes: 1