On Thu, 2009-06-25 at 13:51 -0400, Raymond Dans wrote: > 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?
Why annotate the message at all? The caller is easy enough to determine based on the From header in the first request record. Why not have the redirectors write new record types into the CSE table that indicate the source of the redirection and the contact added based on it? The record could including the dialog identifier, the redirector name, a label for the source of the data (the semantics of which would vary by redirector - could be the key that was looked up to find the new contact, or the database, or the mapping rule identifier), and the new Contact value. The resolver can then use the Contact from the final setup to figure out which rule triggered the change. No need to add to message sizes or monkey with Contact values on the wire (which sometimes causes interop problems). _______________________________________________ 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/
