[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 sr-users
mailing list