On Mon, Sep 29, 2008 at 5:06 PM, Scott Lawrence <[EMAIL PROTECTED]> wrote: > > 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? Please see attached spread sheet. Please let me know if it is clear enough.
Thanks Ranga 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. >> > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > -- M. Ranganathan
from-header-manupulations.ods
Description: application/vnd.oasis.opendocument.spreadsheet
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
