Let me propose the following resolution: a) We agree that we need source routing based on location for multi-branch deployments
b) We agree that the main mechanism will be based on auto-detecting the current location on a per call basis c) We agree that sipXconfig will allow the specification of a location for users and gateways and that this mechanism will be used if auto-detection is not possible d) We agree that this source routing mechanism is done per dialing rule, so that least cost routing for e.g. international calls still works based on called destination e) We agree that it would be a nice to have feature to be able to manually control source routing on a per call basis using a DTMF feature code. Main use case is for debugging. The feature is turned off by default and only implemented if time permits. f) We agree that this source routing mechanism can be turn on or off per dialing rule. g) For remote workers who are not currently in a known location ordinary destination based dialing rules apply. h) Trunk failover still works so that if the preferred gateway is not available or busy the call is routed through the next available gateway on the list. This could be another gateway in the preferred location or some other gateway avafilable anywhere. At some point we will need some reports so that the admin can actually see how calls get routed in actuality. This will become critically important for system debugging, capacity planning and troubleshooting. --martin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lawrence, Scott (BL60:9D30) Sent: Friday, October 17, 2008 11:08 AM To: Joly, Robert (CAR:9D30) Cc: [EMAIL PROTECTED] Subject: Re: [sipX-dev] User-based gateway selection feature proposal(XECS-415) On Fri, 2008-10-17 at 09:54 -0400, Robert Joly wrote: > > Robert Joly wrote: > > My personal experience differs. If you take DISA (Direct Inward System > Access) for example, it is common for companies to hand out the DISA > information to their employees. If fact, I probably still have my > Nortel DISA calling card in my wallet. Having said that, I do not think > that this is an absolute must-have feature but it is easy enough to > implement while the hood is open. I will only add this incremental > feature if I have left-over time in this sprint - the marketing folks > can decide if they want to expose it or not. The fact that an engineer who works for one of the largest phone-equipment suppliers in the world and develops complex phone system equipment does not find user-controlled phone call routing to be complex or difficult doesn't impress me much. Least-cost routing is one problem, and we should have good solutions for it. Good solutions are ones that users do not have to be trained to use - they just Do The Right Thing. Gateway preferences for multi-site installations is a slightly different problem, and we need a solution for it. User-controlled call routing is just a problem - let's not introduce it. The fact that traditional PBXs often have it (with dial-9-for-an-outside-line and the like) is really an artifact of how those systems had to be built, not a user-driven requirement. A phone number is an Address - we should treat Addresses the way the Internet does - the Address specifies the destination, the Network controls how you get there. This puts routing control in the hands of administrators and simplifies things for users. I'm not so much worried that you can't figure out a way to implement this, Robert (I know you are easily clever enough to do it) - my concern is that we are making installation, support, and debugging of a system more complicated. In this case, we are adding a new routing mechanism that No One Asked For. That's not a good thing. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
