[asterisk-bugs] [Asterisk 0016957]: [patch] Rogue Newchannel events for failed Originate calls

Asterisk Bug Tracker noreply at bugs.digium.com
Thu Mar 4 09:26:13 CST 2010


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16957 
====================================================================== 
Reported By:                atis
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16957
Category:                   Core/PBX
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.1.15-rc2 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-03-03 16:36 CST
Last Modified:              2010-03-04 09:26 CST
====================================================================== 
Summary:                    [patch] Rogue Newchannel events for failed Originate
calls
Description: 
When using AMI Originate to unavailable device, there's NewChannel event
without following Hangup event. 

I traced this to ast_pbx_outgoing_cdr_failed() which creates new channel
for CDR posting purposes, however destroys without ast_hangup() sending
Hangup event. It could probably be fixed by replacing ast_channell_free()
with ast_hangup(), however in SVN trunk there's function for allocating
dummy channel instead. 

Attached patch that won't generate events for channels with empty names
(this is probably why there was check for empty name_fmt, however it's
impossible to call ast_channel_alloc with empty name_fmt.

Affected 1.6.1 and 1.6.2 and probably below. SVN trunk uses dummy channel,
so probably unaffected.
====================================================================== 

---------------------------------------------------------------------- 
 (0118963) atis (reporter) - 2010-03-04 09:26
 https://issues.asterisk.org/view.php?id=16957#c118963 
---------------------------------------------------------------------- 
There are many places in asterisk where ast_channel_alloc() is called with
non-empty name and then destroyed with ast_channel_free(). It seems that
any such use would generate Newchannel AMI event as well as device state
error. 

Most weird cases are:

apps/app_minivm.c:      ast = ast_channel_alloc(0, AST_STATE_DOWN, 0, 0,
"", "", "", 0, "%s", "");

apps/app_voicemail.c:           if ((ast = ast_channel_alloc(0,
AST_STATE_DOWN, 0, 0, "", "", "", 0, "Substitution/voicemail"))) {

main/logger.c:          struct ast_channel *c = ast_channel_alloc(0, 0,
"", "", "", "", "", 0, "Logger/rotate");

main/manager.c:                 c = ast_channel_alloc(0, 0, "", "", "",
"", "", 0, "Bogus/manager");

main/pbx.c:                                     struct ast_channel *bogus
= ast_channel_alloc(0, 0, "", "", "", "", "", 0, "Bogus/%p", vars);

main/pbx.c:             struct ast_channel *tmpchan = ast_channel_alloc(0,
chan->_state, 0, 0, chan->accountcode, chan->exten, chan->context,
chan->amaflags, "AsyncGoto/%s", chan->name);

main/pbx.c:     struct ast_channel *chan = ast_channel_alloc(0,
AST_STATE_DOWN, 0, 0, "", "", "", 0, "");

main/pbx.c:                             chan = ast_channel_alloc(0,
AST_STATE_DOWN, 0, 0, "", "", "", 0, "OutgoingSpoolFailed");

I wonder is the channel name for them really necessary? If so, it could be
united to format "Bogus/" so that both channel event and device IE is not
used. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-03-04 09:26 atis           Note Added: 0118963                          
======================================================================




More information about the asterisk-bugs mailing list