git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208504 65c4cc65-6c06-0410-ace0-fbb531ad65f3
149 lines
7.5 KiB
Text
149 lines
7.5 KiB
Text
===========================================================
|
|
===
|
|
=== Information for upgrading between Asterisk 1.6 versions
|
|
===
|
|
=== These files document all the changes that MUST be taken
|
|
=== into account when upgrading between the Asterisk
|
|
=== versions listed below. These changes may require that
|
|
=== you modify your configuration files, dialplan or (in
|
|
=== some cases) source code if you have your own Asterisk
|
|
=== modules or patches. These files also includes advance
|
|
=== notice of any functionality that has been marked as
|
|
=== 'deprecated' and may be removed in a future release,
|
|
=== along with the suggested replacement functionality.
|
|
===
|
|
=== UPGRADE-1.2.txt -- Upgrade info for 1.0 to 1.2
|
|
=== UPGRADE-1.4.txt -- Upgrade info for 1.2 to 1.4
|
|
=== UPGRADE-1.6.txt -- Upgrade info for 1.4 to 1.6
|
|
===
|
|
===========================================================
|
|
|
|
From 1.6.2 to 1.6.3:
|
|
|
|
* Asterisk-addons no longer exists as an independent package. Those modules
|
|
now live in the addons directory of the main Asterisk source tree. They
|
|
are not enabled by default. For more information about why modules live in
|
|
addons, see README-addons.txt.
|
|
|
|
* The rarely used 'event_log' and LOG_EVENT channel have been removed; the few
|
|
users of this channel in the tree have been converted to LOG_NOTICE or removed
|
|
(in cases where the same message was already generated to another channel).
|
|
|
|
* The usage of RTP inside of Asterisk has now become modularized. This means
|
|
the Asterisk RTP stack now exists as a loadable module, res_rtp_asterisk.
|
|
If you are not using autoload=yes in modules.conf you will need to ensure
|
|
it is set to load. If not, then any module which uses RTP (such as chan_sip)
|
|
will not be able to send or receive calls.
|
|
|
|
* The app_dahdiscan.c file has been removed, but the dialplan app DAHDIScan still
|
|
remains. It now exists within app_chanspy.c and retains the exact same
|
|
functionality as before.
|
|
|
|
From 1.6.1 to 1.6.2:
|
|
|
|
* The default console now will use colors according to the default background
|
|
color, instead of forcing the background color to black. If you are using a
|
|
light colored background for your console, you may wish to use the option
|
|
flag '-W' to present better color choices for the various messages. However,
|
|
if you'd prefer the old method of forcing colors to white text on a black
|
|
background, the compatibility option -B is provided for this purpose.
|
|
|
|
* SendImage() no longer hangs up the channel on transmission error or on
|
|
any other error; in those cases, a FAILURE status is stored in
|
|
SENDIMAGESTATUS and dialplan execution continues. The possible
|
|
return values stored in SENDIMAGESTATUS are: SUCCESS, FAILURE, and
|
|
UNSUPPORTED. ('OK' has been replaced with 'SUCCESS', and 'NOSUPPORT'
|
|
has been replaced with 'UNSUPPORTED'). This change makes the
|
|
SendImage application more consistent with other applications.
|
|
|
|
* skinny.conf now has separate sections for lines and devices.
|
|
Please have a look at configs/skinny.conf.sample and update
|
|
your skinny.conf.
|
|
|
|
* Queue names previously were treated in a case-sensitive manner,
|
|
meaning that queues with names like "sales" and "sALeS" would be
|
|
seen as unique queues. The parsing logic has changed to use
|
|
case-insensitive comparisons now when originally hashing based on
|
|
queue names, meaning that now the two queues mentioned as examples
|
|
earlier will be seen as having the same name.
|
|
|
|
* The SPRINTF() dialplan function has been moved into its own module,
|
|
func_sprintf, and is no longer included in func_strings. If you use this
|
|
function and do not use 'autoload=yes' in modules.conf, you will need
|
|
to explicitly load func_sprintf for it to be available.
|
|
|
|
* The res_indications module has been removed. Its functionality was important
|
|
enough that most of it has been moved into the Asterisk core.
|
|
Two applications previously provided by res_indications, PlayTones and
|
|
StopPlayTones, have been moved into a new module, app_playtones.
|
|
|
|
* Support for Taiwanese was incorrectly supported with the "tw" language code.
|
|
In reality, the "tw" language code is reserved for the Twi language, native
|
|
to Ghana. If you were previously using the "tw" language code, you should
|
|
switch to using either "zh" (for Mandarin Chinese) or "zh_TW" for Taiwan
|
|
specific localizations. Additionally, "mx" should be changed to "es_MX",
|
|
Georgian was incorrectly specified as "ge" but should be "ka", and Czech is
|
|
"cs", not "cz".
|
|
|
|
From 1.6.0.1 to 1.6.1:
|
|
|
|
* The ast_agi_register_multiple() and ast_agi_unregister_multiple()
|
|
API calls were added in 1.6.0, so that modules that provide multiple
|
|
AGI commands could register/unregister them all with a single
|
|
step. However, these API calls were not implemented properly, and did
|
|
not allow the caller to know whether registration or unregistration
|
|
succeeded or failed. They have been redefined to now return success
|
|
or failure, but this means any code using these functions will need
|
|
be recompiled after upgrading to a version of Asterisk containing
|
|
these changes. In addition, the source code using these functions
|
|
should be reviewed to ensure it can properly react to failure
|
|
of registration or unregistration of its API commands.
|
|
|
|
* The ast_agi_fdprintf() API call has been renamed to ast_agi_send()
|
|
to better match what it really does, and the argument order has been
|
|
changed to be consistent with other API calls that perform similar
|
|
operations.
|
|
|
|
From 1.6.0.x to 1.6.1:
|
|
|
|
* In previous versions of Asterisk, due to the way objects were arranged in
|
|
memory by chan_sip, the order of entries in sip.conf could be adjusted to
|
|
control the behavior of matching against peers and users. The way objects
|
|
are managed has been significantly changed for reasons involving performance
|
|
and stability. A side effect of these changes is that the order of entries
|
|
in sip.conf can no longer be relied upon to control behavior.
|
|
|
|
* The following core commands dealing with dialplan have been deprecated: 'core
|
|
show globals', 'core set global' and 'core set chanvar'. Use the equivalent
|
|
'dialplan show globals', 'dialplan set global' and 'dialplan set chanvar'
|
|
instead.
|
|
|
|
* In the dialplan expression parser, the logical value of spaces
|
|
immediately preceding a standalone 0 previously evaluated to
|
|
true. It now evaluates to false. This has confused a good many
|
|
people in the past (typically because they failed to realize the
|
|
space had any significance). Since this violates the Principle of
|
|
Least Surprise, it has been changed.
|
|
|
|
* While app_directory has always relied on having a voicemail.conf or users.conf file
|
|
correctly set up, it now is dependent on app_voicemail being compiled as well.
|
|
|
|
* SIP: All of the functionality in SIPCHANINFO() has been implemented in CHANNEL(),
|
|
and you should start using that function instead for retrieving information about
|
|
the channel in a technology-agnostic way.
|
|
|
|
* If you have any third party modules which use a config file variable whose
|
|
name ends in a '+', please note that the append capability added to this
|
|
version may now conflict with that variable naming scheme. An easy
|
|
workaround is to ensure that a space occurs between the '+' and the '=',
|
|
to differentiate your variable from the append operator. This potential
|
|
conflict is unlikely, but is documented here to be thorough.
|
|
|
|
* The "Join" event from app_queue now uses the CallerIDNum header instead of
|
|
the CallerID header to indicate the CallerID number.
|
|
|
|
* If you use ODBC storage for voicemail, there is a new field called "flag"
|
|
which should be a char(8) or larger. This field specifies whether or not a
|
|
message has been designated to be "Urgent", "PRIORITY", or not.
|
|
|