| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
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
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] 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 |