mirror of https://github.com/asterisk/asterisk
master
20
22
23
revert-1530-endpoints-remove-subscription-and-router
revert-1412-master-feature-extended-hangupcause
releases/22
releases/21
releases/23
releases/20
master-issue-1604
21
certified/18.9
certified/20.7
18
revert-1477-taskpool-pjsip
releases/21-pre-reorder
releases/20-pre-reorder
releases/22.5
releases/20.15
releases/21.10
releases/18
releases/certified-18.9
releases/certified-20.7
releases/22.4
releases/21.9
releases/20.14
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.7.0
21.12.0
23.1.0
20.17.0
23.1.0-rc2
22.7.0-rc2
21.12.0-rc2
20.17.0-rc2
22.7.0-rc1
23.1.0-rc1
21.12.0-rc1
20.17.0-rc1
23.0.0
22.6.0
21.11.0
20.16.0
21.11.0-rc2
23.0.0-rc2
22.6.0-rc2
20.16.0-rc2
20.15.0
20.15.0-rc1
20.15.0-rc2
20.15.0-rc3
20.15.1
20.15.2
20.16.0-rc1
21.10.0
21.10.0-rc1
21.10.0-rc2
21.10.0-rc3
21.10.1
21.10.2
21.11.0-rc1
22.5.0-rc1
22.5.0-rc2
22.5.0-rc3
22.5.0
22.5.1
22.5.2
22.6.0-rc1
23.0.0-rc1
18.26.4
certified-18.9-cert17
23.0.0-pre1
certified-20.7-cert7
certified-18.9-cert16
18.26.3
certified-20.7-cert6
certified-18.9-cert15
22.4.1
21.9.1
20.14.1
18.26.2
certified-20.7-cert5
certified-18.9-cert14
22.4.0
21.9.0
20.14.0
22.4.0-rc1
21.9.0-rc1
20.14.0-rc1
22.3.0
21.8.0
20.13.0
22.3.0-rc1
21.8.0-rc1
20.13.0-rc1
22.2.0
21.7.0
20.12.0
22.2.0-rc2
21.7.0-rc2
20.12.0-rc2
22.2.0-rc1
21.7.0-rc1
20.12.0-rc1
certified-20.7-cert4
certified-18.9-cert13
22.1.1
21.6.1
20.11.1
18.26.1
22.1.0
21.6.0
20.11.0
18.26.0
22.1.0-rc1
21.6.0-rc1
20.11.0-rc1
18.26.0-rc1
18.25.0
20.10.0
21.5.0
22.0.0
22.0.0-rc2
21.5.0-rc2
20.10.0-rc2
18.25.0-rc2
22.0.0-rc1
21.5.0-rc1
20.10.0-rc1
18.25.0-rc1
certified-20.7-cert3
certified-18.9-cert12
21.4.3
20.9.3
18.24.3
22.0.0-pre1
21.4.2
20.9.2
18.24.2
certified-20.7-cert2
certified-18.9-cert11
21.4.1
20.9.1
18.24.1
21.4.0
20.9.0
18.24.0
certified-20.7-cert1
certified-18.9-cert10
21.4.0-rc1
20.9.0-rc1
18.24.0-rc1
21.3.1
20.8.1
18.23.1
21.3.0
20.8.0
18.23.0
certified-20.7-cert1-rc2
certified-18.9-cert9
20.8.0-rc1
21.3.0-rc1
18.23.0-rc1
certified-20.7-cert1-rc1
certified-20.7-cert1-pre1
21.2.0
20.7.0
18.22.0
certified-18.9-cert8
21.2.0-rc2
20.7.0-rc2
18.22.0-rc2
21.2.0-rc1
20.7.0-rc1
18.22.0-rc1
certified-18.9-cert8-rc2
certified-18.9-cert8-rc1
21.1.0
20.6.0
18.21.0
21.1.0-rc2
20.6.0-rc2
18.21.0-rc2
21.1.0-rc1
20.6.0-rc1
18.21.0-rc1
21.0.2
20.5.2
18.20.2
certified-18.9-cert7
certified-18.9-cert6
21.0.1
20.5.1
18.20.1
21.0.0
20.5.0
18.20.0
21.0.0-rc1
20.5.0-rc1
18.20.0-rc1
21.0.0-pre1
18.19.0
20.4.0
20.4.0-rc2
18.19.0-rc2
20.4.0-rc1
18.19.0-rc1
20.3.1
certified-18.9-cert5
19.8.1
18.18.1
16.30.1
certified-18.9-cert4
20.3.0
18.18.0
20.3.0-rc1
18.18.0-rc1
20.2.1
18.17.1
20.2.0
18.17.0
20.2.0-rc1
18.17.0-rc1
certified/18.9-cert4
20.1.0
19.8.0
18.16.0
16.30.0
20.1.0-rc2
19.8.0-rc2
18.16.0-rc2
16.30.0-rc2
20.1.0-rc1
18.16.0-rc1
19.8.0-rc1
16.30.0-rc1
certified/18.9-cert3
20.0.1
19.7.1
18.15.1
16.29.1
19.7.0
20.0.0
18.15.0
16.29.0
certified/18.9-cert2
20.0.0-rc2
19.7.0-rc2
18.15.0-rc2
16.29.0-rc2
20.0.0-rc1
19.7.0-rc1
18.15.0-rc1
16.29.0-rc1
19.6.0
18.14.0
16.28.0
19.6.0-rc2
18.14.0-rc2
16.28.0-rc2
19.6.0-rc1
18.14.0-rc1
16.28.0-rc1
19.5.0
18.13.0
16.27.0
19.5.0-rc1
18.13.0-rc1
16.27.0-rc1
19.4.1
18.12.1
16.26.1
19.4.0
18.12.0
16.26.0
19.4.0-rc1
18.12.0-rc1
16.26.0-rc1
certified/18.9-cert1
19.3.3
18.11.3
16.25.3
certified/16.8-cert14
19.3.2
18.11.2
16.25.2
19.3.1
18.11.1
16.25.1
19.3.0
18.11.0
16.25.0
19.3.0-rc1
18.11.0-rc1
16.25.0-rc1
certified/16.8-cert13
19.2.1
18.10.1
16.24.1
19.2.0
18.10.0
16.24.0
19.2.0-rc1
18.10.0-rc1
16.24.0-rc1
certified/18.9-cert1-rc1
19.1.0
18.9.0
16.23.0
19.1.0-rc1
18.9.0-rc1
16.23.0-rc1
19.0.0
18.8.0
16.22.0
certified/16.8-cert12
19.0.0-rc1
18.8.0-rc1
16.22.0-rc1
16.21.1
18.7.1
18.7.0
16.21.0
18.7.0-rc3
16.21.0-rc3
18.7.0-rc2
16.21.0-rc2
18.7.0-rc1
16.21.0-rc1
certified/16.8-cert11
18.6.0
16.20.0
18.6.0-rc1
16.20.0-rc1
certified/16.8-cert10
18.5.1
17.9.4
16.19.1
13.38.3
18.5.0
16.19.0
certified/16.8-cert9
18.5.0-rc1
16.19.0-rc1
18.4.0
16.18.0
18.4.0-rc1
16.18.0-rc1
certified/16.8-cert8
18.3.0
16.17.0
18.3.0-rc2
16.17.0-rc2
18.3.0-rc1
16.17.0-rc1
certified/16.8-cert7
18.2.2
17.9.3
16.16.2
certified/16.8-cert6
18.2.1
17.9.2
16.16.1
13.38.2
18.2.0
16.16.0
18.2.0-rc1
16.16.0-rc1
18.1.1
17.9.1
16.15.1
13.38.1
18.1.0
17.9.0
16.15.0
13.38.0
18.1.0-rc1
17.9.0-rc1
16.15.0-rc1
13.38.0-rc1
18.0.1
17.8.1
16.14.1
certified/16.8-cert5
13.37.1
certified/16.8-cert4
certified/16.8-cert4-rc4
18.0.0
17.8.0
16.14.0
13.37.0
18.0.0-rc2
certified/16.8-cert4-rc3
18.0.0-rc1
17.8.0-rc1
16.14.0-rc1
13.37.0-rc1
17.7.0
16.13.0
13.36.0
17.7.0-rc2
16.13.0-rc2
13.36.0-rc2
17.7.0-rc1
16.13.0-rc1
13.36.0-rc1
certified/16.8-cert4-rc2
17.6.0
16.12.0
13.35.0
17.6.0-rc1
16.12.0-rc1
13.35.0-rc1
certified/16.8-cert4-rc1
certified/16.8-cert3
17.5.1
16.11.1
17.5.0
16.11.0
13.34.0
17.5.0-rc3
16.11.0-rc3
13.34.0-rc3
17.5.0-rc2
16.11.0-rc2
13.34.0-rc2
17.5.0-rc1
16.11.0-rc1
13.34.0-rc1
certified/16.8-cert2
17.4.0
16.10.0
13.33.0
certified/16.8-cert1
17.4.0-rc2
16.10.0-rc2
13.33.0-rc2
17.4.0-rc1
16.10.0-rc1
13.33.0-rc1
certified/16.8-cert1-rc5
certified/16.8-cert1-rc4
17.3.0
16.9.0
13.32.0
17.3.0-rc1
16.9.0-rc1
13.32.0-rc1
certified/16.8-cert1-rc3
certified/16.8-cert1-rc2
certified/16.8-cert1-rc1
17.2.0
16.8.0
13.31.0
17.2.0-rc2
16.8.0-rc2
13.31.0-rc2
17.2.0-rc1
16.8.0-rc1
13.31.0-rc1
certified/16.3-cert1
certified/13.21-cert6
17.1.0
16.7.0
13.30.0
17.1.0-rc2
16.7.0-rc2
13.30.0-rc2
17.1.0-rc1
16.7.0-rc1
13.30.0-rc1
certified/13.21-cert5
17.0.1
16.6.2
13.29.2
17.0.0
17.0.0-rc3
16.6.1
13.29.1
16.6.0
13.29.0
16.6.0-rc2
13.29.0-rc2
17.0.0-rc2
16.6.0-rc1
13.29.0-rc1
16.5.1
15.7.4
13.28.1
17.0.0-rc1
16.5.0
13.28.0
16.5.0-rc1
13.28.0-rc1
certified/13.21-cert4
16.4.1
15.7.3
13.27.1
16.4.0
13.27.0
16.4.0-rc1
13.27.0-rc1
16.3.0
13.26.0
16.3.0-rc1
13.26.0-rc1
16.2.1
15.7.2
16.2.0
13.25.0
13.25.0-rc3
16.2.0-rc2
13.25.0-rc2
16.2.0-rc1
13.25.0-rc1
16.1.1
15.7.1
13.24.1
16.1.0
13.24.0
15.7.0
16.1.0-rc1
15.7.0-rc1
13.24.0-rc1
16.0.1
15.6.2
16.0.0
16.0.0-rc3
certified/13.21-cert3
15.6.1
14.7.8
13.23.1
16.0.0-rc2
15.6.0
13.23.0
15.6.0-rc1
13.23.0-rc1
16.0.0-rc1
15.5.0
13.22.0
15.5.0-rc1
13.22.0-rc1
15.4.1
14.7.7
certified/13.21-cert2
certified/13.18-cert4
13.21.1
certified/13.21-cert1
certified/13.21-cert1-rc2
certified/13.21-cert1-rc1
15.4.0
13.21.0
15.4.0-rc2
15.4.0-rc1
13.21.0-rc1
15.3.0
13.20.0
15.3.0-rc2
13.20.0-rc2
15.3.0-rc1
13.20.0-rc1
15.2.2
certified/13.18-cert3
14.7.6
13.19.2
13.19.1
15.2.1
15.2.0
13.19.0
15.2.0-rc2
13.19.0-rc2
certified/13.18-cert2
15.1.5
14.7.5
13.18.5
certified/13.18-cert1
15.2.0-rc1
13.19.0-rc1
certified/13.18-cert1-rc3
certified/13.13-cert9
15.1.4
14.7.4
13.18.4
15.1.3
certified/13.13-cert8
14.7.3
13.18.3
certified/13.18-cert1-rc2
15.1.2
14.7.2
13.18.2
certified/13.18-cert1-rc1
certified/13.13-cert7
15.1.1
14.7.1
13.18.1
15.1.0
14.7.0
13.18.0
15.1.0-rc2
14.7.0-rc2
13.18.0-rc2
15.1.0-rc1
14.7.0-rc1
13.18.0-rc1
15.0.0
certified/13.13-cert6
certified/11.6-cert18
14.6.2
13.17.2
11.25.3
15.0.0-rc1
14.6.1
certified/13.13-cert5
13.17.1
certified/11.6-cert17
11.25.2
15.0.0-beta1
14.6.0
13.17.0
14.6.0-rc1
13.17.0-rc1
14.5.0
13.16.0
14.5.0-rc2
13.16.0-rc2
14.5.0-rc1
13.16.0-rc1
certified/13.13-cert4
14.4.1
13.15.1
14.4.0
13.15.0
14.4.0-rc3
13.15.0-rc3
14.3.1
13.14.1
certified/13.13-cert3
13.15.0-rc2
14.4.0-rc2
14.4.0-rc1
13.15.0-rc1
certified/13.13-cert2
14.3.0
13.14.0
certified/13.13-cert1
14.3.0-rc2
13.14.0-rc2
certified/13.13-cert1-rc4
14.3.0-rc1
13.14.0-rc1
certified/13.13-cert1-rc3
certified/13.13-cert1-rc2
certified/11.6-cert16
certified/13.8-cert4
14.2.1
13.13.1
11.25.1
certified/13.13-cert1-rc1
14.2.0
13.13.0
14.2.0-rc2
13.13.0-rc2
11.25.0
14.2.0-rc1
13.13.0-rc1
11.25.0-rc1
14.1.2
13.12.2
14.1.1
13.12.1
11.24.1
14.1.0
13.12.0
11.24.0
14.1.0-rc1
13.12.0-rc1
11.24.0-rc1
14.0.2
14.0.1
14.0.0
14.0.0-rc2
14.0.0-rc1
13.11.2
certified/11.6-cert15
certified/13.8-cert3
11.23.1
13.11.1
13.11.0
13.11.0-rc2
14.0.0-beta2
certified/11.6-cert14
certified/11.6-cert14-rc2
certified/13.8-cert2
certified/13.8-cert2-rc1
certified/11.6-cert14-rc1
13.11.0-rc1
14.0.0-beta1
11.23.0
13.10.0
certified/13.1-cert8
13.10.0-rc3
certified/13.8-cert1
13.10.0-rc2
11.23.0-rc1
13.10.0-rc1
certified/13.8-cert1-rc3
13.9.1
13.9.0
certified/13.8-cert1-rc2
13.9.0-rc2
certified/13.1-cert7
13.9.0-rc1
certified/13.1-cert6
13.8.2
13.8.1
certified/13.1-cert5
certified/13.8-cert1-rc1
13.8.0
11.22.0
certified/13.1-cert4
certified/11.6-cert13
11.21.2
13.7.2
11.20.0
13.6.0
13.5.0
11.19.0
certified/13.1-cert3-rc1
13.4.0
11.18.0
0.1.0
0.1.1
0.1.10
0.1.11
0.1.12
0.1.2
0.1.3
0.1.4
0.1.5
0.1.6
0.1.7
0.1.8
0.1.9
0.2.0
0.3.0
0.4.0
0.5.0
0.7.0
0.7.1
0.7.2
0.9.0
1.0.0
1.0.0-rc1
1.0.0-rc2
1.0.1
1.0.10
1.0.11
1.0.11.1
1.0.12
1.0.2
1.0.4
1.0.5
1.0.6
1.0.7
1.0.8
1.0.9
1.2.0
1.2.0-beta1
1.2.0-beta2
1.2.0-rc1
1.2.0-rc2
1.2.1
1.2.10
1.2.10-netsec
1.2.11
1.2.11-netsec
1.2.12
1.2.12-netsec
1.2.12.1
1.2.12.1-netsec
1.2.13
1.2.13-netsec
1.2.14
1.2.14-netsec
1.2.15
1.2.15-netsec
1.2.16
1.2.16-netsec
1.2.17
1.2.17-netsec
1.2.18
1.2.18-netsec
1.2.19
1.2.19-netsec
1.2.2
1.2.2-netsec
1.2.20
1.2.20-netsec
1.2.21
1.2.21-netsec
1.2.21.1
1.2.21.1-netsec
1.2.22
1.2.22-netsec
1.2.23
1.2.23-netsec
1.2.24
1.2.24-netsec
1.2.25
1.2.25-netsec
1.2.26
1.2.26-netsec
1.2.26.1
1.2.26.1-netsec
1.2.26.2
1.2.26.2-netsec
1.2.27
1.2.28
1.2.28.1
1.2.29
1.2.3
1.2.3-netsec
1.2.30
1.2.30.1
1.2.30.2
1.2.30.3
1.2.30.4
1.2.31
1.2.31.1
1.2.31.2
1.2.32
1.2.33
1.2.34
1.2.35
1.2.36
1.2.37
1.2.38
1.2.39
1.2.4
1.2.4-netsec
1.2.40
1.2.5
1.2.5-netsec
1.2.6
1.2.6-netsec
1.2.7
1.2.7-netsec
1.2.7.1
1.2.7.1-netsec
1.2.8
1.2.8-netsec
1.2.9
1.2.9-netsec
1.2.9.1
1.2.9.1-netsec
1.4.0
1.4.0-beta1
1.4.0-beta2
1.4.0-beta3
1.4.0-beta4
1.4.1
1.4.10
1.4.10.1
1.4.11
1.4.12
1.4.12.1
1.4.13
1.4.14
1.4.15
1.4.16
1.4.16.1
1.4.16.2
1.4.17
1.4.18
1.4.18.1
1.4.19
1.4.19-rc1
1.4.19-rc2
1.4.19-rc3
1.4.19-rc4
1.4.19.1
1.4.19.2
1.4.2
1.4.20
1.4.20-rc1
1.4.20-rc2
1.4.20-rc3
1.4.20.1
1.4.21
1.4.21-rc1
1.4.21-rc2
1.4.21.1
1.4.21.2
1.4.22
1.4.22-rc1
1.4.22-rc2
1.4.22-rc3
1.4.22-rc4
1.4.22-rc5
1.4.22.1
1.4.22.2
1.4.23
1.4.23-rc1
1.4.23-rc2
1.4.23-rc3
1.4.23-rc4
1.4.23-testing
1.4.23.1
1.4.23.2
1.4.24
1.4.24-rc1
1.4.24.1
1.4.25
1.4.25-rc1
1.4.25.1
1.4.26
1.4.26-rc1
1.4.26-rc2
1.4.26-rc3
1.4.26-rc4
1.4.26-rc5
1.4.26-rc6
1.4.26.1
1.4.26.2
1.4.26.3
1.4.27
1.4.27-rc1
1.4.27-rc2
1.4.27-rc3
1.4.27-rc4
1.4.27-rc5
1.4.27.1
1.4.28
1.4.28-rc1
1.4.29
1.4.29-rc1
1.4.29.1
1.4.3
1.4.30
1.4.30-rc1
1.4.30-rc2
1.4.30-rc3
1.4.31
1.4.31-rc1
1.4.31-rc2
1.4.32
1.4.32-rc1
1.4.32-rc2
1.4.33
1.4.33-rc1
1.4.33-rc2
1.4.33.1
1.4.34
1.4.34-rc1
1.4.34-rc2
1.4.35
1.4.35-rc1
1.4.36
1.4.36-rc1
1.4.37
1.4.37-rc1
1.4.37.1
1.4.38
1.4.38-rc1
1.4.38.1
1.4.39
1.4.39-rc1
1.4.39.1
1.4.39.2
1.4.4
1.4.40
1.4.40-rc1
1.4.40-rc2
1.4.40-rc3
1.4.40.1
1.4.40.2
1.4.41
1.4.41-rc1
1.4.41.1
1.4.41.2
1.4.42
1.4.42-rc1
1.4.42-rc2
1.4.43
1.4.44
1.4.5
1.4.6
1.4.7
1.4.7.1
1.4.8
1.4.9
1.6.0
1.6.0-beta1
1.6.0-beta2
1.6.0-beta3
1.6.0-beta4
1.6.0-beta5
1.6.0-beta6
1.6.0-beta7
1.6.0-beta7.1
1.6.0-beta8
1.6.0-beta9
1.6.0-rc1
1.6.0-rc2
1.6.0-rc3
1.6.0-rc4
1.6.0-rc5
1.6.0-rc6
1.6.0.1
1.6.0.10
1.6.0.11-rc1
1.6.0.11-rc2
1.6.0.12
1.6.0.13
1.6.0.13-rc1
1.6.0.14
1.6.0.14-rc1
1.6.0.15
1.6.0.16
1.6.0.16-rc1
1.6.0.16-rc2
1.6.0.17
1.6.0.18
1.6.0.18-rc1
1.6.0.18-rc2
1.6.0.18-rc3
1.6.0.19
1.6.0.2
1.6.0.20
1.6.0.20-rc1
1.6.0.21
1.6.0.21-rc1
1.6.0.22
1.6.0.23
1.6.0.23-rc1
1.6.0.23-rc2
1.6.0.24
1.6.0.25
1.6.0.26
1.6.0.26-rc1
1.6.0.27
1.6.0.27-rc1
1.6.0.27-rc2
1.6.0.27-rc3
1.6.0.28
1.6.0.28-rc1
1.6.0.28-rc2
1.6.0.3
1.6.0.3-rc1
1.6.0.3.1
1.6.0.4-rc1
1.6.0.4-testing
1.6.0.5
1.6.0.6
1.6.0.6-rc1
1.6.0.7
1.6.0.7-rc1
1.6.0.7-rc2
1.6.0.8
1.6.0.9
1.6.1-beta1
1.6.1-beta2
1.6.1-beta3
1.6.1-beta4
1.6.1-rc1
1.6.1.0
1.6.1.0-rc2
1.6.1.0-rc3
1.6.1.0-rc4
1.6.1.0-rc5
1.6.1.1
1.6.1.10
1.6.1.10-rc1
1.6.1.10-rc2
1.6.1.10-rc3
1.6.1.11
1.6.1.12
1.6.1.12-rc1
1.6.1.13
1.6.1.13-rc1
1.6.1.14
1.6.1.15-rc1
1.6.1.15-rc2
1.6.1.16
1.6.1.17
1.6.1.18
1.6.1.18-rc1
1.6.1.18-rc2
1.6.1.19
1.6.1.19-rc1
1.6.1.19-rc2
1.6.1.19-rc3
1.6.1.2
1.6.1.20
1.6.1.20-rc1
1.6.1.20-rc2
1.6.1.21
1.6.1.22
1.6.1.23
1.6.1.24
1.6.1.25
1.6.1.3-rc1
1.6.1.4
1.6.1.5
1.6.1.5-rc1
1.6.1.6
1.6.1.7-rc1
1.6.1.7-rc2
1.6.1.8
1.6.1.9
1.6.2.0
1.6.2.0-beta1
1.6.2.0-beta2
1.6.2.0-beta3
1.6.2.0-beta4
1.6.2.0-rc1
1.6.2.0-rc2
1.6.2.0-rc3
1.6.2.0-rc4
1.6.2.0-rc5
1.6.2.0-rc6
1.6.2.0-rc7
1.6.2.0-rc8
1.6.2.1
1.6.2.1-rc1
1.6.2.10
1.6.2.10-rc1
1.6.2.10-rc2
1.6.2.11
1.6.2.11-rc1
1.6.2.11-rc2
1.6.2.12
1.6.2.12-rc1
1.6.2.13
1.6.2.14
1.6.2.14-rc1
1.6.2.15
1.6.2.15-rc1
1.6.2.15.1
1.6.2.16
1.6.2.16-rc1
1.6.2.16.1
1.6.2.16.2
1.6.2.17
1.6.2.17-rc1
1.6.2.17-rc2
1.6.2.17-rc3
1.6.2.17.1
1.6.2.17.2
1.6.2.17.3
1.6.2.18
1.6.2.18-rc1
1.6.2.18.1
1.6.2.18.2
1.6.2.19
1.6.2.19-rc1
1.6.2.2
1.6.2.20
1.6.2.21
1.6.2.22
1.6.2.23
1.6.2.24
1.6.2.3-rc1
1.6.2.3-rc2
1.6.2.4
1.6.2.5
1.6.2.6
1.6.2.6-rc1
1.6.2.6-rc2
1.6.2.7
1.6.2.7-rc1
1.6.2.7-rc2
1.6.2.7-rc3
1.6.2.8
1.6.2.8-rc1
1.6.2.8-rc2
1.6.2.9
1.6.2.9-rc1
1.6.2.9-rc2
1.6.2.9-rc3
1.8.0
1.8.0-beta1
1.8.0-beta2
1.8.0-beta3
1.8.0-beta4
1.8.0-beta5
1.8.0-rc1
1.8.0-rc2
1.8.0-rc3
1.8.0-rc4
1.8.0-rc5
1.8.1
1.8.1-rc1
1.8.1.1
1.8.1.2
1.8.10.0
1.8.10.0-rc1
1.8.10.0-rc2
1.8.10.0-rc3
1.8.10.0-rc4
1.8.10.1
1.8.11.0
1.8.11.0-rc1
1.8.11.0-rc2
1.8.11.0-rc3
1.8.11.1
1.8.12.0
1.8.12.0-rc1
1.8.12.0-rc2
1.8.12.0-rc3
1.8.12.1
1.8.12.2
1.8.13.0
1.8.13.0-rc1
1.8.13.0-rc2
1.8.13.1
1.8.14.0
1.8.14.0-rc1
1.8.14.0-rc2
1.8.14.1
1.8.15-cert4
1.8.15.0
1.8.15.0-rc1
1.8.15.1
1.8.16.0
1.8.16.0-rc1
1.8.16.0-rc2
1.8.17.0
1.8.17.0-rc1
1.8.17.0-rc2
1.8.17.0-rc3
1.8.18.0
1.8.18.0-rc1
1.8.18.1
1.8.19.0
1.8.19.0-rc1
1.8.19.0-rc2
1.8.19.0-rc3
1.8.19.0-tc1
1.8.19.1
1.8.2
1.8.2-rc1
1.8.2.1
1.8.2.2
1.8.2.3
1.8.2.4
1.8.20.0
1.8.20.0-rc1
1.8.20.0-rc2
1.8.20.1
1.8.20.2
1.8.21.0
1.8.21.0-rc1
1.8.21.0-rc2
1.8.22.0
1.8.22.0-rc1
1.8.22.0-rc2
1.8.23.0
1.8.23.0-rc1
1.8.23.0-rc2
1.8.23.1
1.8.24.0
1.8.24.0-rc1
1.8.24.0-rc2
1.8.24.1
1.8.25.0
1.8.25.0-rc1
1.8.25.0-rc2
1.8.26.0
1.8.26.0-rc1
1.8.26.0-rc2
1.8.26.1
1.8.27.0
1.8.27.0-rc1
1.8.27.0-rc2
1.8.28-cert5
1.8.28.0
1.8.28.0-rc1
1.8.28.1
1.8.28.2
1.8.29.0
1.8.29.0-rc1
1.8.3
1.8.3-rc1
1.8.3-rc2
1.8.3-rc3
1.8.3.1
1.8.3.2
1.8.3.3
1.8.30.0
1.8.30.0-rc1
1.8.31.0
1.8.31.0-rc1
1.8.31.1
1.8.32.0
1.8.32.0-rc1
1.8.32.0-rc2
1.8.32.1
1.8.32.2
1.8.32.3
1.8.4
1.8.4-rc1
1.8.4-rc2
1.8.4-rc3
1.8.4.1
1.8.4.2
1.8.4.3
1.8.4.4
1.8.5-rc1
1.8.5.0
1.8.5.1
1.8.6.0
1.8.6.0-rc1
1.8.6.0-rc2
1.8.6.0-rc3
1.8.7.0
1.8.7.0-rc1
1.8.7.0-rc2
1.8.7.1
1.8.7.2
1.8.8.0
1.8.8.0-rc1
1.8.8.0-rc2
1.8.8.0-rc3
1.8.8.0-rc4
1.8.8.0-rc5
1.8.8.1
1.8.8.2
1.8.9.0
1.8.9.0-rc1
1.8.9.0-rc2
1.8.9.0-rc3
1.8.9.1
1.8.9.2
1.8.9.3
10.0.0
10.0.0-beta1
10.0.0-beta2
10.0.0-rc1
10.0.0-rc2
10.0.0-rc3
10.0.0-rc4
10.0.1
10.1.0
10.1.0-rc1
10.1.0-rc2
10.1.1
10.1.2
10.1.3
10.10.0
10.10.0-digiumphones
10.10.0-digiumphones-rc1
10.10.0-digiumphones-rc2
10.10.0-rc1
10.10.0-rc2
10.10.1
10.10.1-digiumphones
10.11.0
10.11.0-digiumphones
10.11.0-digiumphones-rc1
10.11.0-digiumphones-rc2
10.11.0-digiumphones-rc3
10.11.0-rc1
10.11.0-rc2
10.11.0-rc3
10.11.1
10.11.1-digiumphones
10.12.0
10.12.0-digiumphones
10.12.0-digiumphones-rc1
10.12.0-digiumphones-rc2
10.12.0-rc1
10.12.0-rc2
10.12.1
10.12.1-digiumphones
10.12.2
10.12.2-digiumphones
10.12.3
10.12.3-digiumphones
10.12.4
10.12.4-digiumphones
10.2.0
10.2.0-rc1
10.2.0-rc2
10.2.0-rc3
10.2.0-rc4
10.2.1
10.3.0
10.3.0-rc1
10.3.0-rc2
10.3.0-rc3
10.3.1
10.4.0
10.4.0-digiumphones-rc1
10.4.0-digiumphones-rc2
10.4.0-rc1
10.4.0-rc2
10.4.0-rc3
10.4.1
10.4.2
10.5.0
10.5.0-digiumphones
10.5.0-digiumphones-rc1
10.5.0-digiumphones-rc2
10.5.0-rc1
10.5.0-rc2
10.5.1
10.5.1-digiumphones
10.5.2
10.5.2-digiumphones
10.6.0
10.6.0-digiumphones
10.6.0-digiumphones-rc1
10.6.0-digiumphones-rc2
10.6.0-rc1
10.6.0-rc2
10.6.1
10.6.1-digiumphones
10.7.0
10.7.0-digiumphones
10.7.0-digiumphones-rc1
10.7.0-rc1
10.7.1
10.7.1-digiumphones
10.8.0
10.8.0-digiumphones
10.8.0-digiumphones-rc1
10.8.0-digiumphones-rc2
10.8.0-rc1
10.8.0-rc2
10.9.0
10.9.0-digiumphones
10.9.0-digiumphones-rc1
10.9.0-digiumphones-rc2
10.9.0-digiumphones-rc3
10.9.0-rc1
10.9.0-rc2
10.9.0-rc3
11.0.0
11.0.0-beta1
11.0.0-beta2
11.0.0-rc1
11.0.0-rc2
11.0.1
11.0.2
11.1.0
11.1.0-rc1
11.1.0-rc2
11.1.0-rc3
11.1.1
11.1.2
11.10.0
11.10.0-rc1
11.10.1
11.10.2
11.11.0
11.11.0-rc1
11.12.0
11.12.0-rc1
11.12.1
11.13.0
11.13.0-rc1
11.13.1
11.14.0
11.14.0-rc1
11.14.0-rc2
11.14.1
11.14.2
11.15.0
11.15.0-rc1
11.15.0-rc2
11.15.1
11.16.0
11.16.0-rc1
11.17.0
11.17.0-rc1
11.17.1
11.18.0-rc1
11.19.0-rc1
11.2.0
11.2.0-rc1
11.2.0-rc2
11.2.1
11.2.2
11.20.0-rc1
11.20.0-rc2
11.20.0-rc3
11.21.0
11.21.0-rc1
11.21.0-rc2
11.21.0-rc3
11.21.1
11.22.0-rc1
11.3.0
11.3.0-rc1
11.3.0-rc2
11.4.0
11.4.0-rc1
11.4.0-rc2
11.4.0-rc3
11.5.0
11.5.0-rc1
11.5.0-rc2
11.5.1
11.6-cert11
11.6.0
11.6.0-rc1
11.6.0-rc2
11.6.1
11.7.0
11.7.0-rc1
11.7.0-rc2
11.8.0
11.8.0-rc1
11.8.0-rc2
11.8.0-rc3
11.8.1
11.9.0
11.9.0-rc1
11.9.0-rc2
11.9.0-rc3
12.0.0
12.0.0-alpha1
12.0.0-alpha2
12.0.0-beta1
12.0.0-beta2
12.1.0
12.1.0-rc1
12.1.0-rc2
12.1.0-rc3
12.1.1
12.2.0
12.2.0-rc1
12.2.0-rc2
12.2.0-rc3
12.3.0
12.3.0-rc1
12.3.0-rc2
12.3.1
12.3.2
12.4.0
12.4.0-rc1
12.5.0
12.5.0-rc1
12.5.1
12.6.0
12.6.0-rc1
12.6.1
12.7.0
12.7.0-rc1
12.7.0-rc2
12.7.1
12.7.2
12.8.0
12.8.0-rc1
12.8.0-rc2
12.8.1
12.8.2
13.0.0
13.0.0-beta1
13.0.0-beta2
13.0.0-beta3
13.0.1
13.0.2
13.1-cert2
13.1.0
13.1.0-rc1
13.1.0-rc2
13.1.1
13.2.0
13.2.0-rc1
13.2.1
13.3.0
13.3.0-rc1
13.3.1
13.3.2
13.4.0-rc1
13.5.0-rc1
13.6.0-rc1
13.6.0-rc2
13.6.0-rc3
13.7.0
13.7.0-rc1
13.7.0-rc2
13.7.0-rc3
13.7.1
13.8.0-rc1
certified/1.8.11-cert1
certified/1.8.11-cert10
certified/1.8.11-cert2
certified/1.8.11-cert3-rc1
certified/1.8.11-cert3-rc2
certified/1.8.11-cert4
certified/1.8.11-cert5
certified/1.8.11-cert5-rc1
certified/1.8.11-cert5-rc2
certified/1.8.11-cert6
certified/1.8.11-cert7
certified/1.8.11-cert8
certified/1.8.11-cert9
certified/1.8.11-cert9-rc1
certified/1.8.15-cert1
certified/1.8.15-cert1-rc1
certified/1.8.15-cert1-rc2
certified/1.8.15-cert1-rc3
certified/1.8.15-cert2
certified/1.8.15-cert3
certified/1.8.15-cert4
certified/1.8.15-cert5
certified/1.8.15-cert6
certified/1.8.15-cert7
certified/1.8.28-cert1
certified/1.8.28-cert1-rc1
certified/1.8.28-cert2
certified/1.8.28-cert3
certified/1.8.28-cert4
certified/1.8.28-cert5
certified/1.8.6-cert1
certified/11.2-cert1
certified/11.2-cert1-rc1
certified/11.2-cert1-rc2
certified/11.2-cert2
certified/11.2-cert3
certified/11.6-cert1
certified/11.6-cert1-rc1
certified/11.6-cert1-rc2
certified/11.6-cert10
certified/11.6-cert11
certified/11.6-cert12
certified/11.6-cert2
certified/11.6-cert3
certified/11.6-cert4
certified/11.6-cert5
certified/11.6-cert6
certified/11.6-cert7
certified/11.6-cert8
certified/11.6-cert9
certified/13.1-cert1
certified/13.1-cert1-rc1
certified/13.1-cert1-rc2
certified/13.1-cert1-rc3
certified/13.1-cert2
certified/13.1-cert3
${ noResults }
446 Commits (04224c20362f94f99886d6b51adb7b90db62855f)
| Author | SHA1 | Message | Date |
|---|---|---|---|
|
|
851141c131 |
Merged revisions 288079-288080 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r288079 | rmudgett | 2010-09-21 15:29:51 -0500 (Tue, 21 Sep 2010) | 2 lines Protect channel access in CONNECTED_LINE and REDIRECTING interception macro launch code. ........ r288080 | rmudgett | 2010-09-21 15:29:59 -0500 (Tue, 21 Sep 2010) | 8 lines Simplify locking code for REDIRECTING interception macro when forwarding a call. Simplified the locking code by using a local copy of the redirecting party information in app_dial.c:do_forward() and app_queue.c:wait_for_answer() for launching the REDIRECTING interception macro when a call is forwarded. Reduced the lock time of the 'o->chan' and 'in' channels. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@288081 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
|
949c16de77 |
Merged revisions 288007 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r288007 | bbryant | 2010-09-21 15:48:53 -0400 (Tue, 21 Sep 2010) | 21 lines Merged revisions 288006 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r288006 | bbryant | 2010-09-21 15:46:20 -0400 (Tue, 21 Sep 2010) | 14 lines Merged revisions 288005 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r288005 | bbryant | 2010-09-21 15:43:46 -0400 (Tue, 21 Sep 2010) | 8 lines Add a check to fix a rare segmentation fault you'd get if ast_frdup couldn't allocate memory on the first frame being queued in ast_queue_frame. (closes issue #17882) Reported by: seanbright Tested by: seanbright ........ ................ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@288008 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
|
6aa4e2b35e |
Merged revisions 287931 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r287931 | twilson | 2010-09-21 14:02:40 -0500 (Tue, 21 Sep 2010) | 2 lines Revert change in favor of a more targeted fix ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287932 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
|
690561643d |
Merged revisions 287833 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r287833 | twilson | 2010-09-20 23:37:44 -0500 (Mon, 20 Sep 2010) | 3 lines Don't generate connected line buffer twice for comparison ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287834 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
|
03a833f2e8 |
Merged revisions 287757 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r287757 | twilson | 2010-09-20 18:51:38 -0500 (Mon, 20 Sep 2010) | 7 lines Avoid infinite loop with certain local channel connected line updates Compare connected line data before sending a connected line indication to avoid possible loops. Review: https://reviewboard.asterisk.org/r/932/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287764 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
|
c65de13046 |
Merged revisions 287685 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ........ r287685 | alecdavis | 2010-09-21 11:16:45 +1200 (Tue, 21 Sep 2010) | 18 lines ast_channel_masquerade: Avoid recursive masquerades. Check all 4 combinations of (original/clonechan) * (masq/masqr). Initially original->masq and clonechan->masqr were only checked. It's possible with multiple masq's planned - and not yet executed, that the 'original' chan could already have another masq'd into it - thus original->masqr would be set, that masqr would lost. Likewise for the clonechan->masq. (closes issue #16057;#17363) Reported by: amorsen;davidw,alecdavis Patches: based on bug16057.diff4.txt uploaded by alecdavis (license 585) Tested by: ramonpeek, davidw, alecdavis ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287756 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
|
672e1c323f |
Merged revisions 287661 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r287661 | alecdavis | 2010-09-21 10:21:50 +1200 (Tue, 21 Sep 2010) | 14 lines ast_do_masquerade. Keep channels ao2_container locked while unlink and linking channels. Previously, Masquerade would unlock 'original' and 'clonechan' and allow another masq thread to run. End result would be corrupted memory, and the frequent report 'Bad Magic Number'. (closes issue #17801,#17710) Reported by: notthematrix Patches: Based on bug17801.diff1.txt uploaded by alecdavis (license 585) Tested by: alecdavis Review: https://reviewboard.asterisk.org/r/928 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287671 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
|
2f3dee2379 |
Merged revisions 287647 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r287647 | dvossel | 2010-09-20 17:09:16 -0500 (Mon, 20 Sep 2010) | 21 lines Addition of the FrameHook API (AKA AwesomeHooks) So far all our tools for viewing and manipulating media streams within Asterisk have been entirely focused on audio. That made sense then, but is not scalable now. The FrameHook API lets us tap into and manipulate _ANY_ type of media or signaling passed on a channel present today or in the future. This tool is a step in the direction of expanding Asterisk's boundaries and will help generate some rather interesting applications in the future. In addition to the FrameHook API, a simple dialplan function exercising the api has been included as well. This function is called FRAME_TRACE(). FRAME_TRACE() allows for the internal ast_frames read and written to a channel to be output. Filters can be placed on this function to debug only certain types of frames. This function could be thought of as an internal way of doing ast_frame packet captures. Review: https://reviewboard.asterisk.org/r/925/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287648 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
|
bf5121e367 |
Merged revisions 286682 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r286682 | mnicholson | 2010-09-14 13:04:21 -0500 (Tue, 14 Sep 2010) | 21 lines Merged revisions 286681 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r286681 | mnicholson | 2010-09-14 13:02:24 -0500 (Tue, 14 Sep 2010) | 14 lines Merged revisions 286679 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r286679 | mnicholson | 2010-09-14 13:00:01 -0500 (Tue, 14 Sep 2010) | 7 lines Only drop duplicate answer frames if the channel is bridged. Back in r3710 ast_read() was modified to drop answer frames on channels that were in the UP state. This modification prevented bridges that were up before the answer from being broken and reestablished by an ANSWER control frame. That change also prevents pickup of channels called from the ast_dial framework from working properly. The ast_dial framework expects to see an ANSWER frame after dialing and the pickup code queues one but ast_read() drops it. This new change only drops ANSWER frames when the channel is bridged, allowing the answer queued by the pickup code to properly pass through ast_read() on to the ast_dial framework. ABE-2473 (related to issue #2342) ........ ................ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286683 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
15 years ago |
|
|
74ebe38903 |
Merged revisions 285745 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r285745 | qwell | 2010-09-09 15:11:06 -0500 (Thu, 09 Sep 2010) | 23 lines Merged revisions 285744 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r285744 | qwell | 2010-09-09 15:09:23 -0500 (Thu, 09 Sep 2010) | 16 lines Merged revisions 285742 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r285742 | qwell | 2010-09-09 15:06:31 -0500 (Thu, 09 Sep 2010) | 9 lines Transmit silence when reading DTMF in ast_readstring. Otherwise, you could get issues with DTMF timeouts causing hangups. (closes issue #17370) Reported by: makoto Patches: channel-readstring-silence-generator.patch uploaded by makoto (license 38) ........ ................ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@285746 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
2bd6b82737 |
Merged revisions 282468 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r282468 | twilson | 2010-08-16 12:53:44 -0500 (Mon, 16 Aug 2010) | 30 lines Merged revisions 282467 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r282467 | twilson | 2010-08-16 12:32:01 -0500 (Mon, 16 Aug 2010) | 23 lines Merged revisions 282430 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r282430 | twilson | 2010-08-16 12:06:37 -0500 (Mon, 16 Aug 2010) | 16 lines Send a SRCCHANGE indication when we masquerade Masquerading a channel means that the src of the audio is potentially changing, so send a SRCCHANGE so that RTP-based media streams can get a new SSRC generated to reflect the change. Original patch by addix (along with lots of testing--thanks!). (closes issue #17007) Reported by: addix Patches: 1001-reset-SSRC-original-channel.diff uploaded by addix (license 1006) srcchange.diff uploaded by twilson (license 396) Tested by: addix, twilson Review: https://reviewboard.asterisk.org/r/862/ ........ ................ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@282502 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
3770eaadcb |
Merged revisions 281913 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r281913 | jpeeler | 2010-08-11 22:03:37 -0500 (Wed, 11 Aug 2010) | 34 lines Merged revisions 281912 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r281912 | jpeeler | 2010-08-11 22:01:38 -0500 (Wed, 11 Aug 2010) | 27 lines Merged revisions 281911 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r281911 | jpeeler | 2010-08-11 22:00:14 -0500 (Wed, 11 Aug 2010) | 20 lines Ensure SSRC is changed when media source is changed to resolve audio delay. This change causes the SSRC to change right before the channels are bridged, which is what used to happen. It seems that fixes were made to attempt limiting SSRC changes, targeted mainly at sending DTMF. DTMF is not affecting the SSRC with this change. There are two other control frames sent in ast_channel_bridge that probably should also be changed to AST_CONTROL_SRCCHANGE as well, but I'm going to leave this change up to the discretion of resolving issue #17007. For reference - old review implementing new control frame SRCCHANGE: https://reviewboard.asterisk.org/r/540 (closes issue #17404) Reported by: sdolloff Patches: bug17404.patch uploaded by jpeeler (license 325) Tested by: sdolloff ........ ................ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@281914 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
139e3e5d84 |
Merged revisions 280450 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r280450 | dvossel | 2010-07-29 14:13:27 -0500 (Thu, 29 Jul 2010) | 25 lines Merged revisions 280449 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r280449 | dvossel | 2010-07-29 14:05:25 -0500 (Thu, 29 Jul 2010) | 18 lines Merged revisions 280448 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r280448 | dvossel | 2010-07-29 14:04:23 -0500 (Thu, 29 Jul 2010) | 12 lines fixes issue with translator frame not getting freed A translator frame even if it local storage so the translation path can be freed. This issue prevented g729 licenses from being freed up. (closes issue #17630) Reported by: manvirr Patches: encoder_fix.diff uploaded by dvossel (license 671) Tested by: manvirr, dvossel ........ ................ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@280459 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
3def1196b4 |
Merged revisions 280307 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r280307 | mnicholson | 2010-07-29 08:56:35 -0500 (Thu, 29 Jul 2010) | 11 lines Merged revisions 280306 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ........ r280306 | mnicholson | 2010-07-29 08:45:11 -0500 (Thu, 29 Jul 2010) | 2 lines Implement support for ast_channel_queryoption on local channels. Currently only AST_OPTION_T38_STATE is supported. ABE-2229 Review: https://reviewboard.asterisk.org/r/813/ ........ Additionally, pass AST_CONTROL_T38_PARAMETERS control frames through generic bridges. This change appears to have been unintentionally left out of rev 203699. ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@280308 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
395a35900a |
Merged revisions 279949 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r279949 | dvossel | 2010-07-27 15:57:00 -0500 (Tue, 27 Jul 2010) | 31 lines Merged revisions 279946 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r279946 | dvossel | 2010-07-27 15:54:32 -0500 (Tue, 27 Jul 2010) | 24 lines Merged revisions 279945 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r279945 | dvossel | 2010-07-27 15:33:40 -0500 (Tue, 27 Jul 2010) | 19 lines remove empty audiohook write list on channel If a channel has an audiohook write list created on it, that list stays on the channel until the channel is destroyed. There is no reason to keep that list on the channel if it becomes empty. If it is empty that just means we are doing needless translating for every ast_read and ast_write. This patch removes the audiohook list from the channel once it is detected to be empty on either a read or write. If a audiohook is added back to the channel after this list is destroyed, the list just gets recreated as if it never existed to begin with. (closes issue #17630) Reported by: manvirr Review: https://reviewboard.asterisk.org/r/799/ ........ ................ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279951 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
8bd241f238 |
Merged revisions 279636,279815 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r279636 | russell | 2010-07-26 16:53:30 -0500 (Mon, 26 Jul 2010) | 2 lines Ignore a control subclass of -1 in ast_waitfordigit_full(). ........ r279815 | russell | 2010-07-27 11:06:58 -0500 (Tue, 27 Jul 2010) | 4 lines Support "channels" in addition to "channel" in chan_dahdi.conf. Review: https://reviewboard.asterisk.org/r/804 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279816 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
0da891c543 |
Merged revisions 278618 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r278618 | mmichelson | 2010-07-22 09:55:04 -0500 (Thu, 22 Jul 2010) | 13 lines Allow PLC to function properly when channels use SLIN for audio. If a channel involved in a bridge was using SLIN audio, then translation paths were not guaranteed to be set up properly since in all likelihood the number of translation steps was only 1. This patch enforces the transcode_via_slin behavior if transcode_via_slin or generic_plc is enabled and one of the formats to make compatible is SLIN. AST-352 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278620 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
e16a5e4727 |
Print f->subclass.integer instead of f->subclass.
(fix build breakage introduced in r277250) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277262 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
d787ccff35 |
Merged revisions 277247 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r277247 | mnicholson | 2010-07-16 12:29:57 -0500 (Fri, 16 Jul 2010) | 4 lines For pass through DTMF tones, measure the actual duration between the begin and end packets on the wire. If it is detected to be less than AST_MIN_DTMF_DURATION, trigger dtmf emulation. AST-362 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277250 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
e7591ab428 |
Merged revisions 276652 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r276652 | jpeeler | 2010-07-15 08:48:58 -0500 (Thu, 15 Jul 2010) | 2 lines In a perfect world, the frame source would never be NULL. In the meantime, don't crash when it is. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276653 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
cf7bbcc4c6 |
Expand the caller ANI field to an ast_party_id
Expand the ani field in ast_party_caller and ast_party_connected_line to an ast_party_id. This is an extension to the ast_callerid restructuring patch in review: https://reviewboard.asterisk.org/r/702/ Review: https://reviewboard.asterisk.org/r/744/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276393 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
ec37ffbdaf |
ast_callerid restructuring
The purpose of this patch is to eliminate struct ast_callerid since it has
turned into a miscellaneous collection of various party information.
Eliminate struct ast_callerid and replace it with the following struct
organization:
struct ast_party_name {
char *str;
int char_set;
int presentation;
unsigned char valid;
};
struct ast_party_number {
char *str;
int plan;
int presentation;
unsigned char valid;
};
struct ast_party_subaddress {
char *str;
int type;
unsigned char odd_even_indicator;
unsigned char valid;
};
struct ast_party_id {
struct ast_party_name name;
struct ast_party_number number;
struct ast_party_subaddress subaddress;
char *tag;
};
struct ast_party_dialed {
struct {
char *str;
int plan;
} number;
struct ast_party_subaddress subaddress;
int transit_network_select;
};
struct ast_party_caller {
struct ast_party_id id;
char *ani;
int ani2;
};
The new organization adds some new information as well.
* The party name and number now have their own presentation value that can
be manipulated independently. ISDN supplies the presentation value for
the name and number at different times with the possibility that they
could be different.
* The party name and number now have a valid flag. Before this change the
name or number string could be empty if the presentation were restricted.
Most channel drivers assume that the name or number is then simply not
available instead of indicating that the name or number was restricted.
* The party name now has a character set value. SIP and Q.SIG have the
ability to indicate what character set a name string is using so it could
be presented properly.
* The dialed party now has a numbering plan value that could be useful to
have available.
The various channel drivers will need to be updated to support the new
core features as needed. They have simply been converted to supply
current functionality at this time.
The following items of note were either corrected or enhanced:
* The CONNECTEDLINE() and REDIRECTING() dialplan functions were
consolidated into func_callerid.c to share party id handling code.
* CALLERPRES() is now deprecated because the name and number have their
own presentation values.
* Fixed app_alarmreceiver.c write_metadata(). The workstring[] could
contain garbage. It also can only contain the caller id number so using
ast_callerid_parse() on it is silly. There was also a typo in the
CALLERNAME if test.
* Fixed app_rpt.c using ast_callerid_parse() on the channel's caller id
number string. ast_callerid_parse() alters the given buffer which in this
case is the channel's caller id number string. Then using
ast_shrink_phone_number() could alter it even more.
* Fixed caller ID name and number memory leak in chan_usbradio.c.
* Fixed uninitialized char arrays cid_num[] and cid_name[] in
sig_analog.c.
* Protected access to a caller channel with lock in chan_sip.c.
* Clarified intent of code in app_meetme.c sla_ring_station() and
dial_trunk(). Also made save all caller ID data instead of just the name
and number strings.
* Simplified cdr.c set_one_cid(). It hand coded the ast_callerid_merge()
function.
* Corrected some weirdness with app_privacy.c's use of caller
presentation.
Review: https://reviewboard.asterisk.org/r/702/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
16 years ago |
|
|
30071ba71b |
Add which ITU spec specifies the numbering plan.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275725 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
e710ef67b9 |
Merged revisions 275665 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r275665 | jpeeler | 2010-07-12 11:58:39 -0500 (Mon, 12 Jul 2010) | 11 lines Change ast_write to not stop generator when called from ast_prod. For SIP channels configured with the progressinband option on, the ringback was being immediately stopped. This problem was due to ast_prod being moved for a deadlock fix in 259858. Prodding the channel after setting up the generator triggered the check in ast_write to stop the generator. The fix here should write the frame the same as was done before the call to ast_prod was moved. (closes issue #17372) Reported by: tech_admin ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275682 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
816f26c16c |
Generate a correct AstData string for ast_callerid.cid_ton
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274782 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
25a3c313b5 |
Fix trunk compile.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274773 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
a1b89a6a50 |
Implement AstData API data providers as part of the GSOC 2010 project,
midterm evaluation. Review: https://reviewboard.asterisk.org/r/757/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274727 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
b00f58da25 |
adds speex 16khz audio support
(closes issue #17501) Reported by: fabled Patches: asterisk-trunk-speex-wideband-v2.patch uploaded by fabled (license 448) Tested by: malcolmd, fabled, dvossel git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271231 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
fcb055fb4e |
addition of G.719 pass-through support
(closes issue #16293) Reported by: malcolmd Patches: g719.passthrough.patch.7 uploaded by malcolmd (license 924) format_g719.c uploaded by malcolmd (license 924) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270940 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
e8d2153da6 |
Merged revisions 269821 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r269821 | mmichelson | 2010-06-10 14:30:12 -0500 (Thu, 10 Jun 2010) | 19 lines Fix potential crash when writing raw SLIN audio on a PLC-enabled channel. The issue here was that the frame created when adjusting for PLC had no offset to its audio data. If this frame were translated to another format prior to being sent out an RTP socket, all went well because the translation code would put an appropriate offset into the frame. However, if the SLIN audio were not translated before being sent out the RTP socket, bad things would happen. Specifically, the ast_rtp_raw_write makes the assumption that the frame has at least enough of an offset that it can accommodate an RTP header. This was not the case. As such, data was being written prior to the allocation, likely corrupting the data the memory allocator had written. Thus when the time came to free the data, all hell broke loose. ....Well, Asterisk crashed at least. The fix was just what one would expect. Offset the data in the frame by a reasonable amount. The method I used is a bit odd since the data in the frame is 16 bit integers and not bytes. I left a big ol' comment about it. This can be improved on if someone is interested. I was more interested in getting the crash resolved. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269822 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
857814f435 |
Add SRTP support for Asterisk
After 5 years in mantis and over a year on reviewboard, SRTP support is finally being comitted. This includes generic CHANNEL dialplan functions that work for getting the status of whether a call has secure media or signaling as defined by the underlying channel technology and for setting whether or not a new channel being bridged to a calling channel should have secure signaling or media. See doc/tex/secure-calls.tex for examples. Original patch by mikma, updated for trunk and revised by me. (closes issue #5413) Reported by: mikma Tested by: twilson, notthematrix, hemanshurpatel Review: https://reviewboard.asterisk.org/r/191/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268894 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
0760f4e70a |
Add ETSI Malicious Call ID support.
Add the ability to report malicious callers as an AMI event in the call event class. Relevant specification: EN 300 180 Review: https://reviewboard.asterisk.org/r/576/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267350 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
afd4454c44 |
Generic Advice of Charge.
Asterisk Generic AOC Representation - Generic AOC encode/decode routines. (Generic AOC must be encoded to be passed on the wire in the AST_CONTROL_AOC frame) - AST_CONTROL_AOC frame type to represent generic encoded AOC data - Manager events for AOC-S, AOC-D, and AOC-E messages Asterisk App Support - app_dial AOC-S pass-through support on call setup - app_queue AOC-S pass-through support on call setup AOC Unit Tests - AOC Unit Tests for encode/decode routines - AOC Unit Test for manager event representation. SIP AOC Support - Pass-through of generic AOC-D and AOC-E messages to snom phones via the snom AOC specification. - Creation of chan_sip page3 flags for the addition of the new 'snom_aoc_enabled' sip.conf option. IAX AOC Support - Natively supports AOC pass-through through the use of the new AST_CONTROL_AOC frame type DAHDI AOC Support - ETSI PRI full AOC Pass-through support - 'aoc_enable' chan_dahdi.conf option for independently enabling pass-through of AOC-S, AOC-D, AOC-E. - 'aoce_delayhangup' option for retrieving AOC-E on disconnect. - DAHDI A() dial string option for requesting AOC services. example usage: ;requests AOC-S, AOC-D, and AOC-E on call setup exten=>1111,1,Dial(DAHDI/g1/1112/A(s,d,e)) Review: https://reviewboard.asterisk.org/r/552/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267096 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
8999372c33 |
Fix misspelling of macro args.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@266092 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
838ce15e20 |
Memory leak in connected line data when SIP blond transfer done.
The handling of the control subclass AST_CONTROL_READ_ACTION frame leaked connected line string memory in __ast_read(). Also in __ast_read() the frame type switch should not have had a case for AST_CONTROL_READ_ACTION. AST_CONTROL_READ_ACTION is not a frame type. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@265608 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
fdb698ca2b |
fixes segfault when using generic plc
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@265273 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
ba8e183938 |
Channel initialization failure causes crashes.
__ast_channel_alloc_ap() has several points in the initialization of a new channel structure where it could fail. Since the channel structure is now an ao2 object, the destructor callback needs to be able to handle clean up when the structure setup is incomplete. Problems corrected: 1) Failing to setup the alertpipe would not unreference the structure but free it directly. Doing this to an ao2_object is very bad. 2) File descriptors need to be initialized to -1 before a construction failure could occur so the destructor will not close unopened descriptors. 3) The destructor needs to check that the string field has been initialized before using any string field values. Crashes expected. 4) The destructor should not notify devstate if the device name is empty. It is a waste of cycles and a couple ERROR log messages are generated. Review: https://reviewboard.asterisk.org/r/675/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@265174 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
73e8c7572e |
Merged revisions 264996 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r264996 | mmichelson | 2010-05-21 11:28:34 -0500 (Fri, 21 May 2010) | 32 lines Allow ast_safe_sleep to defer specific frames until after the sleep has concluded. From reviewboard Background: A Digium customer discovered a somewhat odd bug. The setup is that parties A and B are bridged, and party A places party B on hold. While party B is listening to hold music, he mashes a bunch of DTMF. Party A takes party B off hold while this is happening, but party B continues to hear hold music. I could reproduce this about 1 in 5 times. The issue: When DTMF features are enabled and a user presses keys, the channel that the DTMF is streamed to is placed in an ast_safe_sleep for 100 ms, the duration of the emulated tone. If an AST_CONTROL_UNHOLD frame is read from the channel during the sleep, the frame is dropped. Thus the unhold indication is never made to the channel that was originally placed on hold. The fix: Originally, I discussed with Kevin possible ways of fixing the specific problem reported. However, we determined that the same type of problem could happen in other situations where ast_safe_sleep() is used. Using autoservice as a model, I modified ast_safe_sleep_conditional() to defer specific frame types so they can be re-queued once the sleep has finished. I made a common function for determining if a frame should be deferred so that there are not two identical switch blocks to maintain. Review: https://reviewboard.asterisk.org/r/674/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264997 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
6bb45831eb |
Fix transcode_via_sln option with SIP calls and improve PLC usage.
From reviewboard: The problem here is a bit complex, so try to bear with me... It was noticed by a Digium customer that generic PLC (as configured in codecs.conf) did not appear to actually be having any sort of benefit when packet loss was introduced on an RTP stream. I reproduced this issue myself by streaming a file across an RTP stream and dropping approx. 5% of the RTP packets. I saw no real difference between when PLC was enabled or disabled when using wireshark to analyze the RTP streams. After analyzing what was going on, it became clear that one of the problems faced was that when running my tests, the translation paths were being set up in such a way that PLC could not possibly work as expected. To illustrate, if packets are lost on channel A's read stream, then we expect that PLC will be applied to channel B's write stream. The problem is that generic PLC can only be done when there is a translation path that moves from some codec to SLINEAR. When I would run my tests, I found that every single time, read and write translation paths would be set up on channel A instead of channel B. There appeared to be no real way to predict which channel the translation paths would be set up on. This is where Kevin swooped in to let me know about the transcode_via_sln option in asterisk.conf. It is supposed to work by placing a read translation path on both channels from the channel's rawreadformat to SLINEAR. It also will place a write translation path on both channels from SLINEAR to the channel's rawwriteformat. Using this option allows one to predictably set up translation paths on all channels. There are two problems with this, though. First and foremost, the transcode_via_sln option did not appear to be working properly when I was placing a SIP call between two endpoints which did not share any common formats. Second, even if this option were to work, for PLC to be applied, there had to be a write translation path that would go from some format to SLINEAR. It would not work properly if the starting format of translation was SLINEAR. The one-line change presented in this review request in chan_sip.c fixed the first issue for me. The problem was that in sip_request_call, the jointcapability of the outbound channel was being set to the format passed to sip_request_call. This is nativeformats of the inbound channel. Because of this, when ast_channel_make_compatible was called by app_dial, both channels already had compatibly read and write formats. Thus, no translation path was set up at the time. My change is to set the jointcapability of the sip_pvt created during sip_request_call to the intersection of the inbound channel's nativeformats and the configured peer capability that we determined during the earlier call to create_addr. Doing this got the translation paths set up as expected when using transcode_via_sln. The changes presented in channel.c fixed the second issue for me. First and foremost, when Asterisk is started, we'll read codecs.conf to see the value of the genericplc option. If this option is set, and ast_write is called for a frame with no data, then we will attempt to fill in the missing samples for the frame. The implementation uses a channel datastore for maintaining the PLC state and for creating a buffer to store PLC samples in. Even when we receive a frame with data, we'll call plc_rx so that the PLC state will have knowledge of the previous voice frame, which it can use as a basis for when it comes time to actually do a PLC fill-in. So, reviewers, now I ask for your help. First off, there's the one line change in chan_sip that I have put in. Is it right? By my logic it seems correct, but I'm sure someone can tell me why it is not going to work. This is probably the change I'm least concerned about, though. What concerns me much more is the set of changes in channel.c. First off, am I even doing it right? When I run tests, I can clearly see that when PLC is activated, I see a significant increase in RTP traffic where I would expect it to be. However, in my humble opinion, the audio sounds kind of crappy whenever the PLC fill-in is done. It sounds worse to me than when no PLC is used at all. I need someone to review the logic I have used to be sure that I'm not misusing anything. As far as I can see my pointer arithmetic is correct, and my use of AST_FRIENDLY_OFFSET should be correct as well, but I'm sure someone can point out somewhere where I've done something incorrectly. As I was writing this review request up, I decided to give the code a test run under valgrind, and I find that for some reason, calls to plc_rx are causing some invalid reads. Apparently I'm reading past the end of a buffer somehow. I'll have to dig around a bit to see why that is the case. If it's obvious to someone reviewing, speak up! Finally, I have one other proposal that is not reflected in my code review. Since without transcode_via_sln set, one cannot predict or control where a translation path will be up, it seems to me that the current practice of using PLC only when transcoding to SLINEAR is not useful. I recommend that once it has been determined that the method used in this code review is correct and works as expected, then the code in translate.c that invokes PLC should be removed. Review: https://reviewboard.asterisk.org/r/622/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264452 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
b5d5cc565f |
Enhancements to connected line and redirecting work.
From reviewboard: Digium has a commercial customer who has made extensive use of the connected party and redirecting information present in later versions of Asterisk Business Edition and which is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions have come about. This patch adds several enhancements to maximize usage of the connected party and redirecting information functionality. First, Asterisk trunk already had connected line interception macros. These macros allow you to manipulate connected line information before it was sent out to its target. This patch adds the same feature except for redirecting information instead. Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI, mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is that it can be set to whatever value the administrator likes. Later, when running connected line and redirecting macros, the admin can read the tag off the appropriate structure to determine what action to take. You can think of this sort of like a channel variable, except that instead of having the variable associated with a channel, the variable is associated with a specific identity within Asterisk. Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force a specific calling presentation value on the outgoing channel. Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party being transferred would not have the opportunity to run a connected line interception macro to possibly alter the transfer target's connected line information. The issue here was that during a blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line update. The way this was corrected was to add this new control frame subclass. Now, we queue an AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should be run. When ast_read is called to read the frame, ast_read responds by calling a callback function associated with the specific read action the control frame describes. In this case, the action taken is to run the connected line interception macro on the transferee's channel. Review: https://reviewboard.asterisk.org/r/652/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
6a0ea1d79e |
Merged revisions 261093-261094 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r261093 | tilghman | 2010-05-04 18:36:53 -0500 (Tue, 04 May 2010) | 7 lines Protect against overflow, when calculating how long to wait for a frame. (closes issue #17128) Reported by: under Patches: d.diff uploaded by under (license 914) ........ r261094 | tilghman | 2010-05-04 18:47:08 -0500 (Tue, 04 May 2010) | 2 lines Add a tiny corner case to the previous commit ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@261095 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
6722251986 |
Merged revisions 259858 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r259858 | dvossel | 2010-04-28 16:16:03 -0500 (Wed, 28 Apr 2010) | 33 lines resolves deadlocks in chan_local Issue_1. In the local_hangup() 3 locks must be held at the same time... pvt, pvt->chan, and pvt->owner. Proper deadlock avoidance is done when the channel to hangup is the outbound chan_local channel, but when it is not the outbound channel we have an issue... We attempt to do deadlock avoidance only on the tech pvt, when both the tech pvt and the pvt->owner are locked coming into that loop. By never giving up the pvt->owner channel deadlock avoidance is not entirely possible. This patch resolves that by doing deadlock avoidance on both the pvt->owner and the pvt when trying to get the pvt->chan lock. Issue_2. ast_prod() is used in ast_activate_generator() to queue a frame on the channel and make the channel's read function get called. This function is used in ast_activate_generator() while the channel is locked, which mean's the channel will have a lock both from the generator code and the frame_queue code by the time it gets to chan_local.c's local_queue_frame code... local_queue_frame contains some of the same crazy deadlock avoidance that local_hangup requires, and this recursive lock prevents that deadlock avoidance from happening correctly. This patch removes ast_prod() from the channel lock so only one lock is held during the local_queue_frame function. (closes issue #17185) Reported by: schmoozecom Patches: issue_17185_v1.diff uploaded by dvossel (license 671) issue_17185_v2.diff uploaded by dvossel (license 671) Tested by: schmoozecom, GameGamer43 Review: https://reviewboard.asterisk.org/r/631/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@259870 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
af6690ba7f |
Merged revisions 259104 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r259104 | mmichelson | 2010-04-26 16:44:43 -0500 (Mon, 26 Apr 2010) | 3 lines Let compilation succeed warning-free when DONT_OPTIMIZE is turned off. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@259105 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
317a12d950 |
Merged revisions 259018 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r259018 | mmichelson | 2010-04-26 16:03:08 -0500 (Mon, 26 Apr 2010) | 13 lines Prevent Newchannel manager events for dummy channels. No Newchannel manager event will be fired for channels that are allocated to not match a registered technology type. Thus bogus channels allocated solely for variable substitution or CDR operations do not result in a Newchannel event. (closes issue #16957) Reported by: atis Review: https://reviewboard.asterisk.org/r/601 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@259023 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
99a7b2fed0 |
Fix previous commit.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258675 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
8c41f2db82 |
Merged revisions 193391,258670 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r193391 | mnicholson | 2009-05-08 16:01:25 -0500 (Fri, 08 May 2009) | 8 lines Set the proper disposition on originated calls. (closes issue #14167) Reported by: jpt Patches: call-file-missing-cdr2.diff uploaded by mnicholson (license 96) Tested by: dlotina, rmartinez, mnicholson ........ r258670 | mnicholson | 2010-04-22 16:49:07 -0500 (Thu, 22 Apr 2010) | 11 lines Fix broken CDR behavior. This change allows a CDR record previously marked with disposition ANSWERED to be set as BUSY or NO ANSWER. Additionally this change partially reverts r235635 and does not set the AST_CDR_FLAG_ORIGINATED flag on CDRs generated from ast_call(). To preserve proper CDR behavior, the AST_CDR_FLAG_DIALED flag is now cleared from all brige CDRs in ast_bridge_call(). (closes issue #16797) Reported by: VarnishedOtter Tested by: mnicholson ........ (closes issue #16222) Reported by: telles Tested by: mnicholson git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258671 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
a753e8878b |
Asterisk data retrieval API.
This module implements an abstraction for retrieving and exporting asterisk data. Developed by: Brett Bryant <brettbryant@gmail.com> Eliel C. Sardanons (LU1ALY) <eliels@gmail.com> For the Google Summer of code 2009 Project. Documentation can be found in doxygen format and inside the header include/asterisk/data.h Review: https://reviewboard.asterisk.org/r/275/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258517 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
e24661fd18 |
Merge Call completion support into trunk.
From Reviewboard: CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date overview of the architecture can be found in the file doc/CCSS_architecture.pdf in the CCSS branch. Off the top of my head, the big differences between what is implemented and what is in the document are as follows: 1. We did not end up modifying the Hangup application at all. 2. The document states that a single call completion monitor may be used across multiple calls to the same device. This proved to not be such a good idea when implementing protocol-specific monitors, and so we ended up using one monitor per-device per-call. 3. There are some configuration options which were conceived after the document was written. These are documented in the ccss.conf.sample that is on this review request. For some basic understanding of terminology used throughout this code, see the ccss.tex document that is on this review. This implements CCBS and CCNR in several flavors. First up is a "generic" implementation, which can work over any channel technology provided that the channel technology can accurately report device state. Call completion is requested using the dialplan application CallCompletionRequest and can be canceled using CallCompletionCancel. Device state subscriptions are used in order to monitor the state of called parties. Next, there is a SIP-specific implementation of call completion. This method uses the methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion using SIP signaling. There are a few things to note here: * The agent/monitor terminology used throughout Asterisk sometimes is the reverse of what is defined in the referenced draft. * Implementation of the draft required support for SIP PUBLISH. I attempted to write this in a generic-enough fashion such that if someone were to want to write PUBLISH support for other event packages, such as dialog-state or presence, most of the effort would be in writing callbacks specific to the event package. * A subportion of supporting PUBLISH reception was that we had to implement a PIDF parser. The PIDF support added is a bit minimal. I first wrote a validation routine to ensure that the PIDF document is formatted properly. The rest of the PIDF reading is done in-line in the call-completion-specific PUBLISH-handling code. In other words, while there is PIDF support here, it is not in any state where it could easily be applied to other event packages as is. Finally, there are a variety of ISDN-related call completion protocols supported. These were written by Richard Mudgett, and as such I can't really say much about their implementation. There are notes in the CHANGES file that indicate the ISDN protocols over which call completion is supported. Review: https://reviewboard.asterisk.org/r/523 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
a5a0a5f867 |
Consolidate ast_channel.cid.cid_rdnis into ast_channel.redirecting.from.number.
SWP-1229 ABE-2161 * Ensure chan_local.c:local_call() will not leak cid.cid_dnid when copying. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256104 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
37797ddd52 |
Merged revisions 256009 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r256009 | russell | 2010-04-02 18:30:15 -0500 (Fri, 02 Apr 2010) | 2 lines Remove extremely verbose debug message. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256010 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
42577406fd |
Improve handling of T.38 re-INVITEs that arrive before a T.38-capable
application is executing on a channel. This patch addresses an issue found during working with end-users using res_fax. If an incoming call is answered in the dialplan, or jumps to the 'fax' extension due to reception of a CNG tone (with faxdetect enabled), and then the remote endpoint sends a T.38 re-INVITE, it is possible for the channel's T.38 state to be 'T38_STATE_NEGOTIATING' when the application starts up. Unfortunately, even if the application wants to use T.38, it can't respond to the peer's negotiation request, because the AST_CONTROL_T38_PARAMETERS control frame that chan_sip sent originally has been lost, and the application needs the content of that frame to be able to formulate a reply. This patch adds a new 'request' type to AST_CONTROL_T38_PARAMETERS, AST_T38_REQUEST_PARMS. If the application sends this request, chan_sip will re-send the original control frame (with AST_T38_REQUEST_NEGOTIATE as the request type), and the application can respond as normal. If this occurs within the five second timeout in chan_sip, the automatic cancellation of the peer reinvite will be stopped, and the application will 'own' the negotiation process from that point onwards. This also improves the code path in chan_sip to allow sip_indicate(), when called for AST_CONTROL_T38_PARAMETERS, to be able to return a non-zero response, which should have been in place before since the control frame *can* fail to be processed properly. It also modifies ast_indicate() to return whatever result the channel driver returned for this control frame, rather than converting all non-zero results into '-1'. Finally, the new request type intentionally returns a positive value, so that an application that sends AST_T38_REQUEST_PARMS can know for certain whether the channel driver accepted it and will be replying with a control frame of its own, or whether it was ignored (if the sip_indicate()/ast_indicate() path had properly supported failure responses before, this would not be necessary). This patch also modifies res_fax to take advantage of the new request. In addition, this patch makes sip_t38_abort() actually lock the private structure before doing its work... bad programmer, no donut. This patch also enhances chan_sip's 'faxdetect' support to allow triggering on T.38 re-INVITEs received as well as CNG tone detection. Review: https://reviewboard.asterisk.org/r/556/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254450 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
48edf2c78a |
Exit native bridging early for greater timing accuracy with warnings
This changes native bridging to break one millisecond early so that the more accurate timeval calculations done in the generic bridge can be performed using the bridge config. Currently the time between exiting native bridging slightly late can sometimes cause a large enough discrepancy for warnings to be missed. For the record, 1.4 does not attempt to native bridge at all when warnings are enabled. (closes issue #15815) Reported by: adomjan Review: https://reviewboard.asterisk.org/r/577/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254050 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
68d1ded8dd |
Only change the RTP ssrc when we see that it has changed
This change basically reverts the change reviewed in https://reviewboard.asterisk.org/r/374/ and instead limits the updating of the RTP synchronization source to only those times when we detect that the other side of the conversation has changed the ssrc. The problem is that SRCUPDATE control frames are sent many times where we don't want a new ssrc, including whenever Asterisk has to send DTMF in a normal bridge. This is also not the first time that this mistake has been made. The initial implementation of the ast_rtp_new_source function also changed the ssrc--and then it was removed because of this same issue. Then, we put it back in again to fix a different issue. This patch attempts to only change the ssrc when we see that the other side of the conversation has changed the ssrc. It also renames some functions to make their purpose more clear. Review: https://reviewboard.asterisk.org/r/540/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@252089 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
efea9ad922 |
Fix placing ISDN calls on hold preventing native bridging from being reexamined after a transfer.
Consider the following scenario:
/-- B
A == * == Network
\-- C
Party B calls party A (EuroISDN BRI phone)
Party A puts B on hold using the HOLD/RETRIEVE messages.
Party A calls party C.
Party A puts C on hold to talk with party B again.
Party A transfers B to C by hanging up.
The call does not get the opportunity to get re-transferred into the ISDN
network by the native bridge because native bridging is not being
reexamined after the initial transfer.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@247609 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
16 years ago |
|
|
091f850a58 |
fixes sample rate conversion issue with Monitor application
When using ast_seekstream with the read/write streams of a monitor, the number of samples we are seeking must be of the same rate as the stream or the jump calculation will be incorrect. This patch adds logic to correctly convert the number of samples to jump to the sample rate the read/write stream is using. For example, if the call is G722 (16khz) and the read/write stream is recording a 8khz wav, seeking 320 samples of 16khz audio is not the same as seeking 320 samples of 8khz audio when performing the ast_seekstream on the stream. ABE-2044 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@246899 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
7d5d0311c1 |
Merged revisions 246545 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r246545 | dvossel | 2010-02-12 17:30:17 -0600 (Fri, 12 Feb 2010) | 16 lines lock channel during datastore removal On channel destruction the channel's datastores are removed and destroyed. Since there are public API calls to find and remove datastores on a channel, a lock should be held whenever datastores are removed and destroyed. This resolves a crash caused by a race condition in app_chanspy.c. (closes issue #16678) Reported by: tim_ringenbach Patches: datastore_destroy_race.diff uploaded by tim ringenbach (license 540) Tested by: dvossel ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@246546 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
72c1b76038 |
Merged revisions 244070 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r244070 | tilghman | 2010-02-01 11:46:31 -0600 (Mon, 01 Feb 2010) | 16 lines Revert previous chan_local fix (r236981) and fix instead by destroying expired frames in the queue. (closes issue #16525) Reported by: kobaz Patches: 20100126__issue16525.diff.txt uploaded by tilghman (license 14) 20100129__issue16525__1.6.0.diff.txt uploaded by tilghman (license 14) Tested by: kobaz, atis (closes issue #16581) Reported by: ZX81 (closes issue #16681) Reported by: alexr1 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@244071 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
c277952cea |
Merged revisions 243258 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r243258 | jpeeler | 2010-01-26 12:19:10 -0600 (Tue, 26 Jan 2010) | 2 lines Remove unnecessary code in ast_read as issue 16058 has been fully solved now. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@243266 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
568c057c4c |
Extend max call limit duration from 24.8 days to 292+ million years.
If the limit was set past MAX_INT upon answering, the call was immediately hung up due to overflow from the return of ast_tvdiff_ms (in ast_check_hangup). The time calculation functions ast_tvdiff_sec and ast_tvdiff_ms have been changed to return an int64_t to prevent overflow. Also the reporter suggested adding a message indicating the reason for the call hanging up. Given that the new limit is so much higher, the message (which would only really be useful in the overflow scenario) has been made a debug message only. (closes issue #16006) Reported by: viraptor git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@241143 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
9228fba7d7 |
Fix broken call pickup
The problem was the OUTGOING flag was not getting set properly on the channel, resulting in pickup failing as ast_read thought the call was inbound. Refer to 170393 for a more verbose description as this is the same exact change. (closes issue #16539) Reported by: syspert Patches: bug16539.patch uploaded by jpeeler (license 325) Tested by: syspert git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@240179 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
03529837cc |
add silence gen to wait apps
asterisk.conf's 'transmit_silence' option existed before this patch, but was limited to only generating silence while recording and sending DTMF. Now enabling the transmit_silence option generates silence during wait times as well. To achieve this, ast_safe_sleep has been modified to generate silence anytime no other generators are present and transmit_silence is enabled. Wait apps not using ast_safe_sleep now generate silence when transmit_silence is enabled as well. (closes issue #16524) Reported by: kobaz (closes issue #16523) Reported by: kobaz Tested by: dvossel Review: https://reviewboard.asterisk.org/r/456/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@239712 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
a575a50cd5 |
fixes ast_transfer stall until hangup if called with a channel that doesn't support transfers
|
16 years ago |
|
|
cf7b67d9d3 |
Merged revisions 235635 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r235635 | jpeeler | 2009-12-18 16:29:51 -0600 (Fri, 18 Dec 2009) | 48 lines Correct CDR dispositions for BUSY/FAILED This patch is simple in that it reorders the disposition defines so that the fix for issue 12946 works properly (the default CDR disposition was changed to AST_CDR_NOANSWER). Also, the AST_CDR_FLAG_ORIGINATED flag was set in ast_call to ensure all CDR records are written. The side effects of CDR changes are scary, so I'm documenting the test cases performed to attempt to catch any regressions. The following tests were all performed using 1.4 rev 195881 vs head (235571) + patch: A calls B C calls B (busy) Hangup C Hangup A (Both SIP and features) A calls B A blind transfers to C Hangup C (Both SIP and features) A calls B A attended transfers to C Hangup C A calls B A attended transfers to C (SIP) C blind transfers to A (features) Hangup A All of the test scenario CDRs matched. The following tests were performed just with the patch to ensure proper operation (with unanswered=yes): exten =>s,1,Answer exten =>s,n,ResetCDR(w) exten =>s,n,ResetCDR(w) exten =>s,1,ResetCDR(w) exten =>s,n,ResetCDR(w) (closes issue #16180) Reported by: aatef Patches: bug16180.patch uploaded by jpeeler (license 325) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@235660 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
473837a4ab |
Change match criteria existence in ast_channel_cmp_cb to use ast_strlen_zero.
(closes issue #16161) Reported by: may213 Patches: core-show-channel.patch uploaded by may213 (license 454) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@235226 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
97bb26bf75 |
Merged revisions 233092 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r233092 | russell | 2009-12-04 11:12:47 -0600 (Fri, 04 Dec 2009) | 7 lines Only do frame payload check for HOLD frames. This code was added for helping to debug the source of invalid HOLD frames. However, a side effect of this is that it will incorrectly report errors for frames that have an integer payload. Make the check for this block specific to the HOLD frame case. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@233100 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
d9f37a67e1 |
Merged revisions 231911 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r231911 | jpeeler | 2009-12-01 15:29:31 -0600 (Tue, 01 Dec 2009) | 12 lines Fix crash with invalid frame data The crash was happening as a result of a frame containing an invalid data pointer, but was set with data length of zero. The few times the issue was reproduced it _seemed_ that the frame was queued properly, that is the data pointer was set to NULL. I never could reproduce the crash so as a last resort the crash has been fixed, but a check in __ast_read has been added to give as much information about the source of problematic frames in the future. (closes issue #16058) Reported by: atis ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@231927 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
f98c12a57d |
Merged revisions 231298 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r231298 | tilghman | 2009-11-25 16:31:57 -0600 (Wed, 25 Nov 2009) | 2 lines After a frame duplication failure, unlock the channel before returning. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@231299 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
5e2aa190fe |
Display a list of channel variables in each channel-oriented event.
(Closes AST-33) Reviewboard: https://reviewboard.asterisk.org/r/368/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@230111 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
fef304e641 |
Merged revisions 228896 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r228896 | lmadsen | 2009-11-09 09:37:43 -0600 (Mon, 09 Nov 2009) | 6 lines Update WARNING message. Update a WARNING message to give a suggested fix when encountered. (closes issue #16198) Reported by: atis Tested by: atis ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@228897 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
10fa8fe8d0 |
Merged revisions 228692 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r228692 | dvossel | 2009-11-06 16:33:27 -0600 (Fri, 06 Nov 2009) | 9 lines fixes audiohook write crash occuring in chan_spy whisper mode. After writing to the audiohook list in ast_write(), frames were being freed incorrectly. Under certain conditions this resulted in a double free crash. (closes issue #16133) Reported by: wetwired (closes issue #16045) Reported by: bluecrow76 Patches: issue16045.diff uploaded by dvossel (license 671) Tested by: bluecrow76, dvossel, habile ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@228693 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
d8e0c58437 |
Expand codec bitfield from 32 bits to 64 bits.
Reviewboard: https://reviewboard.asterisk.org/r/416/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@227580 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
1174a61612 |
Add support for calling and called subaddress. Partial support for COLP subaddress.
The Telecom Specs in NZ suggests that SUB ADDRESS is always on, so doing "desk to desk" between offices each with an asterisk box over the ISDN should then be possible, without a whole load of DDI numbers required. (closes issue #15604) Reported by: alecdavis Patches: asterisk_subaddr_trunk.diff11.txt uploaded by alecdavis (license 585) Some minor modificatons were made. Tested by: alecdavis, rmudgett Review: https://reviewboard.asterisk.org/r/405/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225357 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
cdd1f9e296 |
Finish implementaton of astobj2 OBJ_MULTIPLE, and convert ast_channel_iterator to use it.
This patch finishes the implementation of OBJ_MULTIPLE in astobj2 (the case where multiple results need to be returned; OBJ_NODATA mode already was supported). In addition, it converts ast_channel_iterators (only the targeted versions, not the ones that iterate over all channels) to use this method. During this work, I removed the 'ao2_flags' arguments to the ast_channel_iterator constructor functions; there were no uses of that argument yet, there is only one possible flag to pass, and it made the iterators less 'opaque'. If at some point in the future someone really needs an ast_channel_iterator that does not lock the container, we can provide constructor(s) for that purpose. Review: https://reviewboard.asterisk.org/r/379/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225244 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
0d4726b0a2 |
Merged revisions 223225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r223225 | mnicholson | 2009-10-09 13:20:11 -0500 (Fri, 09 Oct 2009) | 8 lines Signal timeouts by returning AST_CONTROL_RINGING when originating calls. (closes issue #15104) Reported by: nblasgen Patches: manager-timeout1.diff uploaded by mnicholson (license 96) Tested by: nblasgen, mnicholson ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@223273 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
9456ab2724 |
Deadlock in channel masquerade handling
Channels are stored in an ao2_container. When accessing an item within an ao2_container the proper locking order is to first lock the container, and then the items within it. In ast_do_masquerade both the clone and original channel must be locked for the entire duration of the function. The problem with this is that it attemptes to unlink and link these channels back into the ao2_container when one of the channel's name changes. This is invalid locking order as the process of unlinking and linking will lock the ao2_container while the channels are locked!!! Now, both the channels in do_masquerade are unlinked from the ao2_container and then locked for the entire function. At the end of the function both channels are unlocked and linked back into the container with their new names as hash values. This new method of requiring all channels and tech pvts to be unlocked before ast_do_masquerade() or ast_change_name() required several changes throughout the code base. (closes issue #15911) Reported by: russell Patches: masq_deadlock_trunk.diff uploaded by dvossel (license 671) Tested by: dvossel, atis (closes issue #15618) Reported by: lmsteffan Patches: deadlock_local_attended_transfers_trunk.diff uploaded by dvossel (license 671) Tested by: lmsteffan, dvossel Review: https://reviewboard.asterisk.org/r/387/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222761 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
a4ece92018 |
Merged revisions 221200 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r221200 | tilghman | 2009-09-30 11:55:21 -0500 (Wed, 30 Sep 2009) | 7 lines Avoid a potential NULL dereference. (closes issue #15865) Reported by: kobaz Patches: 20090915__issue15865.diff.txt uploaded by tilghman (license 14) Tested by: kobaz ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@221201 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
8c30540269 |
Correct sense of logic test committed in revision 220494.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@220495 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
aabdc575a5 |
Don't use hash-based lookups for ast_channel_get_by_name_prefix().
ast_channel_get_full() tries to use OBJ_POINTER to optimize name-based channel lookups, but this will not work properly when the channel's full name was not supplied; for name-prefix searches, there is no value in doing a hash-based lookup, and in fact doing so could result in many channels being skipped. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@220494 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
16 years ago |
|
|
b27a54b8de |
Merged revisions 219136 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r219136 | mnicholson | 2009-09-17 09:58:39 -0500 (Thu, 17 Sep 2009) | 10 lines Prevent a potential race condition and crash when hanging up a channel by removing the channel from the channel list before begining channel tear down. This fix may potentially cause problems with CDR backends that access the channel a CDR is associated with via the channel list. This fix makes the channel unavabile at the time when the CDR backend is invoked. This has been documented in include/asterisk/cdr.h. (closes issue #15316) Reported by: vmarrone Tested by: mnicholson Review: https://reviewboard.asterisk.org/r/362/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@219139 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
40c13bd1b0 |
Merged revisions 214701 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r214701 | tilghman | 2009-08-28 15:13:32 -0500 (Fri, 28 Aug 2009) | 8 lines Modify comment to be a bit more accurate. We have kept this comment around long enough, that it's pretty clear that we're keeping the code, because changing the code would require a pretty fundamental architectural shift. We've also taken criticism in some quarters, because it was believed that it was referring to the code being nasty. No, the code isn't nasty, just the operation itself is rather odd. Fixed for eternity (probably not). ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@214702 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
2794b198ce |
Merged revisions 214194 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r214194 | dvossel | 2009-08-26 11:36:42 -0500 (Wed, 26 Aug 2009) | 19 lines ast_write() ignores ast_audiohook_write() results In ast_write(), if a channel has a list of audiohooks, those lists are written to and the resulting frame is what ast_write() should continue with. The problem was the returned audiohook frame was not being handled at all, and the original frame passed into it did not contain the mixed audio, so essentially audio was being lost. One result of this was chan_spy's whisper mode no longer worked. To complicate the issue, frames passed into ast_write may either be a single frame, or a list of frames. So, as the list of frames is processed in the audiohook_write, the returned frames had to be added to a new list. (closes issue #15660) Reported by: corruptor Tested by: dvossel ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@214195 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
642bec4d6f |
AST-2009-005
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@211539 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
724c1239fc |
Fix up some issues with getting a channel by "name".
Even though the get_channel_by_name() API advertised that you could search by name or uniqueid (just as the old API did), searching by uniqueid was not actually implemented. This patch fixes that problem. The ast_channel_get_full() function now makes a second search attempt by uniqueid if the parameter was a name. The channel comparison function also now knows how to compare by unqieueid. Finally, a bug was fixed in passing where OBJ_POINTER was being passed in some scenarios where it should not have been. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@211390 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
feced6672c |
Merged revisions 210913 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r210913 | tilghman | 2009-08-06 16:45:01 -0500 (Thu, 06 Aug 2009) | 7 lines Because channel information can be accessed outside of the channel thread, we must lock the channel prior to modifying it. (closes issue #15397) Reported by: caspy Patches: 20090714__issue15397.diff.txt uploaded by tilghman (license 14) Tested by: caspy ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210914 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
28ad5ced1a |
Initial minimum ast_party_caller support.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210354 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
214453904e |
Fix order and redundancy of channel rename manager events in ast_do_masquerade.
Patch contributed by Mark Spencer. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210027 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
0a6e06c7ff |
Rework of T.38 negotiation and UDPTL API to address interoperability problems
Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
44301c95d2 |
Merged revisions 207360 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r207360 | russell | 2009-07-20 11:26:24 -0500 (Mon, 20 Jul 2009) | 9 lines Only do the chan->fdno check in ast_read() in a developer build. I changed this check to only happen in a dev-mode build. I also added a comment explaining what is going on. I also made it so that detection of this situation does not affect ast_read() operation. (closes issue #14723) Reported by: seadweller ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@207361 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
8b878c8303 |
Improve handling of AST_CONTROL_T38 and AST_CONTROL_T38_PARAMETERS for non-T.38-capable channels.
This change allows applications that request T.38 negotiation on a channel that does not support it to get the proper indication that it is not supported, rather than thinking that negotiation was started when it was not. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204948 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
fd6a49beac |
Moved trigger for BRIDGE_END CEL event so that it is more accurate.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204807 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
b5f6eac49e |
Allow trunk to once again compile under MALLOC_DEBUG
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204118 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
59c1998d67 |
Improve T.38 negotiation by exchanging session parameters between application and channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203699 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
0264eef115 |
Merge the new Channel Event Logging (CEL) subsystem.
CEL is the new system for logging channel events. This was inspired after facing many problems trying to represent what is possible to happen to a call in Asterisk using CDR records. For more information on CEL, see the built in HTML or PDF documentation generated from the files in doc/tex/. Many thanks to Steve Murphy (murf) and Brian Degenhardt (bmd) for their hard work developing this code. Also, thanks to Matt Nicholson (mnicholson) and Sean Bright (seanbright) for their assistance in the final push to get this code ready for Asterisk trunk. Review: https://reviewboard.asterisk.org/r/239/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203638 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
2affa3e999 |
Merged revisions 202496 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r202496 | russell | 2009-06-22 15:08:53 -0500 (Mon, 22 Jun 2009) | 4 lines Report CallerID change during a masquerade. Reported by: markster ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@202497 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
d8cc968adc |
Merged revisions 201450 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r201450 | mmichelson | 2009-06-17 14:59:31 -0500 (Wed, 17 Jun 2009) | 9 lines Change the datastore traversal in ast_do_masquerade to use a safe list traversal. It is possible for datastore fixup functions to remove the datastore from the list and free it. In particular, the queue_transfer_fixup in app_queue does this. While I don't yet know of this causing any crashes, it certainly could. Found while discussing a separate issue with Brian Degenhardt. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201458 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
4c0265664e |
Merged revisions 200991 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r200991 | kpfleming | 2009-06-16 12:05:38 -0500 (Tue, 16 Jun 2009) | 11 lines Improve support for media paths that can generate multiple frames at once. There are various media paths in Asterisk (codec translators and UDPTL, primarily) that can generate more than one frame to be generated when the application calling them expects only a single frame. This patch addresses a number of those cases, at least the primary ones to solve the known problems. In addition it removes the broken TRACE_FRAMES support, fixes a number of bugs in various frame-related API functions, and cleans up various code paths affected by these changes. https://reviewboard.asterisk.org/r/175/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201056 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
afcbf2e14f |
Merged revisions 200360 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r200360 | mmichelson | 2009-06-12 14:06:41 -0500 (Fri, 12 Jun 2009) | 10 lines Suppress a warning message and give a better return code when generating inband ringing after a call is answered. (closes issue #15158) Reported by: madkins Patches: 15158.patch uploaded by mmichelson (license 60) Tested by: madkins ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200361 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
dabfa94fdc |
Release the allocated channel decreasing the reference counter.
When allocating the channel use ao2_ref(-1) to release it, instead of calling ast_free(). Also avoid freeing structures inside that channel (on error) if they will be released by the channel destructor being called if the reference counter reachs 0. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200108 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
554456f0fc |
Use ast_channel_unref to instead of ast_free on a newly created channel.
Also I removed an unnecessary free of a cid_name. This will be freed properly in the channel destructor. Reported by mnicholson in #asterisk-dev. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199923 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |
|
|
c42344b319 |
ast_call_forward() todo notes and originate flag copy.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@198954 65c4cc65-6c06-0410-ace0-fbb531ad65f3 |
17 years ago |