[asterisk-dev] Passing AOC information across channels

[Olle E Johansson]

Tilghman Lesher wrote:
> On Monday 30 January 2006 16:18, Steven Critchfield wrote:
> 
>>On Mon, 2006-01-30 at 21:50 +0000, tim panton wrote:
>>
>>>On 30 Jan 2006, at 18:42, Olle E Johansson wrote:
>>>
>>>>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 sometimes it should be passed through asterisk. Like when you
>>>put an asterisk between an existing PBX
>>>and the PRI the pbx was connected to. If that PBX does stuff with
>>>the AOC (like charging cost centers or
>>>limiting call costs) then Asterisk needs to pass it through.
>>>
>>>
>>>>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?
>>>
>>>It isn't CONTROL, but it probably should be in a  frame. It
>>>strikes me as being more like the HTML or TEXT frames
>>>in IAX. It would be nice to try and piggy back it on a voice
>>>frame, but that might get ugly.
>>
>>It seems to me that this should be a channel variable, but I
>>haven't looked into how channel variables are sent from one side to
>>the other. Might be interesting to make sure channel variables
>>could be transmitted at configurable intervals during a call. Of
>>course that would handle IAX, but I don't know about SIP or if that
>>is even a good option for Zap or libpri.
>>
>>Anyone familiar with the messages passed in the D channel of ISDN
>>want to chime in on the thought of exposing some of the messages
>>via channel variables? While most calls might not benefit from it,
>>I could see some custom apps that might make use of the extra info.
> 
> 
> Given that these messages can occur at any time during a call
> (beginning, middle, or end), it really does beg for a frametype.
> Channel variables are really only appropriate for messages which
> appear exclusively at the beginning of a call.  If you want to relay
> AOC which appears towards the middle or end, you need a frame to pass
> along the information.
> 
> I do agree with Olle, though, that passing along the AOC IE isn't
> always advisable.  Perhaps we could do something similar to CallerID
> presentation, where we block it from passing along past a certain
> point.  The main point is that for an AOC IE, what we've got is an
> asynchronous event being passed into a synchronous stream.  We can't
> just stop and ask the dialplan how to proceed when we get such an IE;
> the handler must already be set up to handle such an event.
> 
Thinking about it, both are valid. To get it into CDRs, we need a 
channel variable with the AOC-E (the final message). The code for 
finding AOC-E is already within chan_zap, but we do not set a channel 
variable, something that should be easy to fix.
(See http://bugs.digium.com/view.php?id=3843)

In order to optionally transmit all AOC-* through during a call and 
before a hangup, we need control frames. This can't be done in the 
dialplan since the dial plan does not really execute during the call.

/O