[reSIProcate] Proposed DUM Changes to Queue Offers

[Scott Godin]

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.

 

Scott

 

From: Kovar, William (Bill) [mailto:bkovar at avaya.com] 
Sent: Monday, July 31, 2006 10:41 AM
To: Scott Godin; resiprocate-devel
Subject: RE: [reSIProcate] Proposed DUM Changes to Queue Offers

 

Scott,

 

I would think that being able to turn off this functionality would also
be desirable. When building Call Control apps, they control the queuing
and determine when to send something to an endpoint. And it's usually
done one at a time, or if so designed... more that one SIP contact at a
time. Depends on the features.

 

So, I would not try to queue calls within DUM.

 

Bill Kovar

Avaya Inc.

(732) 852-2609

bkovar at avaya.com

 

 

________________________________

From: resiprocate-devel-bounces at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of
Scott Godin
Sent: Monday, July 31, 2006 9:28 AM
To: resiprocate-devel
Subject: [reSIProcate] Proposed DUM Changes to Queue Offers

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/b1e53e94/attachment.htm>