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

[Armin Schindler]

Hello Christian,

is this plan already somehow 'written'? I would like to join this
for chan-capi.
Did you talk about AOC-E as well?

regards,
Armin

On Fri, 30 Jun 2006, Christian Richter wrote:
> Hello Alexander,
> 
> during the AstriDev Conf Oskar (Sirrix guy) and me worked out how we
> could make AOC-D for cdrs and for passthrough working. It already worked
> for  Passing it between chan_sip and chan_sirrix. We planed to make a
> svn branch for that, but unfortunately Oskar hadn't much time to work on
> that anymore.
> 
> Regards,
> 
> Christian
> 
> 
> Alexander Mayrhofer wrote:
> 
> >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
> >_______________________________________________
> >--Bandwidth and Colocation provided by Easynews.com --
> >
> >asterisk-dev mailing list
> >To UNSUBSCRIBE or update options visit:
> >   http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
> >
> >  
> >
> 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>