1218843 - Media flowing but no media shown

Status: RESOLVED WORKSFORME

Description

[thibaud.buffet]

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

[Byron Campen [:bwc]]

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.

Comment 2

[thibaud.buffet]

Created attachment 8679524 [details]
aboutWebrtc.html

Comment 3

[thibaud.buffet]

Created attachment 8679525 [details]
FFx log NSPR : datachannel:9,sctp:9,signaling:9,mtransport:9,jsep:9,timestamp

Comment 4

[thibaud.buffet]

Created attachment 8679526 [details]
pacapDTLS.png

Comment 5

[thibaud.buffet]

(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

[Byron Campen [:bwc]]

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

[Byron Campen [:bwc]]

Can you attach the pcap file itself? I need to be able to inspect the packets.

Comment 8

[thibaud.buffet]

Created attachment 8679529 [details]
DTLS27102015.pcapng

Comment 9

[thibaud.buffet]

(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

[Byron Campen [:bwc]]

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)?

Comment 11

[Maire Reavy [:mreavy] Plz needinfo]

See comment 10

Comment 12

[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 ?

Comment 13

[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.

Comment 14

[thibaud.buffet]

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.

Comment 15

[Randell Jesup [:jesup]]

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).