mirror of https://github.com/asterisk/asterisk
master
20
21
22
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 }
50 Commits (a0987672f0487a9caf92d91c095115799076a713)
Author | SHA1 | Message | Date |
---|---|---|---|
|
a0987672f0 |
Add SHA-256 and SHA-512-256 as authentication digest algorithms
* Refactored pjproject code to support the new algorithms and added a patch file to third-party/pjproject/patches * Added new parameters to the pjsip auth object: * password_digest = <algorithm>:<digest> * supported_algorithms_uac = List of algorithms to support when acting as a UAC. * supported_algorithms_uas = List of algorithms to support when acting as a UAS. See the auth object in pjsip.conf.sample for detailed info. * Updated both res_pjsip_authenticator_digest.c (for UAS) and res_pjsip_outbound_authentocator_digest.c (UAC) to suport the new algorithms. The new algorithms are only available with the bundled version of pjproject, or an external version > 2.14.1. OpenSSL version 1.1.1 or greater is required to support SHA-512-256. Resolves: #948 UserNote: The SHA-256 and SHA-512-256 algorithms are now available for authentication as both a UAS and a UAC. |
4 months ago |
|
f89e56c178 |
res_pjsip: Expanding PJSIP endpoint ID and relevant resource length to 255 characters
This commit introduces an extension to the endpoint and relevant resource sizes for PJSIP, transitioning from its current 40-character constraint to a more versatile 255-character capacity. This enhancement significantly overcomes limitations related to domain qualification and practical usage, ultimately delivering improved functionality. In addition, it includes adjustments to accommodate the expanded realm size within the ARI, specifically enhancing the maximum realm length. Resolves: #345 UserNote: With this update, the PJSIP realm lengths have been extended to support up to 255 characters. UpgradeNote: As part of this update, the maximum allowable length for PJSIP endpoints and relevant resources has been increased from 40 to 255 characters. To take advantage of this enhancement, it is recommended to run the necessary procedures (e.g., Alembic) to update your schemas. |
2 years ago |
|
881a3f2306 |
res_pjsip: Add TEL URI support for basic calls.
This change allows TEL URI requests to come through for basic calls. The allowed requests are INVITE, ACK, BYE, and CANCEL. The From and To headers will now allow TEL URIs, as well as the request URI. Support is only for TEL URIs present in traffic from a remote party. Asterisk does not generate any TEL URIs on its own. ASTERISK-26894 Change-Id: If5729e6cd583be7acf666373bf9f1b9d653ec29a |
3 years ago |
|
463f6c83e8 |
res_pjsip: Fix for Doxygen.
ASTERISK-29747 Change-Id: Ic7a1e9453f805a6264fe86c96b7d18b87b376084 |
3 years ago |
|
c2adeb9dc2 |
taskprocessor: Enable subsystems and overload by subsystem
To prevent one subsystem's taskprocessors from causing others to stall, new capabilities have been added to taskprocessors. * Any taskprocessor name that has a '/' will have the part before the '/' saved as its "subsystem". Examples: "sorcery/acl-0000006a" and "sorcery/aor-00000019" will be grouped to subsystem "sorcery". "pjsip/distributor-00000025" and "pjsip/distributor-00000026" will bn grouped to subsystem "pjsip". Taskprocessors with no '/' have an empty subsystem. * When a taskprocessor enters high-water alert status and it has a non-empty subsystem, the subsystem alert count will be incremented. * When a taskprocessor leaves high-water alert status and it has a non-empty subsystem, the subsystem alert count will be decremented. * A new api ast_taskprocessor_get_subsystem_alert() has been added that returns the number of taskprocessors in alert for the subsystem. * A new CLI command "core show taskprocessor alerted subsystems" has been added. * A new unit test was addded. REMINDER: The taskprocessor code itself doesn't take any action based on high-water alerts or overloading. It's up to taskprocessor users to check and take action themselves. Currently only the pjsip distributor does this. * A new pjsip/global option "taskprocessor_overload_trigger" has been added that allows the user to select the trigger mechanism the distributor uses to pause accepting new requests. "none": Don't pause on any overload condition. "global": Pause on ANY taskprocessor overload (the default and current behavior) "pjsip_only": Pause only on pjsip taskprocessor overloads. * The core pjsip pool was renamed from "SIP" to "pjsip" so it can be properly grouped into the "pjsip" subsystem. * stasis taskprocessor names were changed to "stasis" as the subsystem. * Sorcery core taskprocessor names were changed to "sorcery" to match the object taskprocessors. Change-Id: I8c19068bb2fc26610a9f0b8624bdf577a04fcd56 |
6 years ago |
|
a3fc97aa13 |
res_pjsip: Send a 503 response when overload state if reliable transport.
When Asterisk's taskprocessors get overloaded we need to reduce the work load. res_pjsip currently ignores new SIP requests and relies on SIP retransmissions in the hope that the overload condition will clear soon enough to handle the retransmitted SIP request. This change adds the following code after ast_taskprocessor_alert_get() has returned TRUE: 1- identifies transport type. If non-udp then send a 503 response 2- if transport type is udp/udp6 then ignore, as before. Change-Id: I1c230b40d43a254ea0f226b7acf9ee480a5d3836 |
7 years ago |
|
07cb13f75f |
res_pjsip: Log IPv6 addresses correctly
Both pjsip_tx_data.tp_info.dst_name and pjsip_rx_data.pkt_info.src_name store IPv6 addresses without enclosing brackets. This causes some log output to be confusing because it is difficult to separate the IPv6 address from a port specification. * Use pj_sockaddr_print() along with pjsip_tx_data.tp_info.dst_addr and pjsip_rx_data.pkt_info.src_addr where possible for consistent IPv6 output. * When a pj_sockaddr is not available, explicitly wrap IPv6 addresses in brackets. * When assigning pjsip_rx_data.pkt_info.src_name ourselves, make sure to also set pjsip_rx_data.pkt_info.src_addr. Change-Id: I5cfe997ced7883862a12b9c7d8551d76ae02fcf8 |
7 years ago |
|
81ac32a85f |
AST-2018-008: Fix enumeration of endpoints from ACL rejected addresses.
When endpoint specific ACL rules block a SIP request they respond with a 403 forbidden. However, if an endpoint is not identified then a 401 unauthorized response is sent. This vulnerability just discloses which requests hit a defined endpoint. The ACL rules cannot be bypassed to gain access to the disclosed endpoints. * Made endpoint specific ACL rules now respond with a 401 unauthorized which is the same as if an endpoint were not identified. The fix is accomplished by replacing the found endpoint with the artificial endpoint which always fails authentication. ASTERISK-27818 Change-Id: Icb275a54ff8e2df6c671a6d9bda37b5d732b3b32 |
7 years ago |
|
8e228fc138 |
Merge "res_pjsip/pjsip_distributor.c: Add missing off-nominal request response."
|
7 years ago |
|
11b7de82c5 |
res_pjsip/pjsip_distributor.c: Add missing off-nominal request response.
Change-Id: I389579b39c523d1d1e8ce020ef549a8bb5781c9b |
7 years ago |
|
6cab3c836a |
res_pjsip/pjsip_distributor.c: Pull some assignments out of if tests.
Change-Id: I3d30d638b53a4bbe9bf9aad853c649d583894112 |
7 years ago |
|
de871515ba |
AST-2018-005: Fix tdata leaks when calling pjsip_endpt_send_response(2)
pjsip_distributor: authenticate() creates a tdata and uses it to send a challenge or failure response. When pjsip_endpt_send_response2() succeeds, it automatically decrements the tdata ref count but when it fails, it doesn't. Since we weren't checking for a return status, we weren't decrementing the count ourselves on error and were therefore leaking tdatas. res_pjsip_session: session_reinvite_on_rx_request wasn't decrementing the ref count if an error happened while sending a 491 response. pre_session_setup wasn't decrementing the ref count if while sending an error after a pjsip_inv_verify_request failure. res_pjsip: ast_sip_send_response wasn't decrementing the ref count on error. ASTERISK-27618 Reported By: Sandro Gauci Change-Id: Iab33a6c7b6fba96148ed465b690ba8534ac961bf |
7 years ago |
|
527cf5a570 |
Remove redundant module checks and references.
This removes references that are no longer needed due to automatic references created by module dependencies. In addition this removes most calls to ast_module_check as they were checking modules which are listed as dependencies. Change-Id: I332a6e8383d4c72c8e89d988a184ab8320c4872e |
7 years ago |
|
b35ac9e566 |
res_pjsip: Fix leak of fake_auth references.
pjsip_distributor leaks references to fake_auth when the default realm has not changed. ASTERISK-27306 Change-Id: I3fcf103b3680ad2d1d4610dcd6738eeaebf4d202 |
8 years ago |
|
a10bc3e23f |
Merge "pjsip_distributor.c: Fix deadlock with TCP type transports."
|
8 years ago |
|
b485f6c59c |
pjsip_distributor.c: Fix deadlock with TCP type transports.
When a SIP message comes in on a transport, pjproject obtains the lock on the transport and pulls the data out of the socket. Unlike UDP, the TCP transport does not allow concurrent access. Without concurrency the transport lock is not released when the transport's message complete callback is called. The processing continues and eventually Asterisk starts processing the SIP message. The first thing Asterisk tries to do is determine the associated dialog of the message to determine the associated serializer. To get the associated serializer safely requires us to get the dialog lock. To send a request or response message for a dialog, pjproject obtains the dialog lock and then obtains the transport lock. Deadlock can result because of the opposite order the locks are obtained. * Fix the deadlock by obtaining the serializer associated with the dialog another way that doesn't involve obtaining the dialog lock. In this case, we use an ao2 container to hold the associated endpoint and serializer. The new locks are held a brief time and won't overlap other existing lock times. ASTERISK-27090 #close Change-Id: I9ed63f4da9649e9db6ed4be29c360968917a89bd |
8 years ago |
|
65a5ac0168 |
pjsip_distributor.c: Fix unidentified_requests hash functions.
The OBJ_SEARCH_xxx defines should not be used as if they were individual bits. They represent a multi-bit enumeration value field. Change-Id: I32abc9a475396dab02402a7014357dd94284e17b |
8 years ago |
|
1774f778f6 |
Merge "res_pjsip: Update artificial auth whenever default_realm changes."
|
8 years ago |
|
6400f5f309 |
res_pjsip: Update artificial auth whenever default_realm changes.
There was code attempting to update the artificial authentication object whenever the default_realm changed. However, once the artificial authentication object was created it would never get updated. The artificial authentication object would require a system restart for a change to the default_realm to take effect. ASTERISK-26799 Change-Id: Id59036e9529c2d3ed728af2ed904dc36e7094802 |
8 years ago |
|
54812f18b5 |
pjsip_distributor.c: Update some debug messages to get transaction name.
* Removed overloaded unmatched response ignore. We obviously sent the request so we shouldn't ignore it because it isn't new work. ASTERISK-26669 ASTERISK-26738 Change-Id: I55fb5cadc83a8e6699b347c6dc7fa32c5a617d37 |
8 years ago |
|
ce810a892b |
pjsip_distributor.c: Fix off-nominal tdata ref leak.
Change-Id: I571f371d0956a8039b197b4dbd8af6b18843598d |
8 years ago |
|
901e612739 |
res_pjsip: Only invoke unidentified endpoint logic when unidentified.
The code was incorrectly invoking the unidentified logic when an endpoint had actually been identified, causing log messages to be output. ASTERISK-26349 #close Change-Id: Id8104fc9e3d138d5e8b6f6977ecc08765fd17d4f |
9 years ago |
|
28b2aeba0b |
res_pjsip: Do not crash on ACKs from unknown endpoints.
The endpoint identification PJSIP module is intended to identify which endpoint an incoming request is from. If an endpoint is not identified, then an artificial endpoint is used in its place when proceeding. The problem is that the ACK request type is an exception to the rule. The artificial endpoint is not used when processing an ACK. This results in the possibility of having a NULL endpoint being used further on. The reason ACK is an exception is an attempt not to spam security logs with unidentified requests. Presumably, you've already logged the unidentified request on the preceeding INVITE. Up until Asterisk 13.10, retrieving a NULL endpoint in this fashion didn't cause an issue. A new change in 13.10 added endpoint ACL checking shortly after endpoint identification. Because we are accessing a NULL endpoint, this ACL check resulted in a crash. The fix here is to be sure to retrieve the artificial endpoint for all request types. ACKs still do not generate unidentified request security events. ASTERISK-26264 #close Reported by nappsoft AST-2016-006 Change-Id: Ie0c795ae2d72273decb972dd74b6a1489fb6b703 |
9 years ago |
|
b6e03a5ff3 |
pjsip_distributor.c: Add missing allocation failure check.
Change-Id: I932ab2cea845e534d9ff318035b6de39972d3b28 |
9 years ago |
|
2cd67d5b07 |
taskprocessors: Implement high/low water mark alerts.
When taskprocessors get backed up, there is a good chance that we are being overloaded and need to defer adding new work to the system. * Implemented a high/low water alert mechanism for modules to check if the system is being overloaded and take appropriate action. When a taskprocessor is created it has default congestion levels set. A taskprocessor can later have those congestion levels altered for specific needs if stress testing shows that the taskprocessor is a symptom of overloading or needs to handle bursty activity without triggering an overload alert. * Add CLI "core show taskprocessor" low/high water columns. * Fixed __allocate_taskprocessor() to not use RAII_VAR(). RAII_VAR() was never a good thing to use when creating a taskprocessor because of the nature of how its references needed to be cleaned up on a partial creation. * Made res_pjsip's distributor check if the taskprocessor overload alert is active before placing a message representing brand new work onto a distributor serializer. ASTERISK-26088 Reported by: Richard Mudgett Change-Id: I182f1be603529cd665958661c4c05ff9901825fa |
9 years ago |
|
2ff26e9746 |
pjsip_distributor.c: Consistently pick a serializer for messages.
Incoming messages that are not part of a dialog or a recognized response to one of our requests need to be sent to a consistent serializer. Under load we may be queueing retransmissions before we can process the original message. We don't need to throw these messages onto random serializers and cause reentrancy and message sequencing problems. * Created a pool of pjsip/distributor serializers that get picked by hashing the call-id and remote tag strings of the received messages. * Made ast_sip_destroy_distributor() destroy items in the reverse order of creation. ASTERISK-26088 Reported by: Richard Mudgett Change-Id: I2ce769389fc060d9f379977f559026fbcb632407 |
9 years ago |
|
df2791da8f |
pjsip_distributor.c: Ignore messages until fully booted.
We should not be processing any incoming messages until we are fully booted. We may not have dialplan or other needed configuration loaded yet. ASTERISK-26089 #close Reported by: Scott Griepentrog ASTERISK-26088 Reported by: Richard Mudgett Change-Id: I584aefb4f34b885a8927e1f13a2c64babd606264 |
9 years ago |
|
aec7916595 |
pjsip_distributor.c: Use correct rdata info access method (Part 2).
The pjproject doxygen for rdata->msg_info.info says to call pjsip_rx_data_get_info() instead of accessing the struct member directly. You need to call the function mostly because the function will generate the struct member value if it is not already setup. Change-Id: I4d519385a577f3e9d9193a88125e493cf17fa799 |
9 years ago |
|
7d44d12816 |
pjsip_distributor.c: Use correct rdata info access method.
The pjproject doxygen for rdata->msg_info.info says to call pjsip_rx_data_get_info() instead of accessing the struct member directly. You need to call the function mostly because the function will generate the struct member value if it is not already setup. Change-Id: Iafe8b01242b7deb0ebfdc36685e21374a43936d2 |
9 years ago |
|
1c02b19b79 |
res_pjsip: Match dialogs on responses better.
When receiving an incoming response to a dialog-starting INVITE, we were not matching the response to the INVITE dialog. Since we had not recorded the to-tag to the dialog structure, the PJSIP-provided method to find the dialog did not match. Most of the time, this was not a problem, because there is a fall-back that makes the response get routed to the same serializer that the request was sent on. However, in cases where an asynchronous DNS lookup occurs in the PJSIP core, the thread that sends the INVITE is not actually a threadpool serializer thread. This means we are unable to record a serializer to handle the incoming response. Now, imagine what happens when an INVITE is sent on a non-serialized thread, and an error response (such as a 486) arrives. The 486 ends up getting put on some random threadpool thread. Eventually, a hangup task gets queued on the INVITE dialog serializer. Since the 486 is being handled on a different thread, the hangup task can execute at the same time that the 486 is being handled. The hangup task assumes that it is the sole owner of the INVITE session and channel, so it ends up potentially freeing the channel and NULLing the session's channel pointer. The thread handling the 486 can crash as a result. This change has the incoming response match the INVITE transaction, and then get the dialog from that transaction. It's the same method we had been using for matching incoming CANCEL requests. By doing this, we get the INVITE dialog and can ensure that the 486 response ends up being handled by the same thread as the hangup, ensuring that the hangup runs after the 486 has been completely handled. ASTERISK-25941 #close Reported by Javier Riveros Change-Id: I0d4cc5d07e2a8d03e9db704d34bdef2ba60794a0 |
9 years ago |
|
69a85a519f |
res_pjsip: Endpoint IP Access Controls
With the old SIP module we can use IP access controls per peer. PJSIP module missing this feature. This patch added next configuration Endpoint options: "acl" - list of IP ACL section names in acl.conf "deny" - List of IP addresses to deny access from "permit" - List of IP addresses to permit access from "contact_acl" - List of Contact ACL section names in acl.conf "contact_deny" - List of Contact header addresses to deny "contact_permit" - List of Contact header addresses to permit This patch also better logging failed request: add custom message instead of "No matching endpoint found" add SIP method to logging ASTERISK-25900 Change-Id: I456dea3909d929d413864fb347d28578415ebf02 |
9 years ago |
|
4f8cfa0220 |
pjsip_distributor: Add missing newline to NOTICE
There was a newline missing from the end of the "no matching endpoint" notice. Change-Id: Idc11fe5bc0354072291663dbffe648c471e39181 |
9 years ago |
|
4ebf9a938d |
res_pjsip: Add ability to identify by Authorization username
A feature of chan_sip that service providers relied upon was the ability to identify by the Authorization username. This is most often used when customers have a PBX that needs to register rather than identify by IP address. From my own experiance, this is pretty common with small businesses who otherwise don't need a static IP. In this scenario, a register from the customer's PBX may succeed because From will usually contain the PBXs account id but an INVITE will contain the caller id. With nothing recognizable in From, the service provider's Asterisk can never match to an endpoint and the INVITE just stays unauthorized. The fixes: A new value "auth_username" has been added to endpoint/identify_by that will use the username and digest fields in the Authorization header instead of username and domain in the the From header to match an endpoint, or the To header to match an aor. This code as added to res_pjsip_endpoint_identifier_user rather than creating a new module. Although identify_by was always a comma-separated list, there was only 1 choice so order wasn't preserved. So to keep the order, a vector was added to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar to find the aor. The res_pjsip_endpoint_identifier_* modules are called in globals/endpoint_identifier_order. Along the way, the logic in res_pjsip_registrar was corrected to match most-specific to least-specific as res_pjsip_endpoint_identifier_user does. The order is: username@domain username@domain_alias username Auth by username does present 1 problem however, the first INVITE won't have an Authorization header so the distributor, not finding a match on anything, sends a securty_alert. It still sends a 401 with a challenge so the next INVITE will have the Authorization header and presumably succeed. As a result though, that first security alert is actually a false alarm. To address this, a new feature has been added to pjsip_distributor that keeps track of unidentified requests and only sends the security alert if a configurable number of unidentified requests come from the same IP in a configurable amout of time. Those configuration options have been added to the global config object. This feature is only used when auth_username is enabled. Finally, default_realm was added to the globals object to replace the hard coded "asterisk" used when an endpoint is not yet identified. The testsuite tests all pass but new tests are forthcoming for this new feature. ASTERISK-25835 #close Reported-by: Ross Beer Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d |
9 years ago |
|
1afc8432dc |
PJSIP: Prevent deadlock due to dialog/transaction lock inversion.
A deadlock was observed where the monitor thread was stuck, therefore resulting in no incoming SIP traffic being processed. The problem occurred when two 200 OK responses arrived in response to a terminating NOTIFY request sent from Asterisk. The first 200 OK was dispatched to a threadpool worker, who locked the corresponding transaction. The second 200 OK arrived, resulting in the monitor thread locking the dialog. At this point, the two threads are at odds, because the monitor thread attempts to lock the transaction, and the threadpool thread loops attempting to try to lock the dialog. In this case, the fix is to not have the monitor thread attempt to hold both the dialog and transaction locks at the same time. Instead, we release the dialog lock before attempting to lock the transaction. There have also been some debug messages added to the process in an attempt to make it more clear what is going on in the process. ASTERISK-25668 #close Reported by Mark Michelson Change-Id: I4db0705f1403737b4360e33a8e6276805d086d4a |
9 years ago |
|
e8881e1770 |
Taskprocessors: Increase high-water mark
In practical tests, we have seen certain taskprocessors, specifically Stasis subscription taskprocessors, cross the recently-added high-water mark and emit a warning. This high-water mark warning is only intended to be emitted when things have tanked on the system and things are heading south quickly. In the practical tests, the Stasis taskprocessors sometimes had a max depth of 180 tasks in them, and Asterisk wasn't in any danger at all. As such, this ups the high-water mark to 500 tasks instead. It also redefines the SIP threadpool request denial number to be a multiple of the taskprocessor high-water mark. Change-Id: Ic8d3e9497452fecd768ac427bb6f58aa616eebce |
10 years ago |
|
40b58a5d2b |
res_pjsip distributor: Don't send 503 response to responses.
When the SIP threadpool is backed up with tasks, we send 503 responses to ensure that we don't try to overload ourselves. The problem is that we were not insuring that we were not trying to send a 503 to an incoming SIP response. This change makes it so that we only send the 503 on incoming requests. Change-Id: Ie2b418d89c0e453cc6c2b5c7d543651c981e1404 |
10 years ago |
|
264c74aa22 |
res_pjsip: Deny requests when threadpool queue is backed up.
We have observed situations where the SIP threadpool may become deadlocked. However, because incoming traffic is still arriving, the SIP threadpool's queue can continue to grow, eventually running the system out of memory. This change makes it so that incoming traffic gets rejected with a 503 response if the queue is backed up too much. Change-Id: I4e736d48a2ba79fd1f8056c0dcd330e38e6a3816 |
10 years ago |
|
30cd559345 |
DNS: Need to use the same serializer for a pjproject SIP transaction.
All send/receive processing for a SIP transaction needs to be done under the same threadpool serializer to prevent reentrancy problems inside pjproject when using an external DNS resolver to process messages for the transaction. * Add threadpool API call to get the current serializer associated with the worker thread. * Pick a serializer from a pool of default serializers if the caller of res_pjsip.c:ast_sip_push_task() does not provide one. This is a simple way to ensure that all outgoing SIP request messages are processed under a serializer. Otherwise, any place where a pushed task is done that would result in an outgoing out-of-dialog request would need to be modified to supply a serializer. Serializers from the default serializer pool are picked in a round robin sequence for simplicity. A side effect is that the default serializer pool will limit the growth of the thread pool from random tasks. This is not necessarily a bad thing. * Made pjsip_resolver.c use the requesting thread's serializer to execute the async callback. * Made pjsip_distributor.c save the thread's serializer name on the outgoing request tdata struct so the response can be processed under the same serializer. ASTERISK-25115 #close Reported by: John Bigelow Change-Id: Iea71c16ce1132017b5791635e198b8c27973f40a |
10 years ago |
|
e62bd46511 |
res_pjsip: make it unloadable (take 2)
Due to the original patch causing memory corruptions it was removed until the problem could be resolved. This patch is the original patch plus some added locking around stasis router subcription that was needed to avoid the memory corruption. Description of the original problem and patch (still applicable): The res_pjsip module was previously unloadable. With this patch it can now be unloaded. This patch is based off the original patch on the issue (listed below) by Corey Farrell with a few modifications. Namely, removed a few changes not required to make the module unloadable and also fixed a bug that would cause asterisk to crash on unloading. This patch is the first step (should hopefully be followed by another/others at some point) in allowing res_pjsip and the modules that depend on it to be unloadable. At this time, res_pjsip and some of the modules that depend on res_pjsip cannot be unloaded without causing problems of some sort. The goal of this patch is to get res_pjsip and only res_pjsip to be able to unload successfully and/or shutdown without incident (crashes, leaks, etc...). Other dependent modules may still cause problems on unload. Basically made sure, with the patch applied, that res_pjsip (with no other dependent modules loaded) could be succesfully unloaded and Asterisk could shutdown without any leaks or crashes that pertained directly to res_pjsip. ASTERISK-24485 #close Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/4363/ patches: pjsip_unload-broken-r1.patch submitted by Corey Farrell (license 5909) ........ Merged revisions 431179 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431180 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
07e2a48ab1 |
REVERTING res_pjsip: make it unloadable
Due to the original patch causing memory corruptions the patch is being removed until the problem can be resolved. ........ Merged revisions 430734 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430735 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
49542a794b |
res_pjsip: make it unloadable
The res_pjsip module was previously unloadable. With this patch it can now be unloaded. This patch is based off the original patch on the issue (listed below) by Corey Farrell with a few modifications. Namely, removed a few changes not required to make the module unloadable and also fixed a bug that would cause asterisk to crash on unloading. This patch is the first step (should hopefully be followed by another/others at some point) in allowing res_pjsip and the modules that depend on it to be unloadable. At this time, res_pjsip and some of the modules that depend on res_pjsip cannot be unloaded without causing problems of some sort. The goal of this patch is to get res_pjsip and only res_pjsip to be able to unload successfully and/or shutdown without incident (crashes, leaks, etc...). Other dependent modules may still cause problems on unload. Basically made sure, with the patch applied, that res_pjsip (with no other dependent modules loaded) could be succesfully unloaded and Asterisk could shutdown without any leaks or crashes that pertained directly to res_pjsip. ASTERISK-24485 #close Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/4311/ patches: pjsip_unload-broken-r1.patch submitted by Corey Farrell (license 5909) ........ Merged revisions 430628 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430629 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
47074f4bfd |
res_pjsip: Ensure in-dialog responses have an endpoint associated.
When handling incoming messages we determine if it is associated with a dialog. If so we use that to determine what serializer and endpoint to use for the message. Previously this would pass the endpoint to the endpoint lookup module to actually place the endpoint completely on the message. For in-dialog responses, however, this did not occur as dialog processing took over and the endpoint lookup did not occur. This change just places the endpoint in the expected spot immediately instead of relying on the endpoint lookup module. In-dialog responses thus have the expected endpoint. AST-1459 #close Review: https://reviewboard.asterisk.org/r/4146/ ........ Merged revisions 427490 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427491 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427492 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
45b7b474ac |
res_pjsip: Prevent crashes when PJPROJECT presents an rdata with no message
When a message that exceeds the PJ_MAX_PKT_SIZE is sent over a reliable transport, it is possible (although it shouldn't occur) for pjproject to pass up an rdata object with a NULL msg in the msg_info. Needless to say, things that attempt to dereference this are in for a rough ride. In particular, this caused crashes in three different locations, all of which are 'low level' enough to intercept an rdata object early in processing: (1) res_pjsip_logger (2) res_hep_pjsip (3) res_pjsip/distributor Anything that can intercept an rdata object before res_pjsip/distributor should be defensive when looking at the received packet. #SIPit31 ASTERISK-24369 #close Reported by: Matt Jordan ........ Merged revisions 424618 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 424619 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424620 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
7cbb6eab15 |
PJSIP: Add Path header support
This adds Path support to chan_pjsip in res_pjsip_path.c with minimal additions in res_pjsip_registrar.c to store the path and additions in res_pjsip_outbound_registration.c to enable advertisement of path support to registrars and intervening proxies. Path information is stored on contacts and is enabled via Address of Record (AoRs) and Registration configuration sections. While adding path support, it became necessary to be able to add SIP supplements that handled messages outside of sessions, so a framework for handling these types of hooks was added in parallel to the already-existing session supplements and several senders of out-of-dialog requests were refactored as a result. (closes issue ASTERISK-21084) Review: https://reviewboard.asterisk.org/r/3050/ ........ Merged revisions 405565 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405566 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
aced8bdd2e |
Fix erroneous behavior when sending auth rejection to artificial endpoint.
We were not including an authentication challenge when sending a 401 response to unmatched endpoints. This was due to the conversion to use a vector for authentication section names on an endpoint. The vector for artificial endpoints was empty, resulting in the challenge being sent back containing no challenges. This is worked around by placing a bogus value in the artificial endpoint's auth vector. This value is never looked up by anything, since they instead will directly call ast_sip_get_artificial_auth(). git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405420 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
b18ed67d16 |
Switch PJSIP auth to use a vector.
Since Asterisk has a vector API now, places where arrays are manually resized don't really make sense any more. Since the auth work in PJSIP was freshly-written, it was easy to reform it to use a vector. Review: https://reviewboard.asterisk.org/r/3044 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403499 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
1b14a78d14 |
res_pjsip: Add support for building against pjproject with SIP transaction group lock support.
SIP transaction group lock support has been backported into our pjproject. Since the code now internally uses a group lock the code is now changed to unlock it if present. Note that the act of finding the transaction is what actually returns it locked. For further information about group locks check out the wiki page at: http://trac.pjsip.org/repos/wiki/Group_Lock (issue ASTERISK-22818) Reported by: Matt Jordan ........ Merged revisions 402864 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402865 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
bb1568caa1 |
PJSIP: Add log messages when requests are received for non-existent endpoints
(closes issue ASTERISK-22552) Reported by: Rusty Newton Review: https://reviewboard.asterisk.org/r/2934/ ........ Merged revisions 401938 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401939 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
a181544299 |
Fix dialog matching in the SIP distributor.
Dialog matching is performed in the distributor for the sole purpose of retrieving an associated serializer so the request may be serialized. This patch fixes two problems. First, incoming CANCEL requests that had no to-tag (which really should be *all* CANCEL requests) would not match with a dialog. An earlier bug fix to deal with early CANCEL requests would result in the CANCEL being replied to with a 481. The fix for this is to find the matching INVITE transaction and get the dialog from that transaction. Second, no SIP responses were matching dialogs. This is because we were inverting the tags that we were passing into PJSIP's dialog finding function. This logic has been corrected by setting local and remote tag variables based on whether the incoming message is a request or response. ........ Merged revisions 397854 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397855 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
735b30ad71 |
The large GULP->PJSIP renaming effort.
The general gist is to have a clear boundary between old SIP stuff and new SIP stuff by having the word "SIP" for old stuff and "PJSIP" for new stuff. Here's a brief rundown of the changes: * The word "Gulp" in dialstrings, functions, and CLI commands is now "PJSIP" * chan_gulp.c is now chan_pjsip.c * Function names in chan_gulp.c that were "gulp_*" are now "chan_pjsip_*" * All files that were "res_sip*" are now "res_pjsip*" * The "res_sip" directory is now "res_pjsip" * Files in the "res_pjsip" directory that began with "sip_*" are now "pjsip_*" * The configuration file is now "pjsip.conf" instead of "res_sip.conf" * The module info for all PJSIP-related files now uses "PJSIP" instead of "SIP" * CLI and AMI commands created by Asterisk's PJSIP modules now have "pjsip" as the starting word instead of "sip" git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395764 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |