[Asterisk-Dev] TCP/IP Gigabit Ethernet accel. question

John Todd jtodd at loligo.com
Sat Feb 12 18:23:25 MST 2005


I've seen Asterisk used as an H323-to-SIP converter on several 
occasions.  Sometimes with good success, sometimes with latency that 
was unacceptable (but I think this was due to just not ironing out 
the config and setup.)  However: I know it works, and I'm confident 
that it can do the "Right Thing" if appropriately configured.

I've also seen Asterisk used as a back-to-back user agent, or 
quasi-Session Border Controller for SIP sessions.  This had been 
limited in the past by some chan_sip issues with the number of 
simultaneous calls, but I believe that has been worked out.

In both of these circumstances, it seems that once some minor 
Asterisk issues were worked out that what was left to do was figure 
out how fast packets could be shuffled from one port to the other if 
RTP was being proxied as well as the SIP sessions.  Once that value 
was determined, the theoretical limit of number of possible channels 
(using, let's say, G.711) could be determined by figuring out the 
packet rate and interface limits, and the limit was not so much 
Asterisk's ability to move packets in an RTP-forwarding environment. 
Much of that burden might be TCP/IP stack overhead, and it seems 
there might be some ways to work around some of this overhead.  (I'm 
going to say at the moment that codec transcoding is out of the realm 
of discussion as far as this discourse is concerned, since that is a 
question of a different nature.)

This puzzlement over packet forwarding rate is not strictly an 
academic exercise to keep me busy on a rainy afternoon.  Asterisk has 
some excellent capabilities for performing RTP forwarding for a 
variety of reasons: topology disguise, SIP normalization (for some 
value of "normalize"), header re-writes, NAT traversal, or relay for 
QoS reasons (parallel network overlay and exit.)  Looking at port 
cost of other SBCs, it seems that Asterisk might be a reasonable 
choice for low-cost and high-flexibility, if the system can create 
fast enough call setup and also then handle RTP at a reasonable rate.

blah blah blah - I lead with too much intro information.  Let's get 
to the "-dev" part of this, shall we?   A hardware manufacturer has 
mentioned to me that they have a TCP/IP stack and hardware interface 
card (gig e) which will improve performance up to 70% in a way that 
is transparent to the application.  It's a series of patches on RH9.0 
which provides this capability.  The card has two Gig-E ports, and 
one would assume that an administrator would have two "sides" of 
their network (public/private? SIP/H323?) balanced, one to a port.

The hardware manufacturer has obliquely offered to allow a test of 
this card in a suitably high-volume environment.  At the moment, I 
don't have the time or the test lab at my disposal to try with a 
large number of channels (>1000) as an experiment.  Does anyone want 
to step forward to commit some time and energy to perhaps getting 
Asterisk more into the "carrier-class" sandbox? (<cough>OSDN<cough>) 
If you are serious, please let me know and I'll introduce you to the 
person who has corresponded with me for this test inquiry.

http://www.sbei.net/Products/LAN/lanPCI-2GC.htm

JT



More information about the asterisk-dev mailing list