asterisk-java-users

[Asterisk-java-users] Intergrating DefaultAsteriskManager

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

Hi,

I started looking at Asterisk-Java a few days ago and so far it looks like a 
really capable library. It has saved me from doing the low level AMI stuff 
manually and that's really great.

I'm looking at using DefaultAsteriskManager in my test applications, and was 
wondering how others that use it have done the integration into their own 
apps. The DefaultAsteriskManager takes care of most/all(?) events behind the 
scenes and my application really doesn't know what a new channel is created 
or a hangup happens. What is the preferred way of performing this 
"information gathering" without constantly polling DefaultAsteriskManager?

Somehow I'd like the information to progress up the food chain. One solution 
could be to override the event handlers in DefaultAsteriskManager that I'm 
interested in and then just call the method i DefaultAsteriskManager to do 
the real work. This isn't too good as the methods in DefaultAsteriskManager 
can fail silently without any trace except a log message. Also 
DefaultAsteriskManager doesn't handle all events sent by Asterisk, they are 
just logged and then ignored, and I'd optionally have to react to some of 
those too.

Bottom line is that Asterisk-Java seems like a really nice piece of work, I 
just don't yet know how to use it properly. Oh, I use the 0.1 version.

Best regards,
    Jan Ekholm


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

Re: [Asterisk-java-users] Intergrating DefaultAsteriskManager

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

Hi Jan,

let me try to clarify the design of the Manager API of Asterisk-Java:

The foundation is the ManagerConnection, it repesents a connection to an
Asterisk Server and is capable to send actions and receive responses and
events. It doesn't add any valuable functionality but rather provides a
"Java" view to the Manager API (freeing you from TCP/IP connection and
parsing stuff).

The AsteriskManager is built on top of the ManagerConnection and is an
attempt to simplify interaction with Asterisk by abstracting the
interface.
You will certainly have less freedom using AsteriskManager but it will
make life easier for easy things (like originating a call or getting a
list of open channels).
AsteriskManager is still in an early state of development as I am kinda
unsure about the abstraction level that is appropriate.
So, when using AsteriskManager be aware that it might change in the futur=
e.

That said it is perfectly valid to combine ManagerConnection and
AsteriskManager in your application.
You get a ManagerConnection (from the factory, or by using spring or
whatever), register your own event handler
(ManagerConnection.addEventHandler()) and then pass the connection it to
the DefaultAsteriskManager.

For future releases I would like to extend the AsteriskManager and the
Domain object to perform event handling at a higher level of abstraction.
So you will be able to register a handler to be notified about new
Channels (or Calls?) and you will be able to register with the instance o=
f
the domain object (say a specific Channel or Queue) to be informed about
changes of that particular object (a Channel being hung up or an Agent
joining a Queue).
If you'd like to provide some information about the application you are
building and the kind of events you need that will be valuable input.

Cheers,
Stefan

Re: [Asterisk-java-users] Intergrating DefaultAsteriskManager

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

Hi,

Thank you for the quick response! See my comments below.

On Wednesday 06 July 2005 12:18, Stefan Reuter wrote:

> let me try to clarify the design of the Manager API of Asterisk-Java:
>
> The foundation is the ManagerConnection, it repesents a connection to an
> Asterisk Server and is capable to send actions and receive responses and
> events. It doesn't add any valuable functionality but rather provides a
> "Java" view to the Manager API (freeing you from TCP/IP connection and
> parsing stuff).
>
> The AsteriskManager is built on top of the ManagerConnection and is an
> attempt to simplify interaction with Asterisk by abstracting the
> interface.
> You will certainly have less freedom using AsteriskManager but it will
> make life easier for easy things (like originating a call or getting a
> list of open channels).
> AsteriskManager is still in an early state of development as I am kinda
> unsure about the abstraction level that is appropriate.
> So, when using AsteriskManager be aware that it might change in the future.

This little brief should go in the docs somewhere, it gives a better 
understanding of what is what. I missed some kind of short overview of the 
relations between the major classes.

> That said it is perfectly valid to combine ManagerConnection and
> AsteriskManager in your application.
> You get a ManagerConnection (from the factory, or by using spring or
> whatever), register your own event handler
> (ManagerConnection.addEventHandler()) and then pass the connection it to
> the DefaultAsteriskManager.

Yes, so true. I had used ManagerConnection.addEventHandler() in my first 
tests, but then somehow got the idea that I couldn't use it anymore once I 
used an AsteriskManager. Of course I can, and it works ok too. I assume that 
AsteriskManager gets to handle the event before my own event handler does, so 
the new channels etc are already in place.

> For future releases I would like to extend the AsteriskManager and the
> Domain object to perform event handling at a higher level of abstraction.
> So you will be able to register a handler to be notified about new
> Channels (or Calls?) and you will be able to register with the instance of
> the domain object (say a specific Channel or Queue) to be informed about
> changes of that particular object (a Channel being hung up or an Agent
> joining a Queue).

This sounds like a good idea. As a lazy programmer I like higher level 
abstractions.

> If you'd like to provide some information about the application you are
> building and the kind of events you need that will be valuable input.

Well, my application will basically do similar tasks to the Flash Operator 
Panel (http://www.asternic.org/), although with a very different UI. So 
monitoring what is going and changing active channels/queues etc is very 
central. I like the action/event/response framework, it is quite handy for my 
case, especially a notification based one.

Best regards,
    Jan Ekholm

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

Re: [Asterisk-java-users] Intergrating DefaultAsteriskManager

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

> This little brief should go in the docs somewhere, it gives a better
> understanding of what is what. I missed some kind of short overview of =
the
> relations between the major classes.

You are right! I will prepare a short design overview of Asterisk-Java so=
on.

> Yes, so true. I had used ManagerConnection.addEventHandler() in my firs=
t
> tests, but then somehow got the idea that I couldn't use it anymore onc=
e I
> used an AsteriskManager. Of course I can, and it works ok too. I assume
> that AsteriskManager gets to handle the event before my own event handl=
er
> does, so the new channels etc are already in place.

That's a valid question. I had a look at the source of
DefaultManagerConnection and noticed that a HashSet is used to store the
event handlers.
Therefore with the current release it is impossible to predict which even=
t
handler will be notified first.
I will change that to a List. Then the event handlers are called in the
same order as they were added to the ManagerConnection, i.e. if you pass
the ManagerConnection to DefaultAsteriskManager before adding your own
event handler it will work as you described above.

> Well, my application will basically do similar tasks to the Flash Opera=
tor
> Panel (http://www.asternic.org/), although with a very different UI. So
> monitoring what is going and changing active channels/queues etc is ver=
y
> central. I like the action/event/response framework, it is quite handy =
for
> my case, especially a notification based one.

Ok, then Channel and Queue state change events will work fine for you.

Cheers,
Stefan