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

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

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

> Untill now this didn't hurt. But we're developing an application that i=
s
> 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.

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

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

=3DStefan

--=20
reuter network consulting
Neusser Str. 110
50760 Koeln
Germany
Telefon: +49 221 1305699-0
Telefax: +49 221 1305699-90
E-Mail:  ste...@re...
Jabber:  ste...@re...