Closed
Bug 1218843
Opened 10 years ago
Closed 10 years ago
Media flowing but no media shown
Categories
(Core :: WebRTC: Signaling, defect)
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 ?
Comment 1•10 years ago
|
||
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.
Reporter | ||
Comment 2•10 years ago
|
||
Reporter | ||
Comment 3•10 years ago
|
||
Reporter | ||
Comment 4•10 years ago
|
||
Reporter | ||
Comment 5•10 years ago
|
||
(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 ?
Comment 6•10 years ago
|
||
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.
Comment 7•10 years ago
|
||
Can you attach the pcap file itself? I need to be able to inspect the packets.
Reporter | ||
Comment 8•10 years ago
|
||
Reporter | ||
Comment 9•10 years ago
|
||
(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.
Comment 10•10 years ago
|
||
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)?
Updated•10 years ago
|
Summary: webrtc → Media flowing but no media shown
Reporter | ||
Comment 12•10 years ago
|
||
(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)
Reporter | ||
Comment 13•10 years ago
|
||
(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.
Reporter | ||
Comment 14•10 years ago
|
||
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
Comment 15•10 years ago
|
||
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.
Description
•