On Thu, 2009-06-25 at 13:51 -0400, Raymond Dans wrote: > 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.
This might run into problems when the call is being forwarded on the authority of the original destination, as X-sipX-Authidentity may not identify the origin of the call. You might want to log the From header (which is supposed to identify the origin). You might want to log both of these bits of information, since the user may really want to know "this call came from an outside number but was forwarded to a long-distance call on the authority of extension XXX". > 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". This seems advantageous, since we can use the header parameter mechanism in the 302's Contacts to cause the proxy to perform these actions. I'm not sure we need the whole routing history (given the ultimate requirements), but it seems wiser to capture that info in the header and then have the CDR processor simplify it as appropriate. Dale _______________________________________________ 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/
