| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
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@xxxxxxxxx] 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 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 |