On Fri, Sep 12, 2008 at 2:15 PM, M. Ranganathan <[EMAIL PROTECTED]> wrote: > 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 >
Here is some evidence ( vendor "documentation" ) that I hope will suffice : Attached is a section of the AT&T questionnaire. Many thanks to Robert Joly for pointing me at this questionnaire which I had forgotten about (although I had filled one out). The customer SIP IP PBX must send its signaling address in the From line using the format shown below. Is this acceptable? If no please explain in the comments section below. From: "<display info>" sip:<calling number>@<IP PBX signaling IP address>:5060> Where: <display info> contains the calling party name. This field is optional. <calling number> contains the E.164 number of the calling phone. This field is optional for the IP Long Distance service. It is REQUIRED for the IP Local service. For the IP Local service, this field must contain one of the TNs (telephone numbers) provisioned within the IP Local service. <IP PBX signaling IP address> is the IP address of the IP PBX signaling endpoint. This address must be provisioned into AT&T BVOIP network. This must be an IP address and CANNOT be a domain name. A sample From is shown next. About anonymous calling : Will the vendor SIP device signal presentation-restricted status of the CPN as follows per RFC 3325: • Set the calling number to "Anonymous" in the From line. • Set the Privacy header to "id". • Send the calling number in the P-Preferred-Identity or P-Asserted-Identity lines. From: "Anonymous" <sip:restricted@<IP PBX signaling address>;tag=9802748 Privacy: id P-Preferred-Identity:"Unavailable" <sip:<calling number>@<IP PBX signaling IP address>:5060 P-Asserted-Identity may be used in place of P-Preferred-Identity. The AT&T network will remove the Privacy and P-Preferred-Identity headers before delivering the message to the called party. -- 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
