< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

RE: [reSIProcate] Proposed DUM Changes to Queue Offers


Probably not - in the case of calling provideOffer when one is already
queued - it probably makes more sense to just replace the previously
queued offer with the newly requested one.

Scott

> -----Original Message-----
> From: jay@xxxxxxxxxxxxxx [mailto:jay@xxxxxxxxxxxxxx]
> Sent: Monday, July 31, 2006 10:33 AM
> To: Scott Godin; resiprocate-devel
> Subject: Re: [reSIProcate] Proposed DUM Changes to Queue Offers
> 
> One question:
> 
> For provideOffer/requestOffer - does it make sense to ever allow the
> queue depth to be greater than 1?  For NITs it makes perfect sense but
> I'm not so sure on offers.
> 
> Jay
> 
> BTW - this is a vote for "make the change"
> 
> ----- Original Message Follows -----
> From: "Scott Godin" <slgodin@xxxxxxxxxxxx>
> To: "resiprocate-devel"
> <resiprocate-devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: [reSIProcate] Proposed DUM Changes to Queue Offers
> Date: Mon, 31 Jul 2006 09:28:25 -0400
> 
> > I'm considering adding queuing of provideOffer (and
> > requestOffer) requests in dum.  It's kind of a pain right now for an
> > application to have to track this state.  Ie.
> > Calling provideOffer when one is still outstanding, or worse yet
> > (because the app didn't initiate it), when a session timer is being
> > sent will result in an error.
> >
> >
> >
> > My proposal is:
> >
> > 1.        If provideOffer is called in a state where we
> > cannot immediately provide the offer, then store the sdp in some
kind
> > of offer queue (deque).
> >
> > 2.       When we return to a regular connected state -
> > check if there are entries in the queue and dispatch the first offer
> > on the queue.
> >
> >
> >
> > These changes will obsolete the WaitingToRequestOffer, and
> > WaitingToOffer states.
> >
> >
> >
> > We can consider doing something similar for NITs (INFO and
> > MESSAGE) too in the future.  But this might be a little more
> > complicated, due to CSEQ generation, since we would need to store
the
> > entire message.
> >
> >
> >
> > Any opposition?
> >
> >
> >
> > Scott
> >
> >
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel