Ex Vito
2007-Nov-23 16:29 UTC
[asterisk-users] AMI Newstate Ringing events -- Inconsistent caller id ?
Hello list,
I'm observing what I believe to be inconsistent behaviour
regarding "Newstate" AMI events for the "Ringing" state.
As such I come to you asking for experience or advice: am
I wrong or should I file a bug ?
I present you a short introduction which I feel is relevant;
however, if you want to go straight to my technical question,
please scroll down to the bottom of the email titled
"The Problem"! (thanks)
---------------------
Context and Objective
---------------------
My purpose is to deliver screen popups on incoming calls
which, initially, will do little more than show caller
identification on the users desktop. The user should get,
if available, the caller id number and name -- the name
will come either directly from the caller, from an LDAP
lookup to a centralized contact database or, lastly, from
a local address book lookup on the user's computer.
------
Method
------
A "daemon" connects to asterisk via AMI and listens for
events; this daemon will know which channels are associated
to which users/desktops and will notify desktop "agents" on
incoming calls -- conceptually trivial.
The biggest reason to go the AMI way is to stay away from
adapting the dialplan to such basic behaviour -- ideally,
this "daemon" would work fine whatever the dialplan is in
place; the second reason is that, effectively, I want to
be able to manage and initiate calls from the destkop in
the future so I will need AMI -- as such, if I can stay
exclusively within the AMI "realm" great (as opposed to using
both AGI + AMI). :)
Since I found very little AMI documentation (FYI: docs
directory in source distribution, the wiki and TFOT 1st
and 2nd ed) I started tracing AMI events to understand
what information I would need to extract from it -- not
the ideal way of doing it !!! :(
(BTW, if you know of any better sources of info for AMI,
apart from the source code itself, please do share!)
-----------
My findings
-----------
Initially I found that the "Newstate" event seemed to have
all the information I needed.
Essentially it is fired when a channel changes state and includes
the caller id information -- great ! (so I thought)
In fact, the "Newstate" event, for the state "Ringing",
only
contains correct information some of the times -- if the ring
is triggered by a Dial() to a SIP destination, the caller id
info seems to be inconsistent.
Read on for the details...
----------------------------------------------------------------------------
The Problem - setup
----------------------------------------------------------------------------
Tests were performed with latest (as of yesterday) asterisk 1.2
and 1.4 versions -- behaviour looks the same to me.
Channels are two SIP user agents on the local LAN segment and one
analog phone connected to a local FXS port: SIP/st2030, SIP/xten
and Zap/1.
Relevant part of dialplan is:
exten => 200,1,Dial(Zap/1)
exten => 202,1,Dial(SIP/st2030)
exten => 203,1,Dial(SIP/xten)
exten => 300,1,Queue(testQueue)
exten => 502,1,Dial(SIP/st2030)
Notes:
- all extensions have a 2nd priority wich does Hangup()
- the 2xx extensions also have a hint priority
- when testing, the testQueue is configured to have
the "other two channels" as static members in a "ring
all" strategy (ie: the two SIP channels when testing
dialling from the Zap one)
-----------------------------------
The Problem - Is this event wrong ?
-----------------------------------
The test/trace methodology I performed is as follows:
- For each of the three phones
- Dial the other two in the 2xx range of extensions
- Dial the queue
So, in all, I have 9 tests:
BAD - Zap/1 -> Dial (SIP/st2030)
BAD - Zap/1 -> Dial (SIP/xten)
OK - Zap/1 -> Queue (SIP/st2030 and SIP/xten)
OK - SIP/st2030 -> Dial (Zap/1)
BAD - SIP/st2030 -> Dial (SIP/xten)
OK - SIP/st2030 -> Queue (SIP/xten and Zap/1)
OK - SIP/xten -> Dial (Zap/1)
BAD - SIP/xten -> Dial (SIP/st2030)
OK - SIP/xten -> Queue (SIP/st2030 and Zap/1)
I flagged OK the tests where the "Newstate" event, in the
"Ringing" state, contains the correct caller id information.
Note that this event is fired twice when we are calling the
queue: one relative to each channel -- which is correct. :)
I flagged BAD the tests where the "Newstate" does not contain
correct information (again, for the "Ringing" state).
Observations:
- All "rings" initiated by the Queue() lead to "Newstate
Ringing"
events that CONTAIN CORRECT caller id information.
- All "rings" initiated by the Dial() towards the Zap destination
lead to events that CONTAIN CORRECT caller id information.
- All "rings" initiated by the Dial() towards SIP destinations
lead to events that DO NOT CONTAIN CORRECT callerd id information.
So, what information is in the "Newstate Ringing" event when
we Dial() a SIP channel ? Oddly enough, the caller id is the
"destination caller id"; or, in other words, the caller id info
is the same as if it was the destination channel that was initiating
the call.
Example:
If Zap/1 is Dial'ing() SIP/st2030 via extension 202,
the "Newstate" event that AMI triggers contains "202" as
the
caller id instead of "200" -- (yes, the caller ids are correctly
setup in the respective sip.conf / zapata.conf!)
That's why you see a second extension (502) Dial'ing() the same
SIP/st2030 channel; if Zap/1 Dial's() SIP/st2030 via the 502
extension, the "Newstate Ringing" event will contain
"502" as
the caller id !!!
---------------------
The Problem - Wrap up
---------------------
Of course I traced more information and noticed that in the
"failing"
circumstace -- Dial() to SIP channels -- there is something different
happening the the overall sequence of AMI events:
- If we Dial() a SIP channel, the "Dial" event is fired BEFORE
the "Newstate Ringing" event.
- If we Dial() a Zap channel, the "Dial" event is fired AFTER
the "Newstate Ringing" event.
- Of course, if we Queue(), there is no "Dial" event, there is
a "Join" event fired BEFORE the "Newstate Ringing"
events.
Oddly enough (lucky enough?), everything seems fine regarding
"Newstate Ringing" events triggered by the queue.
So my main questions are:
1. Is the behaviour I'm observing supposed to be like this ?
Or is this a bug ?
2. If the behaviour is correct, what explains the inconsistency ?
(so that I can correctly account for it in programming the
event watcher daemon)
3. How can I "be certain" that other channel types won't
have a third different type of behaviour ?
POSSIBLE APPROACH / WORKAROUND (which I wouldn't like to take until I
understand what's going on here!) -- in the failing case, the
"Dial"
event precedes the "Newstate Ringing" event and contains correct
info
for both channels and caller id; it is not difficult to track and
associate those two events so as to correct the information contained
in the "Newstate Ringing" event.
Well, this has been a long one! I hope I was clear enough in my
explanation and I hope some one can shed some light into this.
Thanks a lot in advance for any insights! :)
Regards,
PS: I can provide "simplified" traces of the events if needed.
--
Ex Vito
Moises Silva
2007-Nov-23 18:58 UTC
[asterisk-users] AMI Newstate Ringing events -- Inconsistent caller id ?
Wow, what a long post :)
I must confess I did not read slowly, but, I was very interested
because I was the one adding the Dial even feature to Asterisk, and I
remembered it was a mess. From reading Asterisk code one can learn
some stuff. I found this piece of code:
senddialevent(in, c);
/* After calling, set
callerid to extension */
if
(!ast_test_flag(peerflags, OPT_ORIGINAL_CLID)) {
char
cidname[AST_MAX_EXTENSION] = "";
ast_set_callerid(c, S_OR(in->macroexten, in->exten),
get_cid_name(cidname, sizeof(cidname), in), NULL);
Around line 554 of apps/app_dial.c
I added the senddialevent, but not the condition you see below. That
one was added by someone else. It seems that determine wheter or not
the current extension will be set for outgoing calls. Setting
OPT_ORIGINAL_CLID may fix your problem. That option is set, as
voip-info says:
http://www.voip-info.org/wiki/index.php?page=Asterisk+cmd+Dial
Using option 'o'
o: Restore the Asterisk v1.0 CallerId behaviour (send the original
caller's ID) in Asterisk v1.2 (default: send this extension's number)
However, as you can read in
http://lists.digium.com/pipermail/asterisk-dev/2006-July/021546.html
Olle makes a joke about something that is very true. Dial() is
monster. So you might have found a bug, since the 'o' option does not
explain why the Dial event is generated before/after newstate events
for some technologies and other inconsistencies you mentioned.
By the way. I just wrote an application that allow to execute AGI
using the Manager interface, so that might be helpful for you.
http://bugs.digium.com/view.php?id=11282
Just ignore the initial description, I open that bug report for a dial
plan application that allowed dynamic execution of applications thru
AMI, but later on changed my mind and moved that thing to be AGI
command thru the manager. So, the first note I added to that bug
report explain how to use it, in case you care.
Hope this post helps you a bit.
Good Luck!
- Moy
On Nov 23, 2007 10:29 AM, Ex Vito <ex.vitorino at gmail.com>
wrote:> Hello list,
>
>
> I'm observing what I believe to be inconsistent behaviour
> regarding "Newstate" AMI events for the "Ringing"
state.
>
> As such I come to you asking for experience or advice: am
> I wrong or should I file a bug ?
>
> I present you a short introduction which I feel is relevant;
> however, if you want to go straight to my technical question,
> please scroll down to the bottom of the email titled
> "The Problem"! (thanks)
>
>
> ---------------------
> Context and Objective
> ---------------------
>
> My purpose is to deliver screen popups on incoming calls
> which, initially, will do little more than show caller
> identification on the users desktop. The user should get,
> if available, the caller id number and name -- the name
> will come either directly from the caller, from an LDAP
> lookup to a centralized contact database or, lastly, from
> a local address book lookup on the user's computer.
>
>
> ------
> Method
> ------
>
> A "daemon" connects to asterisk via AMI and listens for
> events; this daemon will know which channels are associated
> to which users/desktops and will notify desktop "agents" on
> incoming calls -- conceptually trivial.
>
> The biggest reason to go the AMI way is to stay away from
> adapting the dialplan to such basic behaviour -- ideally,
> this "daemon" would work fine whatever the dialplan is in
> place; the second reason is that, effectively, I want to
> be able to manage and initiate calls from the destkop in
> the future so I will need AMI -- as such, if I can stay
> exclusively within the AMI "realm" great (as opposed to using
> both AGI + AMI). :)
>
> Since I found very little AMI documentation (FYI: docs
> directory in source distribution, the wiki and TFOT 1st
> and 2nd ed) I started tracing AMI events to understand
> what information I would need to extract from it -- not
> the ideal way of doing it !!! :(
>
> (BTW, if you know of any better sources of info for AMI,
> apart from the source code itself, please do share!)
>
>
> -----------
> My findings
> -----------
>
> Initially I found that the "Newstate" event seemed to have
> all the information I needed.
>
> Essentially it is fired when a channel changes state and includes
> the caller id information -- great ! (so I thought)
>
> In fact, the "Newstate" event, for the state
"Ringing", only
> contains correct information some of the times -- if the ring
> is triggered by a Dial() to a SIP destination, the caller id
> info seems to be inconsistent.
>
> Read on for the details...
>
>
>
----------------------------------------------------------------------------
> The Problem - setup
>
----------------------------------------------------------------------------
>
> Tests were performed with latest (as of yesterday) asterisk 1.2
> and 1.4 versions -- behaviour looks the same to me.
>
> Channels are two SIP user agents on the local LAN segment and one
> analog phone connected to a local FXS port: SIP/st2030, SIP/xten
> and Zap/1.
>
> Relevant part of dialplan is:
>
> exten => 200,1,Dial(Zap/1)
> exten => 202,1,Dial(SIP/st2030)
> exten => 203,1,Dial(SIP/xten)
>
> exten => 300,1,Queue(testQueue)
>
> exten => 502,1,Dial(SIP/st2030)
>
> Notes:
> - all extensions have a 2nd priority wich does Hangup()
> - the 2xx extensions also have a hint priority
> - when testing, the testQueue is configured to have
> the "other two channels" as static members in a "ring
> all" strategy (ie: the two SIP channels when testing
> dialling from the Zap one)
>
>
> -----------------------------------
> The Problem - Is this event wrong ?
> -----------------------------------
>
> The test/trace methodology I performed is as follows:
>
> - For each of the three phones
> - Dial the other two in the 2xx range of extensions
> - Dial the queue
>
> So, in all, I have 9 tests:
>
> BAD - Zap/1 -> Dial (SIP/st2030)
> BAD - Zap/1 -> Dial (SIP/xten)
> OK - Zap/1 -> Queue (SIP/st2030 and SIP/xten)
> OK - SIP/st2030 -> Dial (Zap/1)
> BAD - SIP/st2030 -> Dial (SIP/xten)
> OK - SIP/st2030 -> Queue (SIP/xten and Zap/1)
> OK - SIP/xten -> Dial (Zap/1)
> BAD - SIP/xten -> Dial (SIP/st2030)
> OK - SIP/xten -> Queue (SIP/st2030 and Zap/1)
>
>
> I flagged OK the tests where the "Newstate" event, in the
> "Ringing" state, contains the correct caller id information.
> Note that this event is fired twice when we are calling the
> queue: one relative to each channel -- which is correct. :)
>
> I flagged BAD the tests where the "Newstate" does not contain
> correct information (again, for the "Ringing" state).
>
> Observations:
>
> - All "rings" initiated by the Queue() lead to "Newstate
Ringing"
> events that CONTAIN CORRECT caller id information.
>
> - All "rings" initiated by the Dial() towards the Zap
destination
> lead to events that CONTAIN CORRECT caller id information.
>
> - All "rings" initiated by the Dial() towards SIP destinations
> lead to events that DO NOT CONTAIN CORRECT callerd id information.
>
>
> So, what information is in the "Newstate Ringing" event when
> we Dial() a SIP channel ? Oddly enough, the caller id is the
> "destination caller id"; or, in other words, the caller id info
> is the same as if it was the destination channel that was initiating
> the call.
>
> Example:
>
> If Zap/1 is Dial'ing() SIP/st2030 via extension 202,
> the "Newstate" event that AMI triggers contains
"202" as the
> caller id instead of "200" -- (yes, the caller ids are
correctly
> setup in the respective sip.conf / zapata.conf!)
>
> That's why you see a second extension (502) Dial'ing() the same
> SIP/st2030 channel; if Zap/1 Dial's() SIP/st2030 via the 502
> extension, the "Newstate Ringing" event will contain
"502" as
> the caller id !!!
>
>
>
> ---------------------
> The Problem - Wrap up
> ---------------------
>
> Of course I traced more information and noticed that in the
"failing"
> circumstace -- Dial() to SIP channels -- there is something different
> happening the the overall sequence of AMI events:
>
> - If we Dial() a SIP channel, the "Dial" event is fired BEFORE
> the "Newstate Ringing" event.
>
> - If we Dial() a Zap channel, the "Dial" event is fired AFTER
> the "Newstate Ringing" event.
>
> - Of course, if we Queue(), there is no "Dial" event, there is
> a "Join" event fired BEFORE the "Newstate Ringing"
events.
> Oddly enough (lucky enough?), everything seems fine regarding
> "Newstate Ringing" events triggered by the queue.
>
>
> So my main questions are:
>
> 1. Is the behaviour I'm observing supposed to be like this ?
> Or is this a bug ?
>
> 2. If the behaviour is correct, what explains the inconsistency ?
> (so that I can correctly account for it in programming the
> event watcher daemon)
>
> 3. How can I "be certain" that other channel types won't
> have a third different type of behaviour ?
>
>
> POSSIBLE APPROACH / WORKAROUND (which I wouldn't like to take until I
> understand what's going on here!) -- in the failing case, the
"Dial"
> event precedes the "Newstate Ringing" event and contains
correct info
> for both channels and caller id; it is not difficult to track and
> associate those two events so as to correct the information contained
> in the "Newstate Ringing" event.
>
>
> Well, this has been a long one! I hope I was clear enough in my
> explanation and I hope some one can shed some light into this.
>
> Thanks a lot in advance for any insights! :)
> Regards,
>
> PS: I can provide "simplified" traces of the events if needed.
> --
> Ex Vito
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
--
"Within C++, there is a much smaller and cleaner language struggling
to get out."