[asterisk-dev] Passing AOC information across channels

[Tilghman Lesher]

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.

-- 
Tilghman