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.4.0-rc1
21.9.0-rc1
20.14.0-rc1
22.3.0
21.8.0
20.13.0
22.3.0-rc1
21.8.0-rc1
20.13.0-rc1
22.2.0
21.7.0
20.12.0
22.2.0-rc2
21.7.0-rc2
20.12.0-rc2
22.2.0-rc1
21.7.0-rc1
20.12.0-rc1
certified-20.7-cert4
certified-18.9-cert13
22.1.1
21.6.1
20.11.1
18.26.1
22.1.0
21.6.0
20.11.0
18.26.0
22.1.0-rc1
21.6.0-rc1
20.11.0-rc1
18.26.0-rc1
18.25.0
20.10.0
21.5.0
22.0.0
22.0.0-rc2
21.5.0-rc2
20.10.0-rc2
18.25.0-rc2
22.0.0-rc1
21.5.0-rc1
20.10.0-rc1
18.25.0-rc1
certified-20.7-cert3
certified-18.9-cert12
21.4.3
20.9.3
18.24.3
22.0.0-pre1
21.4.2
20.9.2
18.24.2
certified-20.7-cert2
certified-18.9-cert11
21.4.1
20.9.1
18.24.1
21.4.0
20.9.0
18.24.0
certified-20.7-cert1
certified-18.9-cert10
21.4.0-rc1
20.9.0-rc1
18.24.0-rc1
21.3.1
20.8.1
18.23.1
21.3.0
20.8.0
18.23.0
certified-20.7-cert1-rc2
certified-18.9-cert9
20.8.0-rc1
21.3.0-rc1
18.23.0-rc1
certified-20.7-cert1-rc1
certified-20.7-cert1-pre1
21.2.0
20.7.0
18.22.0
certified-18.9-cert8
21.2.0-rc2
20.7.0-rc2
18.22.0-rc2
21.2.0-rc1
20.7.0-rc1
18.22.0-rc1
certified-18.9-cert8-rc2
certified-18.9-cert8-rc1
21.1.0
20.6.0
18.21.0
21.1.0-rc2
20.6.0-rc2
18.21.0-rc2
21.1.0-rc1
20.6.0-rc1
18.21.0-rc1
21.0.2
20.5.2
18.20.2
certified-18.9-cert7
certified-18.9-cert6
21.0.1
20.5.1
18.20.1
21.0.0
20.5.0
18.20.0
21.0.0-rc1
20.5.0-rc1
18.20.0-rc1
21.0.0-pre1
18.19.0
20.4.0
20.4.0-rc2
18.19.0-rc2
20.4.0-rc1
18.19.0-rc1
20.3.1
certified-18.9-cert5
19.8.1
18.18.1
16.30.1
certified-18.9-cert4
20.3.0
18.18.0
20.3.0-rc1
18.18.0-rc1
20.2.1
18.17.1
20.2.0
18.17.0
20.2.0-rc1
18.17.0-rc1
certified/18.9-cert4
20.1.0
19.8.0
18.16.0
16.30.0
20.1.0-rc2
19.8.0-rc2
18.16.0-rc2
16.30.0-rc2
20.1.0-rc1
18.16.0-rc1
19.8.0-rc1
16.30.0-rc1
certified/18.9-cert3
20.0.1
19.7.1
18.15.1
16.29.1
19.7.0
20.0.0
18.15.0
16.29.0
certified/18.9-cert2
20.0.0-rc2
19.7.0-rc2
18.15.0-rc2
16.29.0-rc2
20.0.0-rc1
19.7.0-rc1
18.15.0-rc1
16.29.0-rc1
19.6.0
18.14.0
16.28.0
19.6.0-rc2
18.14.0-rc2
16.28.0-rc2
19.6.0-rc1
18.14.0-rc1
16.28.0-rc1
19.5.0
18.13.0
16.27.0
19.5.0-rc1
18.13.0-rc1
16.27.0-rc1
19.4.1
18.12.1
16.26.1
19.4.0
18.12.0
16.26.0
19.4.0-rc1
18.12.0-rc1
16.26.0-rc1
certified/18.9-cert1
19.3.3
18.11.3
16.25.3
certified/16.8-cert14
19.3.2
18.11.2
16.25.2
19.3.1
18.11.1
16.25.1
19.3.0
18.11.0
16.25.0
19.3.0-rc1
18.11.0-rc1
16.25.0-rc1
certified/16.8-cert13
19.2.1
18.10.1
16.24.1
19.2.0
18.10.0
16.24.0
19.2.0-rc1
18.10.0-rc1
16.24.0-rc1
certified/18.9-cert1-rc1
19.1.0
18.9.0
16.23.0
19.1.0-rc1
18.9.0-rc1
16.23.0-rc1
19.0.0
18.8.0
16.22.0
certified/16.8-cert12
19.0.0-rc1
18.8.0-rc1
16.22.0-rc1
16.21.1
18.7.1
18.7.0
16.21.0
18.7.0-rc3
16.21.0-rc3
18.7.0-rc2
16.21.0-rc2
18.7.0-rc1
16.21.0-rc1
certified/16.8-cert11
18.6.0
16.20.0
18.6.0-rc1
16.20.0-rc1
certified/16.8-cert10
18.5.1
17.9.4
16.19.1
13.38.3
18.5.0
16.19.0
certified/16.8-cert9
18.5.0-rc1
16.19.0-rc1
18.4.0
16.18.0
18.4.0-rc1
16.18.0-rc1
certified/16.8-cert8
18.3.0
16.17.0
18.3.0-rc2
16.17.0-rc2
18.3.0-rc1
16.17.0-rc1
certified/16.8-cert7
18.2.2
17.9.3
16.16.2
certified/16.8-cert6
18.2.1
17.9.2
16.16.1
13.38.2
18.2.0
16.16.0
18.2.0-rc1
16.16.0-rc1
18.1.1
17.9.1
16.15.1
13.38.1
18.1.0
17.9.0
16.15.0
13.38.0
18.1.0-rc1
17.9.0-rc1
16.15.0-rc1
13.38.0-rc1
18.0.1
17.8.1
16.14.1
certified/16.8-cert5
13.37.1
certified/16.8-cert4
certified/16.8-cert4-rc4
18.0.0
17.8.0
16.14.0
13.37.0
18.0.0-rc2
certified/16.8-cert4-rc3
18.0.0-rc1
17.8.0-rc1
16.14.0-rc1
13.37.0-rc1
17.7.0
16.13.0
13.36.0
17.7.0-rc2
16.13.0-rc2
13.36.0-rc2
17.7.0-rc1
16.13.0-rc1
13.36.0-rc1
certified/16.8-cert4-rc2
17.6.0
16.12.0
13.35.0
17.6.0-rc1
16.12.0-rc1
13.35.0-rc1
certified/16.8-cert4-rc1
certified/16.8-cert3
17.5.1
16.11.1
17.5.0
16.11.0
13.34.0
17.5.0-rc3
16.11.0-rc3
13.34.0-rc3
17.5.0-rc2
16.11.0-rc2
13.34.0-rc2
17.5.0-rc1
16.11.0-rc1
13.34.0-rc1
certified/16.8-cert2
17.4.0
16.10.0
13.33.0
certified/16.8-cert1
17.4.0-rc2
16.10.0-rc2
13.33.0-rc2
17.4.0-rc1
16.10.0-rc1
13.33.0-rc1
certified/16.8-cert1-rc5
certified/16.8-cert1-rc4
17.3.0
16.9.0
13.32.0
17.3.0-rc1
16.9.0-rc1
13.32.0-rc1
certified/16.8-cert1-rc3
certified/16.8-cert1-rc2
certified/16.8-cert1-rc1
17.2.0
16.8.0
13.31.0
17.2.0-rc2
16.8.0-rc2
13.31.0-rc2
17.2.0-rc1
16.8.0-rc1
13.31.0-rc1
certified/16.3-cert1
certified/13.21-cert6
17.1.0
16.7.0
13.30.0
17.1.0-rc2
16.7.0-rc2
13.30.0-rc2
17.1.0-rc1
16.7.0-rc1
13.30.0-rc1
certified/13.21-cert5
17.0.1
16.6.2
13.29.2
17.0.0
17.0.0-rc3
16.6.1
13.29.1
16.6.0
13.29.0
16.6.0-rc2
13.29.0-rc2
17.0.0-rc2
16.6.0-rc1
13.29.0-rc1
16.5.1
15.7.4
13.28.1
17.0.0-rc1
16.5.0
13.28.0
16.5.0-rc1
13.28.0-rc1
certified/13.21-cert4
16.4.1
15.7.3
13.27.1
16.4.0
13.27.0
16.4.0-rc1
13.27.0-rc1
16.3.0
13.26.0
16.3.0-rc1
13.26.0-rc1
16.2.1
15.7.2
16.2.0
13.25.0
13.25.0-rc3
16.2.0-rc2
13.25.0-rc2
16.2.0-rc1
13.25.0-rc1
16.1.1
15.7.1
13.24.1
16.1.0
13.24.0
15.7.0
16.1.0-rc1
15.7.0-rc1
13.24.0-rc1
16.0.1
15.6.2
16.0.0
16.0.0-rc3
certified/13.21-cert3
15.6.1
14.7.8
13.23.1
16.0.0-rc2
15.6.0
13.23.0
15.6.0-rc1
13.23.0-rc1
16.0.0-rc1
15.5.0
13.22.0
15.5.0-rc1
13.22.0-rc1
15.4.1
14.7.7
certified/13.21-cert2
certified/13.18-cert4
13.21.1
certified/13.21-cert1
certified/13.21-cert1-rc2
certified/13.21-cert1-rc1
15.4.0
13.21.0
15.4.0-rc2
15.4.0-rc1
13.21.0-rc1
15.3.0
13.20.0
15.3.0-rc2
13.20.0-rc2
15.3.0-rc1
13.20.0-rc1
15.2.2
certified/13.18-cert3
14.7.6
13.19.2
13.19.1
15.2.1
15.2.0
13.19.0
15.2.0-rc2
13.19.0-rc2
certified/13.18-cert2
15.1.5
14.7.5
13.18.5
certified/13.18-cert1
15.2.0-rc1
13.19.0-rc1
certified/13.18-cert1-rc3
certified/13.13-cert9
15.1.4
14.7.4
13.18.4
15.1.3
certified/13.13-cert8
14.7.3
13.18.3
certified/13.18-cert1-rc2
15.1.2
14.7.2
13.18.2
certified/13.18-cert1-rc1
certified/13.13-cert7
15.1.1
14.7.1
13.18.1
15.1.0
14.7.0
13.18.0
15.1.0-rc2
14.7.0-rc2
13.18.0-rc2
15.1.0-rc1
14.7.0-rc1
13.18.0-rc1
15.0.0
certified/13.13-cert6
certified/11.6-cert18
14.6.2
13.17.2
11.25.3
15.0.0-rc1
14.6.1
certified/13.13-cert5
13.17.1
certified/11.6-cert17
11.25.2
15.0.0-beta1
14.6.0
13.17.0
14.6.0-rc1
13.17.0-rc1
14.5.0
13.16.0
14.5.0-rc2
13.16.0-rc2
14.5.0-rc1
13.16.0-rc1
certified/13.13-cert4
14.4.1
13.15.1
14.4.0
13.15.0
14.4.0-rc3
13.15.0-rc3
14.3.1
13.14.1
certified/13.13-cert3
13.15.0-rc2
14.4.0-rc2
14.4.0-rc1
13.15.0-rc1
certified/13.13-cert2
14.3.0
13.14.0
certified/13.13-cert1
14.3.0-rc2
13.14.0-rc2
certified/13.13-cert1-rc4
14.3.0-rc1
13.14.0-rc1
certified/13.13-cert1-rc3
certified/13.13-cert1-rc2
certified/11.6-cert16
certified/13.8-cert4
14.2.1
13.13.1
11.25.1
certified/13.13-cert1-rc1
14.2.0
13.13.0
14.2.0-rc2
13.13.0-rc2
11.25.0
14.2.0-rc1
13.13.0-rc1
11.25.0-rc1
14.1.2
13.12.2
14.1.1
13.12.1
11.24.1
14.1.0
13.12.0
11.24.0
14.1.0-rc1
13.12.0-rc1
11.24.0-rc1
14.0.2
14.0.1
14.0.0
14.0.0-rc2
14.0.0-rc1
13.11.2
certified/11.6-cert15
certified/13.8-cert3
11.23.1
13.11.1
13.11.0
13.11.0-rc2
14.0.0-beta2
certified/11.6-cert14
certified/11.6-cert14-rc2
certified/13.8-cert2
certified/13.8-cert2-rc1
certified/11.6-cert14-rc1
13.11.0-rc1
14.0.0-beta1
11.23.0
13.10.0
certified/13.1-cert8
13.10.0-rc3
certified/13.8-cert1
13.10.0-rc2
11.23.0-rc1
13.10.0-rc1
certified/13.8-cert1-rc3
13.9.1
13.9.0
certified/13.8-cert1-rc2
13.9.0-rc2
certified/13.1-cert7
13.9.0-rc1
certified/13.1-cert6
13.8.2
13.8.1
certified/13.1-cert5
certified/13.8-cert1-rc1
13.8.0
11.22.0
certified/13.1-cert4
certified/11.6-cert13
11.21.2
13.7.2
11.20.0
13.6.0
13.5.0
11.19.0
certified/13.1-cert3-rc1
13.4.0
11.18.0
0.1.0
0.1.1
0.1.10
0.1.11
0.1.12
0.1.2
0.1.3
0.1.4
0.1.5
0.1.6
0.1.7
0.1.8
0.1.9
0.2.0
0.3.0
0.4.0
0.5.0
0.7.0
0.7.1
0.7.2
0.9.0
1.0.0
1.0.0-rc1
1.0.0-rc2
1.0.1
1.0.10
1.0.11
1.0.11.1
1.0.12
1.0.2
1.0.4
1.0.5
1.0.6
1.0.7
1.0.8
1.0.9
1.2.0
1.2.0-beta1
1.2.0-beta2
1.2.0-rc1
1.2.0-rc2
1.2.1
1.2.10
1.2.10-netsec
1.2.11
1.2.11-netsec
1.2.12
1.2.12-netsec
1.2.12.1
1.2.12.1-netsec
1.2.13
1.2.13-netsec
1.2.14
1.2.14-netsec
1.2.15
1.2.15-netsec
1.2.16
1.2.16-netsec
1.2.17
1.2.17-netsec
1.2.18
1.2.18-netsec
1.2.19
1.2.19-netsec
1.2.2
1.2.2-netsec
1.2.20
1.2.20-netsec
1.2.21
1.2.21-netsec
1.2.21.1
1.2.21.1-netsec
1.2.22
1.2.22-netsec
1.2.23
1.2.23-netsec
1.2.24
1.2.24-netsec
1.2.25
1.2.25-netsec
1.2.26
1.2.26-netsec
1.2.26.1
1.2.26.1-netsec
1.2.26.2
1.2.26.2-netsec
1.2.27
1.2.28
1.2.28.1
1.2.29
1.2.3
1.2.3-netsec
1.2.30
1.2.30.1
1.2.30.2
1.2.30.3
1.2.30.4
1.2.31
1.2.31.1
1.2.31.2
1.2.32
1.2.33
1.2.34
1.2.35
1.2.36
1.2.37
1.2.38
1.2.39
1.2.4
1.2.4-netsec
1.2.40
1.2.5
1.2.5-netsec
1.2.6
1.2.6-netsec
1.2.7
1.2.7-netsec
1.2.7.1
1.2.7.1-netsec
1.2.8
1.2.8-netsec
1.2.9
1.2.9-netsec
1.2.9.1
1.2.9.1-netsec
1.4.0
1.4.0-beta1
1.4.0-beta2
1.4.0-beta3
1.4.0-beta4
1.4.1
1.4.10
1.4.10.1
1.4.11
1.4.12
1.4.12.1
1.4.13
1.4.14
1.4.15
1.4.16
1.4.16.1
1.4.16.2
1.4.17
1.4.18
1.4.18.1
1.4.19
1.4.19-rc1
1.4.19-rc2
1.4.19-rc3
1.4.19-rc4
1.4.19.1
1.4.19.2
1.4.2
1.4.20
1.4.20-rc1
1.4.20-rc2
1.4.20-rc3
1.4.20.1
1.4.21
1.4.21-rc1
1.4.21-rc2
1.4.21.1
1.4.21.2
1.4.22
1.4.22-rc1
1.4.22-rc2
1.4.22-rc3
1.4.22-rc4
1.4.22-rc5
1.4.22.1
1.4.22.2
1.4.23
1.4.23-rc1
1.4.23-rc2
1.4.23-rc3
1.4.23-rc4
1.4.23-testing
1.4.23.1
1.4.23.2
1.4.24
1.4.24-rc1
1.4.24.1
1.4.25
1.4.25-rc1
1.4.25.1
1.4.26
1.4.26-rc1
1.4.26-rc2
1.4.26-rc3
1.4.26-rc4
1.4.26-rc5
1.4.26-rc6
1.4.26.1
1.4.26.2
1.4.26.3
1.4.27
1.4.27-rc1
1.4.27-rc2
1.4.27-rc3
1.4.27-rc4
1.4.27-rc5
1.4.27.1
1.4.28
1.4.28-rc1
1.4.29
1.4.29-rc1
1.4.29.1
1.4.3
1.4.30
1.4.30-rc1
1.4.30-rc2
1.4.30-rc3
1.4.31
1.4.31-rc1
1.4.31-rc2
1.4.32
1.4.32-rc1
1.4.32-rc2
1.4.33
1.4.33-rc1
1.4.33-rc2
1.4.33.1
1.4.34
1.4.34-rc1
1.4.34-rc2
1.4.35
1.4.35-rc1
1.4.36
1.4.36-rc1
1.4.37
1.4.37-rc1
1.4.37.1
1.4.38
1.4.38-rc1
1.4.38.1
1.4.39
1.4.39-rc1
1.4.39.1
1.4.39.2
1.4.4
1.4.40
1.4.40-rc1
1.4.40-rc2
1.4.40-rc3
1.4.40.1
1.4.40.2
1.4.41
1.4.41-rc1
1.4.41.1
1.4.41.2
1.4.42
1.4.42-rc1
1.4.42-rc2
1.4.43
1.4.44
1.4.5
1.4.6
1.4.7
1.4.7.1
1.4.8
1.4.9
1.6.0
1.6.0-beta1
1.6.0-beta2
1.6.0-beta3
1.6.0-beta4
1.6.0-beta5
1.6.0-beta6
1.6.0-beta7
1.6.0-beta7.1
1.6.0-beta8
1.6.0-beta9
1.6.0-rc1
1.6.0-rc2
1.6.0-rc3
1.6.0-rc4
1.6.0-rc5
1.6.0-rc6
1.6.0.1
1.6.0.10
1.6.0.11-rc1
1.6.0.11-rc2
1.6.0.12
1.6.0.13
1.6.0.13-rc1
1.6.0.14
1.6.0.14-rc1
1.6.0.15
1.6.0.16
1.6.0.16-rc1
1.6.0.16-rc2
1.6.0.17
1.6.0.18
1.6.0.18-rc1
1.6.0.18-rc2
1.6.0.18-rc3
1.6.0.19
1.6.0.2
1.6.0.20
1.6.0.20-rc1
1.6.0.21
1.6.0.21-rc1
1.6.0.22
1.6.0.23
1.6.0.23-rc1
1.6.0.23-rc2
1.6.0.24
1.6.0.25
1.6.0.26
1.6.0.26-rc1
1.6.0.27
1.6.0.27-rc1
1.6.0.27-rc2
1.6.0.27-rc3
1.6.0.28
1.6.0.28-rc1
1.6.0.28-rc2
1.6.0.3
1.6.0.3-rc1
1.6.0.3.1
1.6.0.4-rc1
1.6.0.4-testing
1.6.0.5
1.6.0.6
1.6.0.6-rc1
1.6.0.7
1.6.0.7-rc1
1.6.0.7-rc2
1.6.0.8
1.6.0.9
1.6.1-beta1
1.6.1-beta2
1.6.1-beta3
1.6.1-beta4
1.6.1-rc1
1.6.1.0
1.6.1.0-rc2
1.6.1.0-rc3
1.6.1.0-rc4
1.6.1.0-rc5
1.6.1.1
1.6.1.10
1.6.1.10-rc1
1.6.1.10-rc2
1.6.1.10-rc3
1.6.1.11
1.6.1.12
1.6.1.12-rc1
1.6.1.13
1.6.1.13-rc1
1.6.1.14
1.6.1.15-rc1
1.6.1.15-rc2
1.6.1.16
1.6.1.17
1.6.1.18
1.6.1.18-rc1
1.6.1.18-rc2
1.6.1.19
1.6.1.19-rc1
1.6.1.19-rc2
1.6.1.19-rc3
1.6.1.2
1.6.1.20
1.6.1.20-rc1
1.6.1.20-rc2
1.6.1.21
1.6.1.22
1.6.1.23
1.6.1.24
1.6.1.25
1.6.1.3-rc1
1.6.1.4
1.6.1.5
1.6.1.5-rc1
1.6.1.6
1.6.1.7-rc1
1.6.1.7-rc2
1.6.1.8
1.6.1.9
1.6.2.0
1.6.2.0-beta1
1.6.2.0-beta2
1.6.2.0-beta3
1.6.2.0-beta4
1.6.2.0-rc1
1.6.2.0-rc2
1.6.2.0-rc3
1.6.2.0-rc4
1.6.2.0-rc5
1.6.2.0-rc6
1.6.2.0-rc7
1.6.2.0-rc8
1.6.2.1
1.6.2.1-rc1
1.6.2.10
1.6.2.10-rc1
1.6.2.10-rc2
1.6.2.11
1.6.2.11-rc1
1.6.2.11-rc2
1.6.2.12
1.6.2.12-rc1
1.6.2.13
1.6.2.14
1.6.2.14-rc1
1.6.2.15
1.6.2.15-rc1
1.6.2.15.1
1.6.2.16
1.6.2.16-rc1
1.6.2.16.1
1.6.2.16.2
1.6.2.17
1.6.2.17-rc1
1.6.2.17-rc2
1.6.2.17-rc3
1.6.2.17.1
1.6.2.17.2
1.6.2.17.3
1.6.2.18
1.6.2.18-rc1
1.6.2.18.1
1.6.2.18.2
1.6.2.19
1.6.2.19-rc1
1.6.2.2
1.6.2.20
1.6.2.21
1.6.2.22
1.6.2.23
1.6.2.24
1.6.2.3-rc1
1.6.2.3-rc2
1.6.2.4
1.6.2.5
1.6.2.6
1.6.2.6-rc1
1.6.2.6-rc2
1.6.2.7
1.6.2.7-rc1
1.6.2.7-rc2
1.6.2.7-rc3
1.6.2.8
1.6.2.8-rc1
1.6.2.8-rc2
1.6.2.9
1.6.2.9-rc1
1.6.2.9-rc2
1.6.2.9-rc3
1.8.0
1.8.0-beta1
1.8.0-beta2
1.8.0-beta3
1.8.0-beta4
1.8.0-beta5
1.8.0-rc1
1.8.0-rc2
1.8.0-rc3
1.8.0-rc4
1.8.0-rc5
1.8.1
1.8.1-rc1
1.8.1.1
1.8.1.2
1.8.10.0
1.8.10.0-rc1
1.8.10.0-rc2
1.8.10.0-rc3
1.8.10.0-rc4
1.8.10.1
1.8.11.0
1.8.11.0-rc1
1.8.11.0-rc2
1.8.11.0-rc3
1.8.11.1
1.8.12.0
1.8.12.0-rc1
1.8.12.0-rc2
1.8.12.0-rc3
1.8.12.1
1.8.12.2
1.8.13.0
1.8.13.0-rc1
1.8.13.0-rc2
1.8.13.1
1.8.14.0
1.8.14.0-rc1
1.8.14.0-rc2
1.8.14.1
1.8.15-cert4
1.8.15.0
1.8.15.0-rc1
1.8.15.1
1.8.16.0
1.8.16.0-rc1
1.8.16.0-rc2
1.8.17.0
1.8.17.0-rc1
1.8.17.0-rc2
1.8.17.0-rc3
1.8.18.0
1.8.18.0-rc1
1.8.18.1
1.8.19.0
1.8.19.0-rc1
1.8.19.0-rc2
1.8.19.0-rc3
1.8.19.0-tc1
1.8.19.1
1.8.2
1.8.2-rc1
1.8.2.1
1.8.2.2
1.8.2.3
1.8.2.4
1.8.20.0
1.8.20.0-rc1
1.8.20.0-rc2
1.8.20.1
1.8.20.2
1.8.21.0
1.8.21.0-rc1
1.8.21.0-rc2
1.8.22.0
1.8.22.0-rc1
1.8.22.0-rc2
1.8.23.0
1.8.23.0-rc1
1.8.23.0-rc2
1.8.23.1
1.8.24.0
1.8.24.0-rc1
1.8.24.0-rc2
1.8.24.1
1.8.25.0
1.8.25.0-rc1
1.8.25.0-rc2
1.8.26.0
1.8.26.0-rc1
1.8.26.0-rc2
1.8.26.1
1.8.27.0
1.8.27.0-rc1
1.8.27.0-rc2
1.8.28-cert5
1.8.28.0
1.8.28.0-rc1
1.8.28.1
1.8.28.2
1.8.29.0
1.8.29.0-rc1
1.8.3
1.8.3-rc1
1.8.3-rc2
1.8.3-rc3
1.8.3.1
1.8.3.2
1.8.3.3
1.8.30.0
1.8.30.0-rc1
1.8.31.0
1.8.31.0-rc1
1.8.31.1
1.8.32.0
1.8.32.0-rc1
1.8.32.0-rc2
1.8.32.1
1.8.32.2
1.8.32.3
1.8.4
1.8.4-rc1
1.8.4-rc2
1.8.4-rc3
1.8.4.1
1.8.4.2
1.8.4.3
1.8.4.4
1.8.5-rc1
1.8.5.0
1.8.5.1
1.8.6.0
1.8.6.0-rc1
1.8.6.0-rc2
1.8.6.0-rc3
1.8.7.0
1.8.7.0-rc1
1.8.7.0-rc2
1.8.7.1
1.8.7.2
1.8.8.0
1.8.8.0-rc1
1.8.8.0-rc2
1.8.8.0-rc3
1.8.8.0-rc4
1.8.8.0-rc5
1.8.8.1
1.8.8.2
1.8.9.0
1.8.9.0-rc1
1.8.9.0-rc2
1.8.9.0-rc3
1.8.9.1
1.8.9.2
1.8.9.3
10.0.0
10.0.0-beta1
10.0.0-beta2
10.0.0-rc1
10.0.0-rc2
10.0.0-rc3
10.0.0-rc4
10.0.1
10.1.0
10.1.0-rc1
10.1.0-rc2
10.1.1
10.1.2
10.1.3
10.10.0
10.10.0-digiumphones
10.10.0-digiumphones-rc1
10.10.0-digiumphones-rc2
10.10.0-rc1
10.10.0-rc2
10.10.1
10.10.1-digiumphones
10.11.0
10.11.0-digiumphones
10.11.0-digiumphones-rc1
10.11.0-digiumphones-rc2
10.11.0-digiumphones-rc3
10.11.0-rc1
10.11.0-rc2
10.11.0-rc3
10.11.1
10.11.1-digiumphones
10.12.0
10.12.0-digiumphones
10.12.0-digiumphones-rc1
10.12.0-digiumphones-rc2
10.12.0-rc1
10.12.0-rc2
10.12.1
10.12.1-digiumphones
10.12.2
10.12.2-digiumphones
10.12.3
10.12.3-digiumphones
10.12.4
10.12.4-digiumphones
10.2.0
10.2.0-rc1
10.2.0-rc2
10.2.0-rc3
10.2.0-rc4
10.2.1
10.3.0
10.3.0-rc1
10.3.0-rc2
10.3.0-rc3
10.3.1
10.4.0
10.4.0-digiumphones-rc1
10.4.0-digiumphones-rc2
10.4.0-rc1
10.4.0-rc2
10.4.0-rc3
10.4.1
10.4.2
10.5.0
10.5.0-digiumphones
10.5.0-digiumphones-rc1
10.5.0-digiumphones-rc2
10.5.0-rc1
10.5.0-rc2
10.5.1
10.5.1-digiumphones
10.5.2
10.5.2-digiumphones
10.6.0
10.6.0-digiumphones
10.6.0-digiumphones-rc1
10.6.0-digiumphones-rc2
10.6.0-rc1
10.6.0-rc2
10.6.1
10.6.1-digiumphones
10.7.0
10.7.0-digiumphones
10.7.0-digiumphones-rc1
10.7.0-rc1
10.7.1
10.7.1-digiumphones
10.8.0
10.8.0-digiumphones
10.8.0-digiumphones-rc1
10.8.0-digiumphones-rc2
10.8.0-rc1
10.8.0-rc2
10.9.0
10.9.0-digiumphones
10.9.0-digiumphones-rc1
10.9.0-digiumphones-rc2
10.9.0-digiumphones-rc3
10.9.0-rc1
10.9.0-rc2
10.9.0-rc3
11.0.0
11.0.0-beta1
11.0.0-beta2
11.0.0-rc1
11.0.0-rc2
11.0.1
11.0.2
11.1.0
11.1.0-rc1
11.1.0-rc2
11.1.0-rc3
11.1.1
11.1.2
11.10.0
11.10.0-rc1
11.10.1
11.10.2
11.11.0
11.11.0-rc1
11.12.0
11.12.0-rc1
11.12.1
11.13.0
11.13.0-rc1
11.13.1
11.14.0
11.14.0-rc1
11.14.0-rc2
11.14.1
11.14.2
11.15.0
11.15.0-rc1
11.15.0-rc2
11.15.1
11.16.0
11.16.0-rc1
11.17.0
11.17.0-rc1
11.17.1
11.18.0-rc1
11.19.0-rc1
11.2.0
11.2.0-rc1
11.2.0-rc2
11.2.1
11.2.2
11.20.0-rc1
11.20.0-rc2
11.20.0-rc3
11.21.0
11.21.0-rc1
11.21.0-rc2
11.21.0-rc3
11.21.1
11.22.0-rc1
11.3.0
11.3.0-rc1
11.3.0-rc2
11.4.0
11.4.0-rc1
11.4.0-rc2
11.4.0-rc3
11.5.0
11.5.0-rc1
11.5.0-rc2
11.5.1
11.6-cert11
11.6.0
11.6.0-rc1
11.6.0-rc2
11.6.1
11.7.0
11.7.0-rc1
11.7.0-rc2
11.8.0
11.8.0-rc1
11.8.0-rc2
11.8.0-rc3
11.8.1
11.9.0
11.9.0-rc1
11.9.0-rc2
11.9.0-rc3
12.0.0
12.0.0-alpha1
12.0.0-alpha2
12.0.0-beta1
12.0.0-beta2
12.1.0
12.1.0-rc1
12.1.0-rc2
12.1.0-rc3
12.1.1
12.2.0
12.2.0-rc1
12.2.0-rc2
12.2.0-rc3
12.3.0
12.3.0-rc1
12.3.0-rc2
12.3.1
12.3.2
12.4.0
12.4.0-rc1
12.5.0
12.5.0-rc1
12.5.1
12.6.0
12.6.0-rc1
12.6.1
12.7.0
12.7.0-rc1
12.7.0-rc2
12.7.1
12.7.2
12.8.0
12.8.0-rc1
12.8.0-rc2
12.8.1
12.8.2
13.0.0
13.0.0-beta1
13.0.0-beta2
13.0.0-beta3
13.0.1
13.0.2
13.1-cert2
13.1.0
13.1.0-rc1
13.1.0-rc2
13.1.1
13.2.0
13.2.0-rc1
13.2.1
13.3.0
13.3.0-rc1
13.3.1
13.3.2
13.4.0-rc1
13.5.0-rc1
13.6.0-rc1
13.6.0-rc2
13.6.0-rc3
13.7.0
13.7.0-rc1
13.7.0-rc2
13.7.0-rc3
13.7.1
13.8.0-rc1
certified/1.8.11-cert1
certified/1.8.11-cert10
certified/1.8.11-cert2
certified/1.8.11-cert3-rc1
certified/1.8.11-cert3-rc2
certified/1.8.11-cert4
certified/1.8.11-cert5
certified/1.8.11-cert5-rc1
certified/1.8.11-cert5-rc2
certified/1.8.11-cert6
certified/1.8.11-cert7
certified/1.8.11-cert8
certified/1.8.11-cert9
certified/1.8.11-cert9-rc1
certified/1.8.15-cert1
certified/1.8.15-cert1-rc1
certified/1.8.15-cert1-rc2
certified/1.8.15-cert1-rc3
certified/1.8.15-cert2
certified/1.8.15-cert3
certified/1.8.15-cert4
certified/1.8.15-cert5
certified/1.8.15-cert6
certified/1.8.15-cert7
certified/1.8.28-cert1
certified/1.8.28-cert1-rc1
certified/1.8.28-cert2
certified/1.8.28-cert3
certified/1.8.28-cert4
certified/1.8.28-cert5
certified/1.8.6-cert1
certified/11.2-cert1
certified/11.2-cert1-rc1
certified/11.2-cert1-rc2
certified/11.2-cert2
certified/11.2-cert3
certified/11.6-cert1
certified/11.6-cert1-rc1
certified/11.6-cert1-rc2
certified/11.6-cert10
certified/11.6-cert11
certified/11.6-cert12
certified/11.6-cert2
certified/11.6-cert3
certified/11.6-cert4
certified/11.6-cert5
certified/11.6-cert6
certified/11.6-cert7
certified/11.6-cert8
certified/11.6-cert9
certified/13.1-cert1
certified/13.1-cert1-rc1
certified/13.1-cert1-rc2
certified/13.1-cert1-rc3
certified/13.1-cert2
certified/13.1-cert3
${ noResults }
613 Commits (b4eb773d5ea9befa25e8045a57dba550a690e541)
Author | SHA1 | Message | Date |
---|---|---|---|
|
1d394774b2 |
app_dial.c: Make 'A' option pass COLP updates.
While the 'A' option is playing the announcement file allow the caller and peer to exchange COLP update frames. ASTERISK-25423 Reported by: John Hardin Change-Id: Iac6cf89b56d26452c6bb88e9363622bbf23895f9 |
10 years ago |
|
680b76eb25 |
app_dial.c: Force COLP update if outgoing channel name changed.
* When a call is answered and the outgoing channel name has changed then force a connected line update because the channel is no longer the same. The channel was masqueraded into by another channel. This is usually because of a call pickup. Note: Forwarded calls are handled in a controlled manner so the original channel name is replaced with the forwarded channel. ASTERISK-25423 Reported by: John Hardin Change-Id: I2e01f7a698fbbc8c26344a59c2be40c6cd98b00c |
10 years ago |
|
fdf0bcb04a |
app_dial.c: Factor out a connected line update routine.
Replace inlined code with update_connected_line_from_peer(). ASTERISK-25423 Reported by: John Hardin Change-Id: Ia14f18def417645cd7fb453e1bdac682630a5091 |
10 years ago |
|
c285879845 |
app_dial.c: Remove some no-op code.
Change-Id: Ice1884a94315d3cb7e3bbd47a9fba76a27276c54 |
10 years ago |
|
3b2b004d69 |
app_dial: Hold reference to calling channel formats when dialing outbound.
Currently when requesting a channel the native formats of the calling channel are provided to the core for usage when dialing the outbound channel. This occurs without holding the channel lock or keeping a reference to the formats. This is problematic as the channel driver may end up changing the formats during this time. In the case of chan_sip this happens when an SDP negotiation completes. This change makes it so app_dial keeps a reference to the native formats of the calling channel which guarantees that they will remain valid for the period of time needed. ASTERISK-25172 #close Change-Id: I2f0a67bd0d5d14c3bdbaae552b4b1613a283f0db |
10 years ago |
|
aae45acbda |
Detect potential forwarding loops based on count.
A potential problem that can arise is the following: * Bob's phone is programmed to automatically forward to Carol. * Carol's phone is programmed to automatically forward to Bob. * Alice calls Bob. If left unchecked, this results in an endless loops of call forwards that would eventually result in some sort of fiery crash. Asterisk's method of solving this issue was to track which interfaces had been dialed. If a destination were dialed a second time, then the attempt to call that destination would fail since a loop was detected. The problem with this method is that call forwarding has evolved. Some SIP phones allow for a user to manually forward an incoming call to an ad-hoc destination. This can mean that: * There are legitimate use cases where a device may be dialed multiple times, or * There can be human error when forwarding calls. This change removes the old method of detecting forwarding loops in favor of keeping a count of the number of destinations a channel has dialed on a particular branch of a call. If the number exceeds the set number of max forwards, then the call fails. This approach has the following advantages over the old: * It is much simpler. * It can detect loops involving local channels. * It is user configurable. The only disadvantage it has is that in the case where there is a legitimate forwarding loop present, it takes longer to detect it. However, the forwarding loop is still properly detected and the call is cleaned up as it should be. Address review feedback on gerrit. * Correct "mfgium" to "Digium" * Decrement max forwards by one in the case where allocation of the max forwards datastore is required. * Remove irrelevant code change from pjsip_global_headers.c ASTERISK-24958 #close Change-Id: Ia7e4b7cd3bccfbd34d9a859838356931bba56c23 |
10 years ago |
|
4a58261694 |
git migration: Refactor the ASTERISK_FILE_VERSION macro
Git does not support the ability to replace a token with a version string during check-in. While it does have support for replacing a token on clone, this is somewhat sub-optimal: the token is replaced with the object hash, which is not particularly easy for human consumption. What's more, in practice, the source file version was often not terribly useful. Generally, when triaging bugs, the overall version of Asterisk is far more useful than an individual SVN version of a file. As a result, this patch removes Asterisk's support for showing source file versions. Specifically, it does the following: * Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and remove passing the version in with the macro. Other facilities than 'core show file version' make use of the file names, such as setting a debug level only on a specific file. As such, the act of registering source files with the Asterisk core still has use. The macro rename now reflects the new macro purpose. * main/asterisk: - Refactor the file_version structure to reflect that it no longer tracks a version field. - Remove the "core show file version" CLI command. Without the file version, it is no longer useful. - Remove the ast_file_version_find function. The file version is no longer tracked. - Rename ast_register_file_version/ast_unregister_file_version to ast_register_file/ast_unregister_file, respectively. * main/manager: Remove value from the Version key of the ModuleCheck Action. The actual key itself has not been removed, as doing so would absolutely constitute a backwards incompatible change. However, since the file version is no longer tracked, there is no need to attempt to include it in the Version key. * UPGRADE: Add notes for: - Modification to the ModuleCheck AMI Action - Removal of the "core show file version" CLI command Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e |
10 years ago |
|
4740ef50f4 |
apps/app_dial: Don't publish DialEnd twice on unexpected GoSub/Macro values
The Dial application has some interesting options with the mid-call Macro (M) and GoSub (U) options. If the MACRO_RESULT/GOSUB_RESULT returns specific values, the Dial application will take some action upon the channels involved in the dial operation (such as hanging up a particular party, etc.) The Dial application ensures that a Stasis message is published in the event that MACRO_RESULT/GOSUB_RESULT returns a value that kills the dial operation, so that there is a corresponding DialEnd event published in AMI/ARI for the DialBegin event that preceeded it. A bug exists where that same DialEnd event will be published on Stasis even if the value returned in MACRO_RESULT/GOSUB_RESULT is not one that the Dial application cares about. This causes two DialEnd events to be published - one with the MACRO_RESULT/GOSUB_RESULT and another with "ANSWERED" - which is all sorts of wrong. This patch fixes the bug by ensuring that we only publish a DialEnd message to Stasis if the Dial application's mid-call Macro/GoSub returns something that Dial cares about. Review: https://reviewboard.asterisk.org/r/4336 ASTERISK-24682 #close Reported by: Matt Jordan ........ Merged revisions 430842 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430844 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
10 years ago |
|
ba5d5da60b |
Improve call forwarding reporting, especially with regards to ARI.
This patch addresses a few issues: 1) The order of Dial events have been changed when performing a call forward. The order has now been altered to 1) Dial begins dialing channel A. 2) When A forwards the call to B, we issue the dial end event to channel A, indicating the dial is being canceled due to a forward to B. 3) When the call to channel B occurs, we then issue a new dial begin to channel B. 2) Call forwards are now reported on the calling channel, not the peer channel. 3) AMI DialEnd events have been altered to display the extension the call is being forwarded to when relevant. 4) You can now get the values of channel variables for channels that are not currently in the Stasis application. This brings the retrieval of channel variables more in line with the rest of channel read operations since they may be performed on channels not in Stasis. ASTERISK-24134 #close Reported by Matt Jordan ASTERISK-24138 #close Reported by Matt Jordan Patches: forward-shenanigans.diff uploaded by Matt Jordan (License #6283) Review: https://reviewboard.asterisk.org/r/3899 ........ Merged revisions 420794 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421310 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
44fc6ea6ff |
apps/app_dial: Fix Dial 'z' option
The 'z' option is supposed to disable the dial timeout in the case of a call forward. Unfortunately, the wrong timeout timer was passed to the do_forward function, resulting in the option not working. ASTERISK-24225 #close Reported by: dimitripietro Tested by: dimitripietro patches: jira_asterisk_24225_v1.8.patch uploaded by rmudgett (License 5621) jira_asterisk_24225_v11.patch uploaded by rmudgett (License 5621) ........ Merged revisions 421232 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 421233 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 421234 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 421235 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421236 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
a2ce95d9d2 |
accountcode: Slightly change accountcode propagation.
The previous behavior was to simply set the accountcode of an outgoing channel to the accountcode of the channel initiating the call. It was done this way a long time ago to allow the accountcode set on the SIP/100 channel to be propagated to a local channel so the dialplan execution on the Local;2 channel would have the SIP/100 accountcode available. SIP/100 -> Local;1/Local;2 -> SIP/200 Propagating the SIP/100 accountcode to the local channels is very useful. Without any dialplan manipulation, all channels in this call would have the same accountcode. Using dialplan, you can set a different accountcode on the SIP/200 channel either by setting the accountcode on the Local;2 channel or by the Dial application's b(pre-dial), M(macro) or U(gosub) options, or by the FollowMe application's b(pre-dial) option, or by the Queue application's macro or gosub options. Before Asterisk v12, the altered accountcode on SIP/200 will remain until the local channels optimize out and the accountcode would change to the SIP/100 accountcode. Asterisk v1.8 attempted to add peeraccount support but ultimately had to punt on the support. The peeraccount support was rendered useless because of how the CDR code needed to unconditionally force the caller's accountcode onto the peer channel's accountcode. The CEL events were thus intentionally made to always use the channel's accountcode as the peeraccount value. With the arrival of Asterisk v12, the situation has improved somewhat so peeraccount support can be made to work. Using the indicated example, the the accountcode values become as follows when the peeraccount is set on SIP/100 before calling SIP/200: SIP/100 ---> Local;1 ---- Local;2 ---> SIP/200 acct: 100 \/ acct: 200 \/ acct: 100 \/ acct: 200 peer: 200 /\ peer: 100 /\ peer: 200 /\ peer: 100 If a channel already has an accountcode it can only change by the following explicit user actions: 1) A channel originate method that can specify an accountcode to use. 2) The calling channel propagating its non-empty peeraccount or its non-empty accountcode if the peeraccount was empty to the outgoing channel's accountcode before initiating the dial. e.g., Dial and FollowMe. The exception to this propagation method is Queue. Queue will only propagate peeraccounts this way only if the outgoing channel does not have an accountcode. 3) Dialplan using CHANNEL(accountcode). 4) Dialplan using CHANNEL(peeraccount) on the other end of a local channel pair. If a channel does not have an accountcode it can get one from the following places: 1) The channel driver's configuration at channel creation. 2) Explicit user action as already indicated. 3) Entering a basic or stasis-mixing bridge from a peer channel's peeraccount value. You can specify the accountcode for an outgoing channel by setting the CHANNEL(peeraccount) before using the Dial, FollowMe, and Queue applications. Queue adds the wrinkle that it will not overwrite an existing accountcode on the outgoing channel with the calling channels values. Accountcode and peeraccount values propagate to an outgoing channel before dialing. Accountcodes also propagate when channels enter or leave a basic or stasis-mixing bridge. The peeraccount value only makes sense for mixing bridges with two channels; it is meaningless otherwise. * Made peeraccount functional by changing accountcode propagation as described above. * Fixed CEL extracting the wrong ie value for the peeraccount. This was done intentionally in Asterisk v1.8 when that version had to punt on peeraccount. * Fixed a few places dealing with accountcodes that were reading from channels without the lock held. AFS-65 #close Review: https://reviewboard.asterisk.org/r/3601/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419520 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
abd3e4040b |
Allow Asterisk to compile under GCC 4.10
This resolves a large number of compiler warnings from GCC 4.10 which cause the build to fail under dev mode. The vast majority are signed/unsigned mismatches in printf-style format strings. ........ Merged revisions 413586 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 413587 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 413588 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413589 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
cbe7f65674 |
app_dial and app_queue: Make lock the forwarding channel while taking the channel snapshot.
* Fixed ast_channel_publish_dial_forward() not locking the forwarded channel when taking the channel snapshot. * Fixed app_dial.c:do_forward() using the wrong channel to get the original call forwarding string. * Removed unnecessary locking when calling ast_channel_publish_dial() and ast_channel_publish_dial_forward() in app_dial and app_queue. Holding channel locks when calling ast_channel_publish_dial_forward() with a forwarded channel could result in pausing the system while the stasis bus completes processsing a forwarded channel subscription. Review: https://reviewboard.asterisk.org/r/3451/ ........ Merged revisions 412579 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412580 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
80ef9a21b9 |
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and much change was necessary to accomplish it. Channel uniqueids and linkedids are split into separate string and creation time components without breaking linkedid propgation. This allowed the uniqueid to be specified by the user interface - and those values are now carried through to channel creation, adding the assignedids value to every function in the chain including the channel drivers. For local channels, the second channel can be specified or left to default to a ;2 suffix of first. In ARI, bridge, playback, and snoop objects can also be created with a specified uniqueid. Along the way, the args order to allocating channels was fixed in chan_mgcp and chan_gtalk, and linkedid is no longer lost as masquerade occurs. (closes issue ASTERISK-23120) Review: https://reviewboard.asterisk.org/r/3191/ ........ Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
66c46fba24 |
CDRs: fix a variety of dial status problems, h/hangup handler creating CDRs
This patch fixes a number of small-ish problems that were noticed when witnessing the records that the FreePBX dialplan produces: (1) Mid-call events (as well as privacy options) have the ability to change the overall state of the Dial operation after the called party answers. This means that publishing the DialEnd event when the called party is premature; we have to wait for the execution of these subroutines to complete before we can signal the overall status of the DialEnd. This patch moves that publication and adds handlers for the mid-call events. (2) The AST_FLAG_OUTGOING channel flag is cleared if an after bridge goto datastore is detected. This flag was preventing CDRs from being recorded for all outbound channels that had a 'continue' option enabled on them by the Dial application. (3) The CDR engine now locks the 'Dial' application as being the CDR application if it detects that the current CDR has entered that app. This is similar to the logic that is done for Parking. In general, if we entered into Dial, then we want that CDR to record the application as such - this prevents pre-dial handlers, mid-call handlers, and other shenaniganry from changing the application value. (4) The CDR engine now checks for the AST_SOFTHANGUP_HANGUP_EXEC in more places to determine if the channel is in hangup logic or dead. In either case, we don't want to record changes in the channel. (5) The default option for "endbeforehexten" has been changed to "yes". In general, you don't want to see CDRs in the 'h' exten or in hangup logic. Since the semantics of that option changed in 12, it made sense to update the default value as well. (6) Finally, because we now have the ability to synchronize on the messages published to the CDR topic, on shutdown the CDR engine will now synchronize to the messages currently in flight. This helps to ensure that all in-flight CDRs are written before shutting down. (closes issue ASTERISK-23164) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/3154 ........ Merged revisions 407084 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407085 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
f922912731 |
app_dial: Allow macro/gosub pre-bridge execution to occur on priorities
The parsing for the destination of the macro/gosub uses the '^' character to separate out context, extension, and priority. However, the logic for the macro/gosub execution was written such that it would only do the actual macro/gosub jump if a '^' character existed. This doesn't apply when the macro/gosub jump occurs in a priority/priority label. This patch changes the logic so that the parsing still occurs, but the jump will occur even for priorities/priority labels. (issue ASTERISK-23164) Review: https://reviewboard.asterisk.org/r/3154 ........ Merged revisions 407041 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 407074 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 407082 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407083 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
11 years ago |
|
28c0cb28d0 |
channel locking: Add locking for channel snapshot creation
Original commit message by mmichelson (asterisk 12 r403311): "This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such." The above was initially committed and then reverted at r403398. The problem was found to be in core_local.c in the publish_local_bridge_message function. The ast_unreal_lock_all function locks and adds a reference to the returned channels and while they were being unlocked they were not being unreffed when no longer needed. Fixed by unreffing the channels. Also in bridge.c a lock was obtained on "other->chan", but then an attempt was made to unlock "other" and not the previously locked channel. Fixed by unlocking "other->chan" (closes issue ASTERISK-22709) Reported by: John Bigelow ........ Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
3a5cc054ed |
res_stasis: Expose event for call forwarding and follow forwarded channel.
This change adds an event for when an originated call is redirected to another target. This event contains the original channel and the newly created channel. If a stasis subscription exists on the original originated channel for a stasis application then a new subscription will also be created on the stasis application to the redirected channel. This allows the application to follow the call path completely. (closes issue ASTERISK-22719) Reported by: Joshua Colp Review: https://reviewboard.asterisk.org/r/3054/ ........ Merged revisions 403808 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403810 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
1212906351 |
Reverting r403311. It's causing ARI tests to hang.
........ Merged revisions 403398 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403404 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
8e8b329e14 |
Add channel locking for channel snapshot creation.
This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such. ........ Merged revisions 403311 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403314 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
701847af22 |
Add an 'R' option to Dial which sends ringing until early media has been received.
(closes issue ASTERISK-10487) Reported by: Gaspar Zoltan Patches: 10487.patch uploaded by n8ideas (license 6075) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401411 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
057d105c5a |
Add channel lock protection around translation path setup.
Most callers of ast_channel_make_compatible() happen before the channels enter a two party bridge. With the new bridging framework, two party bridging technologies may also call ast_channel_make_compatible() when there is more than one thread involved with the two channels. * Added channel lock protection in set_format() and ast_channel_make_compatible_helper() when dealing with the channel's native formats while setting up a translation path. * Fixed best_src_fmt and best_dst_fmt usage consistency in ast_channel_make_compatible_helper(). The call to ast_translator_best_choice() got them backwards. * Updated some callers of ast_channel_make_compatible() and the function documentation. There is actually a difference between the two channels passed in. * Fixed the deadlock potential in res_fax.c dealing with ast_channel_make_compatible(). The deadlock potential was already there anyway because res_fax called ast_channel_make_compatible() with chan locked. (closes issue ASTERISK-22542) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2915/ ........ Merged revisions 401239 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401240 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
c1235f2639 |
Reduce channel snapshot creation and publishing by up to 50%.
This change introduces the ability to stage channel snapshot creation and publishing by suppressing the implicit creation and publishing that some functions have. Once all operations are executed the staging is marked as done and a single snapshot is created and published. Review: https://reviewboard.asterisk.org/r/2889/ ........ Merged revisions 400265 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400266 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
1df1ebdc37 |
Adding a few words to the Dial option 'r' help text to clarify its tone argument description
........ Merged revisions 399874 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399875 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
477dea4661 |
Bridge API: Set a cause code on a channel when it is ejected from a bridge.
The cause code needs to be passed from the disconnecting channel to the bridge peers if the disconnecting channel dissolves the bridge. * Made the call to an app_agent_pool agent disconnect with the busy cause code if the agent does not ack the call in time or hangs up before acking the call. (closes issue ASTERISK-22042) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2772/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397472 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
cafc115896 |
A great big renaming patch
This patch renames the bridging* files to bridge*. This may seem pedantic and silly, but it fits better in line with current Asterisk naming conventions: * channel is not "channeling" * monitor is not "monitoring" etc. A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is the act of using a bridge on a set of channels - and the API that fulfills that role is more than just the action. (closes issue ASTERISK-22130) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
9d8a5ceb02 |
Move after bridge callbacks into their own file
One more major refactoring to go. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395367 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
684c83b29b |
Add transfer support to CEL
This adds CEL support for blind and attended transfers and call pickup. During the course of adding this functionality I noticed that CONF_ENTER, CONF_EXIT, and BRIDGE_TO_CONF events are particularly useless without a bridge identifier, so I added that as well. This adds tests for blind transfers, several types of attended transfers, and call pickup. The extra field in CEL records now consists of a JSON blob whose fields are defined on a per-event basis. Review: https://reviewboard.asterisk.org/r/2658/ (closes issue ASTERISK-21565) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394858 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
a1e219ef51 |
CEL refactoring cleanup
This change removes AST_CEL_BRIDGE_UPDATE since it should no longer be used because masquerade situations are now accounted for in other ways. This also refactors usage of AST_CEL_FORWARD to be produced by a Dial message which has been extended with a "forward" field. (closes issue ASTERISK-21566) Review: https://reviewboard.asterisk.org/r/2635/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392829 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
6258bbe7bd |
Update Asterisk's CDRs for the new bridging framework
This patch is the initial push to update Asterisk's CDR engine for the new bridging framework. This patch guts the existing CDR engine and builds the new on top of messages coming across Stasis. As changes in channel state and bridge state are detected, CDRs are built and dispatched accordingly. This fundamentally changes CDRs in a few ways. (1) CDRs are now *very* reflective of the actual state of channels and bridges. This means CDRs track well with what an actual channel is doing - which is useful in transfer scenarios (which were previously difficult to pin down). It does, however, mean that CDRs cannot be 'fooled'. Previous behavior in Asterisk allowed for CDR applications, channels, and other properties to be spoofed in parts of the code - this no longer works. (2) CDRs have defined behavior in multi-party scenarios. This behavior will not be what everyone wants, but it is a defined behavior and as such, it is predictable. (3) The CDR manipulation functions and applications have been overhauled. Major changes have been made to ResetCDR and ForkCDR in particular. Many of the options for these two applications no longer made any sense with the new framework and the (slightly) more immutable nature of CDRs. There are a plethora of other changes. For a full description of CDR behavior, see the CDR specification on the Asterisk wiki. (closes issue ASTERISK-21196) Review: https://reviewboard.asterisk.org/r/2486/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391947 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
2dc8a06006 |
Refactor the features configuration scheme.
Features configuration is handled in its own API in features_config.h and features_config.c. This way, features configuration is accessible to anything that needs it. In addition, features configuration has been altered to be more channel-oriented. Most callers of features API code will be supplying a channel so that the individual channel's settings will be acquired rather than the global setting. Missing from this commit is XML documentation for the features configuration. That will be handled in a separate commit. Review: https://reviewboard.asterisk.org/r/2578/ (issue ASTERISK-21542) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390751 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
b6aac885be |
Add dial events to app_queue and app_followme.
Also fixes an issue in app_dial, where the channels were swapped on dial events. (closes issue ASTERISK-21551) (closes issue ASTERISK-21550) Review: https://reviewboard.asterisk.org/r/2549/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389492 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
3d63833bd6 |
Merge in the bridge_construction branch to make the system use the Bridging API.
Breaks many things until they can be reworked. A partial list: chan_agent chan_dahdi, chan_misdn, chan_iax2 native bridging app_queue COLP updates DTMF attended transfers Protocol attended transfers git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389378 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
d04f1fd60a |
Publish the outbound channel's application/data when dialing
This patch does two things: * It fixes a bug where the outbound channel's application/data set by the dialing API/app_dial is not communicated until the channel is hung up. If that happens, AMI would incorrectly send a NewExten event immediately after a Hangup. This isn't really AMI's fault, as the dialing APIs never communicated the 'helpful' app/data on the outbound channel until it was hungup. * It makes public sending a stasis message about a change in channel state. This is useful enough that - for now at least - it should be public. If operations on a channel go to being more coarse-grained, this function could be made private again. Review: https://reviewboard.asterisk.org/r/2548 Note that this problem was found and reported by Matt DiMeo. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388976 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
b8d4e573f1 |
Add multi-channel Stasis messages; refactor Dial AMI events to Stasis
This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
abfb23df6b |
app_dial: Honor the 'c' flag when the calling party hangs up
Apparently this feature became broken in 11, probably as a result of the Hangup Cause project. (closes issue ASTERISK-21113) Reprted by: Heiko Wundram Patches: app_dial.patch uploaded by Heiko Wundram (license 5822) ........ Merged revisions 381880 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381881 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
12 years ago |
|
f2bb9afe17 |
Multiple revisions 375993-375994
........ r375993 | mmichelson | 2012-11-07 11:01:13 -0600 (Wed, 07 Nov 2012) | 30 lines Fix misuses of timeouts throughout the code. Prior to this change, a common method for determining if a timeout was reached was to call a function such as ast_waitfor_n() and inspect the out parameter that told how many milliseconds were left, then use that as the input to ast_waitfor_n() on the next go-around. The problem with this is that in some cases, submillisecond timeouts can occur, resulting in the out parameter not decreasing any. When this happens thousands of times, the result is that the timeout takes much longer than intended to be reached. As an example, I had a situation where a 3 second timeout took multiple days to finally end since most wakeups from ast_waitfor_n() were under a millisecond. This patch seeks to fix this pattern throughout the code. Now we log the time when an operation began and find the difference in wall clock time between now and when the event started. This means that sub-millisecond timeouts now cannot play havoc when trying to determine if something has timed out. Part of this fix also includes changing the function ast_waitfor() so that it is possible for it to return less than zero when a negative timeout is given to it. This makes it actually possible to detect errors in ast_waitfor() when there is no timeout. (closes issue ASTERISK-20414) reported by David M. Lee Review: https://reviewboard.asterisk.org/r/2135/ ........ r375994 | mmichelson | 2012-11-07 11:08:44 -0600 (Wed, 07 Nov 2012) | 3 lines Remove some debugging that accidentally made it in the last commit. ........ Merged revisions 375993-375994 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375995 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 376014 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376015 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
e9ab568f88 |
Fix some potential misuses of ast_str in the code.
Passing an ast_str pointer by value that then calls ast_str_set(), ast_str_set_va(), ast_str_append(), or ast_str_append_va() can result in the pointer originally passed by value being invalidated if the ast_str had to be reallocated. This fixes places in the code that do this. Only the example in ccss.c could result in pointer invalidation though since the other cases use a stack-allocated ast_str and cannot be reallocated. I've also updated the doxygen in strings.h to include notes about potential misuse of the functions mentioned previously. Review: https://reviewboard.asterisk.org/r/2161 ........ Merged revisions 375025 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375026 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 375027 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375044 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
e51432027a |
Doxygen Clean ups
Add app_skel.c as an example in app.c and fix some formating for the "Dial Privacy scripts" so it actually shows up in the Doxygen output. (issue ASTERISK-20259) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374956 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
5c946d98ba |
Tweak app_dial documentation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373967 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
adefb772c4 |
Fix hangup cause passthrough regression.
The v1.8 -r369258 change to fix the F and F(x) action logic introduced a regression in passing the hangup cause from the called channel to the caller channel. (closes issue ASTERISK-20287) Reported by: Konstantin Suvorov Patches: app_dial_hangupcause.patch (license #6421) patch uploaded by Konstantin Suvorov (modified) Tested by: rmudgett ........ Merged revisions 371860 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 371861 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 371862 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371863 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
6a539ace84 |
Fix misuses of asprintf throughout the code.
This fixes three main issues * Change asprintf() uses to ast_asprintf() so that it pairs properly with ast_free() and no longer causes MALLOC_DEBUG to freak out. * When ast_asprintf() fails, set the pointer NULL if it will be referenced later. * Fix some memory leaks that were spotted while taking care of the first two points. (Closes issue ASTERISK-20135) reported by Richard Mudgett Review: https://reviewboard.asterisk.org/r/2071 ........ Merged revisions 371590 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 371591 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 371592 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371593 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
fbf4040a36 |
Clean up ManagerEvent Dial documentation
The paragraph describing the SubEvent belongs with the SubEvent parameter itself, and not with its enum values. The order of parsing was placing the description after the last enum, which isn't correct. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370329 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
ac35b92b62 |
Hangup handlers - Dialplan subroutines that run when the channel hangs up.
Hangup handlers are an alternative to the h extension. They can be used in addition to the h extension. The idea is to attach a Gosub routine to a channel that will execute when the call hangs up. Whereas which h extension gets executed depends on the location of dialplan execution when the call hangs up, hangup handlers are attached to the call channel. You can attach multiple handlers that will execute in the order of most recently added first. (closes issue ASTERISK-19549) Reported by: Mark Murawski Tested by: rmudgett Review: https://reviewboard.asterisk.org/r/2002/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369493 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
82a7409c15 |
Add AMI event documentation
This patch adds the core changes necessary to support AMI event documentation in the source files of Asterisk, and adds documentation to those AMI events defined in the core application modules. Event documentation is built from the source by two new python scripts, located in build_tools: get_documentation.py and post_process_documentation.py. The get_documentation.py script mirrors the actions of the existing AWK get_documentation scripts, except that it will scan the entirety of a source file for Asterisk documentation. Upon encountering it, if the documentation happens to be an AMI event, it will attempt to extract information about the event directly from the manager event macro calls that raise the event. The post_process_documentation.py script combines manager event instances that are the same event but documented in multiple source files. It generates the final core-[lang].xml file. As this process can take longer to complete than a typical 'make all', it is only performed if a new make target, 'full', is chosen. Review: https://reviewboard.asterisk.org/r/1967/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369346 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
3d1e26d2d2 |
Check if PBX was started and fix F and F(x) action logic in Dial application.
........ Merged revisions 369258 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 369259 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369260 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
f8746d0009 |
Allow non-normal execution routines to be able to run on hungup channels.
* Make non-normal dialplan execution routines be able to run on a hung up channel. This is preparation work for hangup handler routines. * Fixed ability to support relative non-normal dialplan execution routines. (i.e., The context and exten are optional for the specified dialplan location.) Predial routines are the only non-normal routines that it makes sense to optionally omit the context and exten. Setting a hangup handler also needs this ability. * Fix Return application being able to restore a dialplan location exactly. Channels without a PBX may not have context or exten set. * Fixes non-normal execution routines like connected line interception and predial leaving the dialplan execution stack unbalanced. Errors like missing Return statements, popping too many stack frames using StackPop, or an application returning non-zero could leave the dialplan stack unbalanced. * Fixed the AGI gosub application so it cleans up the dialplan execution stack and handles the autoloop priority increments correctly. * Eliminated the need for the gosub_virtual_context return location. Review: https://reviewboard.asterisk.org/r/1984/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368985 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
571445ab9c |
Convert AST_FLAG_ANSWERED_ELSEWHERE usage to AST_CAUSE_ANSWERED_ELSEWHERE
This was essentially duplicated functionality where normal channels used AST_CAUSE_ANSWERED_ELSEWHERE while local channels and queues used AST_FLAG_ANSWERED_ELSEWHERE. This removes the flag and converts that usage into AST_CAUSE_ANSWERED_ELSEWHER usage. Review: https://reviewboard.asterisk.org/r/1944 (closes issue ASTERISK-19865) Patch-by: Birger Harzenetter git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368519 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
e518536773 |
Fix Dial I option ignored if dial forked and one fork redirects.
The Dial and Queue I option is intended to block connected line updates and redirecting updates. However, it is a feature that when a call is locally redirected, the I option is disabled if the redirected call runs as a local channel so the administrator can have an opportunity to setup new connected line information. Unfortunately, the Dial and Queue I option is disabled for *all* forked calls if one of those calls is redirected. * Make the Dial and Queue I option apply to each outgoing call leg independently. Now if one outgoing call leg is locally redirected, the other outgoing calls are not affected. * Made Dial not pass any redirecting updates when forking calls. Redirecting updates do not make sense for this scenario. * Made Queue not pass any redirecting updates when using the ringall strategy. Redirecting updates do not make sense for this scenario. * Fixed deadlock potential with chan_local when Dial and Queue send redirecting updates for a local redirect. * Converted the Queue stillgoing flag to a boolean bitfield. (closes issue ASTERISK-19511) Reported by: rmudgett Tested by: rmudgett Review: https://reviewboard.asterisk.org/r/1920/ ........ Merged revisions 367678 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 367679 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367693 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
b5a6de76fc |
Commit framework for HANGUPCAUSE (replacement for SIP_CAUSE)
This is the starting point for the Asterisk 11: Who Hung Up work and provides a framework which will allow channel drivers to report the types of hangup cause information available in SIP_CAUSE without incurring the overhead of the MASTER_CHANNEL dialplan function. The initial implementation only includes cause generation for chan_sip and does not include cause code translation utilities. This change deprecates SIP_CAUSE and replaces its method of reporting cause codes with the new framework. This change also deprecates the 'storesipcause' option in sip.conf. Review: https://reviewboard.asterisk.org/r/1822/ (Closes issue SWP-4221) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366408 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
098f74dd4e |
Tweak app_dial predial documentation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366193 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
4ea636c776 |
Run predial routine on local;2 channel where you would expect.
Before this patch, the predial routine executes on the ;1 channel of a local channel pair. Executing predial on the ;1 channel of a local channel pair is of limited utility. Any channel variables set by the predial routine executing on the ;1 channel will not be available when the local channel executes dialplan on the ;2 channel. * Create ast_pre_call() and an associated pre_call() technology callback to handle running the predial routine. If a channel technology does not provide the callback, the predial routine is simply run on the channel. Review: https://reviewboard.asterisk.org/r/1903/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366183 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
e8a6e0ef0e |
PreDial - Ability to run dialplan on callee and caller channels before Dial.
Thanks to Mark Murawski for the initial patch and feature definition. (closes issue ASTERISK-19548) Reported by: Mark Murawski Review: https://reviewboard.asterisk.org/r/1878/ Review: https://reviewboard.asterisk.org/r/1229/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364436 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
f663924517 |
Make app_dial and app_queue use new macro and gosub calls.
* Simplify some code in app_dial and app_queue by calling ast_app_exec_macro() and ast_app_exec_sub(). * Fix minor locking issue in app_dial for post-answer macro/gosub MACRO/GOSUB_RESULT=GOTO: handling. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@363269 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
c870dad57e |
Update app_dial M and U option GOTO return value documentation.
........ Merged revisions 362997 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 362998 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362999 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
01194c5811 |
Use ast_channel_lock_both() where it was inlined before.
The CHANNEL_DEADLOCK_AVOIDANCE() feature of preserving where the channel lock was originally obtained is overkill where ast_channel_lock_both() was inlined. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362888 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
51f0e5c53d |
Remove unnecessary error message in app_dial.c
The error message for failure to stop autoservice after a gosub or macro call during a dial was removed for macro while Asterisk 1.4 was still being actively developed. The corresponding gosub error message was never removed. (closes issue ASTERISK-19551) ........ Merged revisions 361329 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 361330 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@361331 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
c6979ff581 |
Adds F option to Bridge application
Similar to dial and queue F option. (Closes issue ASTERISK-19282) Reported by: To Patches: bridge_f-v3.diff uploaded by To (license 6347) Review: https://reviewboard.asterisk.org/r/1825/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360227 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
827f2eae92 |
Revert the pre-dial addition.
The code may be just fine, but it had not received a "ship it!" on review board yet. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@359857 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
c65b41f57a |
Add options PreDial options 'b' and 'B' to app_dial
* Added 'b' and 'B' options to Dial. These options will allow you to run last-minute dialplan on the caller and callee channels while the Dial application is executing, but before the call is started. For example you can use the 'b' option to run dialplan on the callee channel to get the name of the newly created channel right away. Review: https://reviewboard.asterisk.org/r/1229/ (closes issue: ASTERISK-19548) Reported by: Mark Murawski Tested by: Mark Murawski, Stefan Schmidt git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@359705 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
e9703da1d5 |
Add missing connected line macro calls to initial dial for Dial and Queue apps.
The connected line interception macros do not get executed when the outgoing channel is initially created and that channel's caller-id is implicitly imported into the incoming channel's connected line data. If you are using the interception macros, you would expect that they get run for every change to a channel's connected line information outside of normal dialplan execution. Review: https://reviewboard.asterisk.org/r/1817/ ........ Merged revisions 359609 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 359620 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@359644 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
2019a7e6b9 |
Fix Dial m and r options and forked calls generating warnings for voice frames.
When connected line support was added, the wait_for_answer() variable single changed its meaning slightly. Unfortunately, the places where single was used did not necessarily get updated to reflect that change. Also audio/video frames were sent to all forked calls when the endpoints were never made compatible. * Don't pass audio/video media frames when the channels have not been made compatible. * Added handling of AST_CONTROL_SRCCHANGE to app_dial.c. * Fixed app_dial.c passing on AST_CONTROL_HOLD because that frame can also pass a requested MOH class. (closes issue ASTERISK-16901) Reported by: Chris Gentle (closes issue ASTERISK-17541) Reported by: clint Review: https://reviewboard.asterisk.org/r/1805/ ........ Merged revisions 359344 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 359355 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@359357 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
786f5898d1 |
Finalize ast_channel opaquification
Review: https://reviewboard.asterisk.org/r/1786/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@358907 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
4657b016ad |
Resolve a few more cases of variable shadowing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@358691 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
571cef491f |
Fix copying of CDR(accountcode) to local channels.
In r203638, during the addition of the Channel Event Logging, in mid-2009, this got broken in trunk and ended up in asterisk 1.8 and higher. This fixes so the CDR(accountcode) from the calling channel is available to dialed channels again as well as showing up properly in the CDR's. (closes issue ASTERISK-19384) Reported by: jamicque Patches: accountcode.patch (License #6033) by jamicque Review: https://reviewboard.asterisk.org/r/1775/ Reviewed by: Richard Mudgett ........ Merged revisions 357575 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 357576 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@357577 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
a9d607a357 |
Opaquify ast_channel structs and lists
Review: https://reviewboard.asterisk.org/r/1773/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@357542 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
1fac2fba4b |
Deprecated macro usage for connected line, redirecting, and CCSS
This commit adds GoSub alternatives to connected line, redirecting, and CCSS macro hooks so that macro can finally be deprecated. This also adds deprecation warnings for those features when used and in documentation. Review: https://reviewboard.asterisk.org/r/1760/ (closes issue SWP-4256) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@357013 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
57f42bd74f |
ast_channel opaquification of pointers and integral types
Review: https://reviewboard.asterisk.org/r/1753/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@356042 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
34c55e8e7c |
Opaquify char * and char[] in ast_channel
Review: https://reviewboard.asterisk.org/r/1733/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@354968 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
db24fc2523 |
Avoid cppcheck warnings; removing unused vars and a bit of cleanup.
Patch by: Clod Patry Review: https://reviewboard.asterisk.org/r/1651 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@354429 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
99cae5b750 |
Opaquify channel stringfields
Continue channel opaque-ification by wrapping all of the stringfields. Eventually, we will restrict what can actually set these variables, but the purpose for now is to hide the implementation and keep people from adding code that directly accesses the channel structure. Semantic changes will follow afterward. Review: https://reviewboard.asterisk.org/r/1661/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352348 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
13 years ago |
|
edf466012f |
Make FollowMe optionally update connected line information when the accepting endpoint is bridged.
Like Dial and Queue, FollowMe needs to deal with AST_CONTROL_CONNECTED_LINE information so when the parties are initially bridged, the connected line information will be correct. * Added the 'I' option just like the app_dial and app_queue 'I' option. * Made 'N' option ignored if the call is already answered. (closes issue ASTERISK-18969) Reported by: rmudgett Tested by: rmudgett Review: https://reviewboard.asterisk.org/r/1656/ ........ Merged revisions 350364 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 350415 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350416 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
04da92c379 |
Replace direct access to channel name with accessor functions
There are many benefits to making the ast_channel an opaque handle, from increasing maintainability to presenting ways to kill masquerades. This patch kicks things off by taking things a field at a time, renaming the field to '__do_not_use_${fieldname}' and then writing setters/getters and converting the existing code to using them. When all fields are done, we can move ast_channel to a C file from channel.h and lop off the '__do_not_use_'. This patch sets up main/channel_interal_api.c to be the only file that actually accesses the ast_channel's fields directly. The intent would be for any API functions in channel.c to use the accessor functions. No more monkeying around with channel internals. We should use our own APIs. The interesting changes in this patch are the addition of channel_internal_api.c, the moving of the AST_DATA stuff from channel.c to channel_internal_api.c (note: the AST_DATA stuff will have to be reworked to use accessor functions when ast_channel is really opaque), and some re-working of the way channel iterators/callbacks are handled so as to avoid creating fake ast_channels on the stack to pass in matching data by directly accessing fields (since "name" is a stringfield and the fake channel doesn't init the stringfields, you can't use the ast_channel_name_set() function). I went with ast_channel_name(chan) for a getter, and ast_channel_name_set(chan, name) for a setter. The majority of the grunt-work for this change was done by writing a semantic patch using Coccinelle ( http://coccinelle.lip6.fr/ ). Review: https://reviewboard.asterisk.org/r/1655/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350223 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
011843e36c |
Fix missing doc tags found while fixing ASTERISK-18689
Add missing <variable></variable> tags in app_dial documentation. ........ Merged revisions 348992 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 348993 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@348994 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
e4b07e2d38 |
Merged revisions 339512 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/10 ................ r339512 | rmudgett | 2011-10-05 12:01:46 -0500 (Wed, 05 Oct 2011) | 9 lines Merged revisions 339511 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r339511 | rmudgett | 2011-10-05 12:01:01 -0500 (Wed, 05 Oct 2011) | 1 line Fix Dial F option notes formatting. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@339513 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
12a6131653 |
Merged revisions 339145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/10 ................ r339145 | lmadsen | 2011-10-03 14:55:15 -0500 (Mon, 03 Oct 2011) | 13 lines Merged revisions 339144 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r339144 | lmadsen | 2011-10-03 14:54:52 -0500 (Mon, 03 Oct 2011) | 6 lines Make documentation for Dial() options 'F' and 'F()' more clear. (Closes issue ASTERISK-18646) Reported by: Physis Heckman Tested by: Richard Mudgett ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@339146 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
55b70ae625 |
Merged revisions 337974 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/10 ................ r337974 | rmudgett | 2011-09-26 14:35:23 -0500 (Mon, 26 Sep 2011) | 37 lines Merged revisions 337973 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r337973 | rmudgett | 2011-09-26 14:30:39 -0500 (Mon, 26 Sep 2011) | 30 lines Fix deadlock when using dummy channels. Dummy channels created by ast_dummy_channel_alloc() should be destoyed by ast_channel_unref(). Using ast_channel_release() needlessly grabs the channel container lock and can cause a deadlock as a result. * Analyzed use of ast_dummy_channel_alloc() and made use ast_channel_unref() when done with the dummy channel. (Primary reason for the reported deadlock.) * Made app_dial.c:dial_exec_full() not call ast_call() holding any channel locks. Chan_local could not perform deadlock avoidance correctly. (Potential deadlock exposed by this issue. Secondary reason for the reported deadlock since the held lock was part of the deadlock chain.) * Fixed some uses of ast_dummy_channel_alloc() not checking the returned channel pointer for failure. * Fixed some potential chan=NULL pointer usage in func_odbc.c. Protected by testing the bogus_chan value. * Fixed needlessly clearing a 1024 char auto array when setting the first char to zero is enough in manager.c:action_getvar(). (closes issue ASTERISK-18613) Reported by: Thomas Arimont Patches: jira_asterisk_18613_v1.8.patch (license #5621) patch uploaded by rmudgett Tested by: Thomas Arimont ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@337975 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
e218748ac1 |
Merged revisions 337120 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/10 ................ r337120 | mjordan | 2011-09-20 17:49:36 -0500 (Tue, 20 Sep 2011) | 28 lines Merged revisions 337118 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r337118 | mjordan | 2011-09-20 17:38:54 -0500 (Tue, 20 Sep 2011) | 21 lines Fix for incorrect voicemail duration in external notifications This patch fixes an issue where the voicemail duration was being reported with a duration significantly less than the actual sound file duration. Voicemails that contained mostly silence were reporting the duration of only the sound in the file, as opposed to the duration of the file with the silence. This patch fixes this by having two durations reported in the __ast_play_and_record family of functions - the sound_duration and the actual duration of the file. The sound_duration, which is optional, now reports the duration of the sound in the file, while the actual full duration of the file is reported in the duration parameter. This allows the voicemail applications to use the sound_duration for minimum duration checking, while reporting the full duration to external parties if the voicemail is kept. (issue ASTERISK-2234) (closes issue ASTERISK-16981) Reported by: Mary Ciuciu, Byron Clark, Brad House, Karsten Wemheuer, KevinH Tested by: Matt Jordan Review: https://reviewboard.asterisk.org/r/1443 ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@337124 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
5c71a502a7 |
Merged revisions 336659 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/10 ................ r336659 | rmudgett | 2011-09-19 13:51:19 -0500 (Mon, 19 Sep 2011) | 38 lines Merged revisions 336658 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r336658 | rmudgett | 2011-09-19 13:46:40 -0500 (Mon, 19 Sep 2011) | 31 lines Made Dial d and H options no longer immediately auto-answer the calling leg. The Dial d and H options break DTMF attended transfer atxferdropcall option. 1) Party A calls party B. 2) Party B does a DTMF attended transfer to Party C. If the dialplan uses the Dial d or H options to call Party C then the Dial application answers the call immediately before initiating the call leg to Party C. The premature answer causes the transfer code to not invoke the atxferdropcall=no behavior for a blonde transfer since Party C has "answered". The transfer code thinks that Party B has "consulted" with Party C when Party B hangs up and completes the transfer to Party A. Party A now hears ringback until Party C actually answers. ASTERISK-13294 Dial d option. ASTERISK-11067 Dial H option to disconnect before answer. The referenced issues made Dial answer with the d and H options because many SIP and ISDN phones cannot send DTMF before the call is connected. * Made require the dialplan to control when or if the call needs to be answered to use the Dial application d and H options. (The call is no longer surprise answered when using the Dial d or H options.) Review: https://reviewboard.asterisk.org/r/1381/ JIRA AST-623 JIRA AST-666 ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@336662 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
782cfdc775 |
Merged revisions 335346 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/10 ................ r335346 | kmoore | 2011-09-12 09:22:15 -0500 (Mon, 12 Sep 2011) | 17 lines Merged revisions 335341 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r335341 | kmoore | 2011-09-12 09:21:17 -0500 (Mon, 12 Sep 2011) | 10 lines Ensure frames are not written to dialed channel if ringback is requested When a single channel was dialed and there was media to be forwarded to the calling channel, the media was written without regard for ringback causing silence to be heard in some circumstances. This regression was introduced when the meaning of "single" changed to mean only the number of channels dialed. (closes issue ASTERISK-18083) ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@335354 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
8b5ba33fe0 |
Merged revisions 335078 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/10 ................ r335078 | mjordan | 2011-09-09 11:27:01 -0500 (Fri, 09 Sep 2011) | 29 lines Merged revisions 335064 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r335064 | mjordan | 2011-09-09 11:09:09 -0500 (Fri, 09 Sep 2011) | 23 lines Updated SIP 484 handling; added Incomplete control frame When a SIP phone uses the dial application and receives a 484 Address Incomplete response, if overlapped dialing is enabled for SIP, then the 484 Address Incomplete is forwarded back to the SIP phone and the HANGUPCAUSE channel variable is set to 28. Previously, the Incomplete application dialplan logic was automatically triggered; now, explicit dialplan usage of the application is required. Additionally, this patch adds a new AST_CONTOL_FRAME type called AST_CONTROL_INCOMPLETE. If a channel driver receives this control frame, it is an indication that the dialplan expects more digits back from the device. If the device supports overlap dialing it should attempt to notify the device that the dialplan is waiting for more digits; otherwise, it can handle the frame in a manner appropriate to the channel driver. (closes issue ASTERISK-17288) Reported by: Mikael Carlsson Tested by: Matthew Jordan Review: https://reviewboard.asterisk.org/r/1416/ ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@335079 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
39fe851e79 |
Merged revisions 331644 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/10 ................ r331644 | jrose | 2011-08-12 11:18:57 -0500 (Fri, 12 Aug 2011) | 9 lines Merged revisions 331635 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r331635 | jrose | 2011-08-12 10:49:17 -0500 (Fri, 12 Aug 2011) | 1 line Fixes 32bit compilation warnings brought on by 331634 in app_dial and app_meetme ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@331717 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
1a8069abe2 |
Merged revisions 331579 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/10 ................ r331579 | qwell | 2011-08-11 16:54:54 -0500 (Thu, 11 Aug 2011) | 13 lines Merged revisions 331578 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r331578 | qwell | 2011-08-11 16:46:39 -0500 (Thu, 11 Aug 2011) | 6 lines Use proper values for 64-bit option flags. Also, reusing bits es no bueno, so change the value of a duplicate. (issue ASTERISK-18239) ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@331580 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
3719ee2d65 |
Merged revisions 328664 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.10 ................ r328664 | markm | 2011-07-18 16:50:13 -0400 (Mon, 18 Jul 2011) | 15 lines Merged revisions 328663 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r328663 | markm | 2011-07-18 16:47:04 -0400 (Mon, 18 Jul 2011) | 9 lines app_dial may double free a channel datastore When starting a call with originate, and having the callee channel run Bridge() on pickup, we will double free the dialed_interface_info datastore, causing a crash. Make sure to check if the datastore still exists before trying to free it. (closes issue ASTERISK-17917) Reported by: Mark Murawski Tested by: Mark Murawski ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@328665 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
a525edea59 |
Merged revisions 328247 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.10 ................ r328247 | lmadsen | 2011-07-14 16:25:31 -0400 (Thu, 14 Jul 2011) | 14 lines Merged revisions 328209 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r328209 | lmadsen | 2011-07-14 16:13:06 -0400 (Thu, 14 Jul 2011) | 6 lines Introduce <support_level> tags in MODULEINFO. This change introduces MODULEINFO into many modules in Asterisk in order to show the community support level for those modules. This is used by changes committed to menuselect by Russell Bryant recently (r917 in menuselect). More information about the support level types and what they mean is available on the wiki at https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Support+States ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@328259 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
6c7d437287 |
Merged revisions 325537 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r325537 | mnicholson | 2011-06-29 10:34:47 -0500 (Wed, 29 Jun 2011) | 2 lines don't do native/remote bridging if a framehook is active on the channel ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@325538 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
0096238b52 |
Merged revisions 320823 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r320823 | rmudgett | 2011-05-25 12:06:38 -0500 (Wed, 25 May 2011) | 18 lines The AMI Newstate event contains different information between v1.4 and v1.8. The addition of connected line support in v1.8 changes the behavior of the channel caller ID somewhat. The channel caller ID value no longer time shares with the connected line ID on outgoing call legs. The timing of some AMI events/responses output the connected line ID as caller ID. These party ID's are now separate. * The ConnectedLineNum and ConnectedLineName headers were added to many AMI events/responses if the CallerIDNum/CallerIDName headers were also present. (closes issue #18252) Reported by: gje Tested by: rmudgett Review: https://reviewboard.asterisk.org/r/1227/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@320825 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
2760e05dea |
Merged revisions 319529 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r319529 | twilson | 2011-05-18 13:05:34 -0700 (Wed, 18 May 2011) | 24 lines Merged revisions 319528 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r319528 | twilson | 2011-05-18 13:02:06 -0700 (Wed, 18 May 2011) | 17 lines Merged revisions 319527 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r319527 | twilson | 2011-05-18 12:56:08 -0700 (Wed, 18 May 2011) | 10 lines Fix app_dial ring groups Revert part of r315643. We need to remove the datastore here as well. The code in bridging code will catch anything that app_dial might miss. (closes issue #19311) Reported by: mspuhler Patches: issue_19311_no_answer.diff uploaded by elguero (license 37) ........ ................ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@319530 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
8d2a71877a |
Merged revisions 315644 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r315644 | twilson | 2011-04-26 14:39:01 -0700 (Tue, 26 Apr 2011) | 32 lines Merged revisions 315643 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r315643 | twilson | 2011-04-26 14:27:44 -0700 (Tue, 26 Apr 2011) | 25 lines Merged revisions 315596 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r315596 | twilson | 2011-04-26 14:16:10 -0700 (Tue, 26 Apr 2011) | 18 lines Allow transfer loops without allowing forwarding loops We try to avoid the situation where two phones may be forwarded to each other causing an infinite loop by storing each dialed interface in a channel datastore and checking the list before dialing out. This works, but currently breaks situations like A calls B, A transfers B to C, B transfers C to A, and A transfers C to B. Since human interaction is happening here and not an automated forwarding loop, it should be allowed. This patch removes the dialed_interfaces datastore when a call is bridged (a suggestion from the brilliant mmichelson). If a call is being bridged, it should be safe to assume that we aren't stuck in a loop. Since we are now handling this is the bridge code, the previous attempts at handling it in app_dial and app_queue are removed. Review: https://reviewboard.asterisk.org/r/1195/ ........ ................ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@315670 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
abe0351e12 |
Merged revisions 315452 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r315452 | rmudgett | 2011-04-26 13:00:34 -0500 (Tue, 26 Apr 2011) | 1 line Add missing set of name valid flag when dialing. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@315453 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
072970e1ab |
Merged revisions 314203 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r314203 | lmadsen | 2011-04-19 09:24:25 -0500 (Tue, 19 Apr 2011) | 15 lines Merged revisions 314202 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ........ r314202 | lmadsen | 2011-04-19 09:23:39 -0500 (Tue, 19 Apr 2011) | 7 lines Update seconds to milliseconds in ast_verb output. (closes issue #19084) Reported by: smurfix Patches: app_dial.patch uploaded by smurfix (license 547) Tested by: lmadsen, smurfix ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@314204 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
7c4fc0f0e8 |
Merged revisions 314068 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r314068 | rmudgett | 2011-04-18 11:02:12 -0500 (Mon, 18 Apr 2011) | 7 lines Unclear code in app_dial.c. Make code formatting clear. (closes issue #19134) Reported by: oej ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@314079 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
663ed7fd5c |
Merged revisions 313368-313369 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r313368 | rmudgett | 2011-04-11 18:03:02 -0500 (Mon, 11 Apr 2011) | 2 lines Backport a restructuring change from trunk to make the next change stand out. ........ r313369 | rmudgett | 2011-04-11 18:08:02 -0500 (Mon, 11 Apr 2011) | 13 lines Frames from the inbound channel should go to all outbound channels in app_dial.c. In app_dial.c:wait_for_answer() frames from the inbound channel should be sent to all outbound channels instead of only if there is just one outbound channel. Control frames like AST_CONTROL_CONNECTED_LINE need to be passed to all of the the outbound channels. This can happen if a blond transfer is done by a remote switch on the inbound channel. JIRA AST-443 JIRA SWP-2730 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@313383 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
4a8c77976c |
Merged revisions 311295 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r311295 | rmudgett | 2011-03-17 21:22:07 -0500 (Thu, 17 Mar 2011) | 35 lines Merged revision 310986 from https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier .......... r310986 | rmudgett | 2011-03-16 13:56:28 -0500 (Wed, 16 Mar 2011) | 28 lines Dial() o option broke when connected line feature added. The patch restores the o option behavior and adds the ability to specify the CallerID. The Dial o and f options are complementary to each other. The o option stores the CallerID on the outgoing channel as the channel's CallerID. The f option forces the CallerID sent by the outgoing channel. o(x) - The argument 'x' is optional. If not present, then specify that the CallerID that was present on the *calling* channel be stored as the CallerID on the *called* channel. This was the behavior of Asterisk 1.0 and earlier. If present, then specify the CallerID stored on the *called* channel. Note that o(${CALLERID(all)}) is similar to option o without parameters. f(x) - The argument 'x' is optional and its presence changes the behavior of this option. If not present, then force the outgoing CallerID on a call-forward or deflection to the dialplan extension for this Dial() using a dialplan 'hint'. For example, some PSTNs do not allow CallerID to be set to anything other than the numbers assigned to you. If present, then force the outgoing CallerID to 'x'. Patches: jira_abe_2752_dial_fo_options.patch uploaded by rmudgett (license 664) Tested by: rmudgett JIRA ABE-2752 JIRA SWP-3096 .......... ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@311296 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
b1db966684 |
Merged revisions 307962 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r307962 | rmudgett | 2011-02-15 13:52:45 -0600 (Tue, 15 Feb 2011) | 1 line Don't crash when forcing caller id. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@307963 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
7800a1c330 |
Merged revisions 307750 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r307750 | tilghman | 2011-02-14 00:50:23 -0600 (Mon, 14 Feb 2011) | 23 lines Calling a gosub routine defined in AEL from Dial/Queue ceased to work. A bug in AEL did not distinguish between the "s" extension generated by AEL and an "s" extension that was required to exist by the chan_dahdi (or another channel) that was not supplied with a starting extension. Therefore, AEL made incorrect assumptions about what commands were permissable in the context. This was fixed by making AEL generate a different extension name. However, Dial and Queue make additional assumptions about the name of the default gosub extension. Therefore, they needed to be brought into line with a "macro" rendered by AEL (as a gosub), without breaking traditional dialplans written without the aid of AEL. Related to (issue #18480) Reported by: nivek (closes issue #18729) Reported by: kkm Patches: 20110209__issue18729.diff.txt uploaded by tilghman (license 14) 018729-dial-queue-gosub-try3.patch uploaded by kkm (license 888) Tested by: kkm ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@307751 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
a8aeb04a9f |
Add ISDN display ie text handling options to chan_dahdi.conf.
The display ie handling can be controlled independently in the send and receive directions with the following options: * Block display text data. * Use display text in SETUP/CONNECT messages for name. * Use display text for COLP name updates (FACILITY/NOTIFY as appropriate). * Pass arbitrary display text during a call. Sent in INFORMATION messages. Received from any message that the display text was not used as a name. If the display options are not set then the options default to legacy behavior. The arbitrary display text is exchanged between bridged channels using the AST_FRAME_TEXT frame type. To send display text from the dialplan use the SendText() application when the arbitrary display text option is enabled. JIRA SWP-2688 JIRA ABE-2693 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306396 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
4d8feab7fa |
Merged revisions 306324 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r306324 | rmudgett | 2011-02-04 12:53:06 -0600 (Fri, 04 Feb 2011) | 9 lines Don't send redirecting updates to the caller if the dialplan forked the call. Each fork in the dial could be redirected and confuse the caller. For ISDN the DivLeg1 and DivLeg3 messages would get confused because ISDN redirects calls in sequence not in parallel. * Also fixed a formatting inconsistency in app_dial.c and make a warning message more useful about what frame type could not be written. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306325 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
6908539952 |
Merged revisions 305254 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r305254 | qwell | 2011-01-31 17:07:00 -0600 (Mon, 31 Jan 2011) | 24 lines Merged revisions 305253 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r305253 | qwell | 2011-01-31 16:59:34 -0600 (Mon, 31 Jan 2011) | 17 lines Merged revisions 305252 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r305252 | qwell | 2011-01-31 16:56:54 -0600 (Mon, 31 Jan 2011) | 10 lines 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/trunk@305255 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |
|
876d5dede7 |
Merged revisions 302918 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r302918 | lmadsen | 2011-01-20 09:45:39 -0600 (Thu, 20 Jan 2011) | 16 lines Merged revisions 302917 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ........ r302917 | lmadsen | 2011-01-20 09:42:05 -0600 (Thu, 20 Jan 2011) | 8 lines Option L() is milliseconds, not seconds. > Change the verbose output of option L() to say milliseconds and not seconds > as the value is in milliseconds. > > (closes issue #18264) > Reported by: jacco > Patches: > app_dial_patch.txt uploaded by lmadsen (license 10) ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302919 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
14 years ago |