Re: [Asterisk-java-users] DefaultAsteriskManager and queues

[Jan E. <jan...@pl...>]

On Thursday 14 July 2005 10:55, Stefan Reuter wrote:
> > Doesn't the StatusComplete come before the Queue events event have
> > started to
> > arrive, so thus when they come initialized==true and the events are not
> > handled internally at all but just dispatched to other registered event
> > handlers. That's my interpretation of the 0.1 code.
>
> You are right, the problem is indeed if the StatusCompleteEvent is
> received before the QueueEvents have been processed they are ignored.
>
> > If Asterisk sends out the responses sequentially, ie all Status events
> > before
> > the Queue events are even started on, it might work to reorder the two
> > actions (send QueueStatusAction before StatusAction) or to just send a
> > third
> > dummy action that would act as the "we're done with queues" marker. This
> > may
> > be a naive interpretation of how Asterisk works though...
>
> The events are sent out asynchronously, I think you will even get mixed
> Status and QueueEvents but I didn't verify that yet.

Ok, that rules out the idea of checking stuff based on arrival sequence. It 
would have been a really simple fix.

> The clean solution is the QueueStatusCompleteEvent. Yesterday I submitted
> a patch regarding this (http://bugs.digium.com/view.php?id=4694), so now
> we have it in CVS-HEAD asterisk at least.

Seems this was an ackowledged problem and the Digium folks just waited for a 
fix to it. So the next Asterisk version will have this fixed, although it'll 
take a while before we upgrade, the changes are AFAIK quite large.

> For the 1.0.x Asterisk one solution might be just to wait for a few
> seconds at startup and asume the initial state to be received then.
>
> > Yes, but then when AsteriskManager handles queues internally I end up
> > with the
> > same code duplicated in two places, ie. Asterisk-Java Queue:s and my own
> > Queue:s, both doing basically the same thing but with optionally
> > different names. That I'd rather want to avoid
>
> I understand... so we need to fix this to work with Asterisk 1.0.x and the
> upcoming 1.2 (with QueueStatusCompeleteEvent) is suppose, right?

Hm, nah, I can just react to all incoming queue related events and refesh my 
own visualization of the queues and just generally hold off queue related 
activities for a few seconds. I think that a little delay is no big deal at 
all. 

So far I like Asterisk-Java very much, it hasn't really done anything weird 
(aka. bugs) at all, which is IMHO very nice. :)

Haven't figured out how to put a call on hold yet, but I think SetVarAction 
with the proper magic could do it. There is no CLI command to do it either. 
Need to do some experiments. 

-- 
Jan Ekholm
jan...@pl...