Hi Scott,
I found an issue with the implementation: the elements of mNITQueue are not correctly duplicated on an InviteSession copy as currently implemented (my bad, not yours).
I changed it to be a queue of shared rather than raw pointers.
On Feb 1, 2008, at 9:07 AM, Scott Godin wrote: Thanks Kobi! I think this patch is a good idea - I've had to do the same thing at the app level in many of the applications I've created. I've taken a look at the patch and have made some modifications to my local copy - I'll give others a few days to digest and make comments, then I'll commit it. Here are the changes I've made so far: 1. Removed use of the resip Fifo to store the queued NITs and replaced this with an STL queue - the FIFO classes uses Mutex's that are just unneeded overhead. 2. In an attempt to make things a little cleaner. I renamed the checkNITQueue fn to nitComplete - this fn now sets the state to completed and checks the queue. This new fn is called in dispatchInfo, dispatchMessage on responses and on refer responses. 3. As a consequence of 2 - removed the checkNITQueue call from Dialog.cxx, when receiving a response to INFO or MESSAGE NITs. I've attached a new version of the patch. Thanks, Scott > -----Original Message----- > From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx [mailto:resiprocate- > devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Kobi Eshun > Sent: Thursday, January 31, 2008 7:56 PM > To: resiprocate-devel@xxxxxxxxxxxxxxx > Subject: [reSIProcate] Patch: Adds support to queue NITs > > Hi, > > Please consider the attached patch against HEAD. It implements queueing > for any outgoing REFER, INFO, or MESSAGE requests associated with an > InviteSession. If a non-INVITE transaction is already in progress when > refer(), info() or message() is invoked, the resulting SIP request is > pushed into a FIFO. Queued requestes are shipped out one at a time > without overlap as final responses are processed. > > For INFO and MESSAGE, the new behavior is semantically equivalent to > before (queueing notwithstanding). > > For REFER, the previous code locked out a new request until the > onReferAccepted() callback fired on the first NOTIFY. The patch changes > the end of that lockout to coincide with the final response for the > REFER itself. The new lockout period should be shorter, and proved > easier to code. Does anyone see a problem with this? > > The new queue should also work with the DUM command API, but I did not > test it. > > Cheers, > -- > kobi > <resiprocate_queued_NITs-scott.diff>
|