[OpenSIPS-Devel] RTPProxy's catch_dtmf module progress and bridge_srtp module RFC/plans

[Maxim Sobolev]

Hey Razvan & OpenSIPS folks,

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.

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.

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.

On the OpenSIPS end this would look like the following, bridging SRTP-RTP
in the following examples:

U[...] && M4.1 C
AES_CM_128_HMAC_SHA1_80:9sOd+W72ilwfNgNt0FzlGYj6YZPMqN1sJJx43UuS
L[...]
This would bridge SRTP on Alice side to plain RTP on Bob's side.

U[...]
L[...] && M4.1 C
AES_CM_128_HMAC_SHA1_80:NhqBK/JjtVJgmOgPyDKpvMTEjvFCQ4eiyVQelF6x
This would bridge SRTP on Bob side to plain RTP on Alice's side.

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.

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.

Any comments/suggestions are appreciated!

-Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20200428/5b043708/attachment.html>