[Home]

Summary:ASTERISK-07295: [patch] Decoding / Encoding / sending AOC-D messages ("Advice of charge")
Reporter:Alex Mayrhofer (alexmayrhofer)Labels:
Date Opened:2006-07-06 04:02:53Date Closed:2010-06-16 09:21:33
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-aocd-aoce-diff-SVNtrunk47382-0.2.txt
( 1) libpri-aocd-aoce-diff-SVNtrunk382-0.2-rerelease.txt
Description:Patch to libpri to provide facilities for forwarding "AOC-D" (advice of charge, during call) Q.956 messages between brigded channels. A corresponding patch to chan_zap.c which uses those facilites to actually bridge messages will be posted today as well.

Much of the code is copied from existing AOC-E message handling - thanks for that.

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

disclaimer has just been faxed.
Comments:By: Paul Cadach (pcadach) 2006-07-06 06:50:55

I'm not sure about requirement to encode protocol identification:
+ /* ROSE (0x91) */
+ buffer[i++] = (ASN1_CONTEXT_SPECIFIC | Q932_PROTOCOL_ROSE);

By: Alex Mayrhofer (alexmayrhofer) 2006-07-06 07:08:15

hmm.. the current encoding function produces messages which resemble exactly what we receive from our upstream carrier:

incoming message:

< Message type: FACILITY (98)
< [1c 16 91 a1 13 02 02 04 5d 02 01 22 30 0a a1 05 30 03 02 01 02 82 01 00]
< Facility (len=24, codeset=0) [ 0x91, 0xA1, 0x13, 0x02, 0x02, 0x04, ']', 0x02,0x01, '"0', 0x0A, 0xA1, 0x05, '0', 0x03, 0x02, 0x01, 0x02, 0x82, 0x01, 0x00 ]
PROTOCOL 11
A1 0013 (CONTEXT SPECIFIC [1])
 02 0002 04 5D (INTEGER: 1117)
 02 0001 22 (INTEGER: 34)
 30 000A (SEQUENCE)
   A1 0005 (CONTEXT SPECIFIC [1])
     30 0003 (SEQUENCE)
       02 0001 02 (INTEGER: 2)
   82 0001 00 (CONTEXT SPECIFIC [2])


outgoing (encoded) message:


> Message type: FACILITY (98)
> [1c 15 91 a1 12 02 01 10 02 01 22 30 0a a1 05 30 03 02 01 02 82 01 00]
> Facility (len=23, codeset=0) [ 0x91, 0xA1, 0x12, 0x02, 0x01, 0x10, 0x02, 0x01, '"0', 0x0A, 0xA1, 0x05, '0', 0x03, 0x02, 0x01, 0x02, 0x82, 0x01, 0x00 ]
PROTOCOL 11
A1 0012 (CONTEXT SPECIFIC [1])
 02 0001 10 (INTEGER: 16)
 02 0001 22 (INTEGER: 34)
 30 000A (SEQUENCE)
   A1 0005 (CONTEXT SPECIFIC [1])
     30 0003 (SEQUENCE)
       02 0001 02 (INTEGER: 2)
   82 0001 00 (CONTEXT SPECIFIC [2])
   -- AOC-D: passing 2 unit(s) from Zap/2-1 to Zap/1-1


looks fine to me (but, again, i'm neither an Asterisk nor an Q.931 guru).

By: klaus3000 (klaus3000) 2006-07-13 15:10:55

Hi! I've uploaded a new patch (along with a new patch in bug ASTERISK-7296). This patches add AOC-D and AOC-E passthrough support for Asterisk. Some details:

This patch is suitable in the follwing scenario:
PBX <--PRI--> Asterisk <--PRI--> Telco

The Telco will generate AOC-D messages (FACILITY requests) during outgoing calls and AOC-E messages on hangup.

AOC-D messages will be forwarded from the Telco to the PBX. If the bridge is not yet up when the first AOC-D is received, the AOC-D is sent once the PBX call leg is "CONNECTED". (If the PBX call leg has sent CONNECT, but yet not received CONNECT_ACK, it may happen that 2 FACILITY messages will be sent to the PBX. This is not very pretty, but it should be compliant).

If the telco hangs up, AOC-E is forwarded in the DISCONNECT message to the PBX.

If the PBX hangs up, a "fake AOC-E" message is sent in the RELEASE message to the PBX. The value is derived from the last AOC-D message received from the telco.

You have to turn AOC support explicit on in zapata.conf: allow_aoc=1

These patches are functional complete, but contains lots of added debug messages. Once the patch is stable, these debug message (the ones which contains "klaus: ...") will be removed.

I've used ast_indicate directly, no frames as I tried it with frames but it did not worked.

Please test this patch.

By: Serge Vecher (serge-v) 2006-07-13 15:12:27

klaus3000, please confirm your disclaimer status

By: klaus3000 (klaus3000) 2006-07-31 06:16:09

1. disclaimer is on file
2. As there is no feedback on this patch, I've added a backport for 1.2. Maybe we can find more testers this way.

By: Serge Vecher (serge-v) 2006-07-31 10:06:54

klaus3000: thanks for confirming the disclaimer. It is preferable that testing is done on the "trunk" patch, as that is that is the code that's candidate for merging after 1.4 release. Successful report of trunk patch testing will greatly increase chances of the merge happening ;)

By: klaus3000 (klaus3000) 2006-07-31 11:32:44

Yes I know. But for real testing of AOC you need a device which processes the AOC messages = a legacy PBX. As most people don't have a spare PBX, they have to test this feature on their production Asterisk. I know people which reject to use SNV trunk on a production system, thus I made a backport to address more potential testers.

Of course testing of 1.4 would be great, but IMO testing in 1.2 is better than no testing at all.

By: jmls (jmls) 2006-10-31 14:20:57.000-0600

this patch still applies against trunk.

By: klaus3000 (klaus3000) 2006-11-09 12:10:57.000-0600

patch updated to trunk

By: Serge Vecher (serge-v) 2006-11-15 08:08:16.000-0600

has anybody, besides klaus3000, who is monitoring this bug tested his patches? Can we please get some tests results posted so a judgement can be made whether or not this goes into trunk? Thank you!

By: Matthew Fredrickson (mattf) 2006-11-16 13:59:17.000-0600

Yes, has anyone else had a chance to check these patches?  That would help considerably in the decision to merge them in.

By: Olle Johansson (oej) 2007-02-16 07:51:38.000-0600

Any updates?

By: klaus3000 (klaus3000) 2007-02-16 07:53:52.000-0600

We still had no issues with this patch

By: Serge Vecher (serge-v) 2007-02-19 10:06:37.000-0600

alexmayrhofer: did you test patches by klaus3000?

By: Alex Mayrhofer (alexmayrhofer) 2007-02-19 10:25:24.000-0600

klaus3000 is my colleague, and i have handed this work over to him. this patch is in production on several Asterisk servers, one of them serving about 700 employees  of a medium sized company.

By: Sergio Serrano (srsergio) 2007-05-18 04:24:00

It would be possible get AOC-E data an put into CDR? I have some customers that would like put AOC-E Charge into CDR to tarif theirs customers.



By: Tomislav Parcina (parcina) 2007-05-18 07:50:58

> It would be possible get AOC-E data an put into CDR? I have some customers that > would like put AOC-E Charge into CDR to tarif theirs customers.

That's what I'm looking for!

By: klaus3000 (klaus3000) 2007-05-21 06:15:02

Yes, saving the AOC-E as CDR is possibile (with the same limitation as passthrough: that if the Asterisk extension hangs up only the last AOC-D is recorded). I've extended this patch for a customer. I will ask the costumer if it will disclaim the code.

By: Tomislav Parcina (parcina) 2007-05-23 01:41:54

> Yes, saving the AOC-E as CDR is possibile (with the same limitation as
> passthrough: that if the Asterisk extension hangs up only the last AOC-D is
> recorded). I've extended this patch for a customer. I will ask the costumer if
> it will disclaim the code.

Please do.
One thing, the patch you have created for your costumer, does it solve this problem when Asterisk extension hangs up first?

By: klaus3000 (klaus3000) 2007-05-23 02:04:35

> One thing, the patch you have created for your costumer, does it solve
> this problem when Asterisk extension hangs up first?

No. I have no idea how this could be solved. The problem is, that once Asterisk hangs up the call, all the CDRs are written and Asterisk is done with this call. Thus, if the AOC-E information is received afterwards it can't be used anymore.

A workaround would be to save the AOC-E independently into a separate file, and doing the correlation between the CDR file and the AOC-E logfile afterwards. But if you do not need 100% accuracy then I think using the last AOC-D instead of the AOC-E is acceptable. Because even with AOC-E you usually do not have 100% accuracy as the billing resolution (e.g. per second) is usually smaller than the resolution of the AOC units.

By: Sergio Serrano (srsergio) 2007-06-11 04:28:22

Hi Klaus, Ask you to your customer to release patch for put AOC into CDR?

By: klaus3000 (klaus3000) 2007-06-11 04:30:08

Yes I asked but still got no reply :-(
sorry

By: Ognjen Seslija (sekil) 2007-06-11 17:47:55

Klaus,
I patched my 1.2.18 with your patches as well some found on the Net. IF SIP side hangs up, the last AOC-D is retrieved. Everything is working fine in production for two months. IAX channel support would be nice also.
Regards,
Ognjen

By: klaus3000 (klaus3000) 2007-06-12 02:14:20

What do you mean with "IAX channel support would be nice also"?

This patch is pass-through only. Thus, it only makes sense between ZAP calls.

By: Ognjen Seslija (sekil) 2007-06-12 03:31:14

< This patch is pass-through only. Thus, it only makes sense between ZAP calls.

Sorry. I wasn't clear. My setup is that I do customer billing by AOC records. When in call and ZAP side hangs up everything gets logged properly. Using your patch and the one for SIP side hangup everything gets logged properly also. Example:

exten => h,1,Set(CDR(userfield2)=${AOCE})
exten => h,2,Set(CDR(userfield3)=${MATH(0.1*${AOCE},float)})
exten => h,3,Set(CDR(userfield4)=${HANGUPCAUSE})

When you have IAX->ZAP call and IAX side hangs up there is no proper logging because of IAX channel lack of AOC patch. That's the IAX support I was refering to.

Regards,
Ognjen

By: klaus3000 (klaus3000) 2007-06-12 04:41:58

@sekil:
> exten => h,1,Set(CDR(userfield2)=${AOCE})
> exten => h,2,Set(CDR(userfield3)=${MATH(0.1*${AOCE},float)})
> exten => h,3,Set(CDR(userfield4)=${HANGUPCAUSE})

Im still confused. My patch to chan_sip which exports AOC as channel variable for CDR extra accounting has not been submitted yet. Thus, how can you already use it?

By: Ognjen Seslija (sekil) 2007-06-12 05:49:52

@klaus3000

Isn't this your patch at http://lists.digium.com/pipermail/asterisk-dev/2006-September/023577.html ?
That's the one I'm using. The ${AOCE} variable can be used to Set(CDR(userfield)) i.e.

Regards,
Ognjen



By: klaus3000 (klaus3000) 2007-06-12 06:01:04

oh yes - this is my patch. I've already forgotten about this one ;-)
It is not a nice patch as it introduces zaptel dependencies into the SIP channel (although AOC requires zaptel, thus I could ignore this).

As you see, the patch is very short and rather easy to understand. Thus, you should not have problems adding this piece of code to iax yourself.

By: Ognjen Seslija (sekil) 2007-06-12 06:06:55

< oh yes - this is my patch. I've already forgotten about this one ;-)
< It is not a nice patch as it introduces zaptel dependencies into the SIP channel < (although AOC requires zaptel, thus I could ignore this).

Works nice for me, so far.

< As you see, the patch is very short and rather easy to understand. Thus, you
< should not have problems adding this piece of code to iax yourself.

Thanks for the tip. I'll give it a try.

Regards,
Ognjen

By: klaus3000 (klaus3000) 2007-06-12 06:33:34

Note: The chan_sip patch does not check for SIG_PRI, thus Asterisk could segfault when using other zap channels than PRI.

By: Sergio Serrano (srsergio) 2007-06-18 06:55:36

Hi again,

   I try to change chap_sip.c like you explain in http://lists.digium.com/pipermail/asterisk-dev/2006-September/023577.html but in asterisk 1.4.4 but I don't find source code same as asterisk 1.2, but I understand that your modification is in sip_hangup function, it's really that?

By: klaus3000 (klaus3000) 2007-06-18 13:53:24

yes - during hangup (processing a received BYE request)

By: Dwayne Hubbard (dhubbard) 2008-08-25 15:28:43

I'm going to handle this issue until it makes its way into trunk.  Its time to get 'er done.

By: frank koster (notthematrix) 2009-02-09 16:17:22.000-0600

Wil aoc-d and aoc-e be in the next realease of asterisk or is it already in svn?
It might come handy to calculate the costs of 09xx prenium numbers in the netherlands.
any news on it?

By: Leif Madsen (lmadsen) 2009-02-26 17:18:54.000-0600

I just noticed this issue has 3 patches attached to it, but all are marked as 'License None' -- is there something wrong here?

By: klaus3000 (klaus3000) 2009-02-27 04:28:30.000-0600

So. I searched the archive and found the patches. So I uploaded them again and now the license problem should be solved. You can delete the 3 old patches.

I also uploaded the corresponding asterisk patch (this was in the closed ASTERISK-7437495)

By: Leif Madsen (lmadsen) 2009-02-27 09:18:36.000-0600

Great, thanks klaus3000!

By: Tilghman Lesher (tilghman) 2009-03-16 15:39:40

It appears that IE 26 is interpreted in Belgium as "Charging advice" and is a network-specific extension of the Q.931 standard. See http://www.acacia-net.com/wwwcla/protocol/q931.htm [^]
 
Additional note: decode of this IE is here: http://www.acacia-net.com/wwwcla/protocol/q931_ie.htm

This merges issue PRI-32 into this one, so that the other can be closed.

By: Frank Waller (explidous) 2009-04-14 02:56:25

I have tested the patch on 1.4.21.1 and 1.4.24.1 together with the patches for forwarding PRI IE Information PRI-21 and PRI-1 and their prerequisites (Include ASTERISK-9891). They are together in production on a high volume 4 PRI (2*CPE 2*NET) system using Euroisdn and forwarding calls to an other PBX while doing some magic in between...
Now allowing for proper forwarding of digital ISDN calls (data) and passing of charge information.
Sorry, no way to test on other versions, trunk or without the other patch...

(patches did need manual work to apply together but no programming changes)

These patches are important for passing calls through to other systems, one of my clients was shocked that this was not included by default! They really should be included asap...



By: Frank Waller (explidous) 2009-04-15 04:42:34

One suggestion for improvement:
Verbose output is VERY verbose... might need bumping up levels to keep output of other things more readable.
Otherwise it works great!



By: Leif Madsen (lmadsen) 2009-07-24 10:35:40

Having [post 1.4] in the topic is silly.

By: nenadr (nenadr) 2010-01-23 03:18:11.000-0600

HI ! i'm succesfully using this patch along with a patch from bug 007495 for chan_zap/dahdi and some code fragments based on posts on mail-list for chan.sip and chan_iax, adapted to 1.2 and 1.6.2, for AOC-D/AOC-E based billing of calls over PRI/BRI interfaces for about year now, and I wonder has anyone managed to update this libpri patch for http://svnview.digium.com/svn/libpri/branches/1.4/ (aka libpri trunk) version of libpri (there are some major ROSE handling changes there) ?

By: David Vossel (dvossel) 2010-04-14 11:35:03

AOC has been implemented.  Check out the following review requests for details on testing and the patches.

Asterisk Part: https://reviewboard.asterisk.org/r/552/

LibPRI Part: https://reviewboard.asterisk.org/r/619/

By: Leif Madsen (lmadsen) 2010-04-14 14:09:58

THE END IS NEAR! LONG LIVE THE QUEEN!

By: Russell Bryant (russell) 2010-06-16 09:21:29

AOC support has been completed and merged into Asterisk trunk.  It will be a part of Asterisk 1.8.  doc/advice_of_charge.txt has some additional information.