[asterisk-dev] Advice of Charge (AOC-D) - progressing, but somehow stuck..

[Alexander Mayrhofer]

Hi,

I'm currently working on relaying Advice of Charge messages (Q.956) between
bridged ISDN calls. I'm well aware of the problems regarding AOC-E ("end of
call"), but i'm pretty confident that the architecture would allow AOC-D
("during call") messages to be forwarded. The typical application of this
would be to have an Asterisk Box in front of an PBX, and still letting the
PBX assign call charges as indicated by the carrier to cost centers etc.
(or, individual rooms, in a hotel scenario...)

Asterisk already issues a PRI_EVENT for such messages, because they are
being sent as Q.931 facility messages (However, it treats it as
PRI_EVENT_FACNAME, which is not completely correct for that case). I'v added
code for decoding those AOC-D messages (in libpri/pri_facility.c), added a
field to the PRI event facname structure (ok, that's a hack for now), and
added code to queue a OPTION CONTROL frame when Asterisk encounters such a
frame:

(call came in from the PSTN on Zap/1-1, got bridged back to the PSTN on
Zap/2-1, from where it receives AOC-D messages. I'd like to have those
messages forwarded to the other call leg - in a actual implementation, that
would of course be a different PRI)

--- snip ---
Channel 0/2, Call 32774 - received AOC-D charging: 3 units
!! Don't know how to handle 0x82 inc AOC-D recordedUnitsList
Sending facility event (/1505641634)
<< [ TYPE: Control (4) SUBCLASS: Option (11) ] [Zap/2-1]
    -- Native bridging Zap/1-1 and Zap/2-1
samuel*CLI>
Channel 0/2, Call 32774 - received AOC-D charging: 4 units
!! Don't know how to handle 0x82 inc AOC-D recordedUnitsList
Sending facility event (/1505641634)
<< [ TYPE: Control (4) SUBCLASS: Option (11) ] [Zap/2-1]
    -- Native bridging Zap/1-1 and Zap/2-1
samuel*CLI>
--- snap ---

Due to my lack of understanding the core Asterisk architecture, i'm now a
bit stuck on how to proceed, and appreciate any advice.

Questions:

- Am i queuing the CONTROL frame on the "wrong" call leg, or in the wrong
"direction"?
- Do i have to do something to get the CONTROL frame forwarded to the other
call leg of the bridged call?
- Where would i have to put the code to handle that CONTROL frame on the
destination channel?

- And (more a nice-to-have question): Would it make sense to define a
dedicated CONTROL frame type (like CHARGE?), or is re-using OPTION with an
data structure ok?

I'd post my code if that helps, but it's currently not in a stage that i'm
proud of ;)

again, any advice appreciated.

Alex Mayrhofer
enum.at