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

Daniel-Constantin Mierla miconda at gmail.com
Thu Mar 18 12:54:05 CET 2010


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
* http://www.asipto.com/




More information about the Users mailing list