On Fri, Sep 12, 2008 at 9:03 AM, Scott Lawrence <[EMAIL PROTECTED]> wrote: > > On Thu, 2008-09-11 at 18:05 -0400, M. Ranganathan wrote: > >> 1. Gateway specifies a caller ID and an outbound call is routed >> through the gateway. In this case, I expect that the proxy will place >> a P-Asserted-Identity with the caller-Id as the address for the PAI as >> well as a From header with the same information in it. That is, I >> expect to see >> >> From: caller-id >> P-Asserted-Identity: caller-id >> >> It would also be acceptable to just leave out the PAI header in this case. > > >> 2. Gateway specifies anonymous calling and user makes a call routed >> through the gateway. In this when the user places a trunk call through >> the gateway, I want to see the following headers in the INVITE >> received by sipxbridge >> >> From: [EMAIL PROTECTED] >> P-Asserted-Identity: caller-Id > > > I'd like to suggest some terminology for the purposes of this > discussion, so that we are all sure that we are not agreeing > without realizing it: > > real-caller-address > The actual AOR as configured by sipXconfig for the user > ([EMAIL PROTECTED]). This is what normally appears in a From header > when a request is sent from a phone. > > caller-alias-address > This is what is configured, either for a specific user or for > a wildcard match, when a call is to be routed to a particular > gateway. It is placed in the From header by the sipXproxy as > the request is being sent to the gateway (and the original > From header value is placed in the Route state information so > that it can be restored in messages bound for the original > caller). > > Note that neither of the above is 'caller-Id', so using the term > 'caller-Id' is now out of bounds. > > Note also that sipXecs does not now have a feature that allows > for an 'anonymous' call other than if you configure the address > '[EMAIL PROTECTED]' (the standard for an 'anonymous' call in SIP) > as a caller-alias-address. > > Phones may or may not ever put '[EMAIL PROTECTED]' in the From > address, but at present if they do, the proxy will neither > challenge the call to get a real identity for PAI nor do any > caller-alias substitution of the caller address no matter where > it is sent. > > Given the above, I can think of 4 cases. For theses examples, > treat '[EMAIL PROTECTED]' as a real-caller-address and '[EMAIL PROTECTED]' > as a caller-alias-address: > > 1. Normal Call with No Alias > > Phone sends '[EMAIL PROTECTED]' in From, proxy challenges and adds > '[EMAIL PROTECTED]' in PAI. sipXbridge sees: > > From: [EMAIL PROTECTED] > P-Asserted-Identity: [EMAIL PROTECTED] > > 2. Normal Call with Normal Alias > > Phone sends '[EMAIL PROTECTED]' in From, proxy challenges and adds > '[EMAIL PROTECTED]' in PAI, then proxy replaces From with > '[EMAIL PROTECTED]', so sipXbridge sees: > > From: [EMAIL PROTECTED] > P-Asserted-Identity: [EMAIL PROTECTED] > > 3. Normal Call with "anonymous" Alias > > Phone sends '[EMAIL PROTECTED]' in From, proxy challenges and adds > '[EMAIL PROTECTED]' in PAI, then replaces From with > '[EMAIL PROTECTED]' (same as above, but the with the special > "anonymous" address), so sipXbridge sees: > > From: [EMAIL PROTECTED] > P-Asserted-Identity: [EMAIL PROTECTED]
This is a problem. The problem is that [EMAIL PROTECTED] is not relevant to the ITSP. It is a user that is only relevant to sipx. Not to the ITSP. Let [EMAIL PROTECTED] be the actual "caller ID" for which we want an anonymous alias. What I want to see is : From: [EMAIL PROTECTED] P-Asserted-Identity: [EMAIL PROTECTED] Note that I will not have any record of the actual PBX user when I see a request like this. Therefore, if you prefer, I can handle this case in Sipxbridge as I currently do. Which is to say, I will add the P-Asserted-Identity in sipxbridge when I see From:[EMAIL PROTECTED] if that makes life less complicated for the proxy server. > > 4. Anonymous Call from the phone: > > Phone sends '[EMAIL PROTECTED]' in From, proxy will _not_ > challenge, and will _not_ add PAI, so sipXbridge sees: > > From: [EMAIL PROTECTED] > > So the questions are: > > Which of the above cases do you believe is a problem? > > Is there some capability that we need? Not sure. If this effect can be achieved at present through a configuration option, we add nothing. I know the effect I want to see. I am still learning how to configure sipx. > > Incidentally, in putting this together, one other issues suggests > itself with respect to the existing caller alias feature. At > present, the caller alias feature only substitutes when the From > address is in the domain of the proxy; any foriegn address is > left unmodified. > > A. In the existing implementation, there is already a note that > we should use an authenticated identity to decide whether or > not to do the substitution if we have one. Now we do for > cases 1, 2, and 3 above, so we could change that. This > would not change any of this discussion yet, but would be > more robust and secure than the current behavior. > > > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
