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/ > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 Fax: 434.984.8431 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ Why do mathematicians always confuse Halloween and Christmas? Because 31 Oct = 25 Dec.
_______________________________________________ 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/
