[reSIProcate] Patch: Adds support to queue NITs

[Kobi Eshun]

Hi Scott,

Thanks for the fast turn around. I tested your new and improved  
version and it works fine for me. And I like your encapsulation  
better. Cheers,
--
kobi


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 at resiprocate.org [mailto:resiprocate-
> > devel-bounces at resiprocate.org] On Behalf Of Kobi Eshun
> > Sent: Thursday, January 31, 2008 7:56 PM
> > To: resiprocate-devel at resiprocate.org
> > 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20080201/6ab93409/attachment.htm>