[Asterisk-Dev] Q.956 Advice of Charge (AOC) - basic implementation now in CVS

[Klaus Darilion]

Hi Frank!

I'm stille waiting for the customer to declare which kind of AoC is 
used. If it is AoC-D, I surely can provide them.

regards,
klaus

Frank Sautter wrote:
> hello klaus,
> 
> Klaus Darilion wrote:
> 
>> Are there any news on Advice of Charge inegration into asterisk?
> 
> no, apparently there is nobody with enough asterisk-dev skill and the 
> need for AOC :-/
> at the moment the bridge is destroyed to early and the channels are hung 
> up to early. the hangup and destruction of the bridge should not be done 
> before all hangup messages are processed.
> 
> maybe this is the time for setting up a bounty on that.
> are there any other fellows?a
> 
>> I understand the problem of relaying the AOC at the end of the call in 
>> a bridged scenario.
> 
> exactly.
> 
>  > But is it possible to relay AOC-D messages during the call?
> this should be possible.
> although there is currently no code for decoding or encoding of AOC-D 
> messages (mainly because i do not have AOC-D on our E1-PRI).
> as you are asking for that... are you getting AOC-D IEs dumped to the 
> asterisk console when increasing verbosity and if so could you send them 
> to me so i can write a decoder and encoder for them?
> 
> interestingly newer snom firmware is also featuring AOC for the snom SIP 
> phones :-)
> 
>> Frank Sautter wrote:
>>
>>> my patches for basic support of Advice of Charge Q.956 (AOC) are now 
>>> in the cvs version of asterisk 
>>> http://bugs.digium.com/bug_view_page.php?bug_id=0003843 .
>>>
>>> The ROSE messages are decoded and encoded in libpri and delivered to 
>>> chan_zap which is displaying the charged units as debug message.
>>>
>>> At the moment the behaviour of a bridged channel does not allow to 
>>> forward these AOC messages to another channel. The problem is, that 
>>> the bridge is destroyed very early and there is no possibility to 
>>> send the AOC messages to a connected PBX or to the CDR when they are 
>>> received from the telco .
>>>
>>> now, as the lowlevel part is done, maybe there are some decent 
>>> developers with more insight into the channel bridging than me who 
>>> can change the behaviour of a bridge when a call is hungup.
> 
> 
> regards,
>  frank
> 
>