Summary:ASTERISK-05995: [request] Pass AOC information from Zap <-> IAX
Reporter:Jan-Peter Koopmann (jkoopmann)Labels:
Date Opened:2006-01-06 06:04:43.000-0600Date Closed:2011-06-07 14:02:53
Versions:Frequency of

I would love to have the AOC values transmitted in many PSTNs (at least in germany) to be stored in a seperate cdr value. The bristuffed version is able to receive the AOC-E information but cannot store it in the CDR due to the missing column.
Comments:By: Russell Bryant (russell) 2006-01-10 23:19:20.000-0600

Custom CDR variables are already supported.  Please consult the asterisk-users mailing list or #asterisk IRC channel on freenode for more information.

By: Jan-Peter Koopmann (jkoopmann) 2006-01-11 00:32:43.000-0600

Thanks for my nice karma. Really pays off to report bugs I see, even though we might disagree on this particular case. Such is life. Back to business:

The only custom cdr field I know about is the userfield but I will jump over to freenode and ask around. Still the feature request remains: Why does this have to be a customized field? This makes sense for many people especially in Germany. I have been asked by customers etc. several times on how to implement this. From my point of view the AOC (or call it actual cost or whatever) field is just as important as "Last Application" or "accountcode" etc. and these fields are in the base system and not custom cdr values.

Does every new CDR field - no matter how useful it might be - have to be implemented as a custom CDR field from now on? If this is the case I apologize and please reclose the bug report then.

Kind regards,

By: zoa (zoa) 2006-01-11 03:20:12.000-0600

i personally also think this should be a standard cdr field, instead of a custom one.

By: Jan-Peter Koopmann (jkoopmann) 2006-01-11 03:29:07.000-0600

Actually there is more to it than just the AOC field. Just spoke to some other people and what we really need in Germany is that the AOC data is also able to hop to other channel types. Consider


You should be able to receive the AOC values from the incoming ISDN and transfer it to the outgoing ISDN even though the channel type changed. The cleanest way to do this should be a new AST_CONTROL frame (e.g. AST_CONTROL_AOC). Otherwise we would have to patch stuff into AST_FRAME_TEXT I suppose which does not seem all that clean to me.

Again: Please remember that this is a standard ISDN feature and nothing overly fancy! A lot of companies in Germany do cost accounting on the basis of AOC fields. Currently if you put a * between the PSTN and the company phone system they loose that ability!

By: Russell Bryant (russell) 2006-01-13 13:52:36.000-0600

For the CDR, you can set a custom CDR field by doing ...


and NoOp(${CDR(aoc)}) to read it back.

Then, you can use cdr_custom to define a custom format for ouputting csv cdr's.  I'm not sure which other modules have/haven't been converted to support custom CDR variables, but at some point, they all should be.

I'll change this to be a feature request for being able to pass AOC information over IAX.

Also note that we can accept patches to make this work with chan_zap, but obviously nothing related to bristuff.

By: Matthew Fredrickson (mattf) 2006-01-14 08:49:27.000-0600

Hrm... this is a pretty interesting idea.  I've been thinking about this for a while as well.  I believe there are implementations of AOC available for SIP as well, and I know there is one for PRI.  It probably would be worth having infrastructure for transporting/recording AOC within asterisk.  Right now, we have support for it in libpri, but we don't really do too much with it outside of that context.  I've been considering a similar issue (architecturally at least) about passing progress information between channel types, possibly by using the data portion of the frame (or something of that nature) for transporting it.  Maybe we could do something similar (as you suggested) for AOC.

By: Jan-Peter Koopmann (jkoopmann) 2006-01-16 03:21:41.000-0600

Thanks for the information on custom cdr handling in the dialplan. I really did not knew about this. Is there some documentation on this available anywhere?

One question remains though: How do I get the AOC information from chan_zap (or chan_capi or whatever one uses) in the dialplan so I could possibly put it in the AOC custom field? Let's assume for a second this cannot be done, why exactly is my original question "just a configuration issue" then?

bristuff: Sure. If mattf changes chan_zap this will automatically be included in bristuff sooner or later. Suits me fine.

@mattf: Thanks for taking this in your ToDo list. Please if possible please change the infrastructure of the base system in such a way that other ISDN-channel drivers (chan_capi, vISDN etc.) can make use of it as well.

And please: If somehow possible AOC or an equivalent field (cost of call or whatever) should be part of the standard CDR information and should not be solved via custom CDR mechanisms. Have a look at asterisk-users. I have only been in there for a couple of days and already found several questions regarding AOC, ISDN and Asterisks support for it. This obviously is not just a one man request. :-)

By: pisac (pisac) 2006-01-16 16:13:00.000-0600

I miss AOC informations also, and I'm very surprised that Asterisk do not support this standard ISDN feature. Of course, AOC should be a standard field in CDR.

By: mimmo (mimmo) 2006-01-17 00:45:08.000-0600

I periodically receive this message:
!! Unknown IE 26 (cs6, Unknown Information Element)
I think it's AOC in Italy. This is a feature commonly used in this country for reporting and billing.
I personally think thos should be a mandatory feature in a professional PBX!

By: Jean-Denis Girard (jdg) 2006-01-17 01:14:29.000-0600

Just to add my voice to people asking for this feature, it is also used in France (and French Polynesia).
This is important when using Asterisk as a gateway between the telco and an existing PaBX. Very often companies have billing software on the PaBX which is based on AOC; the asterisk gateway simply breaks the billing software. People don't like this regression, so asterisk should be able to pass AOC on bridged zap channels.

By: Olle Johansson (oej) 2006-01-18 12:13:39.000-0600

Please note that we are moving from a fixed CDR format to a dynamic format with the custom CDR variables. There should be no need to discuss what should be part of the CDR record as soon as the CDR drivers actually support custom CDR fields, then it's up to the sysadmin to configure what goes into each CDR. The problem now is that the infrastructure is there, but only one CDR driver actually supports it.

By: Matthew Fredrickson (mattf) 2006-01-24 13:13:16.000-0600

This discussion probably would be better moved to the -dev mailing list.  That is a more appropriate place for proposed framework additions and changes.  If the interested parties would like to propose a way to do it there, we can discuss this in a little more detail.