<div dir="ltr">Hi<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Ingela Andin <<a href="mailto:ingela.andin@gmail.com">ingela.andin@gmail.com</a>> schrieb am Do., 14. März 2019 um 17:34 Uhr:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Albin!</div><br><div class="gmail_quote"></div></div><div dir="ltr"><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" target="_blank">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></div></div><div dir="ltr"><div class="gmail_quote">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></div><div dir="ltr"><div class="gmail_quote"><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></div><div dir="ltr"><div class="gmail_quote"><div>Sounds reasonable. Otherwise sent to some other Erlang process than the "DTLS-connection" process that is.</div></div></div></blockquote><div><br></div><div>No, that's not enough. Some protocols put additional headers in front of the DTLS packets. So there needs to be a way to strip headers on Rx and add it on Tx (with session information if needed).</div><div><br></div><div>Andreas</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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></div><div dir="ltr"><div class="gmail_quote"><div>Maybe transport_send as compared to the existing transport_accept. Would only work for DTLS.</div></div></div><div dir="ltr"><div class="gmail_quote"><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>
_______________________________________________<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>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span style="font-family:monospace,monospace">-- <br>Dipl.-Inform. Andreas Schultz<br><br>----------------------- enabling your networks ----------------------<br>Travelping GmbH Phone: +49-391-81 90 99 0<br>Roentgenstr. 13 Fax: +49-391-81 90 99 299<br>39108 Magdeburg Email: <a href="mailto:info@travelping.com">info@travelping.com</a><br>GERMANY Web: <a href="http://www.travelping.com">http://www.travelping.com</a><br><br></span><div><span style="font-family:monospace,monospace">Company Registration: Amtsgericht Stendal Reg No.: HRB 10578</span></div><span style="font-family:monospace,monospace">Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780<br>---------------------------------------------------------------------</span></div></div>