asterisk-java-devel

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

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

Hi guys,

The method ChannelManager.handleDialEvent() calls twice the private method
getTraceId() (code bellow):

    private String getTraceId(AsteriskChannel channel)
    {
        String traceId;

        try
        {
            traceId = channel.getVariable(Constants.VARIABLE_TRACE_ID);
        }
        catch (Exception e)
        {
            traceId = null;
        }
        //logger.info("TraceId for channel " + channel.getName() + " is " +
traceId);
        return traceId;
    }

My customer complains that this getVariable() is nonsense because the
variable TRACE_ID is never set on our asterisk server. Also he says this
action consumes resources on the server, so he is asking me to disable this.
He even gave me a patch (bellow) to disable the call to getVariable().

I agree with the points my customer is saying.

Guys, could you add an "option" to the AsteriskServer interface to disable
this action? For example, something like
 AsteriskServer.discoverTraceId(boolean enable)

Meanwhile I believe I'll have to apply his patch:

> ---
./src/main/java/org/asteriskjava/live/internal/ChannelManager.java.original
2006-11-01 10:40:17.000000000 -0300
> +++ ./src/main/java/org/asteriskjava/live/internal/ChannelManager.java
2006-09-20 18:29:25.000000000 -0300
> @@ -604,7 +604,10 @@
>
>          try
>          {
> -            traceId = channel.getVariable(Constants.VARIABLE_TRACE_ID);
> +            //CHANGE BEGINS HERE
> +            //traceId = channel.getVariable(Constants.VARIABLE_TRACE_ID);
> +            traceId = "";
> +            //CHANGE ENDS HERE
>          }
>          catch (Exception e)
>          {
>

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

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

Hi,

this variable is used internally to allow Asterisk-Java to track
originated calls.
Does it really hurt you? i.e. did you notice any performance problems
that you relate to the trace id?

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

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

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

Hi Stefan,


On 11/2/06, Stefan Reuter <ste...@re...> wrote:
>
> Hi,
>
> this variable is used internally to allow Asterisk-Java to track
> originated calls.


Ok, but this variable never has a value in our case. I don't know if our
asterisk server is lacking some configuration that would make that variable
be set.
Should we set this variable?
What do you mean with "track originated calls"?  What is this information?
(maybe it is worth...)

Does it really hurt you? i.e. did you notice any performance problems
> that you relate to the trace id?


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?

Is there any other way to track that information you want without these
getVariable() calls?

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?

I think these events are lacking a lot of valuable information and this is
what is making them so difficult to parse and understand.

regards,
bnegrao



=Stefan
>
> --
> 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...
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Asterisk-java-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/asterisk-java-devel
>
>
>
>

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

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