[erlang-questions] dtls error when used with chrome webrtc

[Joe K]

> Also you may try using external STUN server (check RTCPeerConnection
docs) and hope browser starts with DTLS hello.

I've tried that, but the browser still sends STUN binding requests to the
DTLS process. And it uses the STUN server just to find out it's address.

> It should be quite easy to implement and it would be consistent with
ssl:connect/2 and ssl:ssl_accept for TCP sockets.

Will try this now. Thank you.

On Thu, Dec 28, 2017 at 4:34 PM, Danil Zagoskin <z@REDACTED> wrote:

> > But now I don't know how to reply to both STUN binding request and then
> setup a DTLS session using erlang's ssl module.
> Yes, dtls implementation lacks support of starting/accepting a handshake
> over existing socket.
> It should be quite easy to implement and it would be consistent with
> ssl:connect/2 and ssl:ssl_accept for TCP sockets.
>
> Also you may try using external STUN server (check RTCPeerConnection docs)
> and hope browser starts with DTLS hello.
> If you try this, please share the results.
>
> On Thu, Dec 28, 2017 at 3:26 PM, Joe K <goodjoe2049@REDACTED> wrote:
>
>> Oops, I forgot to reply to the mailing list in my last email.
>>
>> The response was
>>
>>   > Maybe browser sends STUN requests to your port when you expect DTLS
>> hello?
>>   You are absolutely right, Wireshark shows that there are lots of STUN
>> binding requests being made, I didn't think of that.
>>
>>   > Do you use external STUN server?
>>   I don't use external STUN servers ... For some reason, I didn't think I
>> would need them.
>>
>>   > Also try checking chrome://webrtc-internals and chrome://webrtc-logs
>> for browser's view on what's going on.
>>   chrome://webrtc-logs is empty for the webrtc whole session.
>>
>> But now I don't know how to reply to both STUN binding request and then
>> setup a DTLS session using erlang's ssl module.
>>
>> On Thu, Dec 28, 2017 at 1:28 AM, Danil Zagoskin <z@REDACTED> wrote:
>>
>>> Hi!
>>> What do you see in Wireshark?
>>> Did you see handshake between two browsers?
>>> Is your application ready to receive the packet sent by browser?
>>> Do you use external STUN server?
>>> Maybe browser sends STUN requests to your port when you expect DTLS
>>> hello?
>>>
>>> Also try checking chrome://webrtc-internals and chrome://webrtc-logs
>>> for browser's view on what's going on.
>>>
>>>
>>> On Thu, Dec 28, 2017 at 12:09 AM, Joe K <goodjoe2049@REDACTED> wrote:
>>>
>>>> I'm trying to implement parts of webrtc stack with elixir/erlang and
>>>> currently am stuck with setting up a dtls session.
>>>>
>>>> The minimal example is, I think, the following (in console, erlang
>>>> 20.2.2):
>>>>
>>>>     2> ssl:start().
>>>>     ok
>>>>     3> {ok, ListenSocket} = ssl:listen(8090, [
>>>>     3>   binary,
>>>>     3>   {ip, {0, 0, 0, 0}},
>>>>     3>   {protocol, dtls},
>>>>     3>   {keyfile, <<"priv/server.key">>},
>>>>     3>   {certfile, <<"priv/server.pem">>},
>>>>     3>   {active, false}
>>>>     3> ]).
>>>>     {ok, ...}
>>>>     4> {ok, AcceptSocket} = ssl:transport_accept(ListenSocket).
>>>>     {ok,...}
>>>>     5> ssl:ssl_accept(AcceptSocket).
>>>>     {error,{tls_alert,"record overflow"}}
>>>>
>>>> And js (with chrome canary): https://gist.github.c
>>>> om/idi-ot/a07b7330ff02f90373a2dcfe83883afa
>>>>
>>>> After {error,{tls_alert,"record overflow"}} the RTCPeerConnection's
>>>> iceConnectionState becomes "failed" and the connection itself "closed".
>>>>
>>>> I wonder what I am doing wrong.
>>>>
>>>>     openssl s_client -dtls1 -connect 127.0.0.1:8089 -debug
>>>>
>>>> works fine with the code snippet above.
>>>>
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>>
>>>
>>>
>>> --
>>> Danil Zagoskin | z@REDACTED
>>>
>>
>>
>
>
> --
> Danil Zagoskin | z@REDACTED
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171229/dc4f258c/attachment.htm>