Re: [Asterisk-java-users] Patch to DefaultManagerConnection

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

Brett Sutton wrote:
> I'm guessing that the problem revolves around on how
> sendEventGeneratingAction identifies a matching event. I'm guessing tha=
t
> it is using the channel name to do a match (given that it doesn't have =
a
> uniqueid to match on).

sendEventGeneratingAction identifies matching events by using the
internal action id, so there is no dependency on any other data like
unique id, channel name or whatever.

Let me clarify how that action id stuff currently works:

asume you send an action with actionId =3D "MyActionId-1" (lets call this=

user provided actionId) via sendEvent()
sendEvents (in fact it is ActionWriter that is used by sendEvent, but
that doesnt matter here) adds the "internalActionId", i.e. sth like
"6301159_3". So what is sent to asterisk is 6301159_3#MyActionId-1.
when a response or response event is received the internalActionId is
retrieved and removed, so the actionId that your app receives is
"MyActionId-1". Any internal matching is based on the internalActionId.
If your application also needs some matching logic that should probably
be done via the user provided action id.

What your patch seems to do is to use the internalActionId automatically
as userprovided action id as well. So what we sent to asterisk is
finally something like 6301159_3#6301159_3 with the original action id
provided by the user being trashed.

Is this correct?

> If you send an originate such as Zap/g0 then it
> affectively hangs. I'm also concerned with timing issues (which could
> also be the source of the hang). I'm not certain but I have a suspicion=

> that in unusual circumstance other events (such as a hangup) could occu=
r
> before the response event.
> If this occurs then its not possible to match the hangup to the
> originate (and them my program hangs :<).
>=20
> The scenario is this:
> Register hangup event handler
> Send originate - call established
> Call instantly drops
> Hangup event generated
> Event Generation Action sent - oops too late, line has already hungup.
>=20
> For this to work reliably the send event generation call would need to
> be made before the originate is sent (I suspect I have seen the Call
> class fails because of this scenario).

ok i think see the issue here. DefaultAsteriskManager is not capable to
handle this situation right now.
So what do you do in this case?

you can save the action id of the originate and but you have no way to
match it with the hangup event as the hangup event only includes the
uniqueId and that one is only known after the originate event has been
received. so you have to store hangup events somewhere and upon
receiving the originate event check that there was no hangup event
before. right?

> Is it possible to sent the event generation call before the originate?

i dont understand that one.

> I've been running ngrep and it seems to support my arguments.

so your ngrep output indicates that there are hangups before originate
events? then this is a bug in DefaultAsteriskManager.

> The action id method I've implemented resolve all of these issues and
> IMHO is much easier to use.

do you think this works with using a user provided action id or do we
really need to alter the A-J code for this to work. I have a bit of a
problem with just overwriting the action id set by the user as this
users from doing their own matching. That's why my approach was to hide
all that internalActionId stuff from users.

=3DStefan

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