asterisk-java-users

[Asterisk-java-users] DefaultAsteriskManager and queues

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

Hi,

I noticed that DefaultAsteriskManager does handle queues too, or at least it 
has the stubs for it in 0.1. However, as the flag queuesInitialized is always 
true then the queues never get handled by DefaultAsteriskManager.handleEvent 
and the events are instead sent to event handlers directly. Of course I can 
do the handling manually, but as the code already seems to be in place in 
DefaultAsteriskManager I'd like to use that code and not build my own 
framework on top of it. So call me lazy. :) Of course, if 
DefaultAsteriskManager one day starts to handle the events then my own code 
is left cold in the water.

Any hints how to proceed?

Best regards,
    Jan Ekholm

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

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

[Stefan R. <sr...@re...>]

Hi Jan,

> I noticed that DefaultAsteriskManager does handle queues too, or at least=
 it=20
> has the stubs for it in 0.1. However, as the flag queuesInitialized is al=
ways=20
> true

DefaultAsteriskManager requests Channel and Queue state at startup. To
do this it sends a StatusAction and a QueueStatusAction.
Until that initial state is received it queues any state changing events
to apply them as delta to the initial state later on.
The StatusAction results in a StatusEvents being sent for every active
channel. Asterisk indicates that all StatusEvents have been sent by
sending a StatusCompleteEvent. So when DefaultAsteriskManager receives a
StatusCompleteEvent it knows that the initial channel state has been
completely received (now channelsInitialized =3D=3D true).
Unfortunatly the QueueStatusAction does not result in a
QueueStatusComplete event being sent, so it never knows whether queue
state is completely received. Therefore the hack to set it to true at
startup. This will work most of the time, but might cause trouble when
receiving queue changing events while still evaluating the results of
the QueueStatusAction.

> then the queues never get handled by DefaultAsteriskManager.handleEvent=20
> and the events are instead sent to event handlers directly.=20

They are handled and with the limititation above it works fine.

> Of course I can=20
> do the handling manually, but as the code already seems to be in place in=
=20
> DefaultAsteriskManager I'd like to use that code and not build my own=20
> framework on top of it. So call me lazy. :)

Another option is to just fix DefaultAsteriskManager where it might be
broken and submit a patch. So you get free maintainance for that part in
the future :)

> Of course, if DefaultAsteriskManager one day starts to handle the=20
> events then my own code is left cold in the water.

No, your code will always work. At least if you registered your event
handler independently with the underlying ManagerConnection.
In this case you always receive every event regardless of what
DefaultAsteriskManager does with that event.

So have a look at it and decide whether it works for you. I will check
if there is a QueueStatusComplete event in Asterisk CVS-HEAD and maybe
submit a patch to Digium if there isn't.

Cheers,
Stefan

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

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

On Wednesday 13 July 2005 09:18, Stefan Reuter wrote:
> Hi Jan,
>
> > I noticed that DefaultAsteriskManager does handle queues too, or at least
> > it has the stubs for it in 0.1. However, as the flag queuesInitialized is
> > always true
>
> DefaultAsteriskManager requests Channel and Queue state at startup. To
> do this it sends a StatusAction and a QueueStatusAction.
> Until that initial state is received it queues any state changing events
> to apply them as delta to the initial state later on.
> The StatusAction results in a StatusEvents being sent for every active
> channel. Asterisk indicates that all StatusEvents have been sent by
> sending a StatusCompleteEvent. So when DefaultAsteriskManager receives a
> StatusCompleteEvent it knows that the initial channel state has been
> completely received (now channelsInitialized == true).
> Unfortunatly the QueueStatusAction does not result in a
> QueueStatusComplete event being sent, so it never knows whether queue
> state is completely received. Therefore the hack to set it to true at
> startup. This will work most of the time, but might cause trouble when
> receiving queue changing events while still evaluating the results of
> the QueueStatusAction.

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.

I have a few test queues and I see that the events for the queues get sent and 
contain proper data.

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...


> > then the queues never get handled by DefaultAsteriskManager.handleEvent
> > and the events are instead sent to event handlers directly.
>
> They are handled and with the limititation above it works fine.
>
> > Of course I can
> > do the handling manually, but as the code already seems to be in place in
> > DefaultAsteriskManager I'd like to use that code and not build my own
> > framework on top of it. So call me lazy. :)
>
> Another option is to just fix DefaultAsteriskManager where it might be
> broken and submit a patch. So you get free maintainance for that part in
> the future :)

Yup, that's an option too.

> > Of course, if DefaultAsteriskManager one day starts to handle the
> > events then my own code is left cold in the water.
>
> No, your code will always work. At least if you registered your event
> handler independently with the underlying ManagerConnection.
> In this case you always receive every event regardless of what
> DefaultAsteriskManager does with that event.

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.

Regards,
    Jan Ekholm

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

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

[Stefan R. <sr...@re...>]

> Doesn't the StatusComplete come before the Queue events event have star=
ted
> to
> arrive, so thus when they come initialized=3D=3Dtrue 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. Thi=
s
> 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.

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

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 w=
ith
> the
> same code duplicated in two places, ie. Asterisk-Java Queue:s and my ow=
n
> Queue:s, both doing basically the same thing but with optionally differ=
ent
> names. That I'd rather want to avoid

I understand... so we need to fix this to work with Asterisk 1.0.x and th=
e
upcoming 1.2 (with QueueStatusCompeleteEvent) is suppose, right?

=3DStefan

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...

[Asterisk-java-users] Asterisk-Java and its dependency on specific versions of Asterisk

[Stefan R. <sr...@re...>]

>> 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 refe=
sh
> my
> own visualization of the queues and just generally hold off queue relat=
ed
> activities for a few seconds. I think that a little delay is no big dea=
l
> at all.

Ok that's fine.
One thing I still remain unsure about is Asterisk-Java's dependency on
specific Asterisk versions.
When using the ManagerConnection or AGI thats currently no big deal as I
don't expect much change regarding Asterisk's basic concepts in that area=
.
When new ManagerActions or AGICommands are added I usually try to include
a note about since which version of Asterisk it is available, so that
should be fine.
But with the AsteriskManager things are different, here we have a few
options:
1. Support only the lowest common denominator
2. Latest Asterisk-Java supports latest Asterisk (i.e. Asterisk 1.0.x ->
Asterisk-Java 0.1, Asterisk 1.2 -> Asterisk-Java 0.2) and so on
3. Latest Asterisk-Java supports multiple versions of Asterisk (i.e. if
(astversion =3D 1.0.x) then use this construct else use that construct)

Option 1 is bad as we are stuck with the old deficiencies of early
Asterisk versions.
Option 2 means supporting multiple Asterisk-Java branches, but the users
who don't want to upgrade their Asterisk servers probably prefer to stick
with the version of Asterisk-Java that once went through their QA, too.
Option 3 will sooner or later become a maintainance nightmare for me ;)

What do you think? Is Option 2 ok?
How much support (bugfixes, ..) do you need for older releases?

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

Thats nice to hear!

> 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.

Hmm i don't know either. if you got a solution let us know.

=3DStefan