<div dir="ltr"><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div>Hey Razvan & OpenSIPS folks,</div><div><br></div><div>This is quick update on what's going on with the DTMF intercept functionality and some ideas as to where we go from there to allow SRTP<->RTP bridging. The very good question that has been brought up by Razvan last Saturday on our SIPChronicles show.</div><div><br></div><div>Basically the work to integrate code from the rtpp_2_1_dtmf into master is in progress. I am adding missing bits and pieces to allow module tap into command channel.</div><div><br></div><div>Once it's all done, with very little extra effort it would allow us adding SRTP bridging as a separate module. The idea there is to use the same mechanism we used by DTMF to intercept packets for inspection, but with small extension that the SRTP module would "steal" the packet to do decoding/encoding in the module based on direction and then re-introduce it into the normal queue after processing.</div><div><br></div><div>On the OpenSIPS end this would look like the following, bridging SRTP-RTP in the following examples:</div><div><br></div><div>U[...] && M4.1 C AES_CM_128_HMAC_SHA1_80:9sOd+W72ilwfNgNt0FzlGYj6YZPMqN1sJJx43UuS<br>L[...]   </div><div>This would bridge SRTP on Alice side to plain RTP on Bob's side.</div><div><br></div><div>U[...]<br></div><div>L[...] && M4.1 C AES_CM_128_HMAC_SHA1_80:NhqBK/JjtVJgmOgPyDKpvMTEjvFCQ4eiyVQelF6x</div><div>This would bridge SRTP on Bob side to plain RTP on Alice's side.  <br></div><div><br></div><div>Scalability-wise we are going to start with a single dedicated thread to handle encryption/decryption per instance, I suspect that we are still going to be I/O bound. However if this fails this mechanism allows further scaling up by loading SRTP module multiple times within a single instance and then load-balancing by using M4.1, 

M4.2, 

M4.3, etc based on some hash of the session ID on the OpenSIPS end.</div><div><br></div><div>Once it is working, we would cut the 2.2 release and hopefully continue work on bridge_dtls as well as adding some method to secure control channel communication.</div><div><br></div><div>Any comments/suggestions are appreciated!</div><div><br></div><div>-Max</div></div></div>