[Asterisk-java-devel] AsteriskChannels from org.asterisk.live package don't end up in a consistent state.

[Bruno N. <bn...@gm...>]

Hi everybody,

First I'd like to say thank you for your great job on
org.asterisk.live. It is very straightforward and easy to use. When it
will be finished it will make life much easier, absolutely.

I'm testing org.asterisk.live package and I'm noticing the
AsteriskChannel objects not always end up in a consistent state, even
after following all the PropertyChangeEvents they fire.

What showed me that was the following test. First I'll (try to)
explain my test, then I'll tell what would be the expected results and
then I'll show what I'm getting.

===> THE TEST:
A person at extension 3025 asked the asterisk server to call the 3026
extension and then transfer the call to his extension. Simply put, the
person at 3025 wants to talk to the person at 3026, but asked the
asterisk server to initiate the call instead of directly dialing to
3026 by himself.

To accomplish this task the asterisk server will do these steps:

1) asterisk creates a pair of "Local/3025" channels, lets say
"Local/3025@foo,2" and "Local/3025@foo,1".

2) A new channel called "SIP/3025-bleh" is created and
"Local/3025@foo,2" will dial to "SIP/3025-bleh". Let's assume a person
on "SIP/3025-bleh" answers the phone and both channels are linked
together.

3) Now a new channel called "SIP/3026-bzzz" is created and
"Local/3025@foo,1" will dial it.

4) A person at "SIP/3026-bzzz" answered the phone and now a tricky
process happens:
4.1) "SIP/3026-bzzz" channel is renamed to "Local/3025@foo,2<ZOMBIE>"
and is hung up.
4.2) "Local/3025@foo,2" channel is renamed to "SIP/3026-bzzz", what
will remain linked to "SIP/3025-bleh".
4.3)  "Local/3025@foo,1" is hung up.

===> THE EXPECTED RESULT:
The expected result was to find the resultant "SIP/3025-bleh" and
"SIP/3026-bzzz" channels stating clearly that they are linked
together, the 'callerId' should be correct on both channels and they
were supposed to indicate which channel is being charged for this
call.

This expected result can be obtained by instantiating a new
DefaultAsteriskChannel object and calling the getChannels() method.
The output would be something like this:

AsteriskChannel[id='1160660968.768', name='SIP/3026-bzzz',
callerId='<3026>', state='UP', account='3025', dateOfCreation=Thu Oct
12 10:51:07 BRT 2006, dialedChannel=null, dialingChannel=null,
linkedChannel=AsteriskChannel[id='1160660968.769',name='SIP/3025-bleh']]

AsteriskChannel[id='1160660968.769', name='SIP/3025-bleh',
callerId='<3025>', state='UP', account='3025',dateOfCreation=Thu Oct
12 10:54:00 BRT 2006, dialedChannel=null, dialingChannel=null,
linkedChannel=AsteriskChannel[id='1160660968.768',name='SIP/3026-bzzz']]
25358555

The above AsteriskChannel objects are consistent: the 'callerId'
properties are correct in both channels, also the 'account' property
shows that the extension 3025 would be charged. If i would report this
scenario to someone else I could picture that extension 3025 dialed to
3026. Even if it didn't do it directly (asterisk dialed for it), the
idea that 3025 dialed 3026 is reasonable for this situation.


===> THE ACTUAL RESULT:
If instead of running a getChannels() to obtain the resultant active
AsteriskChannels I chose to follow all the PropertyChangeEvents for
those four channels since they were created I would end up with the
following 2 channels:

AsteriskChannel[id='1160660968.768', name='SIP/3026-bzzz',
callerId='<3025>', state='UP', account='null', dateOfCreation=Thu Oct
12 10:51:07 BRT 2006,
dialedChannel=AsteriskChannel[id='1160660968.769',
name='SIP/3025-bleh'], dialingChannel=null,
linkedChannel=AsteriskChannel[id='1160660968.769',name='SIP/3025-bleh']]

AsteriskChannel[id='1160660968.769', name='SIP/3025-bleh',
callerId='<3025>', state='UP', account='null', dateOfCreation=Thu Oct
12 10:51:07 BRT 2006, dialedChannel=null,
dialingChannel=AsteriskChannel[id='1160660968.768',
name='SIP/3026-bzzz'],
linkedChannel=AsteriskChannel[id='1160660968.768',name='SIP/3026-bzzz']]

These channels are not consistent. By reading them you're induced to
believe that 'SIP/3026-bzzz' dialed to 'SIP/3025-bleh', not the
opposite. Although techically 'SIP/3026-bzzz' (former
Local/3025@foo,2) indeed dialed to 'SIP/3025-bleh', it was the person
at 3025 that acctually initiated the call, and the person at 3026
received the call. So the channels are not bringing useful information
for this purpose.

Besides that, the 'callerId' property for the 'SIP/3026-bzzz' channel
is set to '3025' instead of '3026' as would be expected.

The attached file is a text file showing all the PropertyChangeEvents
that happen with the aforementioned channels.

===> CONCLUSION
My conclusion is if I rely on PropertyChangeEvents to get my info I
won't have useful information for all the possible situations.

To get useful information I would need to run getChannels() from time
to time. Although this would work, this is not what I need for my
current project - we need real-time information on what's going on in
the asterisk server, so we need to react to the PropertyChangeEvents.

Guys, now tell me: Is there something I'm getting wrong from all this?
Do you agree this is a problem in the org.asterisk.live package? If
it's not, how should I deal with the resulting info?

Also, is there any alternative strategy I could take to get the
real-time information from the asterisk server without having to
handle all those all-confusing, error-prone, newbies-unfriendly Events
the asterisk Manager interface sends to us?

Thank you very much,

Bruno Negrao