UPGRADE-12.txt 23 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479
  1. ===========================================================
  2. ===
  3. === Information for upgrading between Asterisk versions
  4. ===
  5. === These files document all the changes that MUST be taken
  6. === into account when upgrading between the Asterisk
  7. === versions listed below. These changes may require that
  8. === you modify your configuration files, dialplan or (in
  9. === some cases) source code if you have your own Asterisk
  10. === modules or patches. These files also include advance
  11. === notice of any functionality that has been marked as
  12. === 'deprecated' and may be removed in a future release,
  13. === along with the suggested replacement functionality.
  14. ===
  15. === UPGRADE-1.2.txt -- Upgrade info for 1.0 to 1.2
  16. === UPGRADE-1.4.txt -- Upgrade info for 1.2 to 1.4
  17. === UPGRADE-1.6.txt -- Upgrade info for 1.4 to 1.6
  18. === UPGRADE-1.8.txt -- Upgrade info for 1.6 to 1.8
  19. === UPGRADE-10.txt -- Upgrade info for 1.8 to 10
  20. === UPGRADE-11.txt -- Upgrade info for 10 to 11
  21. ===
  22. ===========================================================
  23. There are many significant architectural changes in Asterisk 12. It is
  24. recommended that you not only read through this document for important
  25. changes that affect an upgrade, but that you also read through the CHANGES
  26. document in depth to better understand the new options available to you.
  27. Additional information on the architectural changes made in Asterisk can be
  28. found on the Asterisk wiki (https://wiki.asterisk.org)
  29. Of particular note, the following systems in Asterisk underwent significant
  30. changes. Documentation for the changes and a specification for their
  31. behavior in Asterisk 12 is also available on the Asterisk wiki.
  32. - AMI: Many events were changed, and the semantics of channels and bridges
  33. were defined. In particular, how channels and bridges behave under
  34. transfer scenarios and situations involving multiple parties has
  35. changed significantly. See https://wiki.asterisk.org/wiki/x/dAFRAQ
  36. for more information.
  37. - CDR: CDR logic was extracted from the many locations it existed in across
  38. Asterisk and implemented as a consumer of Stasis message bus events.
  39. As a result, consistency of records has improved significantly and the
  40. behavior of CDRs in transfer scenarios has been defined in the CDR
  41. specification. However, significant behavioral changes in CDRs resulted
  42. from the transition. The most significant change is the addition of
  43. CDR entries when a channel who is the Party A in a CDR leaves a bridge.
  44. See https://wiki.asterisk.org/wiki/x/pwpRAQ for more information.
  45. - CEL: Much like CDRs, CEL was removed from the many locations it existed in
  46. across Asterisk and implemented as a consumer of Stasis message bus
  47. events. It now closely follows the Bridging API model of channels and
  48. bridges, and has a much closer consistency of conveyed events as AMI.
  49. For the changes in events, see https://wiki.asterisk.org/wiki/x/4ICLAQ.
  50. Build System:
  51. - Removed the CHANNEL_TRACE development mode build option. Certain aspects of
  52. the CHANNEL_TRACE build option were incompatible with the new bridging
  53. architecture.
  54. - Asterisk now depends on libjansson, libuuid and optionally (but recommended)
  55. libxslt and uriparser.
  56. - The new SIP stack and channel driver uses a particular version of PJSIP.
  57. Please see https://wiki.asterisk.org/wiki/x/J4GLAQ for more information on
  58. configuring and installing PJSIP for use with Asterisk.
  59. AgentLogin and chan_agent:
  60. - Along with AgentRequest, this application has been modified to be a
  61. replacement for chan_agent. The chan_agent module and the Agent channel
  62. driver have been removed from Asterisk, as the concept of a channel driver
  63. proxying in front of another channel driver was incompatible with the new
  64. architecture (and has had numerous problems through past versions of
  65. Asterisk). The act of a channel calling the AgentLogin application places the
  66. channel into a pool of agents that can be requested by the AgentRequest
  67. application. Note that this application, as well as all other agent related
  68. functionality, is now provided by the app_agent_pool module.
  69. - This application no longer performs agent authentication. If authentication
  70. is desired, the dialplan needs to perform this function using the
  71. Authenticate or VMAuthenticate application or through an AGI script before
  72. running AgentLogin.
  73. - The agents.conf schema has changed. Rather than specifying agents on a
  74. single line in comma delineated fashion, each agent is defined in a separate
  75. context. This allows agents to use the power of context templates in their
  76. definition.
  77. - A number of parameters from agents.conf have been removed. This includes
  78. maxloginretries, autologoffunavail, updatecdr, goodbye, group, recordformat,
  79. urlprefix, and savecallsin. These options were obsoleted by the move from
  80. a channel driver model to the bridging/application model provided by
  81. app_agent_pool.
  82. - The AGENTUPDATECDR channel variable has also been removed, for the same
  83. reason as the updatecdr option.
  84. - The endcall and enddtmf configuration options are removed. Use the
  85. dialplan function CHANNEL(dtmf-features) to set DTMF features on the agent
  86. channel before calling AgentLogin.
  87. AgentMonitorOutgoing
  88. - This application has been removed. It was a holdover from when
  89. AgentCallbackLogin was removed.
  90. Answer
  91. - It is no longer possible to bypass updating the CDR when answering a
  92. channel. CDRs are based on the channel state and will be updated when
  93. the channel is Answered.
  94. ControlPlayback
  95. - The channel variable CPLAYBACKSTATUS may now return the value
  96. 'REMOTESTOPPED' when playback is stopped by an external entity.
  97. DISA
  98. - This application now has a dependency on the app_cdr module. It uses this
  99. module to hide the CDR created prior to execution of the DISA application.
  100. DumpChan:
  101. - The output of DumpChan no longer includes the DirectBridge or IndirectBridge
  102. fields. Instead, if a channel is in a bridge, it includes a BridgeID field
  103. containing the unique ID of the bridge that the channel happens to be in.
  104. ForkCDR:
  105. - Nearly every parameter in ForkCDR has been updated and changed to reflect
  106. the changes in CDRs. Please see the documentation for the ForkCDR
  107. application, as well as the CDR specification on the Asterisk wiki.
  108. NoCDR:
  109. - The NoCDR application has been deprecated. Please use the CDR_PROP function
  110. to disable CDRs on a channel.
  111. ParkAndAnnounce:
  112. - The app_parkandannounce module has been removed. The application
  113. ParkAndAnnounce is now provided by the res_parking module. See the
  114. Parking changes for more information.
  115. ResetCDR:
  116. - The 'w' and 'a' options have been removed. Dispatching CDRs to registered
  117. backends occurs on an as-needed basis in order to preserve linkedid
  118. propagation and other needed behavior.
  119. - The 'e' option is deprecated. Please use the CDR_PROP function to enable
  120. CDRs on a channel that they were previously disabled on.
  121. - The ResetCDR application is no longer a part of core Asterisk, and instead
  122. is now delivered as part of app_cdr.
  123. Queues:
  124. - Queue strategy rrmemory now has a predictable order similar to strategy
  125. rrordered. Members will be called in the order that they are added to the
  126. queue.
  127. - Removed the queues.conf check_state_unknown option. It is no longer
  128. necessary.
  129. - It is now possible to play the Queue prompts to the first user waiting in a
  130. call queue. Note that this may impact the ability for agents to talk with
  131. users, as a prompt may still be playing when an agent connects to the user.
  132. This ability is disabled by default but can be enabled on an individual
  133. queue using the 'announce-to-first-user' option.
  134. - The configuration options eventwhencalled and eventmemberstatus have been
  135. removed. As a result, the AMI events QueueMemberStatus, AgentCalled,
  136. AgentConnect, AgentComplete, AgentDump, and AgentRingNoAnswer will always be
  137. sent. The "Variable" fields will also no longer exist on the Agent* events.
  138. These events can be filtered out from a connected AMI client using the
  139. eventfilter setting in manager.conf.
  140. - The queue log now differentiates between blind and attended transfers. A
  141. blind transfer will result in a BLINDTRANSFER message with the destination
  142. context and extension. An attended transfer will result in an
  143. ATTENDEDTRANSFER message. This message will indicate the method by which
  144. the attended transfer was completed: "BRIDGE" for a bridge merge, "APP"
  145. for running an application on a bridge or channel, or "LINK" for linking
  146. two bridges together with local channels. The queue log will also now detect
  147. externally initiated blind and attended transfers and record the transfer
  148. status accordingly.
  149. - When performing queue pause/unpause on an interface without specifying an
  150. individual queue, the PAUSEALL/UNPAUSEALL event will only be logged if at
  151. least one member of any queue exists for that interface.
  152. SetAMAFlags
  153. - This application is deprecated in favor of CHANNEL(amaflags).
  154. VoiceMail:
  155. - Mailboxes defined by app_voicemail MUST be referenced by the rest of the
  156. system as mailbox@context. The rest of the system cannot add @default
  157. to mailbox identifiers for app_voicemail that do not specify a context
  158. any longer. It is a mailbox identifier format that should only be
  159. interpreted by app_voicemail.
  160. - The voicemail.conf configuration file now has an 'alias' configuration
  161. parameter for use with the Directory application. The voicemail realtime
  162. database table schema has also been updated with an 'alias' column. Systems
  163. using voicemail with realtime should update their schemas accordingly.
  164. Channel Drivers:
  165. - When a channel driver is configured to enable jiterbuffers, they are now
  166. applied unconditionally when a channel joins a bridge. If a jitterbuffer
  167. is already set for that channel when it enters, such as by the JITTERBUFFER
  168. function, then the existing jitterbuffer will be used and the one set by
  169. the channel driver will not be applied.
  170. chan_bridge
  171. - chan_bridge is removed and its functionality is incorporated into ConfBridge
  172. itself.
  173. chan_dahdi:
  174. - Analog port dialing and deferred DTMF dialing for PRI now distinguishes
  175. between 'w' and 'W'. The 'w' pauses dialing for half a second. The 'W'
  176. pauses dialing for one second.
  177. - The default for inband_on_proceeding has changed to no.
  178. - The CLI command 'dahdi destroy channel' is now 'dahdi destroy channels'.
  179. A range of channels can be specified to be destroyed. Note that this command
  180. should only be used if you understand the risks it entails.
  181. - The script specified by the chan_dahdi.conf mwimonitornotify option now gets
  182. the exact configured mailbox name. For app_voicemail mailboxes this is
  183. mailbox@context.
  184. - Added mwi_vm_boxes that also must be configured for ISDN MWI to be enabled.
  185. - ignore_failed_channels now defaults to True: the channel will continue to
  186. be configured even if configuring it has failed. This is generally a
  187. better setup for systems with not more than one DAHDI device or with DAHDI
  188. >= 2.8.0 .
  189. chan_local:
  190. - The /b option has been removed.
  191. - chan_local moved into the system core and is no longer a loadable module.
  192. chan_sip:
  193. - The 'callevents' parameter has been removed. Hold AMI events are now raised
  194. in the core, and can be filtered out using the 'eventfilter' parameter
  195. in manager.conf.
  196. - Dynamic realtime tables for SIP Users can now include a 'path' field. This
  197. will store the path information for that peer when it registers. Realtime
  198. tables can also use the 'supportpath' field to enable Path header support.
  199. - LDAP realtime configurations for SIP Users now have the AstAccountPathSupport
  200. objectIdentifier. This maps to the supportpath option in sip.conf.
  201. Core:
  202. - Masquerades as an operation inside Asterisk have been effectively hidden
  203. by the migration to the Bridging API. As such, many 'quirks' of Asterisk
  204. no longer occur. This includes renaming of channels, "<ZOMBIE>" channels,
  205. dropping of frame/audio hooks, and other internal implementation details
  206. that users had to deal with. This fundamental change has large implications
  207. throughout the changes documented for this version. For more information
  208. about the new core architecture of Asterisk, please see the Asterisk wiki.
  209. - The following channel variables have changed behavior which is described in
  210. the CHANGES file: TRANSFER_CONTEXT, BRIDGEPEER, BRIDGEPVTCALLID,
  211. ATTENDED_TRANSFER_COMPLETE_SOUND, DYNAMIC_FEATURENAME, and DYNAMIC_PEERNAME.
  212. AMI (Asterisk Manager Interface):
  213. - Version 1.4 - The details of what happens to a channel when a masquerade
  214. happens (transfers, parking, etc) have changed.
  215. - The Masquerade event now includes the Uniqueid's of the clone and original
  216. channels.
  217. - Channels no longer swap Uniqueid's as a result of the masquerade.
  218. - Instead of a shell game of renames, there's now a single rename, appending
  219. <ZOMBIE> to the name of the original channel.
  220. - *Major* changes were made to both the syntax as well as the semantics of the
  221. AMI protocol. In particular, AMI events have been substantially modified
  222. and improved in this version of Asterisk. The major event changes are listed
  223. below.
  224. - NewPeerAccount has been removed. NewAccountCode is raised instead.
  225. - Reload events have been consolidated and standardized.
  226. - ModuleLoadReport has been removed.
  227. - FaxSent is now SendFAX; FaxReceived is now ReceiveFAX. This standardizes
  228. app_fax and res_fax events.
  229. - MusicOnHold has been replaced with MusicOnHoldStart and MusicOnHoldStop.
  230. - JabberEvent has been removed.
  231. - Hold is now in the core and will now raise Hold and Unhold events.
  232. - Join is now QueueCallerJoin.
  233. - Leave is now QueueCallerLeave.
  234. - Agentlogin/Agentlogoff is now AgentLogin/AgentLogoff, respectively.
  235. - ChannelUpdate has been removed.
  236. - Local channel optimization is now conveyed via LocalOptimizationBegin and
  237. LocalOptimizationEnd.
  238. - BridgeAction and BridgeExec have been removed.
  239. - BlindTransfer and AttendedTransfer events were added.
  240. - Dial is now DialBegin and DialEnd.
  241. - DTMF is now DTMFBegin and DTMFEnd.
  242. - Bridge has been replaced with BridgeCreate, BridgeEnter, BridgeLeave, and
  243. BridgeDestroy
  244. - MusicOnHold has been replaced with MusicOnHoldStart and MusicOnHoldStop
  245. - AGIExec is now AGIExecStart and AGIExecEnd
  246. - AsyncAGI is now AsyncAGIStart, AsyncAGIExec, and AsyncAGIEnd
  247. - The 'MCID' AMI event now publishes a channel snapshot when available and
  248. its non-channel-snapshot parameters now use either the "MCallerID" or
  249. 'MConnectedID' prefixes with Subaddr*, Name*, and Num* suffixes instead
  250. of 'CallerID' and 'ConnectedID' to avoid confusion with similarly named
  251. parameters in the channel snapshot.
  252. - The 'Channel' key used in the 'AlarmClear', 'Alarm', and 'DNDState' has been
  253. renamed "DAHDIChannel" since it does not convey an Asterisk channel name.
  254. - All AMI events now contain a 'SystemName' field, if available.
  255. - Local channel information in events is now prefixed with 'LocalOne' and
  256. 'LocalTwo'. This replaces the suffix of '1' and '2' for the two halves of
  257. the Local channel. This affects the 'LocalBridge', 'LocalOptimizationBegin',
  258. and 'LocalOptimizationEnd' events.
  259. - The 'RTCPSent'/'RTCPReceived' events have been significantly modified from
  260. previous versions. They now report all SR/RR packets sent/received, and
  261. have been restructured to better reflect the data sent in a SR/RR. In
  262. particular, the event structure now supports multiple report blocks.
  263. - The deprecated use of | (pipe) as a separator in the channelvars setting in
  264. manager.conf has been removed.
  265. - The SIP SIPqualifypeer action now sends a response indicating it will qualify
  266. a peer once a peer has been found to qualify. Once the qualify has been
  267. completed it will now issue a SIPqualifypeerdone event.
  268. - The AMI event 'Newexten' field 'Extension' is deprecated, and may be removed
  269. in a future release. Please use the common 'Exten' field instead.
  270. - The AMI events 'ParkedCall', 'ParkedCallTimeOut', 'ParkedCallGiveUp', and
  271. 'UnParkedCall' have changed significantly in the new res_parking module.
  272. - The 'Channel' and 'From' headers are gone. For the channel that was parked
  273. or is coming out of parking, a 'Parkee' channel snapshot is issued and it
  274. has a number of fields associated with it. The old 'Channel' header relayed
  275. the same data as the new 'ParkeeChannel' header.
  276. - The 'From' field was ambiguous and changed meaning depending on the event.
  277. for most of these, it was the name of the channel that parked the call
  278. (the 'Parker'). There is no longer a header that provides this channel name,
  279. however the 'ParkerDialString' will contain a dialstring to redial the
  280. device that parked the call.
  281. - On UnParkedCall events, the 'From' header would instead represent the
  282. channel responsible for retrieving the parkee. It receives a channel
  283. snapshot labeled 'Retriever'. The 'from' field is is replaced with
  284. 'RetrieverChannel'.
  285. - Lastly, the 'Exten' field has been replaced with 'ParkingSpace'.
  286. - The AMI event 'Parkinglot' (response to 'Parkinglots' command) in a similar
  287. fashion has changed the field names 'StartExten' and 'StopExten' to
  288. 'StartSpace' and 'StopSpace' respectively.
  289. - The AMI 'Status' response event to the AMI Status action replaces the
  290. 'BridgedChannel' and 'BridgedUniqueid' headers with the 'BridgeID' header to
  291. indicate what bridge the channel is currently in.
  292. CDR (Call Detail Records)
  293. - Significant changes have been made to the behavior of CDRs. The CDR engine
  294. was effectively rewritten and built on the Stasis message bus. For a full
  295. definition of CDR behavior in Asterisk 12, please read the specification
  296. on the Asterisk wiki (wiki.asterisk.org).
  297. - CDRs will now be created between all participants in a bridge. For each
  298. pair of channels in a bridge, a CDR is created to represent the path of
  299. communication between those two endpoints. This lets an end user choose who
  300. to bill for what during bridge operations with multiple parties.
  301. - The duration, billsec, start, answer, and end times now reflect the times
  302. associated with the current CDR for the channel, as opposed to a cumulative
  303. measurement of all CDRs for that channel.
  304. CEL:
  305. - The Uniqueid field for a channel is now a stable identifier, and will not
  306. change due to transfers, parking, etc.
  307. - CEL has undergone significant rework in Asterisk 12, and is now built on the
  308. Stasis message bus. Please see the specification for CEL on the Asterisk
  309. wiki at https://wiki.asterisk.org/wiki/x/4ICLAQ for more detailed
  310. information. A summary of the affected events is below:
  311. - BRIDGE_START, BRIDGE_END, BRIDGE_UPDATE, 3WAY_START, 3WAY_END, CONF_ENTER,
  312. CONF_EXIT, CONF_START, and CONF_END events have all been removed. These
  313. events have been replaced by BRIDGE_ENTER/BRIDGE_EXIT.
  314. - BLINDTRANSFER/ATTENDEDTRANSFER events now report the peer as NULL and
  315. additional information in the extra string field.
  316. Dialplan Functions:
  317. - Certain dialplan functions have been marked as 'dangerous', and may only be
  318. executed from the dialplan. Execution from extenal sources (AMI's GetVar and
  319. SetVar actions; etc.) may be inhibited by setting live_dangerously in the
  320. [options] section of asterisk.conf to no. SHELL(), channel locking, and
  321. direct file read/write functions are marked as dangerous. DB_DELETE() and
  322. REALTIME_DESTROY() are marked as dangerous for reads, but can now safely
  323. accept writes (which ignore the provided value).
  324. - The default value for live_dangerously was changed from yes (in Asterisk 11
  325. and earlier) to no (in Asterisk 12 and greater).
  326. Dialplan:
  327. - All channel and global variable names are evaluated in a case-sensitive
  328. manner. In previous versions of Asterisk, variables created and evaluated in
  329. the dialplan were evaluated case-insensitively, but built-in variables and
  330. variable evaluation done internally within Asterisk was done
  331. case-sensitively.
  332. - Asterisk has always had code to ignore dash '-' characters that are not
  333. part of a character set in the dialplan extensions. The code now
  334. consistently ignores these characters when matching dialplan extensions.
  335. - BRIDGE_FEATURES channel variable is now casesensitive for feature letter
  336. codes. Uppercase variants apply them to the calling party while lowercase
  337. variants apply them to the called party.
  338. Features:
  339. - The features.conf [applicationmap] <FeatureName> ActivatedBy option is
  340. no longer honored. The feature is always activated by the channel that has
  341. DYNAMIC_FEATURES defined on it when it enters the bridge. Use predial to set
  342. different values of DYNAMIC_FEATURES on the channels
  343. - Executing a dynamic feature on the bridge peer in a multi-party bridge will
  344. execute it on all peers of the activating channel.
  345. - There is no longer an explicit 'features reload' CLI command. Features can
  346. still be reloaded using 'module reload features'.
  347. - It is no longer necessary (or possible) to define the ATXFER_NULL_TECH in
  348. features.c for atxferdropcall=no to work properly. This option now just
  349. works.
  350. Parking:
  351. - Parking has been extracted from the Asterisk core as a loadable module,
  352. res_parking.
  353. - Configuration is found in res_parking.conf. It is no longer supported in
  354. features.conf
  355. - The arguments for the Park, ParkedCall, and ParkAndAnnounce applications
  356. have been modified significantly. See the application documents for
  357. specific details.
  358. - Numerous changes to Parking related applications, AMI and CLI commands and
  359. internal inter-workings have been made. Please read the CHANGES file for
  360. the detailed list.
  361. Security Events Framework:
  362. - Security Event timestamps now use ISO 8601 formatted date/time instead of
  363. the "seconds-microseconds" format that it was using previously.
  364. AGENT:
  365. - The password option has been disabled, as the AgentLogin application no
  366. longer provides authentication.
  367. AUDIOHOOK_INHERIT:
  368. - Due to changes in the Asterisk core, this function is no longer needed to
  369. preserve a MixMonitor on a channel during transfer operations and dialplan
  370. execution. It is effectively obsolete.
  371. CDR: (function)
  372. - The 'amaflags' and 'accountcode' attributes for the CDR function are
  373. deprecated. Use the CHANNEL function instead to access these attributes.
  374. - The 'l' option has been removed. When reading a CDR attribute, the most
  375. recent record is always used. When writing a CDR attribute, all non-finalized
  376. CDRs are updated.
  377. - The 'r' option has been removed, for the same reason as the 'l' option.
  378. - The 's' option has been removed, as LOCKED semantics no longer exist in the
  379. CDR engine.
  380. VMCOUNT:
  381. - Mailboxes defined by app_voicemail MUST be referenced by the rest of the
  382. system as mailbox@context. The rest of the system cannot add @default
  383. to mailbox identifiers for app_voicemail that do not specify a context
  384. any longer. It is a mailbox identifier format that should only be
  385. interpreted by app_voicemail.
  386. res_rtp_asterisk:
  387. - ICE/STUN/TURN support in res_rtp_asterisk has been made optional. To enable
  388. them, an Asterisk-specific version of PJSIP needs to be installed.
  389. Tarballs are available from https://github.com/asterisk/pjproject/tags/.
  390. ===========================================================
  391. ===========================================================