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