On Fri, 2008-09-12 at 11:25 -0400, M. Ranganathan wrote: > 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]
Please back up and address each of the 4 scenarios. It is not true that all calls to an ITSP should be anonymous, nor is it true that ITSPs can never handle the real user id (if, for example, the real user id _is_ the DID that the ITSP sends an inbound call to). For those cases where the real-caller-address is not what we want and there is no desire to make an anonymous call, how do the existing behaviors as described in those scenarios differ from what you think you (and more importantly, the ITSPs, need). Can you point to documentation from ITSPs as to the expected behavior? _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
