mirror of https://github.com/asterisk/asterisk
releases/22
releases/21
releases/20
releases/18
releases/certified-20.7
releases/certified-18.9
18
certified/18.9
certified/20.7
master
21
22
20
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
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 }
26229 Commits (dd4d4e40e57a0013c6861f6441f30eadbd1698c6)
Author | SHA1 | Message | Date |
---|---|---|---|
|
918ca7dd36 |
res_pjsip_t38: Fix FAX failures when using PJSIP with authentication
Without this patch, if a PJSIP endpoint with udptl enabled and authentication set attempted to use sendFax, the FAX session would fail during setup. This was because the invite issued in response to being auth challenged would cause the PJSIP channel performing the FAX to receive a second T38 framehook and this would cause frames to be consumed in an inappropriate manner. ASTERISK-24933 #close Reported by: Jonathan Rose Review: https://reviewboard.asterisk.org/r/4577/ ........ Merged revisions 434425 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@434428 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
08945a5c77 |
Security/tcptls: MitM Attack potential from certificate with NULL byte in CN.
When registering to a SIP server with TLS, Asterisk will accept CA signed certificates with a common name that was signed for a domain other than the one requested if it contains a null character in the common name portion of the cert. This patch fixes that by checking that the common name length matches the the length of the content we actually read from the common name segment. Some certificate authorities automatically sign CA requests when the requesting CN isn't already taken, so an attacker could potentially register a CN with something like www.google.com\x00www.secretlyevil.net and have their certificate signed and Asterisk would accept that certificate as though it had been for www.google.com - this is a security fix and is noted in AST-2015-003. ASTERISK-24847 #close Reported by: Maciej Szmigiero Patches: asterisk-null-in-cn.patch submitted by mhej (license 6085) ........ Merged revisions 434337 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 434338 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 434384 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@434418 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
45f09898e9 |
Do not queue message requests that we do not respond to.
If we receive a MESSAGE request that we cannot send a response to, we should not send the incoming MESSAGE to the dialplan. This commit should help the bouncing message_retrans test to pass consistently. ........ Merged revisions 434218 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@434220 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
42b7ebdd4d |
res_pjsip_messaging: Serialize outbound SIP MESSAGEs
Outbound SIP MESSAGEs had the potential to be sent out of order from how they were specified in a set of dialplan steps. This change creates a serializer for sending outbound MESSAGE requests on. This ensures that the MESSAGEs are sent by Asterisk in the same order that they were sent from the dialplan. ASTERISK-24937 #close Reported by Mark Michelson Review: https://reviewboard.asterisk.org/r/4579 ........ Merged revisions 433968 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433970 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
b6fff2719d |
core: avoid possible asterisk -r crash from long id
When connecting to the remote console, an id string is first provided that consts of the hostname, pid, and version. This is parsed by the remote instance using a buffer that may be too short, and can allow a buffer overrun because it is not terminated. This patch adds termination and a larger buffer. Review: https://reviewboard.asterisk.org/r/4182/ AFS-254 ........ Merged revisions 429223 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433918 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
8ae3670781 |
stasis: set a channel variable on websocket disconnect error
Resolve compile errors caused by r433863 by fixing the documentation xml to comply with the schema. ........ Merged revisions 433888 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433890 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
259227eb1a |
stasis: set a channel variable on websocket disconnect error
Resolve compile errors caused by r433839 by included the missing header file, pbx.h. ........ Merged revisions 433863 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433864 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
758fead630 |
stasis: set a channel variable on websocket disconnect error
When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). To remedy this scenario, this patch introduces a new channel variable: STASISSTATUS. The possible values for STASISSTATUS are: SUCCESS - The channel has exited Stasis without any failures FAILED - Something caused Stasis to croak. Some (not all) possible reasons for this: - The app registry is not instantiated; - The app requested is not registered; - The app requested is not active; - Stasis couldn't send a start message ASTERISK-24802 Reported By: Kevin Harwell Review: https://reviewboard.asterisk.org/r/4519/ ........ Merged revisions 433839 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433842 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
b5b44876c2 |
Add stateful PJSIP response API call, and use it for out-of-dialog responses.
Asterisk had an issue where retransmissions of MESSAGE requests resulted in Asterisk processing the retransmission as if it were a new MESSAGE request. This patch fixes the issue by creating a transaction in PJSIP on the incoming request. This way, if a retransmission arrives, the PJSIP transaction layer will resend the response and Asterisk will not ever see the retransmission. ASTERISK-24920 #close Reported by Mark Michelson Review: https://reviewboard.asterisk.org/r/4532/ ........ Merged revisions 433619 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433621 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
66b8c7cab4 |
res_pjsip_registrar_expire.c: Cleanup scheduler leaks on unload/shutdown.
Contact expiration object refs were leaked when the module was unloaded. * Made empty the scheduler of entries before destroying it to release the object ref held by the scheduler entry. Review: https://reviewboard.asterisk.org/r/4523/ ........ Merged revisions 433596 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433618 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
fb7062afca |
Audit ast_pjsip_rdata_get_endpoint() usage for ref leaks.
Valgrind found some memory leaks associated with ast_pjsip_rdata_get_endpoint(). The leaks would manifest when sending responses to OPTIONS requests, processing MESSAGE requests, and res_pjsip supplements implementing the incoming_request callback. * Fix ast_pjsip_rdata_get_endpoint() endpoint ref leaks in res/res_pjsip.c:supplement_on_rx_request(), res/res_pjsip/pjsip_options.c:send_options_response(), res/res_pjsip_messaging.c:rx_data_to_ast_msg(), and res/res_pjsip_messaging.c:send_response(). * Eliminated RAII_VAR() use with ast_pjsip_rdata_get_endpoint() in res/res_pjsip_nat.c:nat_on_rx_message(). * Fixed inconsistent but benign return value in res/res_pjsip/pjsip_options.c:options_on_rx_request(). Review: https://reviewboard.asterisk.org/r/4511/ ........ Merged revisions 433222 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433224 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
cf9799845f |
res_pjsip_sdp_rtp,sorcery: Fix invalid access and memory leak respectively.
Valgrind found a memory leak and invalid access. * Fix invalid access by sscanf() being fed a non-nul terminated string of digits in res/res_pjsip_sdp_rtp.c:get_codecs(). * Fix memory leak in main/sorcery.c:sorcery_object_field_destructor(). * Fix potential NULL pointer dereference in main/xmldoc.c:xmldoc_get_syntax_config_option(). Review: https://reviewboard.asterisk.org/r/4513/ ........ Merged revisions 433199 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433201 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
90fc65da62 |
Audit ast_sockaddr_resolve() usage for memory leaks.
Valgrind found some memory leaks associated with ast_sockaddr_resolve(). Most of the leaks had already been fixed by earlier memory leak hunt patches. This patch performs an audit of ast_sockaddr_resolve() and found one more. * Fix ast_sockaddr_resolve() memory leak in apps/app_externalivr.c:app_exec(). * Made main/netsock2.c:ast_sockaddr_resolve() always set the addrs parameter for safety so the pointer will never be uninitialized on return. The same goes for res/res_pjsip_acl.c:extract_contact_addr(). * Made functions that call ast_sockaddr_resolve() with RAII_VAR() controlling the addrs variable use ast_free instead of ast_free_ptr to provide better MALLOC_DEBUG information. Review: https://reviewboard.asterisk.org/r/4509/ ........ Merged revisions 433056 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 433057 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433059 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
e0b644ddb7 |
res_pjsip: Allow configuration of endpoint identifier query order
Updated some documentation stating that endpoint identifiers registered without a name are place at the front of the lookup list. Also renamed register method 'ast_sip_register_endpoint_identifier_by_name' to 'ast_sip_register_endpoint_identifier_with_name' ASTERISK-24840 Reported by: Mark Michelson ........ Merged revisions 433031 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433034 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
d7c8041f6b |
res_pjsip: Allow configuration of endpoint identifier query order
This patch fixes previously reverted code that caused binary incompatibility problems with some modules. And like the original patch it makes sure that no matter what order the endpoint identifier modules were loaded, priority is given based on the ones specified in the new global 'endpoint_identifier_order' option. ASTERISK-24840 Reported by: Mark Michelson Review: https://reviewboard.asterisk.org/r/4489/ ........ Merged revisions 433028 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433033 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
cd4e18c4cc |
Multiple revisions 431583,433005
........ r431583 | sgriepentrog | 2015-02-06 15:26:12 -0600 (Fri, 06 Feb 2015) | 10 lines various: cleanup issues found during leak hunt In this collection of small patches to prevent Valgrind errors are: fixes for reference leaks in config hooks, evaluating a parameter beyond bounds, and accessing a structure after a lock where it could have been already free'd. Review: https://reviewboard.asterisk.org/r/4407/ ........ r433005 | rmudgett | 2015-03-17 11:10:39 -0500 (Tue, 17 Mar 2015) | 1 line res_pjsip: Add reason comment. ........ Merged revisions 431583,433005 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433025 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
6cd70450fd |
Revert - res_pjsip: Allow configuration of endpoint identifier query order
Due to a break in binary compatibility with some other modules these changes are being reverted until the issue can be resolved. ASTERISK-24840 Reported by: Mark Michelson ........ Merged revisions 432868 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@432888 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
4eb1dd4b35 |
res_pjsip: Allow configuration of endpoint identifier query order
It's possible to have a scenario that will create a conflict between endpoint identifiers. For instance an incoming call could be identified by two different endpoint identifiers and the one chosen depended upon which identifier module loaded first. This of course causes problems when, for example, the incoming call is expected to be identified by username, but instead is identified by ip. This patch adds a new 'global' option to res_pjsip called 'endpoint_identifier_order'. It is a comma separated list of endpoint identifier names that specifies the order by which identifiers are processed and checked. ASTERISK-24840 #close Reported by: Mark Michelson Review: https://reviewboard.asterisk.org/r/4455/ ........ Merged revisions 432638 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@432658 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
52366a423c |
translate: Prevent invalid memory accesses on fast shutdown
When a 'core restart now' or 'core stop now' is executed and a channel is currently in a media operation, the translator matrix can be destroyed while a channel is currently blocked on getting the best translation choice (see ast_translator_best_choice). When the channel gets the mutex, the translation matrix now has invalid memory, and Asterisk crashes. This patch does two things: (1) We now only clean up the translation matrix on a graceful shutdown. In that case, there are no channels, and so there is no risk of this occurring. (2) We also now set the __matrix and __indextable to NULL. In some initial backtraces when this occurred, it looked as if there was a memory corruption occurring, and it wasn't until we determined that something had restarted Asterisk that the issue became clear. By setting these to NULL on shutdown, it becomes a bit easier to determine why a crash is occurring. Note that we could litter the code with NULL checks on the __matrix, but the act of making the translation matrix cleaned up on shutdown should preclude this issue from occurring in the first place, and this part of the code needs to be as fast as possible. Review: https://reviewboard.asterisk.org/r/4457/ ........ Merged revisions 432453 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@432454 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
b17d0953b6 |
res/res_pjsip_sdp_rtp: Revert portion of r432195
Unfortunately, while initial testing with ConfBridge did not reproduce the audio problem alluded to in the comment in res_pjsip_sdp_rtp, further testing did show that bridge_softmix and/or ConfBridge has a severe problem bridging two or more participants at different sampling rates. Sometimes, it even picks odd sampling rates that cause hideous audio problems. This patch backs out the offending portion of the code until the issues in the affected bridging modules can be more properly analyzed. ASTERISK-24841 ........ Merged revisions 432423 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@432424 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
3b4ba353f0 |
app_chanspy, channel: fix frame leaks
Fixed a couple of frame leaks that were found during testing. ASTERISK-24828 #close Reported by: John Hardin Review: https://reviewboard.asterisk.org/r/4445/ ........ Merged revisions 432362 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 432363 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@432365 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
33c73ffeaa |
ARI/PJSIP: Apply requesting channel's format cap to created channels
This patch addresses the following problems: * ari/resource_channels: In ARI, we currently create a format capability structure of SLIN and apply it to the new channel being created. This was originally done when the PBX core was used to create the channel, as there was a condition where a newly created channel could be created without any formats. Unfortunately, now that the Dial API is being used, this has two drawbacks: (a) SLIN, while it will ensure audio will flows, can cause a lot of needless transcodings to occur, particularly when a Local channel is created to the dialplan. When no format capabilities are available, the Dial API handles this better by handing all audio formats to the requsted channels. As such, we defer to that API to provide the format capabilities. (b) If a channel (requester) is causing this channel to be created, we currently don't use its format capabilities as we are passing in our own. However, the Dial API will use the requester channel's formats if none are passed into it, and the requester channel exists and has format capabilities. This is the "best" scenario, as it is the most likely to create a media path that minimizes transcoding. Fixing this simply entails removing the providing of the format capabilities structure to the Dial API. * chan_pjsip: Rather than blindly picking the first format in the format capability structure - which actually *can* be a video or text format - we select an audio format, and only pick the first format if that fails. That minimizes the weird scenario where we attempt to transcode between video/audio. * res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure. Since ast_request already limits us down to one format capability once the format capabilities are passed along, there's no reason to squelch it here. * channel: Fixed a comment. The reason we have to minimize our requested format capabilities down to a single format is due to Asterisk's inability to convey the format to be used back "up" a channel chain. Consider the following: PJSIP/A => L;1 <=> L;2 => PJSIP/B g,u,a g,u,a g,u,a u That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local channel has inherited those format capabilities down the line; PJSIP/B supports only ulaw. According to these format capabilities, ulaw is acceptable and should be selected across all the channels, and no transcoding should occur. However, there is no way to convey this: when L;2 and PJSIP/B are put into a bridge, we will select ulaw, but that is not conveyed to PJSIP/A and L;1. Thus, we end up with: PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B g g X u u Which causes g722 to be written to PJSIP/B. Even if we can convey the 'ulaw' choice back up the chain (which through some severe hacking in Local channels was accomplished), such that the chain looks like: PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B u u u u We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back with only 'ulaw'. This results in all the channel structures being set up correctly, but PJSIP/A *still* sending g722 and causing the chain to fall apart. There's a lot of difficulty just in setting this up, as there are numerous race conditions in the act of bridging, and no clean mechanism to pass the selected format backwards down an established channel chain. As such, the best that can be done at this point in time is clarifying the comment. Review: https://reviewboard.asterisk.org/r/4434/ ASTERISK-24812 #close Reported by: Matt Jordan ........ Merged revisions 432195 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@432197 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
3ad393b043 |
res_pjsip: dtls_handler causes Asterisk to crash
There have been a couple of times where a crash occurred in the dtls_handler section of the code for res_pjsip. Unfortunately, in working this issue the problem was unable to be reproduced. After looking at the backtraces and through the code the current best guess as to why this happened might be due to a reentrance problem and the strtok function. So, the current fix is to convert the strtok function into the reentrant version of the function, strtok_r. ASTERISK-24741 #close Reported by: Zane Conkle Review: https://reviewboard.asterisk.org/r/4409/ ........ Merged revisions 431698 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431700 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
8be00450b9 |
res_http_websocket: websocket write timeout fails to fully disconnect
When writing to a websocket if a timeout occurred the underlying socket did not get closed/disconnected. This patch makes sure the websocket gets disconnected on a write timeout. Also a notice is logged stating that the websocket was disconnected. ASTERISK-24701 #close Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/4412/ ........ Merged revisions 431669 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 431670 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431697 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
340588c721 |
HTTP: Stop accepting requests on final system shutdown.
There are three CLI commands to stop and restart Asterisk each. 1) core stop/restart now - Hangup all calls and stop or restart Asterisk. New channels are prevented while the shutdown request is pending. 2) core stop/restart gracefully - Stop or restart Asterisk when there are no calls remaining in the system. New channels are prevented while the shutdown request is pending. 3) core stop/restart when convenient - Stop or restart Asterisk when there are no calls in the system. New calls are not prevented while the shutdown request is pending. ARI has made stopping/restarting Asterisk more problematic. While a shutdown request is pending it is desirable to continue to process ARI HTTP requests for current calls. To handle the current calls while a shutdown request is pending, a new committed to shutdown phase is needed so ARI applications can deal with the calls until the system is fully committed to shutdown. * Added a new shutdown committed phase so ARI applications can deal with calls until the final committed to shutdown phase is reached. * Made refuse new HTTP requests when the system has reached the final system shutdown phase. Starting anything while the system is actively releasing resources and unloading modules is not a good thing. * Split the bridging framework shutdown to not cleanup the global bridging containers when shutting down in a hurry. This is similar to how other modules prevent crashes on rapid system shutdown. * Moved ast_begin_shutdown(), ast_cancel_shutdown(), and ast_shutting_down(). You should not have to include channel.h just to access these system functions. ASTERISK-24752 #close Reported by: Matthew Jordan Review: https://reviewboard.asterisk.org/r/4399/ ........ Merged revisions 431692 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431696 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
69dc8f9ec2 |
pjsip_options: Fix continued qualifies after endpoint/aor deletion
If you remove an endpoint/aor from pjsip.conf then do a core reload, qualifies will continue even though the object are gone. This happens because nothing clears out the qualify tasks. This patch unschedules all existing qualify tasks before scheduling new ones on reload. Tested-by: George Joseph Review: https://reviewboard.asterisk.org/r/4290/ ........ Merged revisions 430064 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431667 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
2125e1b2de |
Add Asterisk 13 revision 431420 that fixes disabling 100rel option on PJSIP endpoints.
git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431573 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
b732e8cad9 |
app_agent_pool: Fix initial module load agent device state reporting.
When the app_agent_pool module initially loads there is a race condition between the thread loading agents.conf and the device state internal processing thread. If the device state internal processing thread handles the agent creation state updates before the thread that loaded agents.conf registers the device state provider callback then the cached agent state is "Invalid". When a consumer module like app_queue asks for the agent state it gets the cached "Invalid" state instead of the real state from the provider. * Moved loading the agents.conf configuration to the last thing setup by app_agent_pool in load_module(). Now the device state provider callback is registered before the config is loaded so the agent creation state updates are guaranteed to get the initial device state. * Removed some now redundant config cleanup on error in load_config(). * Added lock protection when accessing the device state in agent_pvt_devstate_get() and eliminated the RAII_VAR() usage. ASTERISK-24737 #close Reported by: Steve Pitts Review: https://reviewboard.asterisk.org/r/4390/ ........ Merged revisions 431492 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431494 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
968f8d51b4 |
Fix some memory leaks.
These memory leaks were found and fixed by John Hardin. I'm just committing them for him. ASTERISK-24736 #close Reported by Mark Michelson Review: https://reviewboard.asterisk.org/r/4389 ........ Merged revisions 431468 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431470 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
c92b9290c8 |
Merge r431153 from asterisk/branches/13
r431153 | jrose | 2015-01-27 11:22:52 -0600 (Tue, 27 Jan 2015) | 9 lines Manager: Fix Manager Action ModuleLoad to give correct response when reloading Prior to this patch, ModuleLoad would respond with an error indicating that the requested module wasn't found in spite of finding and reloading the module. Review: https://reviewboard.asterisk.org/r/4373/ ASTERISK-24721 #close git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431467 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
910c3e32e4 |
Multiple revisions 431297-431298
........ r431297 | mmichelson | 2015-01-28 11:05:26 -0600 (Wed, 28 Jan 2015) | 17 lines Mitigate possible HTTP injection attacks using CURL() function in Asterisk. CVE-2014-8150 disclosed a vulnerability in libcURL where HTTP request injection can be performed given properly-crafted URLs. Since Asterisk makes use of libcURL, and it is possible that users of Asterisk may get cURL URLs from user input or remote sources, we have made a patch to Asterisk to prevent such HTTP injection attacks from originating from Asterisk. ASTERISK-24676 #close Reported by Matt Jordan Review: https://reviewboard.asterisk.org/r/4364 AST-2015-002 ........ r431298 | mmichelson | 2015-01-28 11:12:49 -0600 (Wed, 28 Jan 2015) | 3 lines Fix compilation error from previous patch. ........ Merged revisions 431297-431298 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 431299 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 431301 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431334 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
2bb100d538 |
Fix file descriptor leak in RTP code.
SIP requests that offered codecs incompatible with configured values could result in the allocation of RTP and RTCP ports that would not get reclaimed later. ASTERISK-24666 #close Reported by Y Ateya Review: https://reviewboard.asterisk.org/r/4323 AST-2015-001 ........ Merged revisions 431300 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 431303 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431326 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
646dc62cd2 |
res_pjsip_outbound_registration: Fix reload race condition.
Performing a CLI "module reload" command when there are new pjsip.conf registration objects defined frequently failed to load them correctly. What happens is a race condition between res_pjsip pushing its reload into an asynchronous task processor task and the thread that does the rest of the reloads when it gets to reloading the res_pjsip_outbound_registration module. A similar race condition happens between a reload and the CLI/AMI show registrations commands. The reload updates the current_states container and the CLI/AMI commands call get_registrations() which builds a new current_states container. * Made res_pjsip.c reload_module() use ast_sip_push_task_synchronous() instead of ast_sip_push_task() to eliminate two threads processing config reloads at the same time. * Made get_registrations() not replace the global current_states container so the CLI/AMI show registrations command cannot interfere with reloading. You could never add/remove objects in the container without the possibility of the container being replaced out from under you by get_registrations(). * Added a registration loaded sorcery instance observer to purge any dead registration objects since get_registrations() cannot do this job anymore. The struct ast_sorcery_instance_observer callbacks must be used because the callback happens inline with the load process. The struct ast_sorcery_observer callbacks are pushed to a different thread. * Added some global current_states NULL pointer checks in case the container disappears because of unload_module(). * Made sorcery's struct ast_sorcery_instance_observer.object_type_loaded callbacks guaranteed to be called before any struct ast_sorcery_observer.loaded callbacks will be called. * Moved the check for non-reloadable objects to before the sorcery instance loading callbacks happen to short circuit unnecessary work. Previously with non-reloadable objects, the sorcery instance loading/loaded callbacks would always happen, the individual wizard loading/loaded would be prevented, and the non-reloadable type logging message would be logged for each associated wizard. ASTERISK-24729 #close Review: https://reviewboard.asterisk.org/r/4381/ ........ Merged revisions 431243 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431244 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
8d5f90bb39 |
tcptls: Bad file descriptor error when reloading chan_sip
While running through some scenarios using chan_sip and tcp a problem would occur that resulted in a flood of bad file descriptor messages on the cli: tcptls.c:712 ast_tcptls_server_root: Accept failed: Bad file descriptor The message is received because the underlying socket has been closed, so is valid. This is probably happening because unloading of chan_sip is not atomic. That however is outside the scope of this patch. This patch simply stops the logging of multiple occurrences of that message. ASTERISK-24728 #close Reported by: Thomas Thompson Review: https://reviewboard.asterisk.org/r/4380/ ........ Merged revisions 431218 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 431219 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431221 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
dd382f3660 |
chan_sip: stale nonce causes failure
When refreshing (with a small expiration) a registration that was sent to chan_sip the nonce would be considered stale and reject the registration. What was happening was that the initial registration's "dialog" still existed in the dialogs container and upon refresh the dialog match algorithm would choose that as the "dialog" instead of the newly created one. This occurred because the algorithm did not check to see if the from tag matched if authentication info was available after the 401. So, it ended up assuming the original "dialog" was a match and stopped the search. The old "dialog" of course had an old nonce, thus the stale nonce message. This fix attempts to leave the original functionality alone except in the case of a REGISTER. If a REGISTER is received if searches for an existing "dialog" matching only on the callid. If the expires value is low enough it will reuse dialog that is there, otherwise it will create a new one. ASTERISK-24715 #close Reported by: John Bigelow Review: https://reviewboard.asterisk.org/r/4367/ ........ Merged revisions 431187 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 431194 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431200 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
4bd3c0edf0 |
app_confbridge: Repeatedly starting and stopping recording ref leaks the recording channel.
Starting and stopping conference recording more than once causes the recording channels to be leaked. For v13 the channels also show up in the CLI "core show channels" output. * Reworked and simplified the recording channel code to use ast_bridge_impart() instead of managing the recording thread in the ConfBridge code. The recording channel's ref handling easily falls into place and other off nominal code paths get handled better as a result. ASTERISK-24719 #close Reported by: John Bigelow Review: https://reviewboard.asterisk.org/r/4368/ Review: https://reviewboard.asterisk.org/r/4369/ ........ Merged revisions 431135 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 431160 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431162 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
46f6d0bdfb |
bridge / res_pjsip_sdp_rtp: Fix issues with media not being reinvited during direct media.
This change fixes two issues: 1. During a swap operation bridging added the new channel before having the swap channel leave. This was not handled in bridge_native_rtp and could result in a channel not getting reinvited back to Asterisk. After this change the swap channel will leave first and the new channel will then join. 2. If a re-invite was received after a session had been established any upstream elements (such as bridge_native_rtp) were not notified that they may want to re-evaluate things. After this change an UPDATE_RTP_PEER control frame is queued when this situation occurs and upstream can react. AST-1524 #close Review: https://reviewboard.asterisk.org/r/4378/ ........ Merged revisions 431157 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431159 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
757e99a668 |
app_confbridge: Restore user's menu name to CLI output of 'confbridge list'
When issuing a 'confbridge list XXXX' CLI command, the resulting output no longer displays the menu associated with a ConfBridge participant. The issue was caused by ASTERISK-22760. When that patch was done, it removed the copying of the menu name associated with the user from the actual user profile. This patch fixes the issue by copying the menu name over to the user profile when the menu hooks are applied to the user. Since that function now does a little bit more than just apply the hooks, the name of the function has been changed to cover the copying of the menu name over as well. In addition, there is a disparity between the menu name length as it is stored on the conf_menu structure and the confbridge_user structure; this patch makes the lengths match so that a strcpy can be used. Review: https://reviewboard.asterisk.org/r/4372/ ASTERISK-24723 #close Reported by: Steve Pitts ........ Merged revisions 431134 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431140 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
9a324112ef |
res_parking: Fix crash due to race condition when unloading.
There is currently a race condition when unloading the res_parking module. Depending on the will of the universe the subscription invocation may occur AFTER the module is unloaded. This is because the module does NOT use stasis_unsubscribe_and_join when terminating the subscription. It merely uses stasis_unsubscribe. This change makes it use stasis_unsubscribe_and_join which is documented for usage in this exact scenario. AST-1520 #close Review: https://reviewboard.asterisk.org/r/4375/ ........ Merged revisions 431114 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431116 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
1f06f7759c |
Investigate and fix memory leaks in Asterisk
Fixed memory leaks that were found in Asterisk. ASTERISK-24693 #close Reported by: Kevin Harwell Review: https://reviewboard.asterisk.org/r/4347/ ........ Merged revisions 430999 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431016 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
a103640d8d |
Multiple revisions 430223,430373,430395
........ r430223 | gtjoseph | 2015-01-06 11:35:21 -0600 (Tue, 06 Jan 2015) | 24 lines outbound_registration: Add 'pjsip send register' and update 'send unregister' The current behavior of 'pjsip send unregister' is to send the unregister (REGISTER with 0 exp) but let the next scheduled register proceed normally. I don't think that's a good idea. If you unregister, it should stay unregistered until you decide to start registrations again. So this patch just adds a cancel_registration call to the current unregister_task to cancel the timer. Of course, now you need a way to start registration again so I've added a 'pjsip send register' command that unregisters and cancels any existing registration (the same as send unregister), then sends an immediate registration and starts the timer back up again. Both changes also ripple to AMI. There's a new PJSIPRegister command. There's no harm in calling either command repeatedly. They don't care about the actual state. Tested-by: George Joseph Review: https://reviewboard.asterisk.org/r/4301/ ........ r430373 | gtjoseph | 2015-01-08 11:48:29 -0600 (Thu, 08 Jan 2015) | 25 lines res_pjsip_outbound_registration: Fix several reload issues There are 2 issues with reloading registrations... 1. The 'can_reuse_registration' test wasn't considering the intervals or expiration in its determination of whether a registration changed or not so if you changed any of the intervals or the expiration and reloaded, the object would get reloaded but the actual timers wouldn't change. can_reuse_registration now does a sorcery diff on the old and new objects instead of discretely testing certain fields. Now if you change expiration for instance, and reload, the timer is updated and re-registration will occur on the new value. 2. If you mung up your password on an outbound registration you get a permanent failure. If you fix the password (on the outbound_auth object) and reload, nothing tells outbound_registration to try again because the registration itself didn't change. This patch adds an observer on the "auth" object type and if any auth changes, existing registration states are searched and those in a REJECTED_PERMANENT state are retried. Tested-by: George Joseph Review: https://reviewboard.asterisk.org/r/4304/ ........ r430395 | gtjoseph | 2015-01-08 15:37:42 -0600 (Thu, 08 Jan 2015) | 14 lines res_pjsip_outbound_registration: Fix reference leak. Every time a registration started, sip_outbound_registration_response_cb bumps the ref count on client_state then pushes a handle_registration_response task. handle_registration_response never unreffed it though. So every time a registration goes out, the ref count goes up by one. This patch adds the unreffs to handle_registration_response. Tested-by: George Joseph Review: https://reviewboard.asterisk.org/r/4303/ ........ Merged revisions 430223,430373,430395 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@430898 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
c3e98e90e9 |
channels/chan_sip: Fix registration leak during reload
When the SIP registrations were migrated to using ao2 in what was then trunk, the explicit destruction of the registrations on module reload was removed and not replaced with an ao2 equivalent. Debugging done by Stefan Engström, the issue reporter, on ASTERISK-24673 confirmed that the reference in the registry_list container was being leaked. Since the purpose of cleanup_all_regs is to prep a registration for destruction, this function now calls an ao2_callback function callback with the OBJ_MULTIPLE | OBJ_NODATA | OBJ_UNLINK flags used to remove the registrations. This cleans up each registration, and also removes it from the registration container registry_list. Review: https://reviewboard.asterisk.org/r/4355/ ASTERISK-24640 #close Reported by: Max Man ASTERISK-24673 #close Reported by: Stefan Engström Tested by: Stefan Engström ........ Merged revisions 430864 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@430865 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
b9be1f9413 |
apps/app_dial: Don't publish DialEnd twice on unexpected GoSub/Macro values
The Dial application has some interesting options with the mid-call Macro (M) and GoSub (U) options. If the MACRO_RESULT/GOSUB_RESULT returns specific values, the Dial application will take some action upon the channels involved in the dial operation (such as hanging up a particular party, etc.) The Dial application ensures that a Stasis message is published in the event that MACRO_RESULT/GOSUB_RESULT returns a value that kills the dial operation, so that there is a corresponding DialEnd event published in AMI/ARI for the DialBegin event that preceeded it. A bug exists where that same DialEnd event will be published on Stasis even if the value returned in MACRO_RESULT/GOSUB_RESULT is not one that the Dial application cares about. This causes two DialEnd events to be published - one with the MACRO_RESULT/GOSUB_RESULT and another with "ANSWERED" - which is all sorts of wrong. This patch fixes the bug by ensuring that we only publish a DialEnd message to Stasis if the Dial application's mid-call Macro/GoSub returns something that Dial cares about. Review: https://reviewboard.asterisk.org/r/4336 ASTERISK-24682 #close Reported by: Matt Jordan ........ Merged revisions 430842 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@430843 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
a0cc80d513 |
Call extension state callbacks at hint creation.
When a hint gets created, any subsequent device or presence state changes result in extension status events getting sent out to interested parties. However, at the time of hint creation, no such event gets sent out, so watchers of extension state are potentially left in the dark until the first state change after hint creation. Patch contributed by John Hardin (License #6512) ........ Merged revisions 430776 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@430782 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
446da9177e |
res_pjsip_outbound_registration: Fix race condition when reloading and listing registrations.
Due to the split of outbound registration state from configuration it is possible during a reload for a "pjsip show registrations" CLI command to be executed which gets an older snapshot of the configuration. This configuration may include outbound registrations which have been removed due to a reload operation occurring at the same time. The code for printing the outbound registration did not take this into account but now it does. AST-1506 #close Review: https://reviewboard.asterisk.org/r/4338/ ........ Merged revisions 430664 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@430666 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
316a8a17dc |
Disable extended support modules
git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@430293 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
30b1c42f8b |
contrib/ast-db-manage: Correct down_revision path for user_eq_phone
When the user_eq_phone patch was backported to 13, it referenced the downward revision that the PJSIP optimistic encryption option also references. This creates a multi-path upgrade Exception when generating the SQL files. This patch corrects this in the 13 branch. Note that trunk, which already contained both of these features, is unaffected by this problem. ........ Merged revisions 430252 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@430253 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
fb12aedfa5 |
bridge: avoid leaking channel during blond transfer pt2
A blond transfer to a failed destination, when followed by a recall attempt, lead to a leak of the reference to the destination channel. In addition to correcting the regression on the previous attempt (r429826) this fixes the leak and two additional reference leaks on failures of bridge_import. ASTERISK-24513 #close Review: https://reviewboard.asterisk.org/r/4302/ ........ Merged revisions 430199 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 430200 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@430245 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
76e69500f0 |
res/res_agi: Make Verbose message for 'stream file' match other playbacks
The Verbose message displayed when a file is played back via 'stream file' was formatted differently than other playbacks: * It didn't include the channel name * It didn't include the channel language It does, however, include the playback offset as well as any escape digits. That information was kept; however, this patch updates the formatting to more closely match the Verbose messages displayed when a file is played back by 'control stream file', Playback, ControlPlayback, or any other file playback operation. ........ Merged revisions 429519 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@430094 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
c9af0b8c7e |
res_pjsip: Backport missing commits for user_eq_phone
This backports the following from trunk, which were missed: r427257 | file | 2014-11-04 16:31:16 -0600 (Tue, 04 Nov 2014) | 2 lines res_pjsip: Allow + at the beginning of a phone number when user_eq_phone is enabled. r427259 | file | 2014-11-04 16:51:32 -0600 (Tue, 04 Nov 2014) | 2 lines res_pjsip: Apply the 'user_eq_phone' setting to the To header as well. It also adds the Alembic script for the option. ASTERISK-24643 ........ Merged revisions 430092 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@430093 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |