mirror of https://github.com/asterisk/asterisk
master
22
20
21
releases/certified-20.7
releases/certified-18.9
releases/22
releases/21
releases/20
releases/18
18
certified/18.9
certified/20.7
revert-549-master-issue-548
16
19
releases/19
releases/16
20.2
18.17
20.1
19.8
18.16
16.30
20.0
19.7
18.15
16.29
16.19
19.6
18.14
16.28
development/16/python3
development/16/geolocation
19.5
18.13
16.27
19.4
18.12
16.26
19.3
18.11
16.25
certified/16.8
19.2
18.10
16.24
certified/16.3
19.1
18.9
16.23
19.0
18.8
16.22
16.21
18.7
18.6
16.20
18.5
17.9
13.38
17
13
18.4
16.18
18.3
16.17
18.2
16.16
18.1
16.15
jenkinstest-16
18.0
17.8
16.14
13.37
17.7
16.13
13.36
certified/13.21
17.6
16.12
13.35
17.5
16.11
13.34
17.4
16.10
13.33
17.3
16.9
13.32
17.2
16.8
13.31
17.1
16.7
13.30
17.0
16.6
13.29
16.5
15.7
13.28
15
16.4
13.27
16.3
13.26
16.2
13.25
16.1
13.24
16.0
15.6
13.23
14.7
14
certified/13.18
certified/13.13
certified/11.6
11
certified/13.8
certified/13.1
1.8
certified/1.8.28
12
certified/1.8.15
certified/11.2
10-digiumphones
10
certified/1.8.11
certified/1.8.6
1.6.2
1.4
1.6.1
1.6.0
1.2
1.2-netsec
1.0
certified-20.7-cert6
certified-18.9-cert15
22.4.1
21.9.1
20.14.1
18.26.2
certified-20.7-cert5
certified-18.9-cert14
22.4.0
21.9.0
20.14.0
22.4.0-rc1
21.9.0-rc1
20.14.0-rc1
22.3.0
21.8.0
20.13.0
22.3.0-rc1
21.8.0-rc1
20.13.0-rc1
22.2.0
21.7.0
20.12.0
22.2.0-rc2
21.7.0-rc2
20.12.0-rc2
22.2.0-rc1
21.7.0-rc1
20.12.0-rc1
certified-20.7-cert4
certified-18.9-cert13
22.1.1
21.6.1
20.11.1
18.26.1
22.1.0
21.6.0
20.11.0
18.26.0
22.1.0-rc1
21.6.0-rc1
20.11.0-rc1
18.26.0-rc1
18.25.0
20.10.0
21.5.0
22.0.0
22.0.0-rc2
21.5.0-rc2
20.10.0-rc2
18.25.0-rc2
22.0.0-rc1
21.5.0-rc1
20.10.0-rc1
18.25.0-rc1
certified-20.7-cert3
certified-18.9-cert12
21.4.3
20.9.3
18.24.3
22.0.0-pre1
21.4.2
20.9.2
18.24.2
certified-20.7-cert2
certified-18.9-cert11
21.4.1
20.9.1
18.24.1
21.4.0
20.9.0
18.24.0
certified-20.7-cert1
certified-18.9-cert10
21.4.0-rc1
20.9.0-rc1
18.24.0-rc1
21.3.1
20.8.1
18.23.1
21.3.0
20.8.0
18.23.0
certified-20.7-cert1-rc2
certified-18.9-cert9
20.8.0-rc1
21.3.0-rc1
18.23.0-rc1
certified-20.7-cert1-rc1
certified-20.7-cert1-pre1
21.2.0
20.7.0
18.22.0
certified-18.9-cert8
21.2.0-rc2
20.7.0-rc2
18.22.0-rc2
21.2.0-rc1
20.7.0-rc1
18.22.0-rc1
certified-18.9-cert8-rc2
certified-18.9-cert8-rc1
21.1.0
20.6.0
18.21.0
21.1.0-rc2
20.6.0-rc2
18.21.0-rc2
21.1.0-rc1
20.6.0-rc1
18.21.0-rc1
21.0.2
20.5.2
18.20.2
certified-18.9-cert7
certified-18.9-cert6
21.0.1
20.5.1
18.20.1
21.0.0
20.5.0
18.20.0
21.0.0-rc1
20.5.0-rc1
18.20.0-rc1
21.0.0-pre1
18.19.0
20.4.0
20.4.0-rc2
18.19.0-rc2
20.4.0-rc1
18.19.0-rc1
20.3.1
certified-18.9-cert5
19.8.1
18.18.1
16.30.1
certified-18.9-cert4
20.3.0
18.18.0
20.3.0-rc1
18.18.0-rc1
20.2.1
18.17.1
20.2.0
18.17.0
20.2.0-rc1
18.17.0-rc1
certified/18.9-cert4
20.1.0
19.8.0
18.16.0
16.30.0
20.1.0-rc2
19.8.0-rc2
18.16.0-rc2
16.30.0-rc2
20.1.0-rc1
18.16.0-rc1
19.8.0-rc1
16.30.0-rc1
certified/18.9-cert3
20.0.1
19.7.1
18.15.1
16.29.1
19.7.0
20.0.0
18.15.0
16.29.0
certified/18.9-cert2
20.0.0-rc2
19.7.0-rc2
18.15.0-rc2
16.29.0-rc2
20.0.0-rc1
19.7.0-rc1
18.15.0-rc1
16.29.0-rc1
19.6.0
18.14.0
16.28.0
19.6.0-rc2
18.14.0-rc2
16.28.0-rc2
19.6.0-rc1
18.14.0-rc1
16.28.0-rc1
19.5.0
18.13.0
16.27.0
19.5.0-rc1
18.13.0-rc1
16.27.0-rc1
19.4.1
18.12.1
16.26.1
19.4.0
18.12.0
16.26.0
19.4.0-rc1
18.12.0-rc1
16.26.0-rc1
certified/18.9-cert1
19.3.3
18.11.3
16.25.3
certified/16.8-cert14
19.3.2
18.11.2
16.25.2
19.3.1
18.11.1
16.25.1
19.3.0
18.11.0
16.25.0
19.3.0-rc1
18.11.0-rc1
16.25.0-rc1
certified/16.8-cert13
19.2.1
18.10.1
16.24.1
19.2.0
18.10.0
16.24.0
19.2.0-rc1
18.10.0-rc1
16.24.0-rc1
certified/18.9-cert1-rc1
19.1.0
18.9.0
16.23.0
19.1.0-rc1
18.9.0-rc1
16.23.0-rc1
19.0.0
18.8.0
16.22.0
certified/16.8-cert12
19.0.0-rc1
18.8.0-rc1
16.22.0-rc1
16.21.1
18.7.1
18.7.0
16.21.0
18.7.0-rc3
16.21.0-rc3
18.7.0-rc2
16.21.0-rc2
18.7.0-rc1
16.21.0-rc1
certified/16.8-cert11
18.6.0
16.20.0
18.6.0-rc1
16.20.0-rc1
certified/16.8-cert10
18.5.1
17.9.4
16.19.1
13.38.3
18.5.0
16.19.0
certified/16.8-cert9
18.5.0-rc1
16.19.0-rc1
18.4.0
16.18.0
18.4.0-rc1
16.18.0-rc1
certified/16.8-cert8
18.3.0
16.17.0
18.3.0-rc2
16.17.0-rc2
18.3.0-rc1
16.17.0-rc1
certified/16.8-cert7
18.2.2
17.9.3
16.16.2
certified/16.8-cert6
18.2.1
17.9.2
16.16.1
13.38.2
18.2.0
16.16.0
18.2.0-rc1
16.16.0-rc1
18.1.1
17.9.1
16.15.1
13.38.1
18.1.0
17.9.0
16.15.0
13.38.0
18.1.0-rc1
17.9.0-rc1
16.15.0-rc1
13.38.0-rc1
18.0.1
17.8.1
16.14.1
certified/16.8-cert5
13.37.1
certified/16.8-cert4
certified/16.8-cert4-rc4
18.0.0
17.8.0
16.14.0
13.37.0
18.0.0-rc2
certified/16.8-cert4-rc3
18.0.0-rc1
17.8.0-rc1
16.14.0-rc1
13.37.0-rc1
17.7.0
16.13.0
13.36.0
17.7.0-rc2
16.13.0-rc2
13.36.0-rc2
17.7.0-rc1
16.13.0-rc1
13.36.0-rc1
certified/16.8-cert4-rc2
17.6.0
16.12.0
13.35.0
17.6.0-rc1
16.12.0-rc1
13.35.0-rc1
certified/16.8-cert4-rc1
certified/16.8-cert3
17.5.1
16.11.1
17.5.0
16.11.0
13.34.0
17.5.0-rc3
16.11.0-rc3
13.34.0-rc3
17.5.0-rc2
16.11.0-rc2
13.34.0-rc2
17.5.0-rc1
16.11.0-rc1
13.34.0-rc1
certified/16.8-cert2
17.4.0
16.10.0
13.33.0
certified/16.8-cert1
17.4.0-rc2
16.10.0-rc2
13.33.0-rc2
17.4.0-rc1
16.10.0-rc1
13.33.0-rc1
certified/16.8-cert1-rc5
certified/16.8-cert1-rc4
17.3.0
16.9.0
13.32.0
17.3.0-rc1
16.9.0-rc1
13.32.0-rc1
certified/16.8-cert1-rc3
certified/16.8-cert1-rc2
certified/16.8-cert1-rc1
17.2.0
16.8.0
13.31.0
17.2.0-rc2
16.8.0-rc2
13.31.0-rc2
17.2.0-rc1
16.8.0-rc1
13.31.0-rc1
certified/16.3-cert1
certified/13.21-cert6
17.1.0
16.7.0
13.30.0
17.1.0-rc2
16.7.0-rc2
13.30.0-rc2
17.1.0-rc1
16.7.0-rc1
13.30.0-rc1
certified/13.21-cert5
17.0.1
16.6.2
13.29.2
17.0.0
17.0.0-rc3
16.6.1
13.29.1
16.6.0
13.29.0
16.6.0-rc2
13.29.0-rc2
17.0.0-rc2
16.6.0-rc1
13.29.0-rc1
16.5.1
15.7.4
13.28.1
17.0.0-rc1
16.5.0
13.28.0
16.5.0-rc1
13.28.0-rc1
certified/13.21-cert4
16.4.1
15.7.3
13.27.1
16.4.0
13.27.0
16.4.0-rc1
13.27.0-rc1
16.3.0
13.26.0
16.3.0-rc1
13.26.0-rc1
16.2.1
15.7.2
16.2.0
13.25.0
13.25.0-rc3
16.2.0-rc2
13.25.0-rc2
16.2.0-rc1
13.25.0-rc1
16.1.1
15.7.1
13.24.1
16.1.0
13.24.0
15.7.0
16.1.0-rc1
15.7.0-rc1
13.24.0-rc1
16.0.1
15.6.2
16.0.0
16.0.0-rc3
certified/13.21-cert3
15.6.1
14.7.8
13.23.1
16.0.0-rc2
15.6.0
13.23.0
15.6.0-rc1
13.23.0-rc1
16.0.0-rc1
15.5.0
13.22.0
15.5.0-rc1
13.22.0-rc1
15.4.1
14.7.7
certified/13.21-cert2
certified/13.18-cert4
13.21.1
certified/13.21-cert1
certified/13.21-cert1-rc2
certified/13.21-cert1-rc1
15.4.0
13.21.0
15.4.0-rc2
15.4.0-rc1
13.21.0-rc1
15.3.0
13.20.0
15.3.0-rc2
13.20.0-rc2
15.3.0-rc1
13.20.0-rc1
15.2.2
certified/13.18-cert3
14.7.6
13.19.2
13.19.1
15.2.1
15.2.0
13.19.0
15.2.0-rc2
13.19.0-rc2
certified/13.18-cert2
15.1.5
14.7.5
13.18.5
certified/13.18-cert1
15.2.0-rc1
13.19.0-rc1
certified/13.18-cert1-rc3
certified/13.13-cert9
15.1.4
14.7.4
13.18.4
15.1.3
certified/13.13-cert8
14.7.3
13.18.3
certified/13.18-cert1-rc2
15.1.2
14.7.2
13.18.2
certified/13.18-cert1-rc1
certified/13.13-cert7
15.1.1
14.7.1
13.18.1
15.1.0
14.7.0
13.18.0
15.1.0-rc2
14.7.0-rc2
13.18.0-rc2
15.1.0-rc1
14.7.0-rc1
13.18.0-rc1
15.0.0
certified/13.13-cert6
certified/11.6-cert18
14.6.2
13.17.2
11.25.3
15.0.0-rc1
14.6.1
certified/13.13-cert5
13.17.1
certified/11.6-cert17
11.25.2
15.0.0-beta1
14.6.0
13.17.0
14.6.0-rc1
13.17.0-rc1
14.5.0
13.16.0
14.5.0-rc2
13.16.0-rc2
14.5.0-rc1
13.16.0-rc1
certified/13.13-cert4
14.4.1
13.15.1
14.4.0
13.15.0
14.4.0-rc3
13.15.0-rc3
14.3.1
13.14.1
certified/13.13-cert3
13.15.0-rc2
14.4.0-rc2
14.4.0-rc1
13.15.0-rc1
certified/13.13-cert2
14.3.0
13.14.0
certified/13.13-cert1
14.3.0-rc2
13.14.0-rc2
certified/13.13-cert1-rc4
14.3.0-rc1
13.14.0-rc1
certified/13.13-cert1-rc3
certified/13.13-cert1-rc2
certified/11.6-cert16
certified/13.8-cert4
14.2.1
13.13.1
11.25.1
certified/13.13-cert1-rc1
14.2.0
13.13.0
14.2.0-rc2
13.13.0-rc2
11.25.0
14.2.0-rc1
13.13.0-rc1
11.25.0-rc1
14.1.2
13.12.2
14.1.1
13.12.1
11.24.1
14.1.0
13.12.0
11.24.0
14.1.0-rc1
13.12.0-rc1
11.24.0-rc1
14.0.2
14.0.1
14.0.0
14.0.0-rc2
14.0.0-rc1
13.11.2
certified/11.6-cert15
certified/13.8-cert3
11.23.1
13.11.1
13.11.0
13.11.0-rc2
14.0.0-beta2
certified/11.6-cert14
certified/11.6-cert14-rc2
certified/13.8-cert2
certified/13.8-cert2-rc1
certified/11.6-cert14-rc1
13.11.0-rc1
14.0.0-beta1
11.23.0
13.10.0
certified/13.1-cert8
13.10.0-rc3
certified/13.8-cert1
13.10.0-rc2
11.23.0-rc1
13.10.0-rc1
certified/13.8-cert1-rc3
13.9.1
13.9.0
certified/13.8-cert1-rc2
13.9.0-rc2
certified/13.1-cert7
13.9.0-rc1
certified/13.1-cert6
13.8.2
13.8.1
certified/13.1-cert5
certified/13.8-cert1-rc1
13.8.0
11.22.0
certified/13.1-cert4
certified/11.6-cert13
11.21.2
13.7.2
11.20.0
13.6.0
13.5.0
11.19.0
certified/13.1-cert3-rc1
13.4.0
11.18.0
0.1.0
0.1.1
0.1.10
0.1.11
0.1.12
0.1.2
0.1.3
0.1.4
0.1.5
0.1.6
0.1.7
0.1.8
0.1.9
0.2.0
0.3.0
0.4.0
0.5.0
0.7.0
0.7.1
0.7.2
0.9.0
1.0.0
1.0.0-rc1
1.0.0-rc2
1.0.1
1.0.10
1.0.11
1.0.11.1
1.0.12
1.0.2
1.0.4
1.0.5
1.0.6
1.0.7
1.0.8
1.0.9
1.2.0
1.2.0-beta1
1.2.0-beta2
1.2.0-rc1
1.2.0-rc2
1.2.1
1.2.10
1.2.10-netsec
1.2.11
1.2.11-netsec
1.2.12
1.2.12-netsec
1.2.12.1
1.2.12.1-netsec
1.2.13
1.2.13-netsec
1.2.14
1.2.14-netsec
1.2.15
1.2.15-netsec
1.2.16
1.2.16-netsec
1.2.17
1.2.17-netsec
1.2.18
1.2.18-netsec
1.2.19
1.2.19-netsec
1.2.2
1.2.2-netsec
1.2.20
1.2.20-netsec
1.2.21
1.2.21-netsec
1.2.21.1
1.2.21.1-netsec
1.2.22
1.2.22-netsec
1.2.23
1.2.23-netsec
1.2.24
1.2.24-netsec
1.2.25
1.2.25-netsec
1.2.26
1.2.26-netsec
1.2.26.1
1.2.26.1-netsec
1.2.26.2
1.2.26.2-netsec
1.2.27
1.2.28
1.2.28.1
1.2.29
1.2.3
1.2.3-netsec
1.2.30
1.2.30.1
1.2.30.2
1.2.30.3
1.2.30.4
1.2.31
1.2.31.1
1.2.31.2
1.2.32
1.2.33
1.2.34
1.2.35
1.2.36
1.2.37
1.2.38
1.2.39
1.2.4
1.2.4-netsec
1.2.40
1.2.5
1.2.5-netsec
1.2.6
1.2.6-netsec
1.2.7
1.2.7-netsec
1.2.7.1
1.2.7.1-netsec
1.2.8
1.2.8-netsec
1.2.9
1.2.9-netsec
1.2.9.1
1.2.9.1-netsec
1.4.0
1.4.0-beta1
1.4.0-beta2
1.4.0-beta3
1.4.0-beta4
1.4.1
1.4.10
1.4.10.1
1.4.11
1.4.12
1.4.12.1
1.4.13
1.4.14
1.4.15
1.4.16
1.4.16.1
1.4.16.2
1.4.17
1.4.18
1.4.18.1
1.4.19
1.4.19-rc1
1.4.19-rc2
1.4.19-rc3
1.4.19-rc4
1.4.19.1
1.4.19.2
1.4.2
1.4.20
1.4.20-rc1
1.4.20-rc2
1.4.20-rc3
1.4.20.1
1.4.21
1.4.21-rc1
1.4.21-rc2
1.4.21.1
1.4.21.2
1.4.22
1.4.22-rc1
1.4.22-rc2
1.4.22-rc3
1.4.22-rc4
1.4.22-rc5
1.4.22.1
1.4.22.2
1.4.23
1.4.23-rc1
1.4.23-rc2
1.4.23-rc3
1.4.23-rc4
1.4.23-testing
1.4.23.1
1.4.23.2
1.4.24
1.4.24-rc1
1.4.24.1
1.4.25
1.4.25-rc1
1.4.25.1
1.4.26
1.4.26-rc1
1.4.26-rc2
1.4.26-rc3
1.4.26-rc4
1.4.26-rc5
1.4.26-rc6
1.4.26.1
1.4.26.2
1.4.26.3
1.4.27
1.4.27-rc1
1.4.27-rc2
1.4.27-rc3
1.4.27-rc4
1.4.27-rc5
1.4.27.1
1.4.28
1.4.28-rc1
1.4.29
1.4.29-rc1
1.4.29.1
1.4.3
1.4.30
1.4.30-rc1
1.4.30-rc2
1.4.30-rc3
1.4.31
1.4.31-rc1
1.4.31-rc2
1.4.32
1.4.32-rc1
1.4.32-rc2
1.4.33
1.4.33-rc1
1.4.33-rc2
1.4.33.1
1.4.34
1.4.34-rc1
1.4.34-rc2
1.4.35
1.4.35-rc1
1.4.36
1.4.36-rc1
1.4.37
1.4.37-rc1
1.4.37.1
1.4.38
1.4.38-rc1
1.4.38.1
1.4.39
1.4.39-rc1
1.4.39.1
1.4.39.2
1.4.4
1.4.40
1.4.40-rc1
1.4.40-rc2
1.4.40-rc3
1.4.40.1
1.4.40.2
1.4.41
1.4.41-rc1
1.4.41.1
1.4.41.2
1.4.42
1.4.42-rc1
1.4.42-rc2
1.4.43
1.4.44
1.4.5
1.4.6
1.4.7
1.4.7.1
1.4.8
1.4.9
1.6.0
1.6.0-beta1
1.6.0-beta2
1.6.0-beta3
1.6.0-beta4
1.6.0-beta5
1.6.0-beta6
1.6.0-beta7
1.6.0-beta7.1
1.6.0-beta8
1.6.0-beta9
1.6.0-rc1
1.6.0-rc2
1.6.0-rc3
1.6.0-rc4
1.6.0-rc5
1.6.0-rc6
1.6.0.1
1.6.0.10
1.6.0.11-rc1
1.6.0.11-rc2
1.6.0.12
1.6.0.13
1.6.0.13-rc1
1.6.0.14
1.6.0.14-rc1
1.6.0.15
1.6.0.16
1.6.0.16-rc1
1.6.0.16-rc2
1.6.0.17
1.6.0.18
1.6.0.18-rc1
1.6.0.18-rc2
1.6.0.18-rc3
1.6.0.19
1.6.0.2
1.6.0.20
1.6.0.20-rc1
1.6.0.21
1.6.0.21-rc1
1.6.0.22
1.6.0.23
1.6.0.23-rc1
1.6.0.23-rc2
1.6.0.24
1.6.0.25
1.6.0.26
1.6.0.26-rc1
1.6.0.27
1.6.0.27-rc1
1.6.0.27-rc2
1.6.0.27-rc3
1.6.0.28
1.6.0.28-rc1
1.6.0.28-rc2
1.6.0.3
1.6.0.3-rc1
1.6.0.3.1
1.6.0.4-rc1
1.6.0.4-testing
1.6.0.5
1.6.0.6
1.6.0.6-rc1
1.6.0.7
1.6.0.7-rc1
1.6.0.7-rc2
1.6.0.8
1.6.0.9
1.6.1-beta1
1.6.1-beta2
1.6.1-beta3
1.6.1-beta4
1.6.1-rc1
1.6.1.0
1.6.1.0-rc2
1.6.1.0-rc3
1.6.1.0-rc4
1.6.1.0-rc5
1.6.1.1
1.6.1.10
1.6.1.10-rc1
1.6.1.10-rc2
1.6.1.10-rc3
1.6.1.11
1.6.1.12
1.6.1.12-rc1
1.6.1.13
1.6.1.13-rc1
1.6.1.14
1.6.1.15-rc1
1.6.1.15-rc2
1.6.1.16
1.6.1.17
1.6.1.18
1.6.1.18-rc1
1.6.1.18-rc2
1.6.1.19
1.6.1.19-rc1
1.6.1.19-rc2
1.6.1.19-rc3
1.6.1.2
1.6.1.20
1.6.1.20-rc1
1.6.1.20-rc2
1.6.1.21
1.6.1.22
1.6.1.23
1.6.1.24
1.6.1.25
1.6.1.3-rc1
1.6.1.4
1.6.1.5
1.6.1.5-rc1
1.6.1.6
1.6.1.7-rc1
1.6.1.7-rc2
1.6.1.8
1.6.1.9
1.6.2.0
1.6.2.0-beta1
1.6.2.0-beta2
1.6.2.0-beta3
1.6.2.0-beta4
1.6.2.0-rc1
1.6.2.0-rc2
1.6.2.0-rc3
1.6.2.0-rc4
1.6.2.0-rc5
1.6.2.0-rc6
1.6.2.0-rc7
1.6.2.0-rc8
1.6.2.1
1.6.2.1-rc1
1.6.2.10
1.6.2.10-rc1
1.6.2.10-rc2
1.6.2.11
1.6.2.11-rc1
1.6.2.11-rc2
1.6.2.12
1.6.2.12-rc1
1.6.2.13
1.6.2.14
1.6.2.14-rc1
1.6.2.15
1.6.2.15-rc1
1.6.2.15.1
1.6.2.16
1.6.2.16-rc1
1.6.2.16.1
1.6.2.16.2
1.6.2.17
1.6.2.17-rc1
1.6.2.17-rc2
1.6.2.17-rc3
1.6.2.17.1
1.6.2.17.2
1.6.2.17.3
1.6.2.18
1.6.2.18-rc1
1.6.2.18.1
1.6.2.18.2
1.6.2.19
1.6.2.19-rc1
1.6.2.2
1.6.2.20
1.6.2.21
1.6.2.22
1.6.2.23
1.6.2.24
1.6.2.3-rc1
1.6.2.3-rc2
1.6.2.4
1.6.2.5
1.6.2.6
1.6.2.6-rc1
1.6.2.6-rc2
1.6.2.7
1.6.2.7-rc1
1.6.2.7-rc2
1.6.2.7-rc3
1.6.2.8
1.6.2.8-rc1
1.6.2.8-rc2
1.6.2.9
1.6.2.9-rc1
1.6.2.9-rc2
1.6.2.9-rc3
1.8.0
1.8.0-beta1
1.8.0-beta2
1.8.0-beta3
1.8.0-beta4
1.8.0-beta5
1.8.0-rc1
1.8.0-rc2
1.8.0-rc3
1.8.0-rc4
1.8.0-rc5
1.8.1
1.8.1-rc1
1.8.1.1
1.8.1.2
1.8.10.0
1.8.10.0-rc1
1.8.10.0-rc2
1.8.10.0-rc3
1.8.10.0-rc4
1.8.10.1
1.8.11.0
1.8.11.0-rc1
1.8.11.0-rc2
1.8.11.0-rc3
1.8.11.1
1.8.12.0
1.8.12.0-rc1
1.8.12.0-rc2
1.8.12.0-rc3
1.8.12.1
1.8.12.2
1.8.13.0
1.8.13.0-rc1
1.8.13.0-rc2
1.8.13.1
1.8.14.0
1.8.14.0-rc1
1.8.14.0-rc2
1.8.14.1
1.8.15-cert4
1.8.15.0
1.8.15.0-rc1
1.8.15.1
1.8.16.0
1.8.16.0-rc1
1.8.16.0-rc2
1.8.17.0
1.8.17.0-rc1
1.8.17.0-rc2
1.8.17.0-rc3
1.8.18.0
1.8.18.0-rc1
1.8.18.1
1.8.19.0
1.8.19.0-rc1
1.8.19.0-rc2
1.8.19.0-rc3
1.8.19.0-tc1
1.8.19.1
1.8.2
1.8.2-rc1
1.8.2.1
1.8.2.2
1.8.2.3
1.8.2.4
1.8.20.0
1.8.20.0-rc1
1.8.20.0-rc2
1.8.20.1
1.8.20.2
1.8.21.0
1.8.21.0-rc1
1.8.21.0-rc2
1.8.22.0
1.8.22.0-rc1
1.8.22.0-rc2
1.8.23.0
1.8.23.0-rc1
1.8.23.0-rc2
1.8.23.1
1.8.24.0
1.8.24.0-rc1
1.8.24.0-rc2
1.8.24.1
1.8.25.0
1.8.25.0-rc1
1.8.25.0-rc2
1.8.26.0
1.8.26.0-rc1
1.8.26.0-rc2
1.8.26.1
1.8.27.0
1.8.27.0-rc1
1.8.27.0-rc2
1.8.28-cert5
1.8.28.0
1.8.28.0-rc1
1.8.28.1
1.8.28.2
1.8.29.0
1.8.29.0-rc1
1.8.3
1.8.3-rc1
1.8.3-rc2
1.8.3-rc3
1.8.3.1
1.8.3.2
1.8.3.3
1.8.30.0
1.8.30.0-rc1
1.8.31.0
1.8.31.0-rc1
1.8.31.1
1.8.32.0
1.8.32.0-rc1
1.8.32.0-rc2
1.8.32.1
1.8.32.2
1.8.32.3
1.8.4
1.8.4-rc1
1.8.4-rc2
1.8.4-rc3
1.8.4.1
1.8.4.2
1.8.4.3
1.8.4.4
1.8.5-rc1
1.8.5.0
1.8.5.1
1.8.6.0
1.8.6.0-rc1
1.8.6.0-rc2
1.8.6.0-rc3
1.8.7.0
1.8.7.0-rc1
1.8.7.0-rc2
1.8.7.1
1.8.7.2
1.8.8.0
1.8.8.0-rc1
1.8.8.0-rc2
1.8.8.0-rc3
1.8.8.0-rc4
1.8.8.0-rc5
1.8.8.1
1.8.8.2
1.8.9.0
1.8.9.0-rc1
1.8.9.0-rc2
1.8.9.0-rc3
1.8.9.1
1.8.9.2
1.8.9.3
10.0.0
10.0.0-beta1
10.0.0-beta2
10.0.0-rc1
10.0.0-rc2
10.0.0-rc3
10.0.0-rc4
10.0.1
10.1.0
10.1.0-rc1
10.1.0-rc2
10.1.1
10.1.2
10.1.3
10.10.0
10.10.0-digiumphones
10.10.0-digiumphones-rc1
10.10.0-digiumphones-rc2
10.10.0-rc1
10.10.0-rc2
10.10.1
10.10.1-digiumphones
10.11.0
10.11.0-digiumphones
10.11.0-digiumphones-rc1
10.11.0-digiumphones-rc2
10.11.0-digiumphones-rc3
10.11.0-rc1
10.11.0-rc2
10.11.0-rc3
10.11.1
10.11.1-digiumphones
10.12.0
10.12.0-digiumphones
10.12.0-digiumphones-rc1
10.12.0-digiumphones-rc2
10.12.0-rc1
10.12.0-rc2
10.12.1
10.12.1-digiumphones
10.12.2
10.12.2-digiumphones
10.12.3
10.12.3-digiumphones
10.12.4
10.12.4-digiumphones
10.2.0
10.2.0-rc1
10.2.0-rc2
10.2.0-rc3
10.2.0-rc4
10.2.1
10.3.0
10.3.0-rc1
10.3.0-rc2
10.3.0-rc3
10.3.1
10.4.0
10.4.0-digiumphones-rc1
10.4.0-digiumphones-rc2
10.4.0-rc1
10.4.0-rc2
10.4.0-rc3
10.4.1
10.4.2
10.5.0
10.5.0-digiumphones
10.5.0-digiumphones-rc1
10.5.0-digiumphones-rc2
10.5.0-rc1
10.5.0-rc2
10.5.1
10.5.1-digiumphones
10.5.2
10.5.2-digiumphones
10.6.0
10.6.0-digiumphones
10.6.0-digiumphones-rc1
10.6.0-digiumphones-rc2
10.6.0-rc1
10.6.0-rc2
10.6.1
10.6.1-digiumphones
10.7.0
10.7.0-digiumphones
10.7.0-digiumphones-rc1
10.7.0-rc1
10.7.1
10.7.1-digiumphones
10.8.0
10.8.0-digiumphones
10.8.0-digiumphones-rc1
10.8.0-digiumphones-rc2
10.8.0-rc1
10.8.0-rc2
10.9.0
10.9.0-digiumphones
10.9.0-digiumphones-rc1
10.9.0-digiumphones-rc2
10.9.0-digiumphones-rc3
10.9.0-rc1
10.9.0-rc2
10.9.0-rc3
11.0.0
11.0.0-beta1
11.0.0-beta2
11.0.0-rc1
11.0.0-rc2
11.0.1
11.0.2
11.1.0
11.1.0-rc1
11.1.0-rc2
11.1.0-rc3
11.1.1
11.1.2
11.10.0
11.10.0-rc1
11.10.1
11.10.2
11.11.0
11.11.0-rc1
11.12.0
11.12.0-rc1
11.12.1
11.13.0
11.13.0-rc1
11.13.1
11.14.0
11.14.0-rc1
11.14.0-rc2
11.14.1
11.14.2
11.15.0
11.15.0-rc1
11.15.0-rc2
11.15.1
11.16.0
11.16.0-rc1
11.17.0
11.17.0-rc1
11.17.1
11.18.0-rc1
11.19.0-rc1
11.2.0
11.2.0-rc1
11.2.0-rc2
11.2.1
11.2.2
11.20.0-rc1
11.20.0-rc2
11.20.0-rc3
11.21.0
11.21.0-rc1
11.21.0-rc2
11.21.0-rc3
11.21.1
11.22.0-rc1
11.3.0
11.3.0-rc1
11.3.0-rc2
11.4.0
11.4.0-rc1
11.4.0-rc2
11.4.0-rc3
11.5.0
11.5.0-rc1
11.5.0-rc2
11.5.1
11.6-cert11
11.6.0
11.6.0-rc1
11.6.0-rc2
11.6.1
11.7.0
11.7.0-rc1
11.7.0-rc2
11.8.0
11.8.0-rc1
11.8.0-rc2
11.8.0-rc3
11.8.1
11.9.0
11.9.0-rc1
11.9.0-rc2
11.9.0-rc3
12.0.0
12.0.0-alpha1
12.0.0-alpha2
12.0.0-beta1
12.0.0-beta2
12.1.0
12.1.0-rc1
12.1.0-rc2
12.1.0-rc3
12.1.1
12.2.0
12.2.0-rc1
12.2.0-rc2
12.2.0-rc3
12.3.0
12.3.0-rc1
12.3.0-rc2
12.3.1
12.3.2
12.4.0
12.4.0-rc1
12.5.0
12.5.0-rc1
12.5.1
12.6.0
12.6.0-rc1
12.6.1
12.7.0
12.7.0-rc1
12.7.0-rc2
12.7.1
12.7.2
12.8.0
12.8.0-rc1
12.8.0-rc2
12.8.1
12.8.2
13.0.0
13.0.0-beta1
13.0.0-beta2
13.0.0-beta3
13.0.1
13.0.2
13.1-cert2
13.1.0
13.1.0-rc1
13.1.0-rc2
13.1.1
13.2.0
13.2.0-rc1
13.2.1
13.3.0
13.3.0-rc1
13.3.1
13.3.2
13.4.0-rc1
13.5.0-rc1
13.6.0-rc1
13.6.0-rc2
13.6.0-rc3
13.7.0
13.7.0-rc1
13.7.0-rc2
13.7.0-rc3
13.7.1
13.8.0-rc1
certified/1.8.11-cert1
certified/1.8.11-cert10
certified/1.8.11-cert2
certified/1.8.11-cert3-rc1
certified/1.8.11-cert3-rc2
certified/1.8.11-cert4
certified/1.8.11-cert5
certified/1.8.11-cert5-rc1
certified/1.8.11-cert5-rc2
certified/1.8.11-cert6
certified/1.8.11-cert7
certified/1.8.11-cert8
certified/1.8.11-cert9
certified/1.8.11-cert9-rc1
certified/1.8.15-cert1
certified/1.8.15-cert1-rc1
certified/1.8.15-cert1-rc2
certified/1.8.15-cert1-rc3
certified/1.8.15-cert2
certified/1.8.15-cert3
certified/1.8.15-cert4
certified/1.8.15-cert5
certified/1.8.15-cert6
certified/1.8.15-cert7
certified/1.8.28-cert1
certified/1.8.28-cert1-rc1
certified/1.8.28-cert2
certified/1.8.28-cert3
certified/1.8.28-cert4
certified/1.8.28-cert5
certified/1.8.6-cert1
certified/11.2-cert1
certified/11.2-cert1-rc1
certified/11.2-cert1-rc2
certified/11.2-cert2
certified/11.2-cert3
certified/11.6-cert1
certified/11.6-cert1-rc1
certified/11.6-cert1-rc2
certified/11.6-cert10
certified/11.6-cert11
certified/11.6-cert12
certified/11.6-cert2
certified/11.6-cert3
certified/11.6-cert4
certified/11.6-cert5
certified/11.6-cert6
certified/11.6-cert7
certified/11.6-cert8
certified/11.6-cert9
certified/13.1-cert1
certified/13.1-cert1-rc1
certified/13.1-cert1-rc2
certified/13.1-cert1-rc3
certified/13.1-cert2
certified/13.1-cert3
${ noResults }
3687 Commits (2bb01eb0ff9a87bfc95899de19a777746c0e94b7)
Author | SHA1 | Message | Date |
---|---|---|---|
|
2bb01eb0ff |
Reorder startup sequence to prevent lockups when process is sent to background
Although it is very rare and timing dependent, the potential exists for the call to 'daemon' to cause what appears to be a deadlock in Asterisk during startup. This can occur when a recursive mutex is obtained prior to the daemon call executing. Since daemon uses fork to send the process into the background, any threading primitives are unsafe to re-use after the call. Implementations of pthread recursive mutexes are highly likely to store the thread identifier of the thread that previously obtained the mutex. If the mutex was locked prior to the fork, a subsequent unlock operation will potentially fail as the thread identifier is no longer valid. Since the mutex is still locked, all subsequent attempts to grab the mutex by other threads will block. This behavior exhibited itself most often when DEBUG_THREADS was enabled, as this compile time option surrounds the mutexes in Asterisk with another recursive mutex that protects the storage of thread related information. This made it much more likely that a recursive mutex would be obtained prior to daemon and unlocked after the call. This patch does the following: a) It backports a patch from Asterisk 11 that prevents the spawning of the localtime monitoring thread. This thread is now spawned after Asterisk has fully booted. b) It re-orders the startup sequence to call daemon earlier during Asterisk startup. This limits the potential of threading primitives being accessed by initialization calls before daemon is called. c) It removes calls to ast_verbose/ast_log/etc. prior to daemon being called. Developers should send error messages directly to stderr prior to daemon, as calls to ast_log may access recursive mutexes that store thread related information. d) It reorganizes when thread local storage is created for storing lock information during the creation of threads. Prior to this patch, the read/write lock protecting the list of threads in ast_register_thread would utilize the lock in the thread local storage prior to it being initialized; this patch prevents that. On a very related note, this patch will *greatly* improve the stability of the Asterisk Test Suite. Review: https://reviewboard.asterisk.org/r/2197 (closes issue ASTERISK-19463) Reported by: mjordan Tested by: mjordan ........ Merged revisions 376428 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 376431 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376441 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
852bc686c9 |
Patch to prevent stopping the active generator when it is not the silence
generator. This patch introduces an internal helper function to safely check whether the current generator is the one that is expected before deactivating it. The current externally accessible ast_channel_stop_generator() function has been modified to be implemented in terms of the new function. (closes issue ASTERISK-19918) Reported by: Eduardo Abad ........ Merged revisions 376199 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 376208 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376217 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
4e04ea29c7 |
Properly check if the "Context" and "Extension" headers are empty in a ShowDialPlan action.
The code which handles the ShowDialPlan action wrongly assumed that a non-NULL return value from the function which retrieves headers from an action indicates that the header has a value. This is incorrect and the contents must be checked to see if they are blank. (closes issue ASTERISK-20628) Reported by: jkroon Patches: asterisk-showdialplan-incorrect-error.patch uploaded by jkroon ........ Merged revisions 376166 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 376167 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376168 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
1255a271d4 |
Fix Dynamic Hints Variable Substition - Underscore Problem
When adding a dynamic hint, if an extension contains an underscore no variable subsitution is being performed. This patch changes from checking if the extension contains an underscore to checking if the extension begins with an underscore. (closes issue ASTERISK-20639) Reported by: Steven T. Wheeler Tested by: Steven T. Wheeler, Michael L. Young Patches: asterisk-20639-dynamic-hint-underscore.diff uploaded by Michael L. Young (license 5026) Review: https://reviewboard.asterisk.org/r/2188/ ........ Merged revisions 376142 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 376143 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376144 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
1bba4b00b2 |
Add MALLOC_DEBUG enhancements.
* Makes malloc() behave like calloc(). It will return a memory block filled with 0x55. A nonzero value. * Makes free() fill the released memory block and boundary fence's with 0xdeaddead. Any pointer use after free is going to have a pointer pointing to 0xdeaddead. The 0xdeaddead pointer is usually an invalid memory address so a crash is expected. * Puts the freed memory block into a circular array so it is not reused immediately. * When the circular array rotates out a memory block to the heap it checks that the memory has not been altered from 0xdeaddead. * Made the astmm_log message wording better. * Made crash if the DO_CRASH menuselect option is enabled and something is found. * Fixed a potential alignment issue on 64 bit systems. struct ast_region.data[] should now be aligned correctly for all platforms. * Extracted region_check_fences() from __ast_free_region() and handle_memory_show(). * Updated handle_memory_show() CLI usage help. Review: https://reviewboard.asterisk.org/r/2182/ ........ Merged revisions 376029 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 376030 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376048 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
a65fbf8012 |
Multiple revisions 375993-375994
........ r375993 | mmichelson | 2012-11-07 11:01:13 -0600 (Wed, 07 Nov 2012) | 30 lines Fix misuses of timeouts throughout the code. Prior to this change, a common method for determining if a timeout was reached was to call a function such as ast_waitfor_n() and inspect the out parameter that told how many milliseconds were left, then use that as the input to ast_waitfor_n() on the next go-around. The problem with this is that in some cases, submillisecond timeouts can occur, resulting in the out parameter not decreasing any. When this happens thousands of times, the result is that the timeout takes much longer than intended to be reached. As an example, I had a situation where a 3 second timeout took multiple days to finally end since most wakeups from ast_waitfor_n() were under a millisecond. This patch seeks to fix this pattern throughout the code. Now we log the time when an operation began and find the difference in wall clock time between now and when the event started. This means that sub-millisecond timeouts now cannot play havoc when trying to determine if something has timed out. Part of this fix also includes changing the function ast_waitfor() so that it is possible for it to return less than zero when a negative timeout is given to it. This makes it actually possible to detect errors in ast_waitfor() when there is no timeout. (closes issue ASTERISK-20414) reported by David M. Lee Review: https://reviewboard.asterisk.org/r/2135/ ........ r375994 | mmichelson | 2012-11-07 11:08:44 -0600 (Wed, 07 Nov 2012) | 3 lines Remove some debugging that accidentally made it in the last commit. ........ Merged revisions 375993-375994 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375995 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376014 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
647810f1d0 |
Fix stuck DTMF when bridge is broken.
When a bridge is broken by an AMI Redirect action or the ChannelRedirect application, an in progress DTMF digit could be stuck sending forever. * Made simulate a DTMF end event when a bridge is broken and a DTMF digit was in progress. (closes issue ASTERISK-20492) Reported by: Jeremiah Gowdy Patches: bridge_end_dtmf-v3.patch.txt (license #6358) patch uploaded by Jeremiah Gowdy Modified to jira_asterisk_20492_v1.8.patch jira_asterisk_20492_v1.8.patch (license #5621) patch uploaded by rmudgett Tested by: rmudgett Review: https://reviewboard.asterisk.org/r/2169/ ........ Merged revisions 375964 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375965 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@375966 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
f0cd27e027 |
Refactor ast_timer_ack to return an error and handle the error in timer users
Currently, if an acknowledgement of a timer fails Asterisk will not realize that a serious error occurred and will continue attempting to use the timer's file descriptor. This can lead to situations where errors stream to the CLI/log file. This consumes significant resources, masks the actual problem that occurred (whatever caused the timer to fail in the first place), and can leave channels in odd states. This patch propagates the errors in the timing resource modules up through the timer core, and makes users of these timers handle acknowledgement failures. It also adds some defensive coding around the use of timers to prevent using bad file descriptors in off nominal code paths. Note that the patch created by the issue reporter was modified slightly for this commit and backported to 1.8, as it was originally written for Asterisk 10. Review: https://reviewboard.asterisk.org/r/2178/ (issue ASTERISK-20032) Reported by: Jeremiah Gowdy patches: jgowdy-timerfd-6-22-2012.diff uploaded by Jeremiah Gowdy (license 6358) ........ Merged revisions 375893 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375894 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@375895 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
463cbc55ac |
Add safety NULL pointer check in module user references.
Made __ast_module_user_remove() check for NULL pointers. ........ Merged revision 375860 from C.3 ........ Merged revisions 375862 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375863 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@375864 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
769d9aa259 |
Don't attempt to purge sessions when no sessions exist
Manager's tcp/tls objects have a periodic function that purge old manager sessions periodically. During shutdown, the underlying container holding those sessions can be disposed of and set to NULL before the tcp/tls periodic function is stopped. If the periodic function fires, it will attempt to iterate over a NULL container. This patch checks for whether or not the sessions container exists before attempting to purge sessions out of it. If the sessions container is NULL, we simply return. Note that this error was also caught by the Asterisk Test Suite. ........ Merged revisions 375800 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375801 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@375802 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
d38c42aab8 |
Properly clean up manager resources on exit
This patch does two things: 1) It properly unregisters the manager CLI commands 2) It cleans up AMI users on exit. Prior to this patch, the AMI users were not being disposed of properly, resulting in a memory leak. (closes issue ASTERISK-20646) Reported by: Corey Farrell patches: manager_shutdown.patch uploaded by Corey Farrell (license 5909) ........ Merged revisions 375793 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375794 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@375795 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
260da253be |
Properly finalize prepared SQLite3 statements to prevent memory leak
The AstDB uses prepared SQLite3 statements to retrieve data from the SQLite3 database. These statements should be finalized during Asterisk shutdown so that the SQLite3 database can be properly closed. Failure to finalize the statements results in a memory leak and a failure when closing the database. This patch fixes those issues by ensuring that all prepared statements are properly finalized at shutdown. (closes issue ASTERISK-20647) Reported by: Corey Farrell patches: astdb-sqlite3_close.patch uploaded by Corey Farrell (license 5909) ........ Merged revisions 375761 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@375763 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
717068e362 |
Fix memory leaks in XML documentation
This patch fixes two memory leaks: 1) When building XML documentation items, the 'name' attribute was extracted from XML elements but not properly freed after being copied into the item being built. 2) When unloading XML documentation, the doctree container objects were not properly freed. This patch corrects these memory leaks. Note that this patch was modified slightly for this commmit, as the case where the 'name' attribute doesn't exist also wasn't handled in the item construction. This patch also checks for that attribute not existing. (closes issue ASTERISK-20648) Reported by: Corey Farrell Tested by: mjordan patches: xmldoc-memory_leak.patch uploaded by Corey Farrell (license 5909) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@375756 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
69777a9376 |
Prevent multiple CDR batches from conflicting when scheduling the CDR write
The Asterisk Test Suite caught an error condition where a scheduled CDR batch write can be deleted twice if two channels attempt to post their CDRs at the same time. The batch CDR mutex is locked while the CDRs are appended to the current batch list; however, it is unlocked prior to actually scheduling the CDR write. As such, two threads can attempt to remove the currently scheduled batch write at the same time, resulting in an assertion error. This patch extends the time that the mutex is locked to encompass actually scheduling the write. This prevents two threads from unscheduling the currently scheduled write at the same time. ........ Merged revisions 375727 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375728 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@375729 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
93d85a0087 |
Things don't need to be that const.
........ Merged revisions 375658 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375659 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@375661 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
48f0d85bd1 |
Fix the Park 'r' option when a channel parks itself.
When a channel uses the Park appliation to park itself with the 'r' option, the channel hears music-on-hold instead of the requested ringing. * Added a missing check for the 'r' option when a channel parks itself. (closes issue ASTERISK-19382) Reported by: James Stocks Patches by: dsessions Review: https://reviewboard.asterisk.org/r/2148/ ........ Merged revisions 375388 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375389 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@375390 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
7ad1f16efd |
core: Fix a memory leak in app.c from an early return
ast_app_group_match_get_count allocates memory with the regcomp function and we previously forgot to free it when bailing out due to a regex compilation failure against category. (closes issue AST-1018) Reported by: Guenther Kelleter Patches: regcomp_memleak.diff uploaded by Guenther Kelleter (license 6372) ........ Merged revisions 375299 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375300 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@375301 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
09d951514d |
Ensure Asterisk fails TCP/TLS SIP calls when certificate checking fails
When placing a call to a TCP/TLS SIP endpoint whose certificate is not signed by a configured CA certificate, Asterisk would issue a warning and continue to process the call as if there was not an issue with the certificate. Asterisk now properly fails the call if the certificate fails verification or if the certificate does not exist when certificate checking is enabled (the default behavior). (closes issue ASTERISK-20559) Reported by: kmoore Review: https://reviewboard.asterisk.org/r/2163/ ........ Merged revisions 375146 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375147 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@375148 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
94c0fa9098 |
Fix some potential misuses of ast_str in the code.
Passing an ast_str pointer by value that then calls ast_str_set(), ast_str_set_va(), ast_str_append(), or ast_str_append_va() can result in the pointer originally passed by value being invalidated if the ast_str had to be reallocated. This fixes places in the code that do this. Only the example in ccss.c could result in pointer invalidation though since the other cases use a stack-allocated ast_str and cannot be reallocated. I've also updated the doxygen in strings.h to include notes about potential misuse of the functions mentioned previously. Review: https://reviewboard.asterisk.org/r/2161 ........ Merged revisions 375025 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375026 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@375027 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
ccf01fbfdc |
Do not use a FILE handle when doing SIP TCP reads.
This is used to solve an issue where a poll on a file descriptor does not necessarily correspond to the readiness of a FILE handle to be read. This change makes it so that for TCP connections, we do a recv() on the file descriptor instead. Because TCP does not guarantee that an entire message or even just one single message will arrive during a read, a loop has been introduced to ensure that we only attempt to handle a single message at a time. The tcptls_session_instance structure has also had an overflow buffer added to it so that if more than one TCP message arrives in one go, there is a place to throw the excess. Huge thanks goes out to Walter Doekes for doing extensive review on this change and finding edge cases where code could fail. (closes issue ASTERISK-20212) reported by Phil Ciccone Review: https://reviewboard.asterisk.org/r/2123 ........ Merged revisions 374905 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 374906 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374914 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
7c522a5fd3 |
Fix incorrect billing duration reported when batch mode is enabled
Similar to r369351, the billing duration can be skewed when batch mode is enabled. This happened much more rarely than the duration, as it only occured when the call was answered (thereby indicating an actual answer time) and immediately hung up on (indicating a billsec of 0). Since a billing time of '0' can either mean that the call immediately ended or that the CDR was improperly answered, we have to use additional information to know whether or not we can trust the CDR billsec value. Prior to this patch, we looked to see if we had a valid answer time. If we did, and billsec was zero, we used the current time to calculate what billsec value we could from the CDR being written. If batch mode is enabled, this will incorrectly report a billsec value being much greater than the actual duration of the call. Instead of relying on the presence of an answer time to know whether or not we can re-calculate the billsec for the CDR, we now also use the presence of the CDR's end time to know if we need to re-calculate or whether we can trust the billsec value that we have. This prevents erroneous jumps in the billsec value, while still making sure that in the worst case, some billing time will be calculated. (closes issue AST-1016) Reported by: Thomas Arimont Tested by: Thomas Arimont ........ Merged revisions 374843 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 374844 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374845 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
b5f231501b |
Don't make chan_sip export global symbols.
During testing, it was discovered that having chan_sip export global symbols was problematic. The biggest problem was that load order was affected. Trying to use realtime could be problematic since in all likelihood the necessary realtime driver(s) would not be loaded before chan_sip. In addition, it was found that it was impossible to use the Digium Phone Module for Asterisk since it must be loaded before chan_sip since it must hook into chan_sip's configuration parsing. The solution is to use a virtual table in the same manner that other modules in Asterisk do, like app_voicemail. (closes issue ASTERISK-20545) Reported by: kmoore git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374842 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
841158f428 |
Fix segfault regression from r370681
Due to usage of ast_hook_send_action, AMI action handling code should be able to handle a NULL mansession->session. This would cause a crash on NULL dereference if action_originate was called from ast_hook_send_action. (closes issue ASTERISK-20544) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374792 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
1239385a58 |
Fix execution of 'i' extension due to uninitialized variable.
The fix for ASTERISK-18243 added code that could potentially use dst_exten[] uninitialized. As a result the 'i' exten may not be executed when it should. (closes issue ASTERISK-20455) Reported by: Richard Miller Patches: pbx-1.8.16.0.diff (license #5685) patch uploaded by Richard Miller Made some cosmetic modifications. ........ Merged revisions 374758 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 374763 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374771 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
d99578264b |
Trivial patch to make 'best_score' defined for all architectures.
Fixes trivial build error on Solaris: acl.c: In function `get_local_address': acl.c:196: error: `best_score' undeclared (first use in this function) acl.c:196: error: (Each undeclared identifier is reported only once acl.c:196: error: for each function it appears in.) make[2]: *** [acl.o] Error 1 (issue ASTERISK-20366) Reported by: Ben Klang Tested by: Ben Klang patches: 0002-main-acl.c-Trivial.-best_score-should-be-defined-for.patch by Shaun Ruffell (license 5417) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374632 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
a7a10088f3 |
Update documentation for MessageSend application/command's From field for XMPP
When using the channel technology agnostic application/AMI command MessageSend, the "From" field is technically optional for the SIP channel driver. However, if being sent by the XMPP resource module (either res_xmpp or res_jabber), the "From" field is necessary, and must correspond to a defined account. This patch updates the documentation for this application/AMI command to reflect this. (closes issue ASTERISK-20405) Reported by: Leif Madsen git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374611 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
98f78d2c1d |
Multiple revisions 374570,374581
........ r374570 | dlee | 2012-10-05 15:14:41 -0500 (Fri, 05 Oct 2012) | 22 lines Improve AMI long line error handling In AMI's parser, when it receives a long line (> 1024 characters), it discards that line, but continues to process the message normally. Typically, this is not a problem because a) who has lines that long and b) usually a discarded line results in an invalid message. But if that line is specifying an optional field, then the message will be processed, you get a 'Response: Success', but things don't work the way you expected them to. This patch changes the behavior when a line-too-long parse error occurs. * Changes the log message to avoid way-too-long (and truncated anyways) log messages * Adds a 'parsing' status flag to Response: Success * Sets parsing = MESSAGE_LINE_TOO_LONG if, well, a line is too long * Responds with an appropriate error if parsing != MESSAGE_OKAY (closes issue AST-961) Reported by: John Bigelow Review: https://reviewboard.asterisk.org/r/2142/ ........ r374581 | dlee | 2012-10-05 15:20:28 -0500 (Fri, 05 Oct 2012) | 1 line I've committed too much. Reverting part of r374570. ........ Merged revisions 374570,374581 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 374586 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374587 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
ff8dce40f2 |
dsp.c User Configurable DTMF_HITS_TO_BEGIN and DTMF_MISSES_TO_END
Instead of a recompile, allow values to be adjusted in dsp.conf For binary distributions allows easy adjustment for wobbly GSM calls, and other reasons. Defaults to DTMF_HITS_TO_BEGIN=2 and DTMF_MISSES_TO_END=3 (closes issue ASTERISK-17493) Reported by: alecdavis Tested by: alecdavis alecdavis (license 585) Review https://reviewboard.asterisk.org/r/2144/ ........ Merged revisions 374479 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 374481 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374485 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
76436d2064 |
dsp.c fix incorrect DTMF Digit_Duration.
it's always short by 'hits_to_begin*DTMF_GSIZE', or 25.5ms if hitstobegin=2 (issue ASTERISK-16003) Tested by: alecdavis alecdavis (license 585) Review https://reviewboard.asterisk.org/r/2145/ ........ Merged revisions 374475 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 374476 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374477 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
2659db6d61 |
Fix DBDelTree error codes for AMI, CLI and AGI
The AMI DBDelTree command will return Success/Key tree deleted successfully even if the given key does not exist. The CLI command 'database deltree' had a similar problem, but was saved because it actually responded with '0 database entries removed'. AGI had a slightly different error, where it would return success if the database was unavailable. This came from confusion about the ast_db_deltree retval, which is -1 in the event of a database error, or number of entries deleted (including 0 for deleting nothing). * Changed some poorly named res variables to num_deleted * Specified specific errors when calling ast_db_deltree (database unavailable vs. entry not found vs. success) * Fixed similar bug in AGI database deltree, where 'Database unavailable' results in successful result (closes issue AST-967) Reported by: John Bigelow Review: https://reviewboard.asterisk.org/r/2138/ ........ Merged revisions 374426 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 374427 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374428 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
259f43f421 |
dsp.c User configuration of DTMF_NORMAL_TWIST and DTMF_REVERSE_TWIST values
Asterisk's DTMF Specifications are based on AT&T specs, which may not be compatible in other countries. Various countries have different specifications for the maximum power level differences between the DTMF low group and high group of frequencies. Power level difference between frequencies for different Administrations/RPOAs NTT = Max. 5 dB AT&T = 4dB(reverse) to 8dB(normal) Danish = Max. 6 dB Australian = Max. 10 dB Brazilian = Max. 9 dB ETSI = Max. 6 dB from ETSI ES 201 235-3 V1.3.1 (2006-03) Now allow 4 variables to be individually configured in dsp.conf, with reasonable min/max of 2dB to 20dB. Default is AT&T specifications Add's the following variables to dsp.conf ;dtmf_normal_twist=6.31 ;dtmf_reverse_twist=2.51 ;relax_dtmf_normal_twist=6.31 ;relax_dtmf_reverse_twist=3.98 (closes issue ASTERISK-20442) Reported by: tbsky Tested by: tbsky,alecdavis alecdavis (license 585) Review https://reviewboard.asterisk.org/r/2141/ ........ Merged revisions 374384 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 374385 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374386 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
ba781b68e9 |
Destroy the generic_monitors container after the core_instances in ccss
For each item in core_instances disposed of in the shutdown of ccss, any generic monitor instances referenced by the objects will be removed from generic_monitors during their destruction. Hilarity ensues if generic_monitors no longer exists. Thanks to the Asterisk Test Suite's generic_ccss test for complaining loudly when it ran into this. ........ Merged revisions 374300 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374301 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
aa5ac80919 |
Ensure Shutdown AMI event is still fired during Asterisk shutdown
Richard pointed out that having the manager dispose of itself gracefully during shutdown meant that the Shutdown event will no longer get fired. This patch moves the AMI event just prior to running the atexit callbacks. ........ Merged revisions 374230 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 374231 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374248 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
61ac420dfb |
Fix findings from check-in on r374177
Richard pointed out two problems with the check-in from r374177: * The ast_msg_shutdown function declaration doesn't match the prototype in main/message.c. * The ref/alloc function usage in astobj2 (in trunk) can use the ao2_t_* variants of the functions to allow the REF_DEBUG flag to enable/disable their debug counterparts. ........ Merged revisions 374210 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374211 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
8943656ccc |
Fix a variety of ref counting issues
This patch resolves a number of ref leaks that occur primarily on Asterisk shutdown. It adds a variety of shutdown routines to core portions of Asterisk such that they can reclaim resources allocate duringd initialization. Review: https://reviewboard.asterisk.org/r/2137 ........ Merged revisions 374177 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 374178 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374196 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
1449b2cad0 |
app_queue: Support persisting and loading of long member lists.
Greenlight in #asterisk brought up that he was receiving an error message "Could not create persistent member string, out of space" when running app_queue in Asterisk 10. dump_queue_members() made an assumption that 8K would be enough to store the generated string, but with queues that have large member lists this is not always the case. This patch removes the limitation and uses ast_str instead of a fixed sized buffer. The complicating factor comes from the fact that ast_db_get requires a buffer and buffer size argument, which doesn't let us pull back more than what we pass in, so I introduced a new ast_db_get_allocated() which returns an ast_strdup()'d copy of the value from astdb. As an aside, I did some testing on the maximum size of data that we can store in the BDB library we distribute and was able to store a 10MB string and retrieve it with no problems, so I feel this is a safe patch. Review: https://reviewboard.asterisk.org/r/2136/ ........ Merged revisions 374108 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 374135 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374150 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
0dd8b496cf |
Use ast_copy_string instead of strncpy to guarantee a NUL terminated string.
........ Merged revisions 374132 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374133 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
ad8f06037b |
Reset hangup flags on channels created through messages and cleanup globals
in res_xmpp on unload. This patch fixes an issue where hangup flags were not being reset on a channel, affecting subsequent use of that channel. The patch also adds some additional cleanup to res_xmpp to fix an issue with reloading the module. (closes ASTERISK-20360) Reported by: Noah Engelberth Tested by: beagles Review: https://reviewboard.asterisk.org/r/2134/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374019 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
302cc28472 |
loader: Ensure dependent modules are properly initialized.
If an Asterisk module specifies a dependency in ast_module_info.nonoptreq, it is possible for Asterisk to skip calling the modules's .load function. Asterisk was loading and linking the module via load_dynamic_module() but was not adding the module to the resource_heap. Therefore the module was not initialized based on it's priority along with the other modules in the heap. Now use load_resource() instead of load_dynamic_module() for non-optional requirement. This will add the module to the resource_heap so the module can be properly initialized in the correct order. This is required if there are any module global data structures initialized in the .load() callback for the module on platforms which do not support weak references. (issue ASTERISK-20439) Reported by: sruffell Patches: 0001-loader-Ensure-dependent-modules-are-properly-initial.patch uploaded by sruffell (license 5417) ........ Merged revisions 373909 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 373910 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@373911 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
8501e95d97 |
Fix saying of date in Dutch.
The Dutch say the date before the month. (closes issue ASTERISK-20353) Reported by: Teun Ouwehand ........ Merged revisions 373773 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 373774 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@373775 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
42ebea2f2f |
Add support for DTLS-SRTP to res_rtp_asterisk and chan_sip.
As mentioned on the review for this, WebRTC has moved towards choosing DTLS-SRTP as the mechanism for key exchange for SRTP. This commit adds support for this but makes it available for normal SIP clients as well. Testing has been done to ensure that this introduces no regressions with existing behavior and also that it functions as expected. Review: https://reviewboard.asterisk.org/r/2113/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@373229 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
7e9bdcc3e0 |
Named call pickup groups. Fixes, missing functionality, and improvements.
* ASTERISK-20383 Missing named call pickup group features: CHANNEL(callgroup) - Need CHANNEL(namedcallgroup) CHANNEL(pickupgroup) - Need CHANNEL(namedpickupgroup) Pickup() - Needs to also select from named pickup groups. * ASTERISK-20384 Using the pickupexten, the pickup channel selection could fail even though there was a call it could have picked up. In a call pickup race when there are multiple calls to pickup and two extensions try to pickup a call, it is conceivable that the loser will not pick up any call even though it could have picked up the next oldest matching call. Regression because of the named call pickup group feature. * See ASTERISK-20386 for the implementation improvements. These are the changes in channel.c and channel.h. * Fixed some locking issues in CHANNEL(). (closes issue ASTERISK-20383) Reported by: rmudgett (closes issue ASTERISK-20384) Reported by: rmudgett (closes issue ASTERISK-20386) Reported by: rmudgett Tested by: rmudgett Review: https://reviewboard.asterisk.org/r/2112/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@373220 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
522740b00e |
Don't crash when passing a NULL message to __astman_get_header.
Before this commit, __astman_get_header would blindly dereference the passed in 'struct message *' to traverse the header list. There are cases, however, such as '*CLI> sip qualify peer foo' where the message pointer is NULL, so we need to check for that. ........ Merged revisions 373131 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 373132 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@373133 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
9e396da730 |
Resolve memory leaks in TLS initialization and TLS client connections
This patch resolves two sources of memory leaks when using TLS in Asterisk: 1) It removes improper initialization (and multiple re-initializations) of portions of the SSL library. Asterisk calls SSL_library_init and SSL_load_error_strings during SSL initialization; collectively this obviates the need for calling any of the following during initialization or client connection handling: * ERR_load_crypto_strings (handled by SSL_load_error_strings) * OpenSSL_add_all_algorithms (synonym for SSL_library_init) * SSLeay_add_ssl_algorithms (synonym for SSL_library_init) 2) Failure to completely clean up all memory allocated by Asterisk and by the SSL library for TLS clients. This included not freeing the SSL_CTX object in the SIP channel driver, as well as not clearing the error stack when the TLS client exited. Note that these memory leaks were found by Thomas Arimont, and this patch was essentially written by him with some minor tweaks. (closes issue AST-889) Reported by: Thomas Arimont Tested by: Thomas Arimont patches: (bugAST-889.patch) by Thomas Arimont (license 5525) Review: https://reviewboard.asterisk.org/r/2105 ........ Merged revisions 373061 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 373062 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@373079 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
d214ab8b37 |
Fixed make clean when configured --disable-asteriskssl
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@373047 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
061874d811 |
Fix timeouts for ast_waitfordigit[_full].
ast_waitfordigit_full would simply pass its timeout to ast_waitfor_nandfds, expecting it to decrement the timeout by however many milliseconds were waited. This is a problem if it consistently waits less than 1ms. The timeout will never be decremented, and we wait... FOREVER! This patch makes ast_waitfordigit_full manage the timeout itself. It maintains the previously undocumented behavior that negative timeouts wait forever. (closes issue ASTERISK-20375) Reported by: Mark Michelson Tested by: Mark Michelson Review: https://reviewboard.asterisk.org/r/2109/ ........ Merged revisions 373024 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 373025 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@373029 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
14947e93cc |
Fixed r372696 when configured --disable-asteriskssl; properly install libasteriskssl.dylib on OS X.
I didn't realize that libasteriskssl.c was still compiled, even when you disable asteriskssl; it simple gets statically linked into asterisk. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@372930 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
46b730b070 |
Fix inability to shutdown gracefully due to an unending channel reference.
message.c makes use of a special message queue channel that exists in thread storage. This channel never goes away due to the fact that the taskprocessor used by message.c does not get shut down, meaning that it never ends the thread that stores the channel. This patch fixes the problem by shutting down the taskprocessor when Asterisk is shut down. In addition, the thread storage has a destructor that will release the channel reference when the taskprocessor is destroyed. (closes issue AST-937) Reported by Jason Parker Patches: AST-937.patch uploaded by Mark Michelson (License #5049) Tested by Jason Parker ........ Merged revisions 372885 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@372888 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
9bfcbf0f70 |
Fix bad channel application data reference.
When channels get bridged due to an AMI bridge action or a DTMF attended transfer, the two channels that get bridged have their application data pointing to the other channel's name. This means that if one channel is hung up but the other moves on, it means that the channel that moves on will have its application data pointing at freed memory. (issue ASTERISK-20335) Reported by: aragon ........ Merged revisions 372840 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 372841 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@372886 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
05cccdea8c |
Deprecate chan_gtalk, chan_jingle, and res_jabber
chan_gtalk, chan_jingle, and res_jabber are now deprecated in favor of using chan_motif and res_xmpp. They are a feature-equivalent replacement and are written to be more easily maintainable. (closes issue ASTERISK-20298) Review: https://reviewboard.asterisk.org/r/2082/ Reported-by: Leif Madsen git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@372795 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |