Upgrading/Downgrading Asterisk - Revision history

Admin at 06:54, 6 March 2025

2025-03-06T06:54:52Z

@@ Line 1: / Line 1: @@
 Upgrading or downgrading Asterisk should be done only if really needed. Asterisk relies on a series of libraries and different Asterisk versions may need different library versions.
-A sample script to upgrade Asterisk is provided as protected/installAsterisk.sh
+A simple script to upgrade Asterisk is provided as protected/installAsterisk.sh
-Asterisk version up to 13.4.0 (included) are known to work pretty well, but newer versions solve lots of bugs.
+To upgrade to latest version 20, you can just run
-From Asterisk 13.5.0 to 13.9.0 there is a nasty ODBC lock bug and a nasty SIP lock bug, so these versions cannot be used.
+  cp protected/installAsterisk.sh /usr/local/src
-From Asterisk 13.10.0, the nasty ODBC lock bug is solved, but the SIP lock bug was still in place.  It is needed to upgrade unixODBC to at least version 2.3.4-1. A link to upgrade it is provided in the script. If installing a previous asterisk version, upgrading unixODBC can lead to unexpected instabilities.
+If you want to upgrade to a specific asterisk version, you can provide it as
-If you upgrade to unixODBC 2.3.4-1, then you need to comment out the idlecheck parameter and add the max_connections parameters to /etc/asterisk/res_odbc.conf. A good value can be 100.
+  ./installAsterisk 20.12.0

Admin at 09:42, 14 December 2017

2017-12-14T09:42:15Z

← Older revision		Revision as of 09:42, 14 December 2017
Line 9:		Line 9:
	From Asterisk 13.10.0, the nasty ODBC lock bug is solved, but the SIP lock bug was still in place. It is needed to upgrade unixODBC to at least version 2.3.4-1. A link to upgrade it is provided in the script. If installing a previous asterisk version, upgrading unixODBC can lead to unexpected instabilities.		From Asterisk 13.10.0, the nasty ODBC lock bug is solved, but the SIP lock bug was still in place. It is needed to upgrade unixODBC to at least version 2.3.4-1. A link to upgrade it is provided in the script. If installing a previous asterisk version, upgrading unixODBC can lead to unexpected instabilities.

	If you upgrade to unixODBC 2.3.4-1, then you need to add the max_connections parameters to /etc/asterisk/res_odbc.conf. A good value can be 100.		If you upgrade to unixODBC 2.3.4-1, then you need to comment out the idlecheck parameter and add the max_connections parameters to /etc/asterisk/res_odbc.conf. A good value can be 100.

	<pre>		<pre>
Line 17:		Line 17:
	pre-connect => yes		pre-connect => yes
	sanitysql => select 1		sanitysql => select 1
	idlecheck => 28000		;idlecheck => 28000
	max_connections => 100		max_connections => 100

Line 25:		Line 25:
	pre-connect => yes		pre-connect => yes
	sanitysql => select 1		sanitysql => select 1
	idlecheck => 28000		;idlecheck => 28000
	max_connections => 100		max_connections => 100

Line 33:		Line 33:
	pre-connect => yes		pre-connect => yes
	sanitysql => select 1		sanitysql => select 1
	idlecheck => 28000		;idlecheck => 28000
	max_connections => 100		max_connections => 100

Line 41:		Line 41:
	pre-connect => yes		pre-connect => yes
	sanitysql => select 1		sanitysql => select 1
	idlecheck => 28000		;idlecheck => 28000
	max_connections => 100		max_connections => 100
	</pre>		</pre>

	From Asterisk 13.12.0 the nasty SIP lock bug seems gone, but there is a nasty MWI subscribe bug. It is important to get around this bug by enabling "Extern notify" for all extensions. You can do easily from Admin/new Item Defaults, by setting and enforcing "Send MWI only if subscribed" to "no" for all extensions. Set the field as hidden and unavailable to avoid any change.		From Asterisk 13.12.0 the nasty SIP lock bug seems gone, but there is a nasty MWI subscribe bug. It is important to get around this bug by enabling "Extern notify" for all extensions. You can do easily from Admin/new Item Defaults, by setting and enforcing "Send MWI only if subscribed" to "no" for all extensions. Set the field as hidden and unavailable to avoid any change.

Admin at 19:45, 16 November 2017

2017-11-16T19:45:46Z

← Older revision		Revision as of 19:45, 16 November 2017
Line 3:		Line 3:
	A sample script to upgrade Asterisk is provided as protected/installAsterisk.sh		A sample script to upgrade Asterisk is provided as protected/installAsterisk.sh

	Asterisk version up to 13.4.0 (included) are known to work pretty well.		Asterisk version up to 13.4.0 (included) are known to work pretty well, but newer versions solve lots of bugs.

	From Asterisk 13.5.0 to 13.9.0 there is a nasty ODBC lock bug and a nasty SIP lock bug		From Asterisk 13.5.0 to 13.9.0 there is a nasty ODBC lock bug and a nasty SIP lock bug, so these versions cannot be used.

	From Asterisk 13.10.0, the nasty ODBC lock bug is solved, but the SIP lock bug was still in place. It is needed to upgrade unixODBC to at least version 2.3.4-1. A link to upgrade it is provided in the script. If installing a previous asterisk version, upgrading unixODBC can lead to unexpected instabilities.		From Asterisk 13.10.0, the nasty ODBC lock bug is solved, but the SIP lock bug was still in place. It is needed to upgrade unixODBC to at least version 2.3.4-1. A link to upgrade it is provided in the script. If installing a previous asterisk version, upgrading unixODBC can lead to unexpected instabilities.

	If you upgrade to unixODBC 2.3.4-1, then you need to add the max_connections parameters to /etc/asterisk/res_odbc.conf. A good value can be 100.		If you upgrade to unixODBC 2.3.4-1, then you need to add the max_connections parameters to /etc/asterisk/res_odbc.conf. A good value can be 100.
Line 45:		Line 45:
	</pre>		</pre>

	From Asterisk 13.12.0 the nasty SIP lock bug seems gone, but there is a nasty MWI subscribe bug. It is important to get around this bug by enabling "Extern notify" for all extensions. You can do easily from Admin/new Item Defaults.		From Asterisk 13.12.0 the nasty SIP lock bug seems gone, but there is a nasty MWI subscribe bug. It is important to get around this bug by enabling "Extern notify" for all extensions. You can do easily from Admin/new Item Defaults, by setting and enforcing "Send MWI only if subscribed" to "no" for all extensions. Set the field as hidden and unavailable to avoid any change.

Admin at 20:05, 27 July 2017

2017-07-27T20:05:54Z

← Older revision		Revision as of 20:05, 27 July 2017
Line 45:		Line 45:
	</pre>		</pre>

	From Asterisk 13.12.0 the nasty SIP lock bug seems gone.		From Asterisk 13.12.0 the nasty SIP lock bug seems gone, but there is a nasty MWI subscribe bug. It is important to get around this bug by enabling "Extern notify" for all extensions. You can do easily from Admin/new Item Defaults.

Admin at 08:06, 26 October 2016

2016-10-26T08:06:56Z

← Older revision		Revision as of 08:06, 26 October 2016
Line 8:		Line 8:

	From Asterisk 13.10.0, the nasty ODBC lock bug is solved, but the SIP lock bug was still in place. It is needed to upgrade unixODBC to at least version 2.3.4-1. A link to upgrade it is provided in the script. If installing a previous asterisk version, upgrading unixODBC can lead to unexpected instabilities.		From Asterisk 13.10.0, the nasty ODBC lock bug is solved, but the SIP lock bug was still in place. It is needed to upgrade unixODBC to at least version 2.3.4-1. A link to upgrade it is provided in the script. If installing a previous asterisk version, upgrading unixODBC can lead to unexpected instabilities.

			If you upgrade to unixODBC 2.3.4-1, then you need to add the max_connections parameters to /etc/asterisk/res_odbc.conf. A good value can be 100.

			<pre>
			[asteriskcdrdb1]
			enabled => yes
			dsn => asteriskcdrdb1
			pre-connect => yes
			sanitysql => select 1
			idlecheck => 28000
			max_connections => 100

			[asteriskcdrdb2]
			enabled => yes
			dsn => asteriskcdrdb2
			pre-connect => yes
			sanitysql => select 1
			idlecheck => 28000
			max_connections => 100

			[asterisk1]
			enabled => yes
			dsn => asterisk1
			pre-connect => yes
			sanitysql => select 1
			idlecheck => 28000
			max_connections => 100

			[asterisk2]
			enabled => yes
			dsn => asterisk2
			pre-connect => yes
			sanitysql => select 1
			idlecheck => 28000
			max_connections => 100
			</pre>

	From Asterisk 13.12.0 the nasty SIP lock bug seems gone.		From Asterisk 13.12.0 the nasty SIP lock bug seems gone.

Admin: Created page with "Upgrading or downgrading Asterisk should be done only if really needed. Asterisk relies on a series of libraries and different Asterisk versions may need different library ver..."

2016-10-20T16:36:00Z

Created page with "Upgrading or downgrading Asterisk should be done only if really needed. Asterisk relies on a series of libraries and different Asterisk versions may need different library ver..."

New page

Upgrading or downgrading Asterisk should be done only if really needed. Asterisk relies on a series of libraries and different Asterisk versions may need different library versions.

A sample script to upgrade Asterisk is provided as protected/installAsterisk.sh

Asterisk version up to 13.4.0 (included) are known to work pretty well.

From Asterisk 13.5.0 to 13.9.0 there is a nasty ODBC lock bug and a nasty SIP lock bug

From Asterisk 13.10.0, the nasty ODBC lock bug is solved, but the SIP lock bug was still in place. It is needed to upgrade unixODBC to at least version 2.3.4-1. A link to upgrade it is provided in the script. If installing a previous asterisk version, upgrading unixODBC can lead to unexpected instabilities.

From Asterisk 13.12.0 the nasty SIP lock bug seems gone.