5d5324eaed2c193a019b03b60c0e587a43918f87
[asterisk/asterisk.git] / doc / manager_1_1.txt
1 Changes to manager version 1.1:
2 -------------------------------
3
4
5 * SYNTAX CLEANUPS
6 -----------------
7
8 - Response: headers are now either
9         "Success"       - Action OK, this message contains response
10         "Error"         - Action failed, reason in Message: header
11         "Follows"       - Action OK, response follows in following Events.
12
13 - Manager version changed to 1.1
14
15 * CHANGED EVENTS AND ACTIONS
16 ----------------------------
17 - The Hold/Unhold events
18         - Both are now "Hold" events
19                 For hold, there's a "Status: On" header, for unhold, status is off
20         - Modules chan_sip/chan_iax2
21
22 - The Ping Action
23         - Now use Response: success
24         - New header "Ping: pong" :-)
25
26 - The Events action
27         - Now use Response: Success
28         - The new status is reported as "Events: On" or "Events: Off"
29
30 - The JabberSend action
31         - The Response: header is now the first header in the response
32         - now sends "Response: Error" instead of "Failure"
33
34 - Newstate and Newchannel events
35         - these have changed headers
36         "State"         -> ChannelStateDesc     Text based channel state
37                         -> ChannelState         Numeric channel state
38         - The events does not send "<unknown>" for unknown caller IDs just an empty field
39
40 - Newchannel event
41         - Now includes "AccountCode"
42
43 - Newstate event
44         - Now has "CalleridNum" for numeric caller id, like Newchannel
45         - The event does not send "<unknown>" for unknown caller IDs just an empty field
46
47 - Dial event
48         - Event Dial has new headers, to comply with other events
49         - Source        -> Channel              Channel name (caller)
50         - SrcUniqueID   -> UniqueID             Uniqueid
51         (new)           -> Dialstring           Dialstring in app data
52
53 - Link and Unlink events
54         - The "Link" and "Unlink" bridge events in channel.c are now renamed to "Bridge"
55         - The link state is in the bridgestate: header as "Link" or "Unlink"
56         - For channel.c bridges, "Bridgetype: core" is added. This opens up for
57           bridge events in rtp.c 
58         - The RTP channel also reports Bridge: events with bridgetypes
59                 - rtp-native    RTP native bridge
60                 - rtp-direct    RTP peer-2-peer bridge (NAT support only)
61                 - rtp-remote    Remote (re-invite) bridge. (Not reported yet)
62
63 - The "Rename" manager event has a renamed header, to use the same
64         terminology for the current channel as other events
65         - Oldname       -> Channel              
66
67 - The "NewCallerID" manager event has a renamed header
68         - CallerID      -> CallerIDnum
69         - The event does not send "<unknown>" for unknown caller IDs just an empty field
70         
71 - Reload event
72         - The "Reload" event sent at manager reload now has a new header and is now implemented
73         in more modules than manager to alert a reload. For channels, there's a CHANNELRELOAD 
74         event to use.
75         (new)           -> Module: manager | CDR | DNSmgr | RTP | ENUM
76         (new)           -> Status: enabled | disabled
77         - To support reload events from other modules too
78                 - cdr module added
79
80 - Status action replies (Event: Status)
81         Header changes
82         - link          -> BridgedChannel
83         - Account       -> AccountCode
84         - (new)         -> BridgedUniqueid
85
86 - StatusComplete Event
87         New header
88         - (new)         -> Items                Number of channels reported
89         
90
91 - The ExtensionStatus manager command now has a "StatusDesc" field with text description of the state
92
93 - The Registry and Peerstatus events in chan_sip and chan_iax now use "ChannelType" instead of "ChannelDriver"
94
95 - The Response to Action: IAXpeers now have a Response: Success header
96
97 - The MeetmeJoin now has caller ID name and Caller ID number fields (like MeetMeLeave)
98
99 - Action ZapShowChannels
100         Header changes
101         - Channel:      -> ZapChannel
102         For active channels, the Channel: and Uniqueid: headers are added
103         You can now add a "ZapChannel: " argument to zapshowchannels actions
104         to only get information about one channel.
105
106 - Event ZapShowChannelsComplete
107         New header
108         - (new)         -> Items:       Reports number of channels reported
109
110 - Action VoicemailUsersList
111         Added new headers for SayEnvelope, SayCID, AttachMessage, CanReview
112         and CallOperator voicemail configuration settings.
113
114 * NEW ACTIONS
115 -------------
116 - Action: ModuleLoad
117         Modules: loader.c
118         Purpose:
119                 To be able to unload, reload and unload modules from AMI.
120         Variables: 
121           ActionID: <id>          Action ID for this transaction. Will be returned.
122           Module: <name>          Asterisk module name (including .so extension)
123                                   or subsystem identifier:
124                                 cdr, enum, dnsmgr, extconfig, manager, rtp, http
125           LoadType: load | unload | reload
126                           The operation to be done on module
127         If no module is specified for a reload loadtype, all modules are reloaded
128
129 - Action: ModuleCheck
130         Modules: loader.c
131         Purpose:
132                 To check version of a module - if it's loaded
133         Variables:
134           ActionID: <id>          Action ID for this transaction. Will be returned.
135           Module: <name>          Asterisk module name (not including extension)
136         Returns:
137                 If module is loaded, returns version number of the module
138                 
139                 Note: This will have to change. I don't like sending Response: failure
140                 on both command not found (trying this command in earlier versions of
141                 Asterisk) and module not found.
142                 Also, check if other manager actions behave that way.
143
144 - Action: QueueSummary
145         Modules: app_queue
146         Purpose:
147                 To request that the manager send a QueueSummary event (see the NEW EVENTS
148             section for more details).
149         Variables:
150           ActionID: <id>                Action ID for this transaction. Will be returned.
151           Queue: <name>                 Queue for which the summary is desired
152
153 - Action: QueuePenalty
154         Modules: app_queue
155         Purpose:
156                 To change the penalty of a queue member from AMI
157         Variables:
158           Interface: <tech/name>        The interface of the member whose penalty you wish to change
159           Penalty:  <number>            The new penalty for the member. Must be nonnegative.
160           Queue:  <name>                        If specified, only set the penalty for the member for this queue;
161                                                                         Otherwise, set the penalty for the member in all queues to which
162                                                                         he belongs.
163
164 - Action: QueueRule
165         Modules: app_queue
166         Purpose:
167                 To list queue rules defined in queuerules.conf
168         Variables:
169           Rule: <name>                  The name of the rule whose contents you wish to list. If this variable
170                                                                 is not present, all rules in queuerules.conf will be listed.
171                 
172
173 * NEW EVENTS
174 ------------
175
176 - Event: Transfer
177         Modules: res_features, chan_sip
178         Purpose:
179                 Inform about call transfer, linking transferer with transfer target
180                 You should be able to trace the call flow with this missing piece
181                 of information. If it works out well, the "Transfer" event should
182                 be followed by a "Bridge" event
183                 The transfermethod: header informs if this is a pbx core transfer
184                 or something done on channel driver level. For SIP, check the example:
185         Example:
186                 
187                 Event: Transfer
188                 Privilege: call,all
189                 TransferMethod: SIP
190                 TransferType: Blind
191                 Channel: SIP/device1-01849800
192                 SIP-Callid: 091386f505842c87016c4d93195ec67d@127.0.0.1
193                 TargetChannel: SIP/device2-01841200
194                 TransferExten: 100
195                 TransferContext: default
196
197 - Event: ChannelUpdate
198         Modules: chan_sip.c, chan_iax2.c
199         Purpose:
200                 Updates channel information with ID of PVT in channel driver, to
201                 be able to link events on channel driver level.
202                 * Integrated in SVN trunk as of May 4th, 2007
203
204         Example:
205
206                 Event: ChannelUpdate
207                 Privilege: system,all
208                 Uniqueid: 1177271625.27
209                 Channel: SIP/olle-01843c00
210                 Channeltype: SIP
211                 SIPcallid: NTQzYWFiOWM4NmE0MWRkZjExMzU2YzQ3OWQwNzg3ZmI.
212                 SIPfullcontact: sip:olle@127.0.0.1:49054
213
214 - Action: CoreSettings
215         Modules: manager.c
216         Purpose: To report core settings, like AMI and Asterisk version,
217                 maxcalls and maxload settings.
218                 * Integrated in SVN trunk as of May 4th, 2007
219         Example:
220                 Response: Success
221                 ActionID: 1681692777
222                 AMIversion: 1.1
223                 AsteriskVersion: SVN-oej-moremanager-r61756M
224                 SystemName: EDVINA-node-a
225                 CoreMaxCalls: 120
226                 CoreMaxLoadAvg: 0.000000
227                 CoreRunUser: edvina
228                 CoreRunGroup: edvina
229
230 - Action: CoreStatus
231         Modules: manager.c
232         Purpose: To report current PBX core status flags, like
233                 number of concurrent calls, startup and reload time.
234                 * Integrated in SVN trunk as of May 4th, 2007
235         Example:
236                 Response: Success
237                 ActionID: 1649760492
238                 CoreStartupTime: 22:35:17
239                 CoreReloadTime: 22:35:17
240                 CoreCurrentCalls: 20
241
242 - Event: NewAccountCode
243         Modules: cdr.c
244         Purpose: To report a change in account code for a live channel
245         Example:
246                 Event: NewAccountCode
247                 Privilege: call,all
248                 Channel: SIP/olle-01844600
249                 Uniqueid: 1177530895.2
250                 AccountCode: Stinas account 1234848484
251                 OldAccountCode: OllesAccount 12345
252
253 - Event: ModuleLoadReport
254         Modules: loader.c
255         Purpose: To report that module loading is complete. Some aggressive
256                 clients connect very quickly to AMI and needs to know when
257                 all manager events embedded in modules are loaded
258                 Also, if this does not happen, something is seriously wrong.
259                 This could happen to chan_sip and other modules using DNS.
260         Example:
261                 Event: ModuleLoad
262                 ModuleLoadStatus: Done
263                 ModuleSelection: All
264                 ModuleCount: 24
265
266 - Event: QueueSummary
267         Modules: app_queue
268         Purpose: To report a summary of queue information. This event is generated by
269                 issuing a QueueSummary AMI action.
270         Example:
271                 Event: QueueSummary
272                 Queue: Sales
273                 LoggedIn: 12
274                 Available: 5
275                 Callers: 10
276                 HoldTime: 47
277         If an actionID was specified for the QueueSummary action, it will be appended as the
278         last line of the QueueSummary event.
279                 
280
281 * TODO
282 ------
283