On Fri, Sep 12, 2008 at 3:18 PM, Scott Lawrence <[EMAIL PROTECTED]> wrote:
> > Would it also work to just strip the P-Asserted-Identity header in this > case? That is, if From and PAI do not match, then remove the PAI header > altogether? It would work except for the case of From: [EMAIL PROTECTED] > If what we want is a call in which there will be no Caller Id sent to > the PSTN, why do we need any id at all in any header? Actually, we typically want From: [EMAIL PROTECTED] There are a few ITSPs that do not look at the From header ( in which case we dont care). > >> >> From: [EMAIL PROTECTED] >> >> P-Asserted-Identity: [EMAIL PROTECTED] > > Would the call be accepted by these ITSPs if the PAI were missing from > the above? That is if the only caller identity were: > > From: sip:[EMAIL PROTECTED] It would not be accepted. For reference, see attached AT&T questionnaire excerpt in my previous mail. > > > As I said above, the Caller Alias feature in the proxy can set the From > header to be _any_ address - it does not care at all what domain or user > it has in it. I stand corrected. If I simply copied From: into P-A-I in the case of non-Anonymous calls, the current mechanism in place would suffice. > >> I do not have documentation. The behavior is ITSP specific and >> documentation is not provided to me. > > Sorry, I don't accept that (no criticism of you at all intended, Ranga - > I know you're just stuck in the middle here). I did find something, thanks to Robert. I had quite forgotten it existed. See previous mail on this thread. It is just not acceptable > to base product design decisions on trying to "copy" what one sees in a > call trace. I know it may be difficult to get documentation, but that > documentation _does_ exist somewhere and I suspect that with our new > backing from Nortel that we can get it eventually. I'm (nominally) > taking a day off today, so I don't want to start now, but if you would > prepare a summary of which ITSPs we're talking about for me off-list, > I'll get started on tracking that down on Monday. AT&T -- and the documentation has been excerpted and attached previously. The behavior is also empirically verifiable in practice :-) > > It's not completely clear to me that we have a product requirement that > we be able to support making an "anonymous" call (anyone want to weigh > in on that?). In the real world there is no such thing, but what is the > usual interface from a PBX to the PSTN in that regard (and how would one > control when it is used from a phone)? Apparently some (at least one) do mandate support for such an anonymous calling mechanism based upon their test plan. > > The only one of the 4 cases I outlined above that we don't have an easy > way to deal with now is that last case of an anonymous call. And that is the only one which currently concerns me too as the current mechanism does not suffice (which is why I answered to only one of your 4 cases previously). Thanks for taking the time and effort to analyze things so thoroughly. 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
