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

Re: [reSIProcate] Proposed DUM Changes to Queue Offers


On 7/31/06, Scott Godin <slgodin@xxxxxxxxxxxx> wrote:

This change does not mean that the application cannot continue to control
when it requests something.

Also - Currently there are also some conditions  where it is impossible for
an application to control queuing.   For example:  if you are using session
timers, then DUM will take care of sending the session refreshes.  The
application is unaware of this – so it may try to call provideOffer while a
refresh is in progress – which will cause an exception to be thrown.  Let's
say you decide to queue the request in the application at this point.  In
most cases a session refresh will complete without any notification to the
application – in this case the application will NOT know when it is OK to
try and retry the provideOffer call – it will need to resort to some kind of
polling attempt mechanism.


It is reasonable to allow queueing of exactly one offer if the
following is true:
- you are not waiting for an answer
- you have replied to all offers (no unanswered offers)

This allows us to handle the situation above where dum is sending or
responding to a session timer when the application calls provideOffer.