Asterisk 1.6/Manager API 1.1 question

Anyone using Asterisk-IM with asterisk 1.6? It all seems good except for the incoming callerid popups. Worked fine in asterisk 1.4. I do know there are some changes in the manager API for 1.6. Anyone have some ideas? Thanks! --Fred

Oh and heres the manager API output for a typical call if someone wants to look at it and see the diferneces to the older API. Some of the obvious changes spotted ar that CallerID: from 1.4 in most cases becomes CallerIDNum: in 1.6 and Event: Link becomes Event: Bridge. Again thanks for any input anyone might have.

Event: Newchannel
TimeStamp: 2008-10-15 17:30:58
Privilege: call,all
Channel: DAHDI/1-1
ChannelState: 4
ChannelStateDesc: Ring
CallerIDNum: 0000000000
CallerIDName:
AccountCode:
Uniqueid: 1224113458.571

Event: Newexten
TimeStamp: 2008-10-15 17:30:58
Privilege: dialplan,all
Channel: DAHDI/1-1
Context: default
Extension: 0000000000
Priority: 1
Application: Macro
AppData: didexten,SIP/103,103,20
Uniqueid: 1224113458.571

Event: Newexten
TimeStamp: 2008-10-15 17:30:58
Privilege: dialplan,all
Channel: DAHDI/1-1
Context: macro-didexten
Extension: s
Priority: 1
Application: Wait
AppData: 2
Uniqueid: 1224113458.571

Event: NewCallerid
TimeStamp: 2008-10-15 17:30:58
Privilege: call,all
Channel: DAHDI/1-1
CallerIDNum: 0000000000
CallerIDName: XXXXXXXXXXXXXXXXX
Uniqueid: 1224113458.571
CID-CallingPres: 3 (Presentation Allowed, Network Number)

Event: Newstate
TimeStamp: 2008-10-15 17:31:00
Privilege: call,all
Channel: DAHDI/1-1
ChannelState: 6
ChannelStateDesc: Up
CallerIDNum: 0000000000
CallerIDName: XXXXXXXXXXXXXXXX
Uniqueid: 1224113458.571

Event: Newexten
TimeStamp: 2008-10-15 17:31:01
Privilege: dialplan,all
Channel: DAHDI/1-1
Context: macro-didexten
Extension: s
Priority: 11
Application: Dial
AppData: SIP/103,20,twk
Uniqueid: 1224113458.571

Event: Newchannel
TimeStamp: 2008-10-15 17:31:01
Privilege: call,all
Channel: SIP/103-08339fd0
ChannelState: 0
ChannelStateDesc: Down
CallerIDNum:
CallerIDName:
AccountCode:
Uniqueid: 1224113461.572

Event: ChannelUpdate
TimeStamp: 2008-10-15 17:31:01
Privilege: system,all
Channel: SIP/103-08339fd0
Uniqueid: 1224113461.572
Channeltype: SIP
SIPcallid: 67fc4c486e71c82e4779e21b4c346d2e@172.27.1.150
SIPfullcontact: sip:103@172.27.1.156:5060

Event: ChannelUpdate
TimeStamp: 2008-10-15 17:31:01
Privilege: system,all
Channel: SIP/103-08339fd0
Channeltype: SIP
SIPcallid: 67fc4c486e71c82e4779e21b4c346d2e@172.27.1.150
SIPfullcontact: sip:103@172.27.1.156:5060
Peername: 103

Event: Dial
TimeStamp: 2008-10-15 17:31:01
Privilege: call,all
SubEvent: Begin
Channel: DAHDI/1-1
Destination: SIP/103-08339fd0
CallerIDNum: 0000000000
CallerIDName:XXXXXXXXXXXXXXXX
UniqueID: 1224113458.571
DestUniqueID: 1224113461.572
Dialstring: 103

Event: NewCallerid
TimeStamp: 2008-10-15 17:31:01
Privilege: call,all
Channel: SIP/103-08339fd0
CallerIDNum: 5059384795
CallerIDName:
Uniqueid: 1224113461.572
CID-CallingPres: 3 (Presentation Allowed, Network Number)

Event: Newstate
TimeStamp: 2008-10-15 17:31:01
Privilege: call,all
Channel: SIP/103-08339fd0
ChannelState: 5
ChannelStateDesc: Ringing
CallerIDNum: 0000000000
CallerIDName:
Uniqueid: 1224113461.572

Event: ChannelUpdate
TimeStamp: 2008-10-15 17:31:04
Privilege: system,all
Channel: SIP/103-08339fd0
Channeltype: 1224113461.572
Uniqueid: SIP
SIPcallid: 67fc4c486e71c82e4779e21b4c346d2e@172.27.1.150
SIPfullcontact: sip:103@172.27.1.156:5060
Peername: 103

Event: Newstate
TimeStamp: 2008-10-15 17:31:04
Privilege: call,all
Channel: SIP/103-08339fd0
ChannelState: 6
ChannelStateDesc: Up
CallerIDNum: 0000000000
CallerIDName:
Uniqueid: 1224113461.572

Event: Bridge
TimeStamp: 2008-10-15 17:31:04
Privilege: call,all
Bridgestate: Link
Bridgetype: core
Channel1: DAHDI/1-1
Channel2: SIP/103-08339fd0
Uniqueid1: 1224113458.571
Uniqueid2: 1224113461.572
CallerID1: 0000000000
CallerID2: 0000000000

Event: Unlink
TimeStamp: 2008-10-15 17:31:07
Privilege: call,all
Channel1: DAHDI/1-1
Channel2: SIP/103-08339fd0
Uniqueid1: 1224113458.571
Uniqueid2: 1224113461.572
CallerID1: 0000000000
CallerID2: 0000000000

Event: Hangup
TimeStamp: 2008-10-15 17:31:08
Privilege: call,all
Channel: SIP/103-08339fd0
Uniqueid: 1224113461.572
CallerIDNum: 0000000000
CallerIDName:
Cause: 16
Cause-txt: Normal Clearing

Event: Dial
TimeStamp: 2008-10-15 17:31:08
Privilege: call,all
SubEvent: End
Channel: DAHDI/1-1
UniqueID: 1224113458.571
DialStatus: ANSWER

Event: Hangup
TimeStamp: 2008-10-15 17:31:08
Privilege: call,all
Channel: DAHDI/1-1
Uniqueid: 1224113458.571
CallerIDNum: 0000000000
CallerIDName: XXXXXXXXXXXXXX
Cause: 16
Cause-txt: Normal Clearing

And as well for anyone who might want to look at it. The 1.6 manager API doc for the changes that are in the new API:

  • Manager version changed to 1.1
  • CHANGED EVENTS AND ACTIONS

  • The Hold/Unhold events

    • Both are now “Hold” events
      For hold, there’s a “Status: On” header, for unhold, status is off
    • Modules chan_sip/chan_iax2
  • The Ping Action

    • Now use Response: success
    • New header “Ping: pong” :slight_smile:
  • The Events action

    • Now use Response: Success
    • The new status is reported as “Events: On” or “Events: Off”
  • The JabberSend action

    • The Response: header is now the first header in the response
    • now sends “Response: Error” instead of “Failure”
  • Newstate and Newchannel events

    • these have changed headers
      "State" -> ChannelStateDesc Text based channel state
      -> ChannelState Numeric channel state
    • The events does not send “” for unknown caller IDs just an empty field
  • Newchannel event

    • Now includes “AccountCode”
  • Newstate event

    • Now has “CalleridNum” for numeric caller id, like Newchannel
    • The event does not send “” for unknown caller IDs just an empty field
  • Newexten and VarSet events

    • Now are part of the new Dialplan privilege class, instead of the Call class
  • Dial event

    • Event Dial has new headers, to comply with other events
    • Source -> Channel Channel name (caller)
    • SrcUniqueID -> UniqueID Uniqueid
      (new) -> Dialstring Dialstring in app data
  • Link and Unlink events

    • The “Link” and “Unlink” bridge events in channel.c are now renamed to “Bridge”
    • The link state is in the bridgestate: header as “Link” or “Unlink”
    • For channel.c bridges, “Bridgetype: core” is added. This opens up for
      bridge events in rtp.c
    • The RTP channel also reports Bridge: events with bridgetypes
      • rtp-native RTP native bridge
      • rtp-direct RTP peer-2-peer bridge (NAT support only)
      • rtp-remote Remote (re-invite) bridge. (Not reported yet)
  • The “Rename” manager event has a renamed header, to use the same
    terminology for the current channel as other events

    • Oldname -> Channel
  • The “NewCallerID” manager event has a renamed header

    • CallerID -> CallerIDnum
    • The event does not send “” for unknown caller IDs just an empty field
  • Reload event

    • The “Reload” event sent at manager reload now has a new header and is now implemented
      in more modules than manager to alert a reload. For channels, there’s a CHANNELRELOAD
      event to use.
      (new) -> Module: manager | CDR | DNSmgr | RTP | ENUM
      (new) -> Status: enabled | disabled
    • To support reload events from other modules too
      • cdr module added
  • Status action replies (Event: Status)
    Header changes

    • link -> BridgedChannel
    • Account -> AccountCode
    • (new) -> BridgedUniqueid
  • StatusComplete Event
    New header

    • (new) -> Items Number of channels reported
  • The ExtensionStatus manager command now has a “StatusDesc” field with text description of the state

  • The Registry and Peerstatus events in chan_sip and chan_iax now use “ChannelType” instead of “ChannelDriver”

  • The Response to Action: IAXpeers now have a Response: Success header

  • The MeetmeJoin now has caller ID name and Caller ID number fields (like MeetMeLeave)

  • Action DAHDIShowChannels
    Header changes

    • Channel: -> DAHDIChannel
      For active channels, the Channel: and Uniqueid: headers are added
      You can now add a "DAHDIChannel: " argument to DAHDIshowchannels actions
      to only get information about one channel.
  • Event DAHDIShowChannelsComplete
    New header

    • (new) -> Items: Reports number of channels reported
  • Action VoicemailUsersList
    Added new headers for SayEnvelope, SayCID, AttachMessage, CanReview
    and CallOperator voicemail configuration settings.

  • Action Originate
    Now requires the new Originate privilege.
    If you call out to a subshell in Originate with the Application parameter,
    you now also need the System privilege.

  • NEW ACTIONS

  • Action: ModuleLoad
    Modules: loader.c
    Purpose:
    To be able to unload, reload and unload modules from AMI.
    Variables:
    ActionID: Action ID for this transaction. Will be returned.
    Module: Asterisk module name (including .so extension)
    or subsystem identifier:
    cdr, enum, dnsmgr, extconfig, manager, rtp, http
    LoadType: load | unload | reload
    The operation to be done on module
    If no module is specified for a reload loadtype, all modules are reloaded

  • Action: ModuleCheck
    Modules: loader.c
    Purpose:
    To check version of a module - if it’s loaded
    Variables:
    ActionID: Action ID for this transaction. Will be returned.
    Module: Asterisk module name (not including extension)
    Returns:
    If module is loaded, returns version number of the module

      Note: This will have to change. I don't like sending Response: failure
      on both command not found (trying this command in earlier versions of
      Asterisk) and module not found.
      Also, check if other manager actions behave that way.
    
  • Action: QueueSummary
    Modules: app_queue
    Purpose:
    To request that the manager send a QueueSummary event (see the NEW EVENTS
    section for more details).
    Variables:
    ActionID: Action ID for this transaction. Will be returned.
    Queue: Queue for which the summary is desired

  • Action: QueuePenalty
    Modules: app_queue
    Purpose:
    To change the penalty of a queue member from AMI
    Variables:
    Interface: <tech/name> The interface of the member whose penalty you wish to change
    Penalty: The new penalty for the member. Must be nonnegative.
    Queue: If specified, only set the penalty for the member for this queue;
    Otherwise, set the penalty for the member in all queues to which
    he belongs.

  • Action: QueueRule
    Modules: app_queue
    Purpose:
    To list queue rules defined in queuerules.conf
    Variables:
    Rule: The name of the rule whose contents you wish to list. If this variable
    is not present, all rules in queuerules.conf will be listed.

  • NEW EVENTS

  • Event: Transfer
    Modules: res_features, chan_sip
    Purpose:
    Inform about call transfer, linking transferer with transfer target
    You should be able to trace the call flow with this missing piece
    of information. If it works out well, the “Transfer” event should
    be followed by a “Bridge” event
    The transfermethod: header informs if this is a pbx core transfer
    or something done on channel driver level. For SIP, check the example:
    Example:

      Event: Transfer
      Privilege: call,all
      TransferMethod: SIP
      TransferType: Blind
      Channel: SIP/device1-01849800
      SIP-Callid: 091386f505842c87016c4d93195ec67d@127.0.0.1
      TargetChannel: SIP/device2-01841200
      TransferExten: 100
      TransferContext: default
    
  • Event: ChannelUpdate
    Modules: chan_sip.c, chan_iax2.c
    Purpose:
    Updates channel information with ID of PVT in channel driver, to
    be able to link events on channel driver level.
    * Integrated in SVN trunk as of May 4th, 2007

Example:

Event: ChannelUpdate
Privilege: system,all
Uniqueid: 1177271625.27
Channel: SIP/olle-01843c00
Channeltype: SIP
SIPcallid: NTQzYWFiOWM4NmE0MWRkZjExMzU2YzQ3OWQwNzg3ZmI.
SIPfullcontact: sip:olle@127.0.0.1:49054

  • Action: CoreSettings
    Modules: manager.c
    Purpose: To report core settings, like AMI and Asterisk version,
    maxcalls and maxload settings.
    * Integrated in SVN trunk as of May 4th, 2007
    Example:
    Response: Success
    ActionID: 1681692777
    AMIversion: 1.1
    AsteriskVersion: SVN-oej-moremanager-r61756M
    SystemName: EDVINA-node-a
    CoreMaxCalls: 120
    CoreMaxLoadAvg: 0.000000
    CoreRunUser: edvina
    CoreRunGroup: edvina

  • Action: CoreStatus
    Modules: manager.c
    Purpose: To report current PBX core status flags, like
    number of concurrent calls, startup and reload time.
    * Integrated in SVN trunk as of May 4th, 2007
    Example:
    Response: Success
    ActionID: 1649760492
    CoreStartupTime: 22:35:17
    CoreReloadTime: 22:35:17
    CoreCurrentCalls: 20

  • Event: NewAccountCode
    Modules: cdr.c
    Purpose: To report a change in account code for a live channel
    Example:
    Event: NewAccountCode
    Privilege: call,all
    Channel: SIP/olle-01844600
    Uniqueid: 1177530895.2
    AccountCode: Stinas account 1234848484
    OldAccountCode: OllesAccount 12345

  • Event: ModuleLoadReport
    Modules: loader.c
    Purpose: To report that module loading is complete. Some aggressive
    clients connect very quickly to AMI and needs to know when
    all manager events embedded in modules are loaded
    Also, if this does not happen, something is seriously wrong.
    This could happen to chan_sip and other modules using DNS.
    Example:
    Event: ModuleLoad
    ModuleLoadStatus: Done
    ModuleSelection: All
    ModuleCount: 24

  • Event: QueueSummary
    Modules: app_queue
    Purpose: To report a summary of queue information. This event is generated by
    issuing a QueueSummary AMI action.
    Example:
    Event: QueueSummary
    Queue: Sales
    LoggedIn: 12
    Available: 5
    Callers: 10
    HoldTime: 47
    If an actionID was specified for the QueueSummary action, it will be appended as the
    last line of the QueueSummary event.

  • TODO

I was able to get it working this morning. Grabbed the 1.0.0 snapshot of the asterisk-java library and then recompiled asterisk-im with that, Caller ID popups now show up with my Asterisk 1.6 system.

Oh and heres the asterisk-im plugin compiled with asterisk-java 1.0.0 snapshot. Be warned though. While it does bring things back to functionality for asterisk 1.6, the plugin config screen on openfire looks to be blank after installing it. The old config is still there for the previous version, just no way to make changes. Maybe someone else will have different results or maybe someone more familar with the plugin source can correct. This was comiled for openfire 3.6.0. --Fred
asterisk-im-server-1.4.1-SNAPSHOT.jar (551732 Bytes)