Summary:	ASTERISK-02392: [post-1.0][patch]Move 'lastcallerid' into 'struct ast_channel'
Reporter:	robf (robf)	Labels:
Date Opened:	2004-09-12 11:53:42	Date Closed:	2011-06-07 14:10:00
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) lastcallerid.diffu.txt
Description:	There are three different channel types (Zap, MGCP, and Skinny) that keep track of 'lastcallerid', deep down in private data structures that are not exposed through common include files, and are thus inaccessible from applications. ****** ADDITIONAL INFORMATION ****** I've been experimenting with options here.  I started by trying to move some struct definitions out of chan_zap.c into a .h file that could be included elsewhere, but that got really ugly, and would have to be done for each channel type.  I looked further and there are only a couple places the lastcallerid fields are used right now.  I've moved the callerid field out of zt_pvt, and the equivalents in chan_mgcp and chan_skinny, and up into ast_channel (in asterisk/channel.h).  Now I can access this information from an app_*.c of my own.  There was only one place in chan_zap that I was unsure of...  Someone with more PRI knowledge should take a look... Patch included.  I have a disclaimer on file.
Comments:	By: Brian West (bkw918) 2004-09-12 16:59:52 Naughty Naughty.... channel.h changes...... hehe bkw By: Brian West (bkw918) 2004-09-12 17:45:39 Save the callerid before it gets clobbered: [somecontext] exten => _.,1,SetVar(ORIG_CALLERIDNUM=${CALLERIDNUM}) ; then start all extensions with priority 2 [othercontext] include => somecontext exten => _NXXNXXX,2,Dial(Zap/g1/foo) exten => _NXXNXXX,3,Hangup exten => 1234,2,SetCallerID(123456) exten => 1234,3,Dial(Zap/g2/foo) exten => 1234,104,SetCallerID(${ORIG_CALLERIDNUM}) exten => 1234,105,Goto(5551212,1) Then anytime you want to move current callerid to ORIG_CALLERID just goto(exten,1) bkw By: robf (robf) 2004-09-12 18:06:20 While I agree that's a pretty neat idea, it won't help get vertical service code features into res_features or into asterisk applications of their own.  Three diffferent channel types store lastcallerid in structures that are completely hidden from the rest of the code -- no struct definitions in header files to allow them to be used elsewhere. An alternative to changing the channel structure to expose the lastcallerid string would be to add an entry point to each channel type to return lastcallerid in a read-only fashion...  I'd be interested in why it would need to be read-only  from within Asterisk... By: Mark Spencer (markster) 2004-09-12 23:57:50 What is the application for needing the last callerid in the channel? By: robf (robf) 2004-09-13 10:12:45 My intention is to move vertical service code functions out of specific channel drivers (though some may be more difficult than others), and put them either in their own applications, or into res_features. In particular, there are several that need access to the last callerid information, and scripting around in the dialplan to save the last callerid somewhere else seems like a hack, especially when channel drivers are already keeping track of that automatically. The first set of features on my list would be: readback of last callerid automatic call return add to blacklist add to arbitrary list Personally, I'd rather see these in applications, because if they're split up into well-thought-out building blocks, then the power of the dialplan could still be used to customize their particular behavior.  For example, perhaps a single new application is all that's necessary, that just retrieves the lastcallerid value and puts it into a channel variable.  Or, now that I think about it, maybe there just needs to be a new automatic channel variable defined... By: robf (robf) 2004-09-13 10:35:42 Ok, so I looked into the automatic channel variable thing, and it looks like implementation of that would be done in pbx.c, and would need the lastcallerid to be available in struct ast_channel anyway... I like the idea of adding LASTCALLERID, LASTCALLERIDNAME, and LASTCALLERIDNUM, but I still like the idea of that data being available for other C applications by making it available in ast_channel... By: robf (robf) 2004-09-13 10:41:09 New patch -- now includes addition of LASTCALLERID* channel variables to pbx.c. By: robf (robf) 2004-09-13 19:16:17 Forget it.  This version doesn't work like I thought it did.  I'm back to the drawing board. Bug marshals -- kill this bug report.