[asterisk-dev] [Code Review] Queue SIP requests/responses that cannot be immediately processed.

[Kevin P. Fleming]

Johansson Olle E wrote:

> Let's start with this generic queue and test the effects. The locking  
> in the SIP channel in combination with the locking in the core is,  
> well, not clearly coded and especially in 1.6 with multiple sockets we  
> need to sort out the effects of this change. Do we need one queue per  
> socket or one queue for all sockets? If we sort that out properly, we  
> cold solve many more issues than the particular one you found on this  
> system.

The queueing I implemented here won't affect subscriptions or
registrations, since it is only triggered when the SIP private structure
is attached to an ast_channel. There is one queue per sip_pvt, which was
the simplest way to ensure the proper processing order and reduce the
complexity of the background processing.

> However I don't see why we should integrate it into 1.4. Care to  
> comment about that? I think it's a bit too massive change for release  
> code and would suggest that we test it very hard in many kind of  
> situations in trunk or a branch first.

Recent changes in 1.4 in other areas have begun to trigger these 'packet
drop' messages for a number of people, even in what would have been
considered to be fairly simple configurations. As channel locking issues
get fixed, and channels are kept locked for longer (but proper) periods
of time, this is only going to get worse.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming at digium.com
Check us out at www.digium.com & www.asterisk.org