[asterisk-dev] Passing AOC information across channels
Olle E Johansson
oej at edvina.net
Mon Jan 30 11:42:06 MST 2006
Koopmann, Jan-Peter wrote:
> Hi,
>
>
>
>>>The AOC information tells you the exact cost for the call while the
>>>accountcode
>>
>> > specifies where the cost should be charged to in your company. This
>>might explain
>> > our misunderstanding in bug 6152. There currently seems to be no
>>way
>>of storing
>> > the AOC information in the CDRs. "Use custom CDRs" does not seem to
>>be a valid answer,
>> > since there is no way to access the AOC information from within the
>>dialplan. At least none I know of. Correct?
>>
>>No. Custom CDR variables can be anything - the amount of apples, the
>>LCR route identifier, the absolutely needed Inter-galactic routing
>>number
>>and the Mastercard pin code. They are working in Asterisk 1.2 and svn
>>trunk.
>
>
> Let's settle this once again. I have understood the use of custom CDR and I know it can be anything I like. That is not the point and never really has been. My original request in bug 6152 was "I would like to store AOC in CDR". Your response was: "Use custom CDR, this is a configuration issue, -2 karma".
>
> Even though my original question might have been misleading a bit what it really meant was "We need an infrastructure to get and process AOC information". This clearly is not a configuration issue since there currently seems no way of fetching the AOC from libpri what I would need to do in order to store it in a custom cdr field.
>
> Therefore I keep stressing this point since receiving a bad "configuration issue" karma for this does not feel right. :-)
>
>
>
>>We are moving towards a more dynamic format for CDRs, which means that
>>we are very cautios of adding more fields to the fixed formats.
>>
>>The current problem with custom CDR variables are that the developers
>>of the CDR drivers haven't added support for them in the CDR drivers.
>>There
>>is no way you can tell the MySQL CDR driver "oh, by the way, please
>>add
>>the AOC CDR variable to field #18, thank you and have a cookie on me".
>>This is needed.
>
>
> I know, I understand and I am all in favor! :-)
>
>
>>As far as I see it, the problem is that neither of the three AOC codes
>>are available from incoming zap calls. The patch that added AOC-E does
>>nothing with it at all, so it is not reachable.
>
>
> Have not had a look at it but yes that is my knowledge as well.
>
>
>> From reading the specs, this is an ETSI standard which seems very
>>European (newton's telecom dictionnary claims that it is only used in
>>GSM networks). We need to either convince (or pay) Digium (read:
>>mattf)
>>to add it or create a patch and submit it to the bug tracker. What is
>>needed is taking the AOC and putting it in a channel variable. After
>>that we can either store it in the cdr user field or - when it is
>>useful - in the CDR variables for storage by the CDR drivers.
>>
>>Questions:
>>- Has anyone used AOC on PRI links outside of Europe?
>>- Anyone that wants to hack zaptel/libpri to fix this?
>
>
> I originally talked about this with Klaus-Peter Junghanns. If I understood him correctly he
> would love to add AOC support but needs some infrastructural changes
in Asterisk to do so
> (e.g. a facility to transport AOC information across channels). He
sort of gave up on this
> topic and told me something like "You convice the Asterisk guys to
agree to the necessary
> infrastructural changes and I will start with AOC support".
>
> I am pretty sure that once we agree on how to do this (new AST_CONTROL frame yes/no? Etc.)
>we can convince him to have another look at it.
>
I don't think AST_CONTROL frames is the way to go. We must be able
to handle this in a more generic way, like I proposed earlier, with
either dialplan variables
or a dialplan function. Transmission of cost between call legs seems to
me like something you want to be in control of in the dial plan. (Your
service provider's cost should not be transmitted to your customers).
But I do understand why he wants it in AST_CONTROL frames on the other
hand, so it's not an easy fix. Anyone with a suggestion?
Before you contract KPJ about it, make sure that he agrees to disclaim
the code to Digium - otherwise you won't see it in Asterisk but only in
his patches.
/Olle
More information about the asterisk-dev
mailing list