[asterisk-dev] Passing AOC information across channels

[Christian Richter]

I want to continue my thoughts regarding this thread. I have developed 
an idea on how we can fix a part of the problem of "post-call events". I 
want some asterisk developers to look through the concept, and add 
comments to it.

I think this is a way we could go and which would arm us for other 
events than AOC (E).

Please find attached the architecture of pct (post-call tracker).

Thanks,

Christian
(crich)
-------------- next part --------------
Post-Call Tracker Architecture Draft
====================================


This document describes a way how to implement post-call events for different
channel technologies in asterisk.

First of all there is an overview of the problem, then a way of how to solve
it is discussed.


* The Problem
-------------

Asterisk supports multiple telephony technologies, it abstracts every
technology in a common channel architecture, which contains a subset of
functionality of the original functionalities of each technology. This means
that the asterisk channel architecture can not cover all special details of a
certain technology.

One famous example is the ISDN AOC message. After an ISDN call (after
Release_complete), there may occure AOC facilities. An AOC facility contains
billing information.

Asterisk stops the call bridge very soon, an ISDN Disconnect will be
translated to asterisk as a hangup. A hangup will destroy the channel
structure, which means every post disconnect(isdn) message cannot be processed
by the standard call-finish routines from asterisk and cannot be transfered
through asterisks native channel interface to the "other end" channel.

The CDR will be created directly after the hangup, so there will be no chance
to add the AOC information to it, but this would be very useful. When the AOC
message arrives finally, there is no more channel anymore with which the
information could be combined, also the CDR is gone already.

There are numerous other examples in ISDN, where post-call information could
be useful to the other asterisk channel end, or should be processed by
asterisk routines. One important is the CCBS facility. This allows the user to
request a call back if the other end is busy. Which means more comfort to the
user, since he doesn't need to dial and dial again, till the other end is
free.


* One Way to solve it
---------------------

To solve this problem, there needs to be an instance which takes care of calls
after they where hangup'ed, at least for a certain timeout. This instance
needed to track every hanguped channel of technologies which support post-call
facilities, namely chan_zap, chan_sip and chan_misdn for now.

This instance will be called pct (post-call tracker) in the further document. 

The pct would be embedded in an ressource object, which could be loaded
dynamically. It has a configuration file which contains the
channel-technologies, which need to be tracked, and the timeout values after
which a call can be safely considered as completely finished.

There will be a need to hook the pct interface into the post_cdr function. It
needed also interface functions to transmit and receive out-of-band
information via a post-call reference object with the involved channel
drivers, these information will be encapsulated in special frames.

The life of an pct object will start with the hangup, and end either with the
processed post-call event or with a timeout. A pct object will be accessed
with a pct reference.

To create a pct object, a channel technology needs to create it explicitly
when it finishes the call in the ast_hangup function. 

The channel technology needs to define an identifier, for later post-call
information transmission, this identifier would be the call-reference in
PRI/BRI. This identifier will be supplied by the post-call event, like the AOC
information.

The pct object will store the identifier, a copy of the channel object and of
the cdr in its life time, it will if necessary stop the cdr to be posted.

There is only one pct object for both channel legs, so if there is already a
pct object form the other end channel, the identfier is only attached to the
existing object, and the additional cdr and channel object is copied as well
to the pct object.

The pct object receives later ast_pc_frames, which contain the post-call
information from the involved technology. These frames contain the identifier
so that they can be correlated with one of the active pct objects. The event
will be transmitted to the post-call processors, which then will decide what
to do with the available information.

The decission of what to do with the pc-information can be configured. If the
pc-information is an AOC facility for example, the pct will add the aoc info
to the cdr and post it now finally. It could also transmit the ast_pc_frame to
the other channel end, if the other channel end has got a pc-identifier as
well.

If no pc-event arrived the pct object will call the timeout-processors, which
could post the cdr for example finally after the configured timeout.

The post-call and timeout processors can be registered/unregistered to the
pct, like the cdr processors do in the cdr engine. This will ensure the
maximum flexibility for this architecture.



* Example Life Cycle of a pct object
------------------------------------


tech1 <--> ANSWERED <---> tech2

HANGUP --> tech1 
tech1 --> create_or_attach identifier to PCT_1 
tech1 --> finish hangup

cdr1 from tech1 will be delayed, because of the PCT_1 object

HANGUP --> tech2
tech1 --> create_or_attach identifier to PCT_1 
tech2 --> finish hangup

cdr2 from tech2 will not be delayed


AOC Event --> tech1 
tech1 --> ast_pc_frame (aoc) --> PCT_1 
PCT_1 --> post cdr1
PCT_1 --> post cdr2
PCT_1 --> ast_pc_frame (aoc) --> tech2 

tech2 --> AOC Event 

Destroy --> PCT_1


* configfile idea
-----------------

The configfile of the pct could look like, 

pct.conf:

[AOCE]			  ; event name

channels=> zap,sip,misdn  ; channel types which may send this event

timeout=>2000		  ; milliseconds, till the timeout processor 
			  ; will be activated 

transfer=> yes		  ; transfer the event to the other channel end if 
			  ; possible

processor=> delay_cdr		; which processor should be started 
				; when this event happens
timeout_processor => post_cdr	; which timeout processor should be 
				; started when the timeout happens before the
				; event arrives

Another idea would be to handle post-call events in a dialplan like
way. *Needs to be filled*.


* Summary
---------

The pct architecture could be a base for post-call events, which may happen in
different channel technologies.

The main point is the pct object. Its lifetime starts with the hangup. It will
delay certain post-call asterisk routines, like the posting of the cdr. It
will wait for post-call events and supply them to the post-call
processors. The post-call processors would finally start the post-call
asterisk routines again.