[asterisk-dev] Streamlining RTP code.

Constantine Filin cfilin at intermedia.net
Tue Jul 11 10:20:16 MST 2006


Greetings, 
 
I am looking into channel.c of asterisk version 1.2.9 and trying to figure out what can be changed
to increase asterisk ability to handle large RTP volume. As it is this code can sustain about 20 
simultaneous calls on a Pentium 2 (not a top of the line, I know) but I would like to increase this 
number.
 
I have a couple of ideas how the performance can be optimized and would like to run it by the
rest of the list of see if someone was already moving in this direction and has code prototypes.
Otherwise I just solicit any comments.
 
So.
 
1) Right now RTP bridging happens in channel.c in function "ast_generic_bridge". This function
    calls "ast_waitfor_n" to see where the next packet comes from, then reads from it and 
    does "ast_write" to write RTP to the other channel. 

    The problem with "ast_waitfor_n" is that it can only report a single channel as the winner,
    whereas it is quite possible that the packets from both channels are waiting to be handled.
    If "ast_waitfor_n" (or another function) is changed to return an array of winners, then this can
    shave off quite a bit of CPU cycles and increase the performance. Of course the rest of 
    "ast_generic_bridge" has to be modified to work with several winners.
 
2) I am seeing in frame.c a TODO comment next to "ast_frfree": 
 
/*!
 * \todo Important: I should be made more efficient.  Frame headers should
 * most definitely be cached
 */

   The thing is that this comment has been in the code for more than a year already and
   nobody has gotten it done. I am wondering if this is just lack of time or there is a more
   fundamental difficulty behind caching the frame headers? Caching frame headers will
   definitely add to the performance.


Another big architectural issue I am trying to wrap my mind around is multiple PBX threads. 
Having 20 threads on a Pentium II doing RTP I/O pretty much starves off other threads in
the process (e.g. SIP thread or Zap thread). Has anyone been thinking about RTP I/O
multiplexing in PBX? 
 
Please let me know your ideas about this and let me know if I am looking into the right 
direction. What else can be done to increase the RTP performance?
 
Respectfully
 
Constantine.
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20060711/613b2aca/attachment.htm


More information about the asterisk-dev mailing list