mirror of https://github.com/asterisk/asterisk
master
22
20
21
releases/22
releases/21
releases/20
certified/18.9
certified/20.7
18
releases/certified-20.7
releases/certified-18.9
releases/18
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.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 }
4994 Commits (1.4)
Author | SHA1 | Message | Date |
---|---|---|---|
|
656d2e043a |
Default to nat=yes; warn when nat in general and peer differ
It is possible to enumerate SIP usernames when the general and user/peer nat settings differ in whether to respond to the port a request is sent from or the port listed for responses in the Via header. In 1.4 and 1.6.2, this would mean if one setting was nat=yes or nat=route and the other was either nat=no or nat=never. In 1.8 and 10, this would mean when one was nat=force_rport and the other was nat=no. In order to address this problem, it was decided to switch the default behavior to nat=yes/force_rport as it is the most commonly used option and to strongly discourage setting nat per-peer/user when at all possible. For more discussion of the issue, please see: http://lists.digium.com/pipermail/asterisk-dev/2011-November/052191.html (closes issue ASTERISK-18862) Review: https://reviewboard.asterisk.org/r/1591/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@345776 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
1bca16589d |
Don't leak SIP username information
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@325275 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
9bc8ac021e |
Addresses AST-2011-010, remote crash in IAX2 driver
Thanks to twilson for identifying the issue and providing the patches. AST-2011-010 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@324627 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
847e704100 |
unlock pvt when we drop voice frames received in early media when in t.38 mode
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@322698 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
f6d89f46b1 |
whitespace
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@322657 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
9ed0888605 |
don't drop any voice frames when checking for T.38 during early media
(closes issue ASTERISK-17705) Review: https://reviewboard.asterisk.org/r/1186/ patch by oej reported by oej git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@322646 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
a93fce4278 |
chan_sip: Destroy variables on a sip_pvt before copying vars from the sip_peer.
(closes issue #19202) Reported by: wdoekes Patches: issue19202_destroy_challenged_invite_chanvars.patch uploaded by wdoekes (license 717) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@320055 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
a5819437ae |
Make sure everyone gets an unhold when a transfer succeeds
Some phones, like the Snom phones, send a hold to the transfer target after before sending the REFER. We need to make sure that we unhold the parties that are being connected after the masquerade. If Local channels with the /nm option are used when dialing the parties, hold music would still be playing on the transfer target, even after being connected with the transferee. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@319652 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
2f024e4544 |
Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 * The applicable fixes for v1.4 are the SIP deadlock and the in progress masquerade check for multiple parties trying to pickup the same call. issue18654_v1.4.patch uploaded by rmudgett (license 664) * Backported to v1.6.2. issue18654_v1.6.2.patch uploaded by rmudgett (license 664) ........ r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines Fix directed group pickup feature code *8 with pickupsounds enabled Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues. 1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked. 2). dialplan applications for directed_pickups shouldn't beep. 3). feature code for directed pickup should beep on success/failure if configured. Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite. Moved app_directed:pickup_do() to features:ast_do_pickup(). Functions below, all now use the new ast_do_pickup() app_directed_pickup.c: pickup_by_channel() pickup_by_exten() pickup_by_mark() pickup_by_part() features.c: ast_pickup_call() (closes issue #18654) Reported by: Docent Patches: ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585) Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett Review: https://reviewboard.asterisk.org/r/1185/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@318734 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
bdf971df60 |
Regression after r297603 (Improve handling of REGISTER requests with multiple contact headers.)
Uninitialized variable. (issue #18640) (closes issue #18785) Reported by: pnlarsson Patches: issue18785_enegaard.patch uploaded by enegaard (license 1197) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@317719 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
b2ad693b90 |
chan_sip: fix broken realtime peer count, fix memory leak
This patch addresses two bugs in chan_sip: 1) The count of realtime peers and users was off. The increment checked the value of the caching option, while the decrement did not. 2) Add a missing regfree() for a regex. (closes issue #19108) Reported by: vrban Patches: missing_regfree.patch uploaded by vrban (license 756) sip_object_counter.patch uploaded by vrban (license 756) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@317211 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
806fef4ef5 |
Fixes chan_local crashs in local_fixup()
Thanks OEJ for tracking down the issue and submitting the patch. (closes issue #19053) Reported by: oej Tested by: oej Review: https://reviewboard.asterisk.org/r/1158/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@316328 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
17ca06cdb8 |
Partial revert of r315671 which removed a logging statement and not a manager event.
Reported by ibercom in #asterisk-bugs. (issue #16033) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@315989 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
acfd6d4bad |
Fix our compliance with RFC 3261 section 18.2.2.
This change optimizes the free_via() function and removes some redundant null checking. It also fixes compliance with RFC 3261 section 18.2.2 by always using the port specified in the Via header for routing responses (even when maddr is not set). Also the htons() function is now used when setting the port. Additional documentation comments have been added in various places to make the logic in the code clearer. (closes issue #18951) Reported by: jmls Patches: issue18951_set_proper_port_from_via.patch uploaded by wdoekes (license 717) (modified) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@315891 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
a851a4834f |
Make sure unregistering a peer unlinks it from the peer container
Instead of mostly copying the code from expire_register, just use the function that "does the right thing". (closes issue #16033) Reported by: kkm Patches: 016033-tilgman-fixed-refcount.diff uploaded by kkm (license 888) Tested by: kkm, tilghman, twilson git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@315671 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
b3d58b6260 |
chan_local:check_bridge() misplaced misplaced ast_mutex_unlock
if !p->chan->_bridge->_softhangup path isn't followed, brigde remains locked. (closes issue #19176) Reported by: alecdavis Patches: bug19176.diff.txt uploaded by alecdavis (license 585) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@315051 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
1cfde1088c |
Prevent the login thread and the app threads from using the asterisk channel at the same time.
ABE-2756 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@314908 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
9bd88702b7 |
Added limits to the number of unauthenticated sessions TCP based protocols are allowed to have open simultaneously. Also added timeouts for unauthenticated sessions where it made sense to do so.
Unrelated, the manager interface now properly checks if the user has the "system" privilege before executing shell commands via the Originate action. AST-2011-005 AST-2011-006 (closes issue #18787) Reported by: kobaz (related to issue #18996) Reported by: tzafrir git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@314607 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
afbfce2971 |
Stuck channel using FEATD_MF if caller hangs up at the right time.
The cause was actually a caller hanging up just at the end of the Feature Group D DTMF tones that setup the call. The reason for this is a "guard timer" that's implemented using ast_safe_sleep(100). If the caller happens to hang up AFTER the final tone of the DTMF string but BEFORE the end of that ast_safe_sleep(), then ast_safe_sleep() will return non-zero. This causes the code to bounce to the end of ss_thread(), but it does NOT tear down the call properly. This should be a rare occurrence because the caller has to hang up at EXACTLY the right time. Nonetheless, it was happening quite regularly on the reporter's system. It's not easily reproducible, unless you purposely increase the guard-time to 2000 or more. Once you do that, you can reproduce it every time by watching the DTMF debug and hanging up just as it ends. Simply add an ast_hangup() before goto quit. (closes issue #15671) Reported by: jcromes Patches: issue15671.patch uploaded by pabelanger (license 224) Tested by: jcromes git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@313188 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
cd24c868cb |
Issues with ISDN calls changing B channels during call negotiations.
The handling of the PROCEEDING message was not using the correct call structure if the B channel was changed. (The same for PROGRESS.) The call was also not hungup if the new B channel is not provisioned or is busy. * Made all call connection messages (SETUP_ACKNOWLEDGE, PROCEEDING, PROGRESS, ALERTING, CONNECT, CONNECT_ACKNOWLEDGE) ensure that they are using the correct structure and B channel. If there is any problem with the operations then the call is now hungup with an appropriate cause code. * Made miscellaneous messages (INFORMATION, FACILITY, NOTIFY) find the correct structure by looking for the call and not using the channel ID. NOTIFY is an exception with versions of libpri before v1.4.11 because a call pointer is not available for Asterisk to use. * Made all hangup messages (DISCONNECT, RELEASE, RELEASE_COMPLETE) find the correct structure by looking for the call and not using the channel ID. (closes issue #18313) Reported by: destiny6628 Tested by: rmudgett JIRA SWP-2620 (closes issue #18231) Reported by: destiny6628 Tested by: rmudgett JIRA SWP-2924 (closes issue #18488) Reported by: jpokorny JIRA SWP-2929 JIRA AST-437 (The issues fixed here are most likely causing this JIRA issue.) JIRA DAHDI-406 JIRA LIBPRI-33 (Stuck resetting flag likely fixed) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@312573 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
c0e4bdd609 |
Don't hold the pvt lock while streaming a file.
ABE-2756 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@311203 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
5510659c1f |
Remove the provisional keepalive scheduler entry's reference to the pvt when we remove the scheduler entry.
ABE-2756 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@311199 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
212f41ddf3 |
Reentrancy problem if outgoing call gets different B channel than requested.
The chan_dahdi pri_fixup_principle() routine needs to protect the Asterisk channel with the channel lock when it changes the technology private pointer to a new private structure. * Added lock protection while pri_fixup_principle() moves a call from one private structure to another. * Made some pri_fixup_principle() messages more meaningful. Partial backport from v1.8 -r300714. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@307623 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
9b490b1adc |
Fix comparison for REFER Replaces tags with pedantic=yes
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@306972 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
c80738307a |
Don't allow a REFER w/replaces to replace its own dialog
Asterisk currently accepts a REFER with a Refer-To with an embedded Replaces header that matches the dialog of the REFER. This would be a situation like A calls B, A calls C, A transfers B to A, which is just silly. This patch makes the transfer fail instead of making Asterisk freak out and forget to hang other channels up. Review: https://reviewboard.asterisk.org/r/1093/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@306617 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
a5955e4b8f |
Set hangup cause in local_hangup
When a call involves a local channel (like SIP -> Local -> SIP), the hangup cause was not being set. This resulted in SIP channels sometimes getting a 503 error instead of a 486 when the far side sent a busy. In Asterisk 1.8+ this also can cause issues with CCSS that involve a local channel. This patch sets the hangupcause for one side of the local channel to the other in local_hangup for outbound calls. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@306119 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
9fe4bc60b5 |
Minor AST_FRAME_TEXT related issues.
* Include the null terminator in the buffer length. When the frame is queued it is copied. If the null terminator is not part of the frame buffer length, the receiver could see garbage appended onto it. * Add channel lock protection with ast_sendtext(). git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@305888 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
46d7f5d734 |
Obtain the pri lock for PRI queue counters.
Need to obtain the pri lock when calling pri_dump_info_str() to avoid a reentrancy problem when calculating the Q.921 Q count statistic. JIRA AST-484 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@305341 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
e03c6ed738 |
Prevent a crash when dialing a technology with no destination (ex: Dial(SIP/))
chan_iax2 and other channel drivers already had code to prevent this. The attempt that app_dial was making to prevent it was not correct, so I fixed that. (closes issue #18371) Reported by: gbour Patches: 18371.patch uploaded by gbour (license 1162) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@305252 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
0e62797165 |
Convert from network to host byte ordering before checking if an IP is a multicast address.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@304247 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
a40495fe84 |
This patch modifies chan_sip to route responses to the address the request came from. It also modifies chan_sip to respect the maddr parameter in the Via header.
ABE-2664 Review: https://reviewboard.asterisk.org/r/1059/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@304241 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
9f262f2772 |
Guard against retransmitting BYEs indefinitely
In the case of an attended transfer (A calls B, A atxfers to C) where A becomes unreachable before replying to Asterisk's BYE, Asterisk can sometimes retransmit the BYE indefinitely. This is because __sip_autodestruct tests p->refer && !ast_test_flag(&p->flags[0], SIP_ALREADYGONE and will then transmit a BYE. When this BYE times out, it will not ever be marked as ALREADYGONE, so when __sip_autodestruct is called again, we end up starting the cycle over. This patch adds a call to sip_alreadygone(pkt->owner) in retrans_pkt in the case of a BYE that has timed out. This should prevent Asterisk from trying to transmit new BYE messages in the future. Review: https://reviewboard.asterisk.org/r/1077/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@303906 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
c759dd9c8f |
Sending out unnecessary PROCEEDING messages breaks overlap dialing.
Issue #16789 was a good idea. Unfortunately, it breaks overlap dialing through Asterisk. There is not enough information available at this point to know if dialing is complete. The ast_exists_extension(), ast_matchmore_extension(), and ast_canmatch_extension() calls are not adequate to detect a dial through extension pattern of "_9!". Workaround is to use the dialplan Proceeding() application early in non-dial through extensions. * Effectively revert issue #16789. * Allow outgoing overlap dialing to hear dialtone and other early media. A PROGRESS "inband-information is now available" message is now sent after the SETUP_ACKNOWLEDGE message for non-digital calls. An AST_CONTROL_PROGRESS is now generated for incoming SETUP_ACKNOWLEDGE messages for non-digital calls. * Handling of the AST_CONTROL_CONGESTION in chan_dahdi/sig_pri was inconsistent with the cause codes. * Added better protection from sending out of sequence messages by combining several flags into a single enum value representing call progress level. * Added diagnostic messages for deferred overlap digits handling corner cases. (closes issue #17085) Reported by: shawkris (closes issue #18509) Reported by: wimpy Patches: issue18509_early_media_v1.8_v3.patch uploaded by rmudgett (license 664) Expanded upon issue18509_early_media_v1.8_v3.patch to include analog and SS7 because of backporting requirements. Tested by: wimpy, rmudgett git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@303765 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
518b09e786 |
Reset configuration before parsing users.conf.
Some values configured in chan_dahdi.conf were able to leak in to users.conf configuration. This was surprising users, and potentially setting non-sane "defaults". ASTNOW-125 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@303284 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
b53679ab6a |
URI encode the user part of the contact header.
ABE-2705 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@302311 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
59bd4a2ba3 |
Merged revisions 293493 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 [^] ........ r293493 | twilson | 2010-11-01 09:58:00 -0500 (Mon, 01 Nov 2010) | 14 lines Only offer codecs both sides support for directmedia When using directmedia, Asterisk needs to limit the codecs offered to just the ones that both sides recognize, otherwise they may end up sending audio that the other side doesn't understand. (closes issue 0017403) Reported by: one47 Patches: sip_codecs_simplified4 uploaded by one47 (license 23) Tested by: one47, falves11 Review: https://reviewboard.asterisk.org/r/967/ [^] ........ Back port a fix that should have been included git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@302087 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
a106ce66a4 |
Don't authenticate SUBSCRIBE re-transmissions
This only skips authentication on retransmissions that are already authenticated. A similar method is already used for INVITES. This is the kind of thing we end up having to do when we don't have a transaction layer... (closes issue #18075) Reported by: mdu113 Patches: diff.txt uploaded by twilson (license 396) Tested by: twilson, mdu113 Review: https://reviewboard.asterisk.org/r/1005/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@300216 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
e913a29969 |
Move check for extension existence below variable inheritance, due to the possible use of an eswitch.
(closes issue #16228) Reported by: jlaguilar git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@299624 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
ab674cd470 |
Use ast_free() instead of free()
ABE-2656 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@299220 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
7c10869584 |
Remove changes to via processing that were not supposed to go into the last commit.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@299198 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
b3edf004d2 |
Respond as soon as possible with a 202 Accepted to refer requests.
This change also plugs a few memory leaks that can occur when parking sip calls. ABE-2656 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@299194 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
24118f5839 |
Typos: recieved => received
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@299002 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
0543f25d7c |
Outgoing PRI/BRI calls cannot do DTMF triggered transfers.
Outgoing PRI/BRI calls cannot do DTMF triggered transfers if a PROCEEDING message is not received. The debug output shows that the DTMF begin event is seen, but the DTMF end event is missing. When the DTMF begin happens, the call is muted so we now have one way audio (until a DTMF end event is somehow seen). * Made set the proceeding flag when the PRI_EVENT_ANSWER event is received. * Made absorb the DTMF begin and DTMF end events if we are overlap dialing and have not seen a PROCEEDING message. * Added a debug message when absorbing a DTMF event. JIRA SWP-2690 JIRA ABE-2697 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@298193 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
d7877331c0 |
Ignore spurious REGISTER requests
If a REGISTER request with a Call-ID matching an existing transaction is received it was possible that the REGISTER request would overwrite the initreq of the private structure. This info is used to generate messages for other responses in the transaction. This patch ignores REGISTER requests that match non-REGISTER transactions. (closes issue #18051) Reported by: eeman Tested by: twilson Review: https://reviewboard.asterisk.org/r/1050/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@297959 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
919ad38940 |
Improve handling of REGISTER requests with multiple contact headers.
The changes here attempt to more strictly follow RFC 3261 section 10.3. Basically the following will now cause a 400 Bad Response to be returned, if: - multiple Contact headers are present with one set to expire all bindings ("*") - wildcard parameter is specified for Contact without Expires header or Expires header is not set to zero. ABE-2442 ABE-2443 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@297603 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
8b2304108a |
If we get a NOTIFY from a non-existing subscription we should answer with 481, not bad event.
If we answer 481 the subscription that we don't want will be cancelled. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@297185 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
046f56ce1c |
Fix not stopping MOH when transfered local channel queue member is answered.
The problem here is only present when local channels are used with the MOH passthru option as well as no optimization (/nm). I will describe the slightly bizarre scenario that was used to test, where phones B and C are queue members: Phone A dials into a queue with two members using local channels and the above options. Phone B answers. Phone A blind transfers phone B into the same queue. Phone A hangs up. Phone C answers, but phone B didn't stop playing MOH. In this scenario, the unhold frame that should have gotten to phone B never arrived due to the masquerade from the blind transfer. This is usually fine since app_queue manages the starting and stopping of MOH. However, with the passthrough option enabled when app_queue attempts to stop MOH it tries to do so on the local channel rather than the real channel. The easiest solution was to just make sure to send an unhold frame during the transfer since it wouldn't make sense to have MOH playing after a transfer anyway. This only modifies SIP transfers, but the other transfers did not seem to be a problem. If DTMF based transfers were a problem it might be okay to add ast_moh_stop to finishup, but I didn't want to have to add that unless required. ABE-2624 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@297072 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
196032208f |
Get rid of the annoying startup and shutdown errors on OS X.
This mainly deals with the problem of constructors on platforms where an explicit constructor order cannot be specified (any system with gcc 4.2 or less). However, this is only a problem on those systems where we need to initialize mutexes with a constructor, because we have other code that also relies upon constructors, and we cannot specify that mutexes are initialized first (and destroyed last). There are two approaches to dealing with this issue, related to whether the code exists in the core Asterisk binary or in a separate code module. In the core case, constructors are run immediately upon load, and the file_versions list mutex needs to be already initialized, as it is referenced in the first constructor within each core source file. In this case, we use pthread_once to ensure that the mutex is initialized immediately before it is used for the first time. The only caveat is that the mutex is not ever destroyed, but because this is the core, it makes no real difference; the only time when destruction is safe would be just prior to process destruction, which takes care of that anyway. And due to using pthread_once, the mutex will never be reinitialized, which means only one structure has leaked at the end of the process. Hence, it is not a problematic leak. The second approach is to use the load_module and unload_module routines, which, for obvious reasons, exist only in loadable modules. In this second case, we don't have a problem with the constructors, but only with destructor order, because mutexes can be destroyed before their final usage is employed. However, we need the mutexes to still be destroyed, in certain scenarios: if the module is unloaded prior to the process ending, it should be clean, with no allocations by the module hanging around after that point in time. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@296867 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
728bb5ac67 |
Make sure nothing else is needed before destroying the scheduler.
(closes issue #18398) Reported by: pabelanger git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@296670 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
c98862958a |
Oneway audio to SIP phone from FXS port after FXS port gets a CallWaiting pip.
The FXS connected phone has to have CW/CID support to fail, as it will send back a DTMF 'A' or 'D' when it's ready to receive CallerID. A normal phone with no CID never fails. Also the SIP phone does not hear MOH when the CW call is answered. The DTMF end frame is suppressed when the phone acknowledges the CW signal for CID. The problem is the DTMF begin frame needs to be suppressed as well. The DTMF begin frame is causing SIP to start sending the DTMF RTP frames. Since the DTMF end frame is suppressed, SIP will not stop sending those DTMF RTP packets. * Suppress the DTMF begin and end frames when the channel driver is looking for DTMF digits. * Fixed a couple issues caused by not cleaning up the CID spill if you answer the CW call while it is sending the CID spill. * Fixed not sending CW/CID spill to the phone when the call is natively bridged. (Fixed by not using native bridge if CW/CID is possible.) * Suppress received audio when sending CW/CID spills. The other parties involved do not need to hear the CW/CID spills and may be confused if the CW call is for them. (closes issue #18129) Reported by: alecdavis Patches: issue_18129_v1.8_v3.patch uploaded by rmudgett (license 664) Tested by: alecdavis, rmudgett NOTE: * v1.4 does not have the main problem fixed by suppressing the DTMF start frames. The other three items fixed are relevant. * If you really must restore native bridging between analog ports, you need to disable CW/CID either by configuring chan_dahdi.conf callwaitingcallerid=no or dialing *70 before dialing the number to temporarily disable CW. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@296165 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |