> From: Steinmann, Martin (BL60:2500) > > 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
The automatic detection is done for users only. Gateways belong to the location(s) that they have been configured with. Given that gateways typically do not move around, that should be acceptable and keeps the gateway election process more understanbable. > 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 To the extent that we can disable source routing on a per-dialplan rule - see f). > > 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. The way the current proposal reads, ifsource-based routing is enabled for the dialplan rule, the call will be routed to the subset of gateways that belong to the 'default' location. I think that this is the best way to retain some control over the gateway selection for non-locatable users. Consider this example. Site A has 3 users and a single-line gateway while site B has 20 users and a 20 lines gateway. Even though a given dialplan rule to be source-routed may include both gateways, due to its limited capacity, an admin may want to exclude the single-line gateway from the list of gateways used by the non-locatable user exercising the dialplan rule. This can be achieved by setting the location of gateway A to "siteA" and setting gateway B's location to "SiteB" + "default". Note that every gateway whose location information has not explicitly been set by the administrator is considered to be part of the 'default' location. Also, a gateway can belong to more than one location, e.g. "Ottawa + default". > > 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. Same comment as above. If the prefered gateways are not available, the 'default' one(s) will be used. > > 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
