[Asterisk-Dev] Unacceptable delays in IAX channel.

[Steve Kann]

tim panton wrote:

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


Locking in general gets more complex!

I'm not sure how it's done now, but you can handle delayed acks just 
like retransmissions:  you can immediately schedule a delayed ack when 
you get something, and then, whenever you send a full frame, check to 
see if there's a scheduled ack, and if there is, piggyback the sequence 
number change with your full frame, and then cancel the ack.

-SteveK