Re: [Asterisk-java-devel] The "getVariable(Constants.VARIABLE_TRACE_ID)" inside of ChannelManager.handleDialEvent() is annoying.

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

On 11/2/06, Stefan Reuter <ste...@re...> wrote:
>
> > What do you mean with "track originated calls"?  What is this
> > information? (maybe it is worth...)
>
> The trace id is the the indendet solution to the following problem:
>
> Wehn you originate a call you receive the call id (uniqueId) with the
> OriginateSuccess event, i.e. when the first party answers the call. For
> several use cases (e.g. hangup an originated call before the first party
> answered) this is too late. So the idea is to set a variable (the trace
> id) with the originate and poll for it for each new channel that is
> detected.
> This is only needed if you use the originateXX methods from
> AsteriskServer in the new live package. If you dont use it its of course
> worthless so I understand your concerns.


Stefan, indeed  we're not using the AsteriskServer.originateXX methods. We
use other means to initiate the calls.

> Untill now this didn't hurt. But we're developing an application that is
> > supposed to run in every desktop of a company. My customer argues that
> > if all the desktops call getVariable() at the same time after they
> > receive a DialEvent, the asterisk server can get slow. And I think he's
> > right, don't you?
>
> Umm if you really plan to open the Manager API to every desktop this
> might call for trouble depending on how many dektops there are and how
> trustworty your environment is. Remember that the Manager API exposes a
> whole bunch of functions that are in no way restricted to a set of
> channels/extensions. In my opinion this raises questions regarding
> privacy and abuse (looking what numbers your boss is dialing, hangup or
> redirecting calls from collegues, etc.). I would implement a central
> server that talks to Asterisk and only passes the relevant information
> to each client and checks the validity of requests they make.


Very nice advice Stefan, thank you. Probably we'll change our solution to
something like this in the future.

> Is there any other way to track that information you want without these
> > getVariable() calls?
>
> I am very open to any suggestions as long as they address the problem
> outlined above.
>
> > If I'll make a patch for the manager interface on the asterisk server,
> > couldn't I add some info to be sent on the DialEvents that would save
> > you from actively calling a getVariable() on the server?
>
> The bristuff patches from Junghanns provide the uniqueId in the response
> to the OriginateAction but thats non-standard. If you manage to get
> Digium to adapt this by providing a disclaimed patch and convince them
> of the need to integrate it into Asterisk 1.6, well...


where can I get the patches Junghanns did? so you're saying they'll save you
from activelly run getVariable(), right?
I can try to make them incorporate the patch. i can try....

> I think these events are lacking a lot of valuable information and this
> > is what is making them so difficult to parse and understand.
>
> Yes the Manager API is a pain and the live package tries to work around
> that asuming that its easier to use what is there than to redesign the
> Manager API.


Your assumption makes sense for a person like you, that has a huge
experience with the Manager API. But for any beginner, and for any project
that must complete in a hurry, the manager api shows itself confusing and
bad-designed. It can be much easier to use if it tells complete and
meaningful messages.

regards,
bruno