On Thu, 2008-09-18 at 12:00 -0400, Scott Lawrence wrote: > We've had a number of issues lately related to how the address values in > To, From, and P-Asserted-Identity should be manipulated by various > components. > > I think that we should take a step back and revisit our requirements for > this. The initial data I'd like to collect are: > > 1. What manipulations are performed now (on main) by each > component, and how those manipulations are configured and > triggered.
I've attached the documentation of the sipXproxy CallerAlias plugin (which I discovered this morning that I'd never properly written). That describes the mechanics of what the plugin does... The end-user visible goal when we created that plugin was to override the PSTN caller-id, but also to allow SIP calls to present different caller ids to different domains (bear in mind that different gateways are, in SIP terms, different domains). The From header was assumed to be the source of any caller-id in either case. So in the office I could use the address: From: "Scott Lawrence" <sip:[EMAIL PROTECTED]> and have that translated for an external call through a T1 gateway to one provider as: From: "Scott Lawrence" <sip:[EMAIL PROTECTED]> and also have it change to a number in a different form when going through a different gateway to another provider: From: "Scott Lawrence" <sip:[EMAIL PROTECTED]> Since the CallerAlias AuthPlugin was added, we have also added the P-Asserted-Identity support: If an unauthenticated request is received with a From header whose identity matches an identity in our domain, it is challenged (407) for authentication. When (if) it is authenticated, the proxy adds a P-Asserted-Identity header containing the authenticated identity. As things stand today, this is not changed by any other sipXecs component. Ranga - could you please summarize any changes that the sipXbridge can currently do to the To, From, and PAI headers and how they are configured? Then we can go on to: > 2. What manipulations may be needed that are not now possible. > > The above items need to be explained in the context of a user scenario: > what end-user effect is desired, and what are the deployment environment > constraints (including restrictions imposed ITSPs and including the > identities of those ITSPs). > > The goals are to work out: > > A. How to configure the required behavior for each user scenario. > B. What changes are needed before the end of the 4.0 development > cycle. > > The ideal we are striving for is that for any given behavior, there is > exactly one way to configure it. This may be counter-intuitive, but I > think it's important: we want it to be true that systems are set up as > uniformly as possible because it limits what we need to test and what a > service person needs to look at to diagnose a problem. This ideal may > or may not be achievable, but the only way we'll figure that out is to > get all the requirements scenarios together at once and match them up > with the capabilities we have and see what we've got. >
Documentation of the CallerAlias AuthPlugin (in sipXproxy): This AuthPlugin provides a caller aliasing feature by modifying the From header in an initial request and maintaining the translation throughout the dialog. It is intended to provide a way to modify the caller-id presented in a PSTN call. The translation is controlled by entries in the caller-alias sipdb, which has two key columns: the caller identity and the target domain; and one output column: the From header field value. On an initial request, the first test is for an exact match of the identity ([EMAIL PROTECTED], with no parameters) in the From header of the request and the target domain (from the request URI). Note that the target domain for a PSTN call is the domain of some gateway, which could be a local device or a remote SIP Trunk service. The lookup is _not_ affected by any Route on the request, so a request to an ITSP that is Routed through a local SBC matches on the ITSP domain, not that of the SBC. If an exact match is found, then the resulting From header from the output column is substituted. This is used to replace the identity of a specific user when calling a specific domain. If no exact match is found, and if the existing From header identity is a user in the domain of this proxy, then a second check is made in the caller-alias database for a "wildcard" match: the caller identity used for this lookup is "*", and the target domain from the request URI (as in the exact match test). If this matches a row in the caller-alias database, the From value from that row is substituted. Note the exclusion: this wildcard match is not attempted if the caller is not within the domain, so a call coming from outside the domain that is forwarded by a local user is not aliased (the original outside caller-id is maintained). If neither match finds a row in the caller-alias database, the From header is left unchanged. When a From header value is substituted, the entire value from the table is used, and the only part of the original From header value that is preserved is the 'tag' field parameter. Both the full original From header value and the aliased From header value are added to the RouteState for the request. This causes these values to be preserved in the route set. As subsequent requests and responses follow the route set through this proxy, this plugin modifies the From header using these saved values so that each participant in the dialog sees only the From header value they expect to see (the caller sees only the original value, and the called party sees only the aliased value).
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
