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

[Andrew Kohlsmith]

On Monday 12 September 2005 00:34, Derek Smithies wrote:
> 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.

I wasn't saying it was taking hundreds of miliseconds to switch a thread.  I 
was saying "If the CPU's punked out what's adding MORE overhead going to 
help?"  You did, however explain it in D) below:

> 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....

If the box is loaded then you will have all kinds of other problems in 
addition to the timers shifting.  I don't think any kind of hard timer source 
is going to help.  Asterisk is *very* dependent on the host CPU being able to 
do things in a near-realtime fashion.

I worked with Steve Kann on the IAX2 jitter buffer implementation.  (Ok, he 
did all of the work and I provided half-assed bug reports, let me have my 15 
mintues, ok?  :-)) -- the JB is quite abstracted from the channel driver, and 
it was my understanding that it was done this way *specifically* to 
facilitate its being used in any channel technology which could benefit from 
it.

-A.