[reSIProcate] Proposed DUM Changes to Queue Offers

[Scott Godin]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060731/37e90ce1/attachment.htm>