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

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16957 
====================================================================== 
Reported By:                atis
Assigned To:                mmichelson
====================================================================== 
Project:                    Asterisk
Issue ID:                   16957
Category:                   Core/PBX
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.6.1.15-rc2 
JIRA:                       SWP-1019 
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-31 13:04 CDT
====================================================================== 
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.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0015291 [regression] Received invalid event tha...
====================================================================== 

---------------------------------------------------------------------- 
 (0120038) mmichelson (administrator) - 2010-03-31 13:04
 https://issues.asterisk.org/view.php?id=16957#c120038 
---------------------------------------------------------------------- 
I have an idea that should cover the other cases that atis has pointed out.
The determination of whether a NewChannel event is sent depends on the
name_fmt parameter to ast_channel_alloc_ap(). I think what makes more sense
is to perform a search for a specific channel technology. If one is found,
then send the NewChannel event. If not, then do not send the NewChannel
event.

As far as I know, most administrators don't actually care to know that a
bogus channel was created just for facilitating variable substitution, so
not sending a NewChannel event in these situations should be okay. I'll
have a patch up as soon as I have verified that what I have written will
work. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-03-31 13:04 mmichelson     Note Added: 0120038                          
======================================================================