[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