From: [email protected] [mailto:[email protected]] On Behalf Of Tony Graziano Sent: Saturday, December 12, 2009 10:20 AM To: Scott Lawrence Cc: sipX-dev Subject: Re: [sipX-dev] SIP trunk gateway selection by sipXbridge 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. Tony, In your scenario - if the ITSP will give you an different IP address for each Account, then you can do this with the current SipXbridge. Being that each is on it own terminating IP, they look like different accounts. Then you set each account's phones into a common group and assign them their own account in the dial plan. Their calls will only go out on their trunks. ON the incoming side, their alias will allow them to deliver calls to the correct users as well. And, as I have discovered, using the Voice Operator Panel software, you can display the incoming caller id, and the number the party was calling. You can facilitate displaying the correct business name with their directory structure, so one attendant can answer all calls, giving the correct party called information. This is somewhat off topic, but also defends some of the features of SipXbridge and its ability to handle multiple tenants on the same switch. Ya' did good Ranga! _______________________________________________ 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/
