[Asterisk-Dev] I need help to make a simple iax switch/proxy

[Derek Smithies]

On Sun, 11 Sep 2005, Andrew Kohlsmith wrote:

> On Sunday 11 September 2005 22:28, Derek Smithies wrote:
> > You see, implementing IAX2 as is done is asterisk is unfortunate, cause
> > there is a serious bottle neck at the reception and transmission of
> > packets. The receive thread has to do reception and decoding of the
> > packets, leaving insufficient time to do correctly receive all packets.
> 
> I'm not sure I understand.
> 
> If there is CPU starvation with a single-threaded IAX decoder how is adding 
> more overhead (thread switches) going to help out?  I can see how it could 
> help on a multiprocessor system but yet still I'm not so sure, as you're 
> still fighting over resources (memory and network) and no amount of CPUs or 
> threads are going to help with that.
> 
> Where exactly are you seeing these starvation issues?  I have to say I haven't 
> noticed any quality issues with IAX2, but then again I guess I'm just not 
> hitting the level of CPU usage that this becomes a problem.  Do you have 
> packet dumps/audio files that show this?

Sorry, I cannot provide you with concrete evidence. I am basing my 
comments on information I gathered at the German Unix Users Group 
conference at the start of this year, comments from Brian West, (indeed 
you will have seen his previous email), and reading reviews from the web.

A)It is 100% clear that there are no design flaws (that would influence 
   quality) in IAX2.

B)Several people (each with businesses providing asterisk services) have 
  reported that asterisk IAX2 does not work well on multi CPU machines.
  They report audio dropouts. 

C)The time to do a thread switch arguement is nonsense.
  Recent kernels report thread switching times well under a microsecond.
  Sure, it was a problem with 2.0 kernels. Things have moved on.

D)A review of the asterisk IAX2 code shows that the receive thread does a 
  lot of work. 
  The iax2 channel consists of two threads, which handles all of the 
  current iax2 calls. One thread is for reading, one is for writing.
  Thus, one thread will read in all iax2 frames, process them, and pass 
  them on to the queues (as used by the * core).
  The other thread will pick the packets of the queues, process, and 
  transmit. This is O.K, until you realise that if the core locks the 
  queues, the read&write threads are totally locked, and no sending can 
  happen. By using more threads to do the read/write process, would not 
  stop the entire read/write process by a mutex on the queues.

E)Jitter buffers.
   There does not seem to be a uniform approach to jitter buffers in 
asterisk. IAX2, SIP and H.323 all appear to have quite different 
approacches to this problem - why not one jitter buffer for all ?
In IAx2, it relies uppon the computer (with software timers) to correctly 
deliver the packets. Software timers are not, in my view, reliable enough 
for this task - particularly when the box is loaded....

Derek.
  
-- 
Derek Smithies Ph.D.                 Any fool can write code that 
IndraNet Technologies Ltd.                a computer can understand.        
Email: derek at indranet.co.nz         Good programmers write code 
ph +64 3 365 6485                          that humans can understand.
Web: http://www.indranet-technologies.com/            Martin Fowler