[Kamailio-Users] Rtpproxy/Kamailio modification to support high capacity encryption, transcoding
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 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?
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.
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.
Daniel-
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.
Yes SEMS looks good. We've been talking with Stefan Sayer.
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]
With the above scenario, the issue for us is channel capacity -- Asterisk can't do a lot of transcoding, and even if the TC400B card is used, it turns into a "PCIe bus slugfest" as all speech/packet data has to go back and forth. Asterisk + Linux kernel still have to "touch" every RTP packet. Also the TC400B can't do encryption, conferencing, etc. Other hardware can do 100s or even 1000s of channels, so it seems to make sense to enhance rtpproxy, at least at this point.
For an Asterisk-centric approach, one way may be to enhance native bridging (canreinvite=yes). We're looking at ways to spoof SDP negotiation so both ends think they have the same media (codec) capabilities, even if not actually the case. Then exchange RTP through a card with its own GbE that does the transcoding (or other required functionality). The advantage in this case would be "keep it simple": add a card to Asterisk, some external software, and capacity is enhanced. Advantages such as "included with the chip" Texas Inst licensing might also be useful.
-Jeff
Hi Jeff,
On 03/17/2010 09:04 PM, Jeff Brower wrote:
[...]
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.
Yes SEMS looks good. We've been talking with Stefan Sayer.
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]
With the above scenario, the issue for us is channel capacity -- Asterisk can't do a lot of transcoding, and even if the TC400B card is used, it turns into a "PCIe bus slugfest" as all speech/packet data has to go back and forth. Asterisk + Linux kernel still have to "touch" every RTP packet. Also the TC400B can't do encryption, conferencing, etc. Other hardware can do 100s or even 1000s of channels, so it seems to make sense to enhance rtpproxy, at least at this point.
For an Asterisk-centric approach, one way may be to enhance native bridging (canreinvite=yes). We're looking at ways to spoof SDP negotiation so both ends think they have the same media (codec) capabilities, even if not actually the case. Then exchange RTP through a card with its own GbE that does the transcoding (or other required functionality). The advantage in this case would be "keep it simple": add a card to Asterisk, some external software, and capacity is enhanced. Advantages such as "included with the chip" Texas Inst licensing might also be useful.
when coming to transconding, capacity is indeed a problem. I agree that some of the existing solutions are consuming resources and would be good to have a lighweight application that takes care only of this job, removing the overhead of dealing with signaling, allocating channels, etc.
I can help you assisting with kamailio code, which is nathelper module related.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Jeff Brower -
Vikram Ragukumar