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