[Home]

Summary:ASTERISK-14820: NewChannel AMI event on DAHDI (or Zaptel) channels contains CallerID information from previous call
Reporter:Jared Smith (jsmith)Labels:
Date Opened:2009-09-11 10:36:03Date Closed:2010-04-06 13:22:52
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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

****** ADDITIONAL INFORMATION ******

Here's a capture of an AMI session in which an outbound call was made.  I've added some comments to the capture, indicated by semicolons on the beginning of the line.  Phone numbers have been changed, to protect the innocent.  It should also be noted that the CallerID has been set to "John Q. Public <8668340996>" before this point in the dialplan.

; here is the call in the dialplan to the Dial() application, asking
; it to call out a DAHDI channel

Event: Newexten
Privilege: call,all
Channel: SIP/4029-b23866e8
Context: macro-dialout-trunk
Extension: s
Priority: 19
Application: Dial
AppData: DAHDI/g0/19998868132|300|wWtT
Uniqueid: 1252618998.342

; Now we get the "Newchannel" event, showing that the DAHDI channel
; (number 3 in this case) has been reserved, so that no other call
; can steal this channel away from us

; Notice that the CallerID information is from the *previous* call
; on this DAHDI channel

Event: Newchannel
Privilege: call,all
Channel: DAHDI/3-1
State: Rsrvd
CallerIDNum: 3339957321
CallerIDName: Caller Previous
Uniqueid: 1252618998.343

; Now we get the the "Newstate" event.  Notice how the CallerID information
; is now correct for this call

Event: Newstate
Privilege: call,all
Channel: DAHDI/3-1
State: Dialing
CallerID: 8668340996
CallerIDName: John Q. Public
Uniqueid: 1252618998.343

Event: Dial
Privilege: call,all
Source: SIP/4029-b23866e8
Destination: DAHDI/3-1
CallerID: 8668340996
CallerIDName: <unknown>
SrcUniqueID: 1252618998.342
DestUniqueID: 1252618998.343

Event: Newcallerid
Privilege: call,all
Channel: DAHDI/3-1
CallerID: 9998868132
CallerIDName: <Unknown>
Uniqueid: 1252618998.343
CID-CallingPres: 0 (Presentation Allowed, Not Screened)
Comments:By: Jeff Peeler (jpeeler) 2009-10-13 14:58:29

I'm having difficulty reproducing this. Are these PRI channels here? Do you still have the chan_dahdi.conf for uploading?
By: Digium Subversion (svnbot) 2009-10-16 20:36:49

Repository: asterisk
Revision: 224330

U   branches/1.4/channels/chan_dahdi.c

------------------------------------------------------------------------
r224330 | jpeeler | 2009-10-16 20:36:48 -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 ASTERISK-14820)
Reported by: jsmith

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

http://svn.digium.com/view/asterisk?view=rev&revision=224330
By: Digium Subversion (svnbot) 2009-10-16 20:40:10

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 ASTERISK-14820)
 Reported by: jsmith
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=224331
By: Digium Subversion (svnbot) 2009-10-16 20:46:51

Repository: asterisk
Revision: 224332

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

------------------------------------------------------------------------
r224332 | jpeeler | 2009-10-16 20:46:50 -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 ASTERISK-14820)
   Reported by: jsmith
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=224332
By: Digium Subversion (svnbot) 2009-10-16 20:49:30

Repository: asterisk
Revision: 224333

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

------------------------------------------------------------------------
r224333 | jpeeler | 2009-10-16 20:49:30 -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 ASTERISK-14820)
   Reported by: jsmith
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=224333
By: Digium Subversion (svnbot) 2009-10-16 21:02:47

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 ASTERISK-14820)
   Reported by: jsmith
 ........
................

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

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