On Fri, 2008-09-12 at 14:15 -0400, M. Ranganathan 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.
Correct.
> 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).
see next item...
> >> > 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.
Perhaps my example was poorly constructed. There is no requirement (in
the caller-alias authplugin, at least) that the caller-alias-address be
within the domain of the sipXecs. It could just as easily be an address
in the ITSPs domain, as you say they want.
The P-Asserted-Identity as it will arrive at the sipXbridge will always
be in the sipXecs domain, but if the ITSP wants them to be the same,
there is no reason why sipXbridge could not copy the From address into
the P-Asserted-Identity header so that they matched exactly. This could
be just a boolean switch and would not require any configuration of any
addresses in sipXbridge (see comment regarding motivations at the bottom
of this note).
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?
> >> > 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 :
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?
> >> 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 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?
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.
> 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?
>
>
> 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.
Sorry, I don't accept that (no criticism of you at all intended, Ranga -
I know you're just stuck in the middle here). 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.
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)?
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.
Full disclosure: I am trying mightily to avoid having any changes to
>From headers made anywhere _except_ the sipXproxy. The reasons for this
are simple:
1. Debugging what happens to a SIP call that goes wrong is HARD.
If there is just one place where header or request URI addresses
are ever changed, that is a very good thing from the point of
view of understanding and diagnosing problems (admittedly this
goal may not be completely achievable, but any reduction in the
potential complexity is a big gain). Servicability is of
paramount importance.
2. In developing the Caller Alias feature (twice!) we found that
many phone and gateway implementations were very poor in this
regard - changes to headers that the standard clearly allows
caused calls to fail. I'm a bit gun-shy about this now.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
