On Fri, Sep 12, 2008 at 12:37 PM, Scott Lawrence <[EMAIL PROTECTED]> wrote: > > 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: >> > 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]
This cannot be forwarded by sipxbridge. If I understand correctly, the domain above is referring to the sipx domain. From:[EMAIL PROTECTED] makes no sense to the ITSP. It would want to see : From:[EMAIL PROTECTED] (examples of failing calls can be posted if you wish). >> > >> > 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] I cannot forward this request because From:[EMAIL PROTECTED] where domain is the sipx domain would not make sense to the ITSP. Also P-Asserted-Identity: [EMAIL PROTECTED] Makes no sense to the ITSP ( assuming user is the sipx user and domain is the sipx domain ). AT&T call trace can be generated to verify if necessary. >> > >> > 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. Addressed in line above. > > It is not true that all calls to an ITSP should be anonymous, nor is it Agree. I don't think I made such a claim. If I did make such a claim it is incorrect. > 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). True but what would the request look like if it came from a phone/user that is NOT mapped to that DID? 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). I think I have answered above. If more clarification is needed, please let me know. > > Can you point to documentation from ITSPs as to the expected behavior? I can post call flows that I have run. I do not have documentation. The behavior is ITSP specific and documentation is not provided to me. Thank you Ranga > > > -- 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
