[Kamailio-Users] Rtpproxy/Kamailio modification to support high capacity encryption, transcoding

Daniel-Constantin Mierla miconda at gmail.com
Wed Mar 17 13:58:33 CET 2010


Hello,

On 03/16/2010 10:33 PM, Vikram Ragukumar wrote:
> Hello,
>
> We're making initial modifications to rtpproxy to support high channel 
> capacity transcoding and encryption.
>
> At this point we want to get some general idea of the scope of changes 
> needed for rtpproxy and Kamailio... so we're starting with small steps.
>
> We've been studying rtpproxy source and our current thinking is to add 
> a sub-structure to the existing rtpp_session structure (defined in 
> rtpp_session.h). The new sub-structure would include:
>
>   -encryption options (type, key length,
>    salt size, type of key mgt protocol, etc)
>
>   -encode / decode options (type, VAD/CNG,
>    VIF size, etc)
>
> Any comments or advice on this approach appreciated.

Not being a rtpproxy developer at all, I do not see a problem with the 
approach. Also note that rtpproxy is a single process application (or 
used to be in case last version changed), take that in consideration 
when designing.

> Not sure whether to start a separate thread, but also there is the 
> issue of what changes are necessary to Kamailio to support sending 
> updated commands to rtpproxy. Would modifying Nathelper alone be 
> sufficient?

Just updating the nathelper is sufficient in kamailio.

Another idea I was playing with in the past, but time was limited, was 
to enhance sems (sip express media server) to support communication via 
nathelper-rtpproxy protocol. sems is lightweight sip media server, 
supporting already transcoding. Not being a rtp/audio guy, my plan was 
to use an existing audio mixer.

Right now i use routing via a media server when needing transconding, so 
call flow is:

[caller] ---- [kamailio] ------ [media server: asterisk/freeswitch/sems] 
----- [kamailio] ------ [caller]

rtpproxy is no longer used, since media servers support comedia 
extension. But a kamailio-mediaserver control protocol will reduce the 
signaling path.

Cheers,
Daniel

>
> Thanks and Regards,
> Vikram.
>
> PS : I'm posting on Kamailio's mailing list because it seems that both 
> Kamailio and rtpproxy developers closely follow this list.





More information about the sr-users mailing list