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

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