[asterisk-bugs] [Asterisk 0015883]: NewChannel AMI event on DAHDI (or Zaptel) channels contains CallerID information from previous call

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15883 
====================================================================== 
Reported By:                jsmith
Assigned To:                jpeeler
====================================================================== 
Project:                    Asterisk
Issue ID:                   15883
Category:                   Channels/chan_dahdi
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.26.2 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-09-11 10:36 CDT
Last Modified:              2009-10-16 21:02 CDT
====================================================================== 
Summary:                    NewChannel AMI event on DAHDI (or Zaptel) channels
contains CallerID information from previous call
Description: 
When the dialplan attempts to make an outbound call on a DAHDI channel, an
"NewChannel" AMI event is sent.  The CallerID information in this event is
actually the information for the *previous* call on that channel (which can
be especially bad or confusing if the previous call on that channel was an
inbound call).

Not only does this mean the wrong information is being passed via the
manager interface, it has the potential of disclosing private information
about other calls on the system.

My suggestions for a resolution are either:

A) Don't pass any CallerID information for the NewChannel event (or at
least when the state is "Rsrvd")

or

B) Clear out the CallerID information after reserving a channel but before
sending out the AMI event
====================================================================== 

---------------------------------------------------------------------- 
 (0112384) svnbot (reporter) - 2009-10-16 21:02
 https://issues.asterisk.org/view.php?id=15883#c112384 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 224334

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_dahdi.c

------------------------------------------------------------------------
r224334 | jpeeler | 2009-10-16 21:02:46 -0500 (Fri, 16 Oct 2009) | 27
lines

Merged revisions 224331 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

................
  r224331 | jpeeler | 2009-10-16 20:36:08 -0500 (Fri, 16 Oct 2009) | 20
lines
  
  Merged revisions 224330 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4
  
  ........
    r224330 | jpeeler | 2009-10-16 20:32:47 -0500 (Fri, 16 Oct 2009) | 13
lines
    
    Fix stale caller id data from being reported in AMI NewChannel event
    
    The problem here is that chan_dahdi is designed in such a way to set
    certain values in the dahdi_pvt only once. One of those such values
    is the configured caller id data in chan_dahdi.conf. For PRI, the
    configured caller id data could be overwritten during a call. Instead
    of saving the data and restoring, it was decided that for all
non-analog
    channels it was simply best to not set the configured caller id in the
    first place and also clear it at the end of the call.
    
    (closes issue https://issues.asterisk.org/view.php?id=15883)
    Reported by: jsmith
  ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=224334 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-16 21:02 svnbot         Checkin                                      
2009-10-16 21:02 svnbot         Note Added: 0112384                          
======================================================================