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 }
26229 Commits (dd4d4e40e57a0013c6861f6441f30eadbd1698c6)
Author | SHA1 | Message | Date |
---|---|---|---|
|
20f50131d7 |
res_pjsip_refer: Prevent sending duplicate headers.
res_pjsip_refer will attempt to add Referred-By or Replaces headers to outbound INVITEs at times. If the INVITE gets challenged for authentication, then we will resend the INVITE. Prior to this patch, the Referred-By or Replaces header would be re-added to the outbound INVITE, resulting in duplicated headers. ASTERISK-25204 #close Reported by Mark Michelson Change-Id: I59fb5c08b4d253c0dba9ee3d3950b5025358222d |
10 years ago |
|
3ba48755c8 |
Merge "AMI: Add Linkedid to the standard channel snapshot AMI event headers." into certified/13.1
|
10 years ago |
|
0d535df734 |
res_pjsip_nat: Rewrite route set when required.
When performing some provider testing, the rewrite_contact option was interfering with proper construction of a route set when sending an ACK after receiving a 200 OK response to an INVITE. The initial INVITE was sent to address sip:foo. The 200 OK had a Contact header with URI sip:bar. In addition, the 200 OK had Record-Route headers for sip:baz and sip:foo, in that order. Since the Record-Route headers had the lr parameter, the result should have been: * Set R-URI of the ACK to sip:bar. * Add Route headers for sip:foo and sip:baz, in that order. However, the rewrite_contact option resulted in our rewriting the Contact header on the 200 OK to sip:foo. The result was: * R-URI remained sip:foo. * We added Route headers for sip:foo and sip:baz, in that order. The result was that sip:bar was not indicated in the ACK at all, so the far end never received our ACK. The call eventually dropped. The intention of rewrite_contact is to rewrite the most immediate destination of our SIP request to be the same address on which we received a request or response. In the case of processing a SIP response with Record-Route headers, this means that instead of rewriting the Contact header, we should instead rewrite the bottom-most Record-Route header. In the case of processing a SIP request with Record-Route headers, this means we rewrite the top-most Record-route header. Like when we rewrite the Contact header, we also ensure to update the dialog's route set if it exists. ASTERISK-25196 #close Reported by Mark Michelson Change-Id: I9702157c3603a2d0bd8a8215ac27564d366b666f |
10 years ago |
|
3332869b48 |
AMI: Add Linkedid to the standard channel snapshot AMI event headers.
ASTERISK-25189 #close Reported by: John Hardin Change-Id: I2b1778c3fdc1dca0ed55db4e3a639eddfb16c2ac |
10 years ago |
|
a35d6feae2 |
res_pjsip_mwi: Set up unsolicited MWI upon registration.
The res_pjsip_mwi previously required a reload to set up the proper subscriptions to allow unsolicited MWI to work. This change makes it so the act of registering will also cause this to occur. This is particularly useful if realtime is involved as no reload needs to occur within Asterisk to cause the MWI information to get sent. ASTERISK-25180 #close Change-Id: Id847b47de4b8b3ab8858455ccc2f07b0f915f252 |
10 years ago |
|
3e3ea112c6 |
Merge "bridge: When performing a blonde transfer update connected line information." into certified/13.1
|
10 years ago |
|
75589c4a3b |
bridge: When performing a blonde transfer update connected line information.
When performing a blonde transfer the code uses the old masquerade mechanism to move a channel around. As a result of this certain information, such as connected line, is moved between the channels involved. Upon completion of the move a frame is queued which is supposed to update the connected line information on the channel. This does not occur as the code considers it a redundant update since the masquerade operation updated the channel (but did not inform it of the new connected line information). The code also does not queue a connected line update to be handled by the thread handling the channel. Without this any other channel that may be loosely involved does not know it is talking to a different caller. This change does the following to resolve this: 1. The indicated connected line information is cleared upon completion of the masquerade operation when doing a blonde transfer. This prevents the connected line update from being considered redundant. 2. A connected line update frame is now queued upon the completion of the masquerade operation so any other channel loosely involved knows that there is a different caller. ASTERISK-25157 #close Reported by: Joshua Colp Change-Id: Ibb8798184a1dab3ecd35299faecc420034adbf20 |
10 years ago |
|
8142b922ab |
app_directory: Fix crash when using the alias option 'a'.
The voicemail.conf mailbox key/value pair is defined as: <mailbox>=[<password>[,<full-name>[,<email>[,<pager>[,<options>]]]]] Where all fields in the value including the field values are optional. Since the parsing code for the mailbox key/value pair is sloppy, this patch tightens the parsing for the directory information. * Renamed the 'pos' and 'bufptr' variables to 'name' and 'options' respectively in search_directory_sub(). Those names make more sense. * Made sure that search_directory_sub() is dealing with the voicemail.conf mailbox options field if it even exists when looking for the 'hidefromdir' and 'alias' options. * Fix crash if a voicemail.conf mailbox is just <mailbox>=<password>,<name> when the 'a' option is used. If there were no fields after the name then the 'options' pointer was not checked for NULL. * Fix users.conf alias processing if the 'a' option is used. The wrong variable was used. ASTERISK-25087 #close Reported by: Chet Stevens Change-Id: I86052ea77307beddddba5279824d39dc0d593374 |
10 years ago |
|
2e04bc2e6d |
Merge "AMI: Escape string values." into certified/13.1
|
10 years ago |
|
ca2174bb23 |
.version: Update for certified/13.1-cert3-rc1
|
10 years ago |
|
2ef2c12fae |
.lastclean: Update for certified/13.1-cert3-rc1
|
10 years ago |
|
5032390639 |
realtime: Add database scripts for certified/13.1-cert3-rc1
|
10 years ago |
|
2bf6fd263a |
AMI: Escape string values.
So this issue is a bit complicated. Since it is possible to pass values to AMI that contain a '\r\n' (or other similar sequences) these values need to be escaped. One way to solve this is to escape the values and then pass the escaped values to the AMI variable parameter string building function. However, this puts the onus on the pre-build function to escape all string values. This potentially requires a fair amount of changes along with a lot of string allocations/freeing for all values. Surely there is a way to push this complexity down a level into the string building function itself? This of course is possible, but ends up requiring a way to distinguish between strings that need to be escaped and those that don't. The best way to handle this is by introducing a new format specifier in the format string. For instance a %s (no escape) and %S (escape). However, that is a bit weird and unexpected. So faced with those possibilities this patch implements a limited version of the first option. Instead of attempting to escape all string values this patch only escapes those values that make sense. This approach limits the number of changes and doesn't suffer from the odd format specifier problem. ASTERISK-24934 #close Reported by: warren smith Change-Id: Ib55a5b84fe0481b0f2caaaab68c566f392c0aac0 |
10 years ago |
|
5f954e1e00 |
res_pjsip: Prevent access of NULL channels.
It is possible to receive incoming requests or responses after the channel on an ast_sip_session has been destroyed and NULLed out. Handlers of these sorts of requests or responses need to be prepared for the possibility that the channel is NULL or else they could cause a crash. While several places have been amended to deal with NULL channels, there were still a couple of places that needed updating. res_pjsip_dtmf_info.c: When handling incoming INFO requests, we need to return early if there is no channel on the session. res_pjsip_session.c: When handling a 302 response, we need to stop the redirecting attempt if there is no channel on the session. ASTERISK-25148 #close reported by Mark Michelson Change-Id: Id1a75ffc3d0eaa168b0b28188fb54d6cf9fc47a9 |
10 years ago |
|
c994a3bfa0 |
res_pjsip_refer: Fix crash from a REFER and BYE collision.
Analyzing a one-off crash on a busy system showed that processing a REFER request had a NULL session channel pointer. The only way I can think of that could cause this is if an outgoing BYE transaction overlapped the incoming REFER transaction in a collision. Asterisk sends a BYE while the phone sends a REFER to complete an attended transfer. * Made check the session channel pointer before processing an incoming REFER request in res_pjsip_refer. * Fixed similar crash potential for res_pjsip supplement incoming request processing for res_pjsip_sdp_rtp INFO, res_pjsip_caller_id INVITE/UPDATE, res_pjsip_messaging MESSAGE, and res_pjsip_send_to_voicemail REFER messages. * Made res_pjsip_messaging respond to a message body too large with a 413 instead of ignoring it. ASTERISK-24700 #close Reported by: Zane Conkle Review: https://reviewboard.asterisk.org/r/4417/ ........ Merged revisions 431898 from http://svn.asterisk.org/svn/asterisk/branches/13 Change-Id: I57878adc0846dd942a699ad36dcec9cba5e57994 |
10 years ago |
|
a159e08d15 |
Merge "res_pjsip_session: Fix in-dialog authentication." into certified/13.1
|
10 years ago |
|
1e98fcac6b |
res_pjsip: config option 'timers' can't be set to 'no'
When setting the configuration option 'timers' equal to 'no' the bit flag was not properly negated. This patch clears all associated flags and only sets the specified one. pjsip will handle any necessary flag combinations. Also went ahead and did similar for the '100rel' option. ASTERISK-24910 #close Reported by: Ray Crumrine Review: https://reviewboard.asterisk.org/r/4582/ ........ Merged revisions 434131 from http://svn.asterisk.org/svn/asterisk/branches/13 Change-Id: Ibbc25d4592aabf7596ef473447d630961f88c217 |
10 years ago |
|
bd32327353 |
res_pjsip_session: Fix in-dialog authentication.
When the remote peer requires authentication for in-dialog requests then re-INVITEs to the peer cause the call to be disconnected and other in-dialog requests to the peer like MESSAGE just don't go through. * Made session_inv_on_tsx_state_changed() handle in-dialog authentication for re-INVITEs and other methods. Initial INVITEs cannot be handled here because the INVITE transaction must be restarted earlier. * Pulled needed code from res/res_pjsip/pjsip_outbound_auth.c in preparation for removing the file. The generic outbound authentication code did not work as well as anticipated. * Created outbound_invite_auth() to only handle initial outbound INVITEs. Re-INVITEs cannot be handled here. The re-INVITE transaction is still in progress and the PJSIP library cannot handle the overlapping INVITE transactions. Other method types should not be handled here as this code only works on outgoing calls and we need to handle incoming and outgoing calls. ASTERISK-25131 #close Reported by: Richard Mudgett Change-Id: I12bdd7ddccc819b4ce4b091e826d1e26334601b0 |
10 years ago |
|
b81353a0ec |
app_voicemail: fix moving when old messages full
When completing voicemail playback of a message in the 'INBOX', the message gets moved to the 'Old' messages folder. Without this patch, if the 'Old' folder is already at its set limit, then the 'INBOX' message will simply be deleted. With this patch, the flag to delete the message will be removed if the save_to_folder function indicates that the message could not be moved due to a full folder. ASTERISK-25082 #close Reported by: Jonathan Rose Review: https://gerrit.asterisk.org/#/c/448/ Change-Id: I2be440a09f42e2d06d50975c40d1ad7f836ecb3f |
10 years ago |
|
523fab02d8 |
chan_dahdi/sig_pri: Fix crash on ISDN call hangup collision.
If an ISDN call is hungup by both sides at the same time a crash could happen. * Added missing NULL checks for the owner channel after calling pri_queue_pvt_cause_data() in two places. Code after those calls need to check the owner channel pointer for NULL before use because pri_queue_pvt_cause_data() needs to do deadlock avoidance to lock the owner and the owner may get hung up. ASTERISK-21893 #close Reported by: Alexandr Gordeev Change-Id: Ica3e266ebc7a894b41d762326f08653e1904bb9a |
10 years ago |
|
dd1363a510 |
Merge "bridge.c: NULL app causes crash during attended transfer" into certified/13.1
|
10 years ago |
|
b764454d4d |
bridge.c: NULL app causes crash during attended transfer
Due to a race condition there was a chance that during an attended transfer the channel's application would return NULL. This, of course, would cause a crash when attempting to access the memory. This patch retrieves the channel's app at an earlier time in processing in hopes that the app name is available. However, if it is not then "unknown" is used instead. Since some string value is now always present the crash can no longer occur. ASTERISK-24869 #close Reported by: viniciusfontes Review: Change-Id: I5134b84c4524906d8148817719d76ffb306488ac |
10 years ago |
|
6433b697ae |
res_pjsip_exten_state: Fix race condition between sending NOTIFY and termination
The res_pjsip_exten_state module currently has a race condition between processing the extension state callback from the PBX core and processing the subscription shutdown callback from res_pjsip_pubsub. There is currently no synchronization between the two. This can present a problem as while the SIP subscription will remain valid the tree it points to may not. This is in particular a problem as a task to send a NOTIFY may get queued which will try to use the tree that may no longer be valid. This change does the following to fix this problem: 1. All access to the subscription tree is done within the task that sends the NOTIFY to ensure that no other thread is modifying or destroying the tree. This task executes on the serializer for the subscriptions. 2. A reference to the subscription serializer is kept to ensure it remains valid for the lifetime of the extension state subscription. 3. The NOTIFY task has been changed so it will no longer attempt to send a NOTIFY if the subscription has already been terminated. ASTERISK-25057 #close Reported by: Matt Jordan Change-Id: I0b3cd2fac5be8d9b3dc5e693aaa79846eeaf5643 |
10 years ago |
|
5602fc3e2e |
Merge "res_pjsip / res_pjsip_multihomed: Use the correct transport and addressing information on UAS sessions." into certified/13.1
|
10 years ago |
|
bf31a486cb |
res_pjsip / res_pjsip_multihomed: Use the correct transport and addressing information on UAS sessions.
The first thing this patch fixes is UAS dialogs. Previously if a transport was configured on an endpoint and an inbound session was created there was no guarantee that requests sent on the dialog would use the correct transport and address information. This has now been fixed so an explicitly configured transport is taken into account. The second thing this patch fixes is res_pjsip_multihomed. The res_pjsip_multihomed module attempts to determine what transport a message should go out on and what addressing information should go into the message itself. In a scenario where multiple transports exist bound to the same IP address but a different port the code would incorrectly alter the transport and change the message to the wrong transport. This change makes the res_pjsip_multihomed module smarter so it will only change the transport and address information in the message when it is possible and makes sense. ASTERISK-24615 #close Reported by: David Justl Change-Id: I5b57362201cc8c6555834ec8707e9fbddeff7904 |
10 years ago |
|
7c687c8e54 |
stasis: Fix dial masquerade datastore lifetime
A recent change went into Asterisk which added reference counts to the channels stored in a dial masquerade datastore. Unfortunately this included a reference to the caller in a dialing operation. While all of the dialed targets have the datastore removed from them upon dialing completion this did not occur for the caller, causing it to have a reference to itself that could go never go away (as it depended on the destruction of the datastore which only happened when the channel was destroyed). This resulted in the caller channel remaining on the system despite it having hung up. This change does the following to fix this issue: 1. The dial masquerade datastore is now removed from the caller upon dialing completion, just like the dialed targets. 2. Upon destruction of the caller all the dialed targets are also removed from the dial masquerade datastore (just in case). 3. The reference to the caller has been removed as it should not be possible for the datastore to now be valid/useful after the lifetime of the caller has ended. ASTERISK-25025 #close Change-Id: I1ef4ca5ca04980028604cc2af5d2992ac3431b3f |
10 years ago |
|
0602409c89 |
chan_dahdi: Add the chan_dahdi.conf force_restart_unavailable_chans option.
Some telco switches occasionally ignore ISDN RESTART requests. The fix for ASTERISK-19608 added an escape clause for B channels in the restarting state if the telco ignores a RESTART request. If the telco fails to acknowledge the RESTART then Asterisk will assume the telco acknowledged the RESTART on the second call attempt requesting the B channel by the telco. The escape clause is good for dealing with RESTART requests in general but it does cause the next call for the restarting B channel to be rejected if the telco insists the call must go on that B channel. chan_dahdi doesn't really need to issue a RESTART request in response to receiving a cause 44 (Requested channel not available) code. Sending the RESTART in such a situation is not required (nor prohibited) by the standards. I think chan_dahdi does this for historical reasons to deal with buggy peers to get channels unstuck in a similar fashion as the chan_dahdi.conf resetinterval option. * Add the chan_dahdi.conf force_restart_unavailable_chans compatability option that when disabled will prevent chan_dahdi from trying to RESTART the channel in response to a cause 44 code. ASTERISK-25034 #close Reported by: Richard Mudgett Change-Id: Ib8b17a438799920f4a2038826ff99a1884042f65 |
10 years ago |
|
561f89b693 |
Merge "res_pjsip_outbound_authenticator_digest: Add missing outbound authenticator callback." into certified/13.1
|
10 years ago |
|
c6c06bbe70 |
Prevent potential crash on blond transfer.
Scenario: Alice calls Bob. Bob performs a blond transfer to Carol. Carol rejects the incoming call (or some other immediate circumstance causes Carol not to answer the call) What occurs in this case is that when the bridge between Alice and Bob breaks, Alice is told to masquerade into Bob's channel that had placed the call to Carol. The actual masquerade goes down without a hitch. However, a channel fixup callback that attempts to publish dial events over Stasis has a crash. The reason for this crash is that the datastore on Bob's channel that placed the outbound call to Carol only had a bare pointer to Carol's channel. Since Carol rejected the incoming call, Carol's channel has been hung up and freed, meaning accessing her channel results in a crash. The fix here is simple. The dial fixup code has been altered to hold references to the involved channels and to drop those references when freeing data. ASTERISK-25025 #close Reported by Chet Stevens Change-Id: I54eedda207b8ec7a69263353b43abe5746aea197 |
10 years ago |
|
08a4cf3237 |
res_pjsip_outbound_authenticator_digest: Add missing outbound authenticator callback.
The Asterisk 13 version of the fix for outbound registration was missing a key component that set the outbound authenticator's callback that creates an authenticated request based on an old request. This was picked up by some outbound registration tests failing in the testsuite. Change-Id: I5ca9379698c606da36bc38eaffccedaf64211ce3 |
10 years ago |
|
47df4e031c |
res_pjsip_outbound_registration: Fix double unref on error return.
When the PJSIP pjsip_regc_send function is invoked and an error status returned the caller currently decrements the reference count of the client state that it just incremented, assuming the registration callback would not have been invoked. In practice this is not correct. If the failure happens after the transaction has been set up the callback will still be invoked. This will cause the reference count to be incorrectly decremented twice, once by the registration callback and second by the caller of pjsip_regc_send. This change makes it so that whether the callback is invoked or not is known by the caller of pjsip_regc_send. Depending on this it can know whether it is responsible for decrementing the reference count of the client state or not. ASTERISK-25037 #close Reported by: Joshua Colp Change-Id: I749dc12f3a22115c49c5d7d95ff42a5fa45319de |
10 years ago |
|
11d85ea251 |
res_pjsip_outbound_registration: Don't fail on delayed processing: 13.
This is the Asterisk 13 version of a change to master that allows for registration responses to be processed successfully potentially after the original transaction has timed out. The main difference between this and the master change is that the master version has API changes that are unacceptable for 13. For 13, this is worked around by adding a new API call that the outbound registration code uses instead. The following is the text from the master version of this commit: Odd behaviors have been observed during outbound registrations. The most common problem witnessed has been one where a request with authentication credentials cannot be created after receiving a 401 response. Other behaviors include apparently processing an incorrect SIP response. Inspecting the code led to an apparent issue with regards to how we handle transactions in outbound registration code. When a response to a REGISTER arrives, we save a pointer to the transaction and then push a task onto the registration serializer. Between the time that we save the pointer and push the task, it's possible for the transaction to be destroyed due to a timeout. It's also possible for the address to be reused by the transaction layer for a new transaction. To allow for authentication of a REGISTER request to be authenticated after the transaction has timed out, we now also hold a reference to the original REGISTER request instead of the transaction. The function for creating a request with authentication has been altered to take the original request instead of the transaction where the original request was sent. ASTERISK-25020 Reported by Mark Michelson Change-Id: If1ee5f601be839479a219424f0358a229f358f7c |
10 years ago |
|
0037ca59a6 |
res_pjsip_outbound_registration: Add debugging messages.
When problems occur regarding outbound registrations, it currently is difficult to debug. Most off-nominal paths had warning messages, but sometimes we want to know what's going on before hitting the off-nominal path. This patch adds lots of debugging output that should give a clearer picture of what is happening with regards to outbound registrations. ASTERISK-25020 Reported by Mark Michelson Change-Id: I577bde7860be0a6c872b5bcb4d5047340bf45d45 |
10 years ago |
|
f9b6336528 |
Merge "res_pjsip_t38: Don't crash on authenticated reinvite after originated T.38 FAX." into certified/13.1
|
10 years ago |
|
e84fcb2464 |
res/res_pjsip_t38: Add missing initialization of t38faxmaxdatagram
Prior to this patch, the far_max_datagram value on the UDPTL structure would remain -1 if the remote endpoint fails to provide the SDP media attribute T38FaxMaxDatagram. This can result in the INVITE request being rejected. With this patch, we will now properly initialize the value with either the default value or with the value provided by pjsip.conf's t38_udptl_maxdatagram parameter. Review: https://reviewboard.asterisk.org/r/4589 ASTERISK-24928 #close Reported by: Juergen Spies Tested by: Juergen Spies patches: pjsipT38patch20150331.txt submitted by Juergen Spies (License 6698) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434688 65c4cc65-6c06-0410-ace0-fbb531ad65f3 Change-Id: I15bde169fd59a224a02005fec9a439f0679a375e |
10 years ago |
|
008076ecf4 |
res_pjsip_t38: Don't crash on authenticated reinvite after originated T.38 FAX.
When Asterisk originates a channel to an application, the channel is hung up once the application finishes executing. When the application in question is SendFax, the Asterisk PJSIP code will attempt to reinvite the T.38 session to audio after the FAX completes. The hangup of the channel happens in the midst of this reinvite transaction. In most circumstances, this works out okay because the BYE is delayed until the reinvite transaction can complete. However, if the reinvite that Asterisk sends receives a 401/407 response, then Asterisk's attempt to re-send the reinvite with authentication will fail. This is because the session supplement in res_pjsip_t38 makes the assumption that the channel on the session will always be non-NULL. Since the channel has been hung up, though, the channel is now NULL. Attempting to operate on the channel causes a crash. This patch fixes the issue by ensuring that the channel on the session is not NULL before attempting to mess with the T.38 framehook. This patch also contains some corrections for comments that were incorrect and really confused me when I first started looking at the code. ASTERISK-25004 #close Reported by Mark Michelson Change-Id: Ic5a1230668369dda4bb13524098aed9306ab45a0 |
10 years ago |
|
d7e82690f1 |
Merge topic 'certified-13.1' into certified/13.1
* changes: Detect potential forwarding loops based on count. More .gitignore updates .gitignore updates for master/13 |
10 years ago |
|
689a251ab5 |
Merge "build_tools/make_version: Update version parsing for Git migration" into certified/13.1
|
10 years ago |
|
c5bb6e207f |
Merge "git migration: Remove support for file versions" into certified/13.1
|
10 years ago |
|
6bf92934a1 |
Merge topic 'certified-13.1' into certified/13.1
* changes: main/editline: Add .gitignore. .gitignore: Ignore tarballs (*.gz) |
10 years ago |
|
f698b71275 |
Merge "Add .gitignore and .gitreview files" into certified/13.1
|
10 years ago |
|
1bb6122f35 |
Detect potential forwarding loops based on count.
A potential problem that can arise is the following: * Bob's phone is programmed to automatically forward to Carol. * Carol's phone is programmed to automatically forward to Bob. * Alice calls Bob. If left unchecked, this results in an endless loops of call forwards that would eventually result in some sort of fiery crash. Asterisk's method of solving this issue was to track which interfaces had been dialed. If a destination were dialed a second time, then the attempt to call that destination would fail since a loop was detected. The problem with this method is that call forwarding has evolved. Some SIP phones allow for a user to manually forward an incoming call to an ad-hoc destination. This can mean that: * There are legitimate use cases where a device may be dialed multiple times, or * There can be human error when forwarding calls. This change removes the old method of detecting forwarding loops in favor of keeping a count of the number of destinations a channel has dialed on a particular branch of a call. If the number exceeds the set number of max forwards, then the call fails. This approach has the following advantages over the old: * It is much simpler. * It can detect loops involving local channels. * It is user configurable. The only disadvantage it has is that in the case where there is a legitimate forwarding loop present, it takes longer to detect it. However, the forwarding loop is still properly detected and the call is cleaned up as it should be. Address review feedback on gerrit. * Correct "mfgium" to "Digium" * Decrement max forwards by one in the case where allocation of the max forwards datastore is required. * Remove irrelevant code change from pjsip_global_headers.c ASTERISK-24958 #close Change-Id: Ia7e4b7cd3bccfbd34d9a859838356931bba56c23 |
10 years ago |
|
cb67aae596 |
More .gitignore updates
Added .pyc and .sha1 to the top-level .gitignore. Change-Id: I7dfc4f554d54d22947b38140d3305007503cc16a Tested-by: George Joseph <george.joseph@fairview5.com> |
10 years ago |
|
70fab74baf |
.gitignore updates for master/13
Added products of ./bootstrap Added nmenuselect and gmenuselect to menuselect/ Change-Id: Ied658463958bafc04a9aff9ebc28e40c116a6e35 |
10 years ago |
|
735bea479a |
build_tools/make_version: Update version parsing for Git migration
External systems - such as the Asterisk Test Suite - require knowledge of the upstream branch. Unfortunately, after moving to Git, the Asterisk version currently consists of only a 'GIT" prefix followed by an object blob, e.g., GIT-as08d7. This makes it difficult for such systems to know what features are available in a particular check out of Asterisk. This patch fixes this by hardcoding the branch in a variable in the make_version script. Since the mainline branches are not changed often - typically only once a year - this is a reasonable approach to solving the problem, and is more reliable than parsing the output of 'git branch -vv'. Branches that track off of an upstream primary branch will then get the benefit of knowing which mainline branch they are currently based off of. ASTERISK-24954 #close Change-Id: I8090d5d548b6d19e917157ed530b914b7eaf9799 |
10 years ago |
|
7d64479748 |
git migration: Remove support for file versions
Git does not support the ability to replace a token with a version string during check-in. While it does have support for replacing a token on clone, this is somewhat sub-optimal: the token is replaced with the object hash, which is not particularly easy for human consumption. What's more, in practice, the source file version was often not terribly useful. Generally, when triaging bugs, the overall version of Asterisk is far more useful than an individual SVN version of a file. As a result, this patch removes Asterisk's support for showing source file versions. Specifically, it does the following: * main/asterisk: - Refactor the file_version structure to reflect that it no longer tracks a version field. - Alter the "core show file version" CLI command such that it always reports the version of Asterisk. The file version is no longer available. * main/manager: The Version key now always reports the Asterisk version. * UPGRADE: Add notes for: - Modification to the ModuleCheck AMI Action. - Modification of the "core show file version" CLI command. Change-Id: Ia932d3c64cd18a14a3c894109baa657ec0a85d28 |
10 years ago |
|
9237e8b11e |
main/editline: Add .gitignore.
This patch adds a .gitignore for main/editline to ignore all build results. Change-Id: I68c7bf375ea46282689e5a706534b69fca233b5d |
10 years ago |
|
630dbcb8b4 |
.gitignore: Ignore tarballs (*.gz)
This patch updates the root .gitignore file to ignore files with a .gz extension. This will cause git to ignore downloaded sound tarballs in the the sounds/ directory. Change-Id: I1e42fbfa02a8884231507b683e8e49ac3e278aaa |
10 years ago |
|
e4892f9aa4 |
Add .gitignore and .gitreview files
Add the .gitignore and .gitreview files to the asterisk repo. NB: You can add local ignores to the .git/info/exclude file without having to do a commit. Common ignore patterns are in the top-level .gitignore file. Subdirectory-specific ignore patterns are in their own .gitignore files. Change-Id: I4c8af3b8e3739957db545f7368ac53f38e99f696 Tested-by: George Joseph |
10 years ago |
|
677898f839 |
res_pjsip_mwi: Send unsolicited MWI NOTIFY on startup and when endpoint registers.
Currently the res_pjsip_mwi module only sends an unsolicited MWI NOTIFY upon a mailbox state change (such as a new message being left, or one being deleted). In practice this is not sufficient to keep clients aware of the current MWI status. This change makes the module send unsolicited MWI NOTIFY on startup so that clients are guaranteed to have the most up to date MWI information. It also makes clients receive an unsolicited MWI NOTIFY upon registration so if they are unaware of the current MWI status they receive it. ASTERISK-24982 #close Reported by: Joshua Colp Change-Id: I043f20230227e91218f18a82c7d5bb2aa62b1d58 |
10 years ago |