On Sat, 2009-12-12 at 11:15 -0500, M. Ranganathan wrote:
>
> > Multiple providers I understand... multiple accounts with the same
> > provider that cannot be distinguished by either target domain part
> or by
> > caller address is what I'm having trouble with.
>
>
> The problem is that when sipXbridge sees the request, it may not have
> enough information to disambiguate between accounts. \
I didn't make myself clear... I understand _how_ to set up a situation
that creates this problem. What I don't understand well is _why_ those
configurations are needed.
Todd offers this case:
> System installed for one company that sublets some of their empty office
> space, however, the sublets need trunks for their own set of billing
> requirements. One way to handle is separate domain names if the ITSP
> supports this, but if they don't, then you need a method of identifying
> calls from one group of users to use one specific group of trunks for
> billing purposes.
... which bleeds over a bit into the multi-tenant solution space, which
is not something we've tried to address (and for which we have _many_
other shortcomings).
In the post that started this thread, Mark Gertsvolf says:
> sipXecs dial plan logic is implemented in sipXproxy. sipXbridge
> maintains ITSP accounts (SIP trunk gateways) and it is in charge of the
> ITSP account selection when handling outgoing calls.
> Even though sipXproxy dial plan logic knows the ITSP account (SIP trunk
> gateway) chosen for a particular call it does not tell sipXbridge
> explicitly what the account is. Instead it sets the domain name in R-URI
> and also sets the CallerID ("from" header) before sending the request to
> sipXbridge.
Well, it only sets the From header if a caller alias has been
configured, and then (as you noted below) only for local users.
> In order to find the right ITSP account sipXbridge looks at the target
> domain in R-URI and finds the ITSP account with matching domain. If
> there are multiple ITSP accounts with the same domain the "from" header
> is used for disambiguation.
>
> This mechanism to signal the choice of ITSP account from sipXproxy to
> sipXbidge is not sufficiently reliable. It breaks when multiple accounts
> exist with the same target domain name and when an external caller is
> making a call, which is routed to sipXbridge. In case where the caller
> is external sipXproxy CallerAlias plugin refuses to manipulate the
> CallerID and the disambiguation of the ITSP accounts does not work.
I still don't understand what problem the configuration you describe in
the issue is for, Mark - why have 3 accounts when you can only make
outgoing calls on one of them?
We could, I suppose, create an explicit ITSP account identifier and pass
it to the sipXbridge in the request (I think a url parameter would be
the mechanism of choice), but I'd like to understand the reasoning
better to make sure that we're not trying to provide a mechanism to work
around a work around for some other problem.
On the related implied question:
> It is not totally clear to me why CallerAlias does not manipulate
> CallerID for external callers,
The reasoning is pretty simple - we are trying to make the caller id as
much as possible reflect who will be on the other end of the phone if
the callee answers it. If I have my office phone forwarded to my cell,
or if someone in the office blind transfers an outside call to me, then
the caller id presented on my cell phone will be that of the party I'll
be speaking to if I accept the call (at least to the extent that the
caller id they provided when they called my office was honest, but
there's nothing much we can do about that problem). If the system
replaced that From header with that of some number for the office, then
I get misleading caller-id: it's not my office calling, and I won't be
talking to my office if I answer.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
