<div dir="ltr"><div dir="ltr">Hi Albin!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tors 14 mars 2019 kl 15:38 skrev Albin Stigö <<a href="mailto:albin.stigo@gmail.com">albin.stigo@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Ingela,<br>
<br>Thanks for the quick reply!<br>
<br>While cb_info certainly is one way of doing it, it feels a bit<br>complicated... specifically if switching between active and passive<br>mode. Not sure if ssl ever use passive mode internally? Demuxing is a<br>different use case, I think..<br>
<br></blockquote><div><br></div>The cb_info is intended so that you may replace the transport layer, with most likely, an SCTP transport (can be done for both TLS and DTLS although there are some extensions needed for the DLTS version to work properly). I think some people also use it to implement WebSockets.<div><br></div><div>ssl internally uses active n for TLS (since latest release) and active once for DTLS (we might change it) but an OTP supervised process will not use passive recv as we do not want it to block. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Something that IMHO would be fantastic and simple (?) would be a<br>dtls_filter_fun option. If true packet is passed up the ssl stack,<br>otherwise passed on like a normal udp packet!<br>
<br></blockquote><div><br></div><div>Sounds reasonable. Otherwise sent to some other Erlang process than the "DTLS-connection" process that is.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There's an RFC regarding the demultiplexing of SRTP/DTLS, it basically<br>boils down to looking at the first byte of the packet, if it's<br>[20..63] it should be treated as DTLS otherwise something else. So<br>this would be absolutely trivial to implement if there was a<br>dtls_filter_fun...<br>
<br>
<a href="https://tools.ietf.org/html/rfc7983" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc7983</a><br>
<br>Then of course there also has to be a way to bypass DTLS when sending<br>data... maybe send/3 (Socket, Data, Options)...<br>
<br></blockquote><div><br></div><div>Maybe transport_send as compared to the existing transport_accept. Would only work for DTLS.</div><div><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What do you think?<br>
<br>
<br>--Albin<br>
<br>On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin <<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>> wrote:<br>><br>> Hi!<br>><br>> Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö <<a href="mailto:albin.stigo@gmail.com" target="_blank">albin.stigo@gmail.com</a>>:<br>>><br>>> Hi,<br>>><br>>> I'm working on an Erlang WebRTC peer client (to send audio/video to<br>>> the browser).<br>>><br>>> WebRTC requires dtls-srtp and that in turn requires:<br>>><br>>> 1. The use_srtp extension for key exchange.<br>><br>><br>> We will be implementing this as part of TLS-1.3 that we are currently working on, and we will have something runnable for OTP-22.0, although we are not promising that it will complete or that use_srtp will be part of OTP-22.0<br>><br>><br>>><br>>> 2. Multiplexing of stun/turn/srtp packets on the socket.<br>>><br>>> I know there's been work towards use_srtp and it's even in the source,<br>>> but commented out. Ingela has been working on it for OTP 2, I believe,<br>>> is there an ETA on this feature?<br>><br>><br>>><br>>><br>>><br>>> Is multiplexing on the DTLS socket already possible using the cb_info?<br>>> Has anyone tried that?<br>>><br>>> <a href="http://erlang.org/pipermail/erlang-questions/2018-October/096457.html" rel="noreferrer" target="_blank">http://erlang.org/pipermail/erlang-questions/2018-October/096457.html</a><br>>><br>><br>> The code has been written to make such extensions possible. There might be a need for more callbacks. I have not really had time to work on that as<br>> TLS-1.3, optimizations and erlang distribution over TLS has been prioritized higher. Suggestions are welcome.<br>><br>> Regards Ingela Erlang/OTP team - Ericsson AB<br>><br>><br>><br>><br>>><br>>><br>>> --Albin<br>>> _______________________________________________<br>>> erlang-questions mailing list<br>>> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div></div>