I might add I can specify this via an FXO gateway and POTS lines, just not with sipXbridge and ITSP's.
On Sat, Dec 12, 2009 at 12:56 PM, Tony Graziano < [email protected]> wrote: > I'll offer this: > > A customer has 6 entities, one sipx system. Each entity is required to have > independent phone lines (in Virginia, this is required of real estate > insurance providers, to meet the Virginia Real Estate Settlement Practices > Act, RESPA). It's not tenanting, same people, desks, physical address, they > simply know how to answer the phone based on the line called, all easily > done with DID. They are required to have separate billing. In the financial > world there's a lot of movement towards that for transparency, where we have > to thank the current economic climate for making this necessary. It also > means they have to have CNAM for each entity on outbound calls and not > misproperly send the wrong ID for another entity. > > > > > On Sat, Dec 12, 2009 at 12:40 PM, Scott Lawrence < > [email protected]> wrote: > >> 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/ >> >
_______________________________________________ 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/
