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