| Summary: | ASTERISK-19180: ast_cel_fabricate_channel_from_event causes AMI VarSet events to be sent for a temporary/dummy channel | ||
| Reporter: | Corey Farrell (coreyfarrell) | Labels: | |
| Date Opened: | 2012-01-10 20:24:55.000-0600 | Date Closed: | 2012-01-11 16:53:01.000-0600 |
| Priority: | Minor | Regression? | |
| Status: | Closed/Complete | Components: | CEL/cel_custom CEL/cel_sqlite3_custom |
| Versions: | 1.8.8.1 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| Environment: | Centos 6/x86_64 | Attachments: | ( 0) asterisk_cel_noevent_varset.diff |
| Description: | I noticed AMI event for VarSet(BRIDGEPEER=) on channels that I had not received Newchannel yet, and channels I had already received Hangup. ast_cel_fabricate_channel_from_event sets a couple variables on the new temporary channel directly (eventtype, eventtime, eventextra), but then uses pbx_builtin_setvar_helper to set BRIDGEPEER. Switching BRIDGEPEER to be set the same way as the other 3 variables removes the extra VarSet AMI events. I don't think not locking is a problem since it's a temporary channel object that no other code has access to yet. Since the BRIDGEPEER variable is not actually being set on the real channel AMI should not be notified. To reproduce: 1) Enable cel_custom or cel_sqlite3_custom (or maybe just ensure one of them is loaded). 2) Track AMI Events for any call. Extra events for VarSet BRIDGEPEER will show up, one for every CEL event. | ||
| Comments: | By: Corey Farrell (coreyfarrell) 2012-01-10 20:30:51.484-0600 This patch copies the method used to set other variables in the dummy channel to prevent extra AMI VarSet events. This code effects cel_custom and cel_sqlite3_custom, I've only tested with cel_custom. | ||