[asterisk-users] AMI Newstate Ringing events -- Inconsistent caller id ?

[Ex Vito]

  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