GST/Chrome WebRTC stream DTLS handshake failure

Fri Apr 19 19:51:56 UTC 2019

Hi all,

I've been trying to offer a WebRTC stream from a gstreamer pipeline to Chrome without much success.  I'm able to reproduce the same issue with the Centricular webrtc-sendrecv example:

       https://github.com/centricular/gstwebrtc-demos/blob/master/sendrecv/gst/webrtc-sendrecv.c

The GStreamer app creates and sends offer, the Chrome app responds with an answer and ICE candidates are exchanged but things go downhill from there.  On the Chrome side, webrtc-internals show that a candidate pair was successfully selected (googReadable/googWritable are true) but the PeerConnection's ICE connection state gets stuck in "checking".  The Chrome debug logs show that there's a DTLS timeout.

On the GStreamer side, with *tls* logs set to level 5, I see this sequence repeatedly:

                0:00:11.835289000 15540 00000286D591D440 DEBUG                dtlsdec gstdtlsdec.c:548:sink_chain:<dtlsdec0> received buffer from rtp_0_2873075822 with length 155

                0:00:11.847957000 15540 00000286D591D440 LOG           dtlsconnection gstdtlsconnection.c:629:log_state:<GstDtlsConnection at 00000286D56A6890> process start: role=server buf=(00000286D5D3E130:0/155) 10110|0 before SSL initialization

                0:00:11.869501000 15540 00000286D591D440 LOG           dtlsconnection gstdtlsconnection.c:629:log_state:<GstDtlsConnection at 00000286D56A6890> process after read: role=server buf=(00000286D5D3E130:0/155) 10110|0 before SSL initialization

                0:00:11.887298000 15540 00000286D591D440 LOG           dtlsconnection gstdtlsconnection.c:629:log_state:<GstDtlsConnection at 00000286D56A6890> poll: before handshake: role=server buf=(00000286D5D3E130:0/155) 10110|0 before SSL initialization

                0:00:11.904438000 15540 00000286D591D440 LOG           dtlsconnection gstdtlsconnection.c:629:log_state:<GstDtlsConnection at 00000286D56A6890> poll: after handshake: role=server buf=(00000286D5D3E130:0/155) 10110|0 before SSL initialization

                0:00:11.920380000 15540 00000286D591D440 DEBUG         dtlsconnection gstdtlsconnection.c:758:openssl_poll:<GstDtlsConnection at 00000286D56A6890> do_handshake encountered BIO error

                0:00:11.935830000 15540 00000286D591D440 ERROR         dtlsconnection gstdtlsconnection.c:771:openssl_poll:<GstDtlsConnection at 00000286D56A6890> SSL error

                0:00:11.946996000 15540 00000286D591D440 ERROR         dtlsconnection gstdtlsconnection.c:727:ssl_err_cb:<GstDtlsConnection at 00000286D56A6890> ssl error: 26156:error:140B4090:SSL routines:SSL_do_handshake:connection type not set:ssl/ssl_lib.c:3554:

                0:00:11.968253000 15540 00000286D591D440 LOG           dtlsconnection gstdtlsconnection.c:629:log_state:<GstDtlsConnection at 00000286D56A6890> process after poll: role=server buf=(00000286D5D3E130:0/155) 10110|0 before SSL initialization

                0:00:11.987237000 15540 00000286D591D440 DEBUG         dtlsconnection gstdtlsconnection.c:551:gst_dtls_connection_process:<GstDtlsConnection at 00000286D56A6890> read result: -1

Based on the "SSL_do_handshake:connection type not set" error, it appears that SSL_set_connect_state()/SSL_set_accept_state() hasn't been called on GstDtlsConnection's OpenSSL handle which should happen in gst_dtls_connection_start() but I never see the corresponding "log_state:initial state set:" message.

I *am* able to successfully run the gst-plugins-bad/tests/examples/webrtc/webrtc.c app.  In that case, after the answer is processed, I see "initial state set" message preceded by creation of a new src pad on the webrtcbin instance which I *don't* see in my problem apps:

                0:00:01.867442000 35404 0000017960746740 DEBUG              webrtcbin gstwebrtcbin.c:3145:_update_transceiver_from_sdp_media:<recv> creating new receive pad for transceiver <webrtctransceiver1>

                0:00:01.881440000 35404 00000179607466C0 DEBUG                dtlsenc gstdtlsenc.c:378:src_activate_mode:<dtlsenc0> src pad activating in push mode

                0:00:01.896187000 35404 0000017960746740 DEBUG              webrtcbin gstwebrtcbin.c:268:gst_webrtc_bin_pad_new:<'':src_0> new visible pad with direction src

                0:00:01.910867000 35404 00000179607466C0 DEBUG                dtlsenc gstdtlsenc.c:330:gst_dtls_enc_change_state:<dtlsenc0> starting connection rtp_0_324247815

                0:00:01.921569000 35404 0000017960746740 INFO               webrtcbin gstwebrtcbin.c:2910:_connect_output_stream:<recv> linking output stream 0

                0:00:01.936102000 35404 00000179607466C0 LOG           dtlsconnection gstdtlsconnection.c:629:log_state:<GstDtlsConnection at 00000179607C1EE0> initial state set: role=server buf=(0000000000000000:0/0) 10110|0 before SSL initialization

Here's the Chrome answer:

                v=0

                o=- 671422098252769522 2 IN IP4 127.0.0.1

                s=-

                t=0 0

                a=group:BUNDLE video0 audio1

                a=msid-semantic: WMS y6ekH83vxbrWGYgIHXshcbQUTSYjesz8cTQU

                m=video 9 UDP/TLS/RTP/SAVPF 96

                c=IN IP4 0.0.0.0

                a=rtcp:9 IN IP4 0.0.0.0

                a=ice-ufrag:UN/v

                a=ice-pwd:5pyFZoXXTB6g/AAPq2ASVSdt

                a=ice-options:trickle

                a=fingerprint:sha-256 98:9C:D6:67:6D:C8:8D:80:61:A1:C0:08:89:6B:1C:99:56:AE:EF:00:61:22:1B:27:CB:20:2F:FB:13:C2:FE:32

                a=setup:active

                a=mid:video0

                a=sendrecv

                a=rtcp-mux

                a=rtcp-rsize

                a=rtpmap:96 VP8/90000

                a=rtcp-fb:96 nack pli

                a=ssrc:1873007401 cname:PbAeaJtZ3DsTAyc8

                a=ssrc:1873007401 msid:y6ekH83vxbrWGYgIHXshcbQUTSYjesz8cTQU e5c18420-14d4-4ccd-b884-4f81b51081c5

                a=ssrc:1873007401 mslabel:y6ekH83vxbrWGYgIHXshcbQUTSYjesz8cTQU

                a=ssrc:1873007401 label:e5c18420-14d4-4ccd-b884-4f81b51081c5

                m=audio 9 UDP/TLS/RTP/SAVPF 97

                c=IN IP4 0.0.0.0

                a=rtcp:9 IN IP4 0.0.0.0

                a=ice-ufrag:UN/v

                a=ice-pwd:5pyFZoXXTB6g/AAPq2ASVSdt

                a=ice-options:trickle

                a=fingerprint:sha-256 98:9C:D6:67:6D:C8:8D:80:61:A1:C0:08:89:6B:1C:99:56:AE:EF:00:61:22:1B:27:CB:20:2F:FB:13:C2:FE:32

                a=setup:active

                a=mid:audio1

                a=sendrecv

                a=rtcp-mux

                a=rtpmap:97 OPUS/48000/2

                a=fmtp:97 minptime=10;useinbandfec=1

                a=ssrc:4026464680 cname:PbAeaJtZ3DsTAyc8

                a=ssrc:4026464680 msid:y6ekH83vxbrWGYgIHXshcbQUTSYjesz8cTQU b7c37d92-042c-417e-a4ab-79fdbe577974

                a=ssrc:4026464680 mslabel:y6ekH83vxbrWGYgIHXshcbQUTSYjesz8cTQU

                a=ssrc:4026464680 label:b7c37d92-042c-417e-a4ab-79fdbe577974

And the webrtc.c example answer:

                v=0

                o=- 2260608518856376157 0 IN IP4 0.0.0.0

                s=-

                t=0 0

                a=ice-options:trickle

                m=video 9 UDP/TLS/RTP/SAVPF 96

                c=IN IP4 0.0.0.0

                a=ice-ufrag:tkt9ckCYhpGXYbx3vOHGSN68tTAOlomF

                a=ice-pwd:Mvu5cUlmqpvF6xrssiXcYOr0ShtJCOwn

                a=rtcp-mux

                a=mid:video0

                a=setup:active

                a=rtpmap:96 VP8/90000

                a=rtcp-fb:96 nack pli

                a=recvonly

                a=fingerprint:sha-256 DD:30:10:C2:F2:60:91:85:9F:6F:ED:BF:0A:23:AB:60:0B:FB:08:8E:04:83:D9:A1:DF:26:54:BC:A4:E8:59:BD

My system config:

                Windows 10

                GStreamer x86_64 v1.15.2 (I've also tried v1.14.4 with the same result)

                Chrome 73.0.3683.103

Any ideas as to what could be going wrong would be EXTREMELY appreciated!

Best,

Eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190419/1e37729f/attachment-0001.html>