I've been working on XX-4741 (CDR subsystem should allow the
identification of call type in reports) and after some healthy
discussions with our resident SipXecs Proxy expert (we'll call him Bob),
I believe I have a proposed solution that I'd like to get your feeback
on.
(Apologies in advance for the length of this).
Problem:
=======
CDR records today contain a fair bit of information about the calls
that have occurred on the system, however, there isn't enough to
determine the call type. Call Type in this context can be described as:
1) Inbound
- to a normal extension
- call to an ACD queue
- call to a Hunt Group
- call to an Auto-Attendant
- .....
2) Outbound
- Local call
- Long Distance call
- International call
- .....
3) Internal
- Call from one extension to another
A call type in a CDR record provides the ability of either an
external third party or our own SipXecs CDR reporting mechanism to
generate more accurate call cost accounting, detect fraudulent use,
statistical analysis of the use of the system (i.e. ACD, Hunt Group,
....) as well as others I haven't thought of.
Proposal:
========
Solving the problem of providing call type or information to
determine a call type in a CDR record can be quite complex given the
configurability of the components of SipXecs. Suggestions were made to
add a new table in the CDR database that contained dial plan information
or a method of obtaining the dial plan when CDR records are being
generated. Each of these methods would end up being quite complex and
prone to errors.
The proposed solution that I would like to implement involves the
generation of 2 new pieces of data (to be added to the Call State Events
- CSEs generated in the Proxy).
The 1st piece of data would be the identification of the source of
the call as either an internal or external location. With this, a call
could be potentially tagged as "Inbound" or "Tandem" if it came from an
external location or as "Outbound" or "Internal" if it came from an
extension on the system. Generating the appropriate tag in the CSE for
the source could be done based on the absence or existence of the
P-Asserted-Identity or X-SipX-Authidentity header in the INVITE.
The 2nd piece of data would be the "identification or history trail"
of the destination of the call. The history trail for the destination
(added by the redirect plugins) would be generated by adding appropriate
tags (ie. ACD-Qx, HGx, AA, .., LocalCall, LongDistanceCall,
InternationalCall - actual definitions to be defined at a later time)
to each Contact placed in a "302 Moved Temporarily" by the redirect
plugins. Tag values added would be based on information obtained from
the config files that govern their redirection logic and/or the
redirection policy they implement. These tags would later be attached
to the Record-Route by the Proxy Auth plugin in order to (in a multiple
fork scenario) be able to determine where the call eventually ended up
(being answered).
The nice thing about generating these tags in the Redirect Server
plugins is that it would take into account various routing decisions
that are made based on Call Forwarding, Time-Of-Day, .... rules.
Interpretation of the destination tags associated with a call could
appear a bit odd but it should accurately represent how the call was
routed. For example, if we have an incoming call to ACD Queue 1 that is
to be routed to an internal destination but that destination has a call
forwarding rule that specifies a Long Distance location, the tags would
be something like "ACD-Q1, LongDistanceCall".
The combination of the two pieces of data would provide a CDR record
post-processor with all of the necessary information to determine call
type (Inbound, Tandem, Outbound, Internal) as well as other information
related to number of ACD, HG, AA, ... Calls.
Thoughts or Comments on the viability of the solution and whether or
not it would satisfy requirements?
Thanks
Raymond
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
