aboutsummaryrefslogtreecommitdiffstats
path: root/doc/manager_1_1.txt
blob: 8de37e591e66821d86b6ba34d3c4830968d5c75c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
Changes to manager version 1.1:
-------------------------------


* SYNTAX CLEANUPS
-----------------

- Response: headers are now either
	"Success"	- Action OK, this message contains response
	"Error"		- Action failed, reason in Message: header
	"Follows"	- Action OK, response follows in following Events.

- 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" :-)

- 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 "<unknown>" 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 "<unknown>" 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 "<unknown>" 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.

- Action SIPshowpeer
	Response now includes the configured parkinglot

* NEW ACTIONS
-------------
- Action: ModuleLoad
	Modules: loader.c
	Purpose:
		To be able to unload, reload and unload modules from AMI.
	Variables: 
	  ActionID: <id>          Action ID for this transaction. Will be returned.
  	  Module: <name>          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: <id>          Action ID for this transaction. Will be returned.
  	  Module: <name>          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: <id>		Action ID for this transaction. Will be returned.
	  Queue: <name>			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:  <number>		The new penalty for the member. Must be nonnegative.
	  Queue:  <name>			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: <name>			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.
		
- Action: Atxfer
	Modules: none
	Purpose:
		Initiate an attended transfer
	Variables:
		Channel: The transferer channel's name
		Exten: The extension to transfer to
		Priority: The priority to transfer to
		Context: The context to transfer to

- Action: SipShowRegistry
	Modules: chan_sip
	Purpose:
		To request that the manager send a list of RegistryEntry events.
	Variables:
	  ActionId: <id>		Action ID for this transaction. Will be returned.

* 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.

- Event: AgentRingNoAnswer
	Modules: app_queue
	Purpose: Reports when a queue member was rung but there was no answer.
	Example:
		Event: AgentRingNoAnswer
		Queue: Support
		Uniqueid: 1177530895.2
		Channel: SIP/1000-53aee458
		Member: SIP/1000
		MemberName: Thaddeus McClintock
		Ringtime: 10

- Event: RegistryEntry
	Modules: chan_sip
	Purpose: Reports the state of the SIP registrations. This event is generated by
                issuing a QueueSummary AMI action.
		The RegistrationTime header is expressed as epoch.
	Example:
		Event: RegistryEntry
		Host: sip.myvoipprovider.com
		Port: 5060
		Username: guestuser
		Refresh: 105
		State: Registered
		RegistrationTime: 1219161830
	If an actionID was specified for the SipShowRegistry action, it will be appended as the
	last line of the RegistrationsComplete event.

* TODO
------