[Asterisk-Dev] Unacceptable delays in IAX channel.

[Steve Kann]

Dmytro Mishchenko wrote:

>Hello,
>
>Here is a problem with IAX and probably other kind of channels.
>
>IAX2 channel function socket_read() process all kind of IAX frames.
>Frames of type: IAX_COMMAND_REGREQ, IAX_COMMAND_AUTHREQ, IAX_COMMAND_AUTHREP 
>etc. may take some significant time for processing. E.g. in the case when 
>realtime engine will try to get data from DB. 
>If this time is even half of a second its enough to interrupt ALL currently 
>running calls. All audio streams delayed until one frame being processed. It 
>makes audio choppy.
>
>I'm thinking that such kind of work as finding user should be scheduled and 
>executed by other thread. Does it make sense? Or may be some other solution 
>can be used?
>  
>

I've talked about this with people in chat before, and yes, you're right.

This wasn't really as big of an issue before RealTime stuff was added, 
because before then, everything was CPU-bound, and there weren't any(?) 
cases where these actions would block.

Now, though, there are.

So, there's lots of solutions to the problem, and I would probably go 
with this:

Have a pool of "worker" threads, and a "work queue".   When socket_read 
reads and parses frames, if there's a possible blocking operation 
involved (like ARA), it puts the frame into the work queue, which these 
worker threads are waiting on (or servicing).  It would seem that other 
than some reorganizing of socket_read (probably to break it up into 
smaller functions), this could be done without having to do major surgery.

I'm not sure myself which types of frames can lead to blocking like 
this, but it certainly would only be a tiny minority of the frames that 
are being processed.

-SteveK