[Asterisk-Dev] Unacceptable delays in IAX channel.

[tim panton]

On 21 Dec 2005, at 15:39, Steve Kann wrote:

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

There is a thing to watch here, you might need to ack the command  
frame before you actually act on it, then
send an explicit response eg REGREJ or REGACK. Eitherway the IAX  
sequence numbering gets a
bit more complex to implement than in the single thread version.


>
> -SteveK
>

Tim.

http://www.westhawk.co.uk/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20051221/296aeef3/attachment.htm