(I’m using asterisk server 126.96.36.199 extracted from source, and asterisk-java 0.3-m1)
I’m developing a Java GUI to show in real-time what is happening with the active channels on the asterisk server. I want to show each channel ringing, dialing, up, hungup, as soon as the state changes. I also need to show accurately what channel dialed to what channel, the phone numbers of each channel and what channel is being charged by the call. I’m using the Events sent by the manager interface to get the real-time info.
But my tests are showing the Events sent by the manager cannot report clearly what the asterisk server is actually doing. The Events get particularly confusing whenever a channel masquerading process is involved.
My GUI application is aimed for the regular end-user, so it need to be able to show for the user information like this: “Extension 3025 is dialing extension 3026” and “Extension 3026 is ringing (receiving a call from extension 3025)”. After the person on the extension 3026 answers the phone, I need to show “Extension 3025(being charged) is talking to 3026”.
This should be simple to accomplish but when the Local channels are involved, the Events issued by the asterisk server are totally meaningless.
I have some ideas of how these events could be more meaningful so I’ll show some Events bellow and I’ll give my suggestions of how they could be more meaningful.
In this example, the asterisk server dials extension 3026 and transfers the call to extension 3025. For doing this, it creates 2 Local channels, 1 dials to 3025, after the person at 3025 answers, the other channel dials to 3026. When the person at 3026 answers the call the Local channel that dialed 3025 is masqueraded into 3026.
The first two events are these “Newchannel” bellow:
Why are they meaningless? Because they don’t tell what were they created for.
They should state, somehow, that they were created because 3025 will talk to 3026, and 3025 will be charged.
If the Account header showed up, we could say what extension is on charge.
Also, if the Originate-Channel and Originate-Exten (headers used on the Originate action that created these channels) showed up, we could affirm which extension is calling which one.
Without this information these Newchannel Events are empty of “human-useful” information. The “real-time” goal is defeated. A developer will only find some useful information after he strove to make sense from the bunch of subsequent Events thrown.
Also on this case, after the masquerade process finished, by following the events, it seems that extension 3026 dialed to 3025, not the opposite. Although this is technically correct, this is not what a human needs to know about this call.
If at least the Events showed the Account header, we could tell who is being charged by the call.
And by following the Events, the ending channel SIP/3026 (former Local/3025@agente_out-6caa,2) stays with the callerId 3025, instead of 3026. I believe the manager Interface should issue a Newcallerid to inform this change.
I’d like to know from you what do you think about these points and how are you dealing with these difficulties.