Closed Bug 1218843 Opened 10 years ago Closed 10 years ago

Media flowing but no media shown

Categories

(Core :: WebRTC: Signaling, defect)

40 Branch
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: thibaud.buffet, Unassigned)

Details

Attachments

(4 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36 Steps to reproduce: I try to negociate a WebRTC audio/video call from my local server to a FFx client. Actual results: The negociation seems OK, the browser asks to allow the webcam and microphone ... but nothing happen then. I think I'm missing something in my SDP negociation. Here are the Local / remote SDPs : Local SDP (Firefox) v=0 o=mozilla...THIS_IS_SDPARTA-41.0.2 4294967295 0 IN IP4 0.0.0.0 s=- t=0 0 a=sendrecv a=fingerprint:sha-256 EC:23:8A:A2:93:C4:A6:BA:2F:B1:19:3E:7E:5B:2F:C6:24:E5:5F:15:22:31:06:0E:3A:FA:69:BA:D3:B7:CE:F7 a=group:BUNDLE audio video a=ice-options:trickle a=msid-semantic:WMS * m=audio 52148 RTP/SAVPF 109 c=IN IP4 16.16.46.243 a=candidate:0 1 UDP 2128609535 16.16.46.243 52148 typ host a=candidate:1 1 UDP 2128543999 192.168.56.1 52149 typ host a=candidate:2 1 UDP 2128478463 192.168.99.1 52150 typ host a=sendrecv a=end-of-candidates a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=ice-pwd:bf5f33b70cd2d868015716dfb614315f a=ice-ufrag:261e7fc2 a=mid:audio a=msid:{0cc2d878-3c11-47fa-89db-66ee80ce06a7} {88cd92e1-876c-43a7-8824-2fa693ac24bf} a=rtcp-mux a=rtpmap:109 opus/48000/2 a=setup:active a=ssrc:4050798895 cname:{86c1ff4a-65be-401e-89ad-8a2bca4a6fcd} m=video 52148 RTP/SAVPF 120 c=IN IP4 16.16.46.243 a=sendrecv a=fmtp:120 max-fs=12288;max-fr=60 a=ice-pwd:bf5f33b70cd2d868015716dfb614315f a=ice-ufrag:261e7fc2 a=mid:video a=msid:{0cc2d878-3c11-47fa-89db-66ee80ce06a7} {de64f7ca-0fea-4df8-82fe-d4cdd12b9ac1} a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=rtcp-mux a=rtpmap:120 VP8/90000 a=setup:active a=ssrc:430521593 cname:{86c1ff4a-65be-401e-89ad-8a2bca4a6fcd} Remote SDP (remote server) v=0 o=ISF 4294967295 2 IN IP4 127.0.0.1 s=- t=0 0 a=sendrecv a=group:BUNDLE audio video a=ice-lite a=msid-semantic:WMS Tn6+CGxv9/H83A3YDKbEZb1BTgQ+NaAgB6fE m=audio 40000 RTP/SAVPF 109 9 0 8 c=IN IP4 16.17.30.130 a=candidate:4070578974 1 udp 2130706431 16.17.30.130 40000 typ host a=sendrecv a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=fingerprint:sha-256 BD:BE:FC:FB:22:FE:51:F3:24:59:71:54:F3:6C:35:1D:DC:09:FA:3A:EC:D6:B0:DE:0D:FB:FA:7E:FF:F5:84:DA a=ice-pwd:l2k9cMhd0mfWKl6/ecDS4PBG a=ice-ufrag:05iE0cMuOrsKmuf7 a=mid:audio a=rtcp:40000 IN IP4 16.17.30.130 a=rtcp-mux a=rtpmap:109 opus/48000/2 a=rtpmap:9 G722/8000/1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=setup:actpass a=ssrc:2037938966 cname:BQz+Q66H6xf986CV a=ssrc:2037938966 msid:Tn6+CGxv9/H83A3YDKbEZb1BTgQ+NaAgB6fE db842d27-6684-6b1b-6cba-60157140760d1ea4 a=ssrc:2037938966 mslabel:Tn6+CGxv9/H83A3YDKbEZb1BTgQ+NaAgB6fE a=ssrc:2037938966 label:db842d27-6684-6b1b-6cba-60157140760d1ea4 m=video 40000 RTP/SAVPF 120 126 97 c=IN IP4 16.17.30.130 a=candidate:4070578974 1 udp 2130706431 16.17.30.130 40000 typ host a=sendrecv a=fingerprint:sha-256 BD:BE:FC:FB:22:FE:51:F3:24:59:71:54:F3:6C:35:1D:DC:09:FA:3A:EC:D6:B0:DE:0D:FB:FA:7E:FF:F5:84:DA a=fmtp:120 max-fs=12288;max-fr=60 a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1 a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1 a=ice-pwd:l2k9cMhd0mfWKl6/ecDS4PBG a=ice-ufrag:05iE0cMuOrsKmuf7 a=mid:video a=rtcp:40000 IN IP4 16.17.30.130 a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=rtcp-fb:126 nack a=rtcp-fb:126 nack pli a=rtcp-fb:126 ccm fir a=rtcp-fb:97 nack a=rtcp-fb:97 nack pli a=rtcp-fb:97 ccm fir a=rtcp-mux a=rtpmap:120 VP8/90000 a=rtpmap:126 H264/90000 a=rtpmap:97 H264/90000 a=setup:actpass a=ssrc:2064526838 cname:BQz+Q66H6xf986CV a=ssrc:2064526838 msid:Tn6+CGxv9/H83A3YDKbEZb1BTgQ+NaAgB6fE 40d26f3c-7616-1e76-4e01-677f20687ca1d63 a=ssrc:2064526838 mslabel:Tn6+CGxv9/H83A3YDKbEZb1BTgQ+NaAgB6fE a=ssrc:2064526838 label:40d26f3c-7616-1e76-4e01-677f20687ca1d63 I suspect multiple things maybe you can help me to found out which one to focus on : - I'm using DTLSv1.0 and make the handshake with the browser in DTLSv1.0 as described here : https://bugzilla.mozilla.org/show_bug.cgi?id=1153702 - I changed the group bundle to audio video instead of sparta-0 sparta_1 - I used to use SHA-1 and I changed to SHA-256 Expected results: PS : it works well with chromium/chrome browser, what am I missing with FFx ?
Are you checking for error callbacks in JS? If you are, and there aren't any, the next thing to check is about:webrtc. That should tell you if there is an ICE failure. If that is ok, then the next thing we'd suspect is a DTLS handshake problem, which will require a pcap to diagnose.
Attached file aboutWebrtc.html
Attached image pacapDTLS.png
(In reply to Byron Campen [:bwc] from comment #1) > Are you checking for error callbacks in JS? If you are, and there aren't > any, the next thing to check is about:webrtc. That should tell you if there > is an ICE failure. If that is ok, then the next thing we'd suspect is a DTLS > handshake problem, which will require a pcap to diagnose. I updated the thread with some attachements. Seems like FFx does not like the DTLSv1.0 right ?
It is not that FFX doesn't like DTLSv1.0, it is that it only supports ciphers with perfect forward secrecy, which is not a super common configuration.
Can you attach the pcap file itself? I need to be able to inspect the packets.
Attached file DTLS27102015.pcapng
(In reply to Byron Campen [:bwc] from comment #6) > It is not that FFX doesn't like DTLSv1.0, it is that it only supports > ciphers with perfect forward secrecy, which is not a super common > configuration. I'm using diffie hellman protocol as ciphers with perfect forward secrecy.
Ok, not seeing any sign of cipher suite mismatch, and the nspr logs indicate that media (audio and video) is flowing fine in both directions. Maybe you're caught up in some compatibility breakage (eg; onaddstream vs onaddtrack vs ontrack)?
Summary: webrtc → Media flowing but no media shown
Flags: needinfo?(thibaud.buffet)
(In reply to Byron Campen [:bwc] from comment #10) > Ok, not seeing any sign of cipher suite mismatch, and the nspr logs indicate > that media (audio and video) is flowing fine in both directions. Maybe > you're caught up in some compatibility breakage (eg; onaddstream vs > onaddtrack vs ontrack)? Hello, Thanks for your previous answers. ATM, I am only using the MediaStream API with MediaStream not MediaStreamTrack. It means, I am only implementing onaddstream. Also I am using RTCPeerConnection.addstream(). Is it mandatory in FFx to use the RTCRtpSender & RTCRtpReceiver ? Did I miss something here ?
Flags: needinfo?(thibaud.buffet)
(In reply to thibaud.buffet from comment #12) > (In reply to Byron Campen [:bwc] from comment #10) > > Ok, not seeing any sign of cipher suite mismatch, and the nspr logs indicate > > that media (audio and video) is flowing fine in both directions. Maybe > > you're caught up in some compatibility breakage (eg; onaddstream vs > > onaddtrack vs ontrack)? > > Hello, > > Thanks for your previous answers. > > ATM, I am only using the MediaStream API with MediaStream not > MediaStreamTrack. > It means, I am only implementing onaddstream. > Also I am using RTCPeerConnection.addstream(). > > Is it mandatory in FFx to use the RTCRtpSender & RTCRtpReceiver ? > > Did I miss something here ? Edit : I just checked and the onaddtrack is raised 2 times (audio and video I guess) but I did not implemented anything on this.
UPDATE : I found out my issue, it was not related to anything I mentionned before. I just forget to add the objectURL to the video tag. video.src = window.URL.createObjectURL(stream), I was just passing the stream... video.play(); Thanks for your assistance.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
or use video.srcObject = stream... (not sure if Chrome has implemented it yet). (Used to be mozSrcObject before we unprefixed it.) The advantage over createObjectURL is that once createObjectURL() is used on an object, the object can't be GC'd until the entire page is gone (at minimum).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: