Scott Lawrence wrote: >Subject: Re: [sipX-dev] Call Type in CDR Records - XX-4741 > >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. > The From header can be different(possibly forged) from the actual originator. I just thought it would be simpler to just check for the existence of the P-Asserted-Identity since we always challenge internal addresses and the existence of this header would indicate it was a verified internal user. >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. > The thing I don't like about the redirectors writing a new record to the CSE, is that each one of them would then have to open the Database and write the (new) record. The number of CSE records generated in the database would then increase by quite a bit which would then require a lot more processing required in CDR. In addition, since we haven't yet establed a dialog (i.e. no To tag yet), I'm not sure how this dialog identifier would be unique and allow us to properly tag it to the destination which answered. The current method of writing CSE's is nicer since it occurs in the Proxy only (CSE Observer) and is easier to manage. >No need to add to message sizes or monkey with Contact values >on the wire (which sometimes causes interop problems). > The Contact values shouldn't be an issue since the call tags would be removed from it and placed in the Record-Route by the Proxy Auth plugin before the INVITE went out. In this manner, we would then receive them in the 200 OK which would come from the destination which answered. _______________________________________________ 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/
