Can we extract the ANI-II from the ISUP-OLI in the From: field to determine which calls are payphone calls? So that payphone calls will show up in our cdr reports.
do you have a sip packet
do you have a sip packet showing an example of this entry in the From: header?
It's possible to extract the
It's possible to extract the information from the headers if it's provided but I'd like to know if there's a field in CDR where it would be appropriate to store said information? I initially considered the "userfield" but it appears TL MTE uses this to keep track of which tenant the call belonged to.
newer versions of asterisk
newer versions of asterisk support additional userfields I believe, you should be able to add a column and reference it in cdr_mysql.conf.
I'm running 1.4.35 which, as
I'm running 1.4.35 which, as far as I can tell, unfortunately does not support this feature.
I added a column to the cdr table called "extra_data"
I then added a [columns] section to my cdr_mysql.conf and added a line like...
alias extra => extra_data
Which I got from http://code.google.com/p/audiowiki/source/browse/trunk/cdr_mysql.conf?s…
I tested it by creating a feature code that is a copy of tl-goto-userexten and added as the 2nd line line...
exten => s,n,Set(CDR(extra)=Testing 123)
And then queried the database... The "extra_data" column is NULL :-(
It seems that this features is available in 1.6 but I'd rather not install/go through the hassle of upgrading as it's not an LTS release and it seems to have special issues of it's own that I don't want to bother with. If I'm going to go through the upgrade process/hair-pulling event, I'd rather just upgrade to 1.8 :-)
Does what I've done seem like it would accomplish what I want if I had the correct version or am I just doing it wrong?
AFAIK your configuration
AFAIK your configuration entry looks appropriate for a asterisk 1.6.2 installation. (the list of columns already exists in the 1.6 sample files, you'd just be adding your alias to the end of a lengthy list)
as of right now I am only aware of a couple issues standing in the way of a 1.8 deployment:
MOH for parked calls when module res_timing_dahdi is loaded
multi-parking in 1.8 not parking channel in correct parking lot
new feature of 1.8, SIP UPDATE message, will crash older proxies requiring you to possibly update your customers prior to upgrading.
Bump