[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 20:40 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
====================================================================== 

---------------------------------------------------------------------- 
 (0112381) svnbot (reporter) - 2009-10-16 20:40
 https://issues.asterisk.org/view.php?id=15883#c112381 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 224331

_U  trunk/
U   trunk/channels/chan_dahdi.c
U   trunk/channels/sig_pri.c

------------------------------------------------------------------------
r224331 | jpeeler | 2009-10-16 20:40:10 -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=224331 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-16 20:40 svnbot         Checkin                                      
2009-10-16 20:40 svnbot         Note Added: 0112381                          
======================================================================