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.