> 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".
Correct. Currently we do not add PAI if the request has sipX-authidentity but we could (carefully) change this so that we always try to do PAI if the request appears to come from a valid local user. This way, we could solely rely upon PAI and leave sipX-authidentity out of this. > > > 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/ > _______________________________________________ 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/
