A few comments to make sure I understand this right; a) Location based call routing is specific to a rule in the dialplan. This is important so that for exampele location based routing is done for all local and long distance (domestic) calls, but calls following a rule for international calls would be least cost routed, not taking the callers location into account.
b) I like the ability to auto-detect a user's location on a per call basis. This would make config easier as long as the algorithm used to make this selection is simple enough for an admin to easily understand it intuitively. I still think that the concept of a user's location should be a property that is configurable in sipXconfig on a per user or per user group level. c) I also like the ability to dial a feature code and location prefix. Is there a reason why this has to be three digits? This capability is not a requirement for this realease, but a nice to have that could enable other use cases. --martin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lawrence, Scott (BL60:9D30) Sent: Thursday, October 16, 2008 11:49 AM To: Joly, Robert (CAR:9D30) Cc: [email protected] Subject: Re: [sipX-dev] User-based gateway selection feature proposal (XECS-415) On Thu, 2008-10-16 at 10:01 -0400, Robert Joly wrote: > Hi, > The purpose of this e-mail is to formally propose a set of modifications > that would make it possible for an administrator to customize the > routing of calls to gateways based on the location of originating user. > That proposal addresses XECS-415 and some of its elements are based on, > or extends prior work by Dave Saint and Andrei Cristian Niculae. > > Problem Statement > ================= > > In VoIP deployments that have a number of PSTN gateways deployed, > sipXecs relies on dialplan digit matching to determine the list of > gateways will be used to route the call. In many scenarios, it would be > desirable to also consider the 'location' of the call originator when > selecting the gateways that will route the call. Here are some examples > where such a feature would be beneficial. > > Example #1: > - Multi-branch enterprise > - sipXecs at the main branch > - PSTN gateway in each branch > - An emergency call is made > Desired behavior: When a user in a branch is making an emergency call, > that call should be routed to the gateway that is local to that branch. > > Example #2: > - Multi-branch enterprise > - sipXecs at the main branch > - PSTN gateway in each branch > - Branch 'X' has very limited WAN bandwidth > Desired behavior: When a user in a branch 'X' is making a PSTN call, > that call should be routed to the gateway that is local to that branch > to preserve WAN bandwidth. PSTN calls made from users in other branches > can be routed to any available gateway excluding the one at branch 'X'. > > Example #3: > - Single-site enterprise > - enterprise has multiple departments > - each department has a dedicated gateway > - each department has a budget allocated for long distance calls. > Desired behavior: For administrative purposes, a long distance call > should be routed to the user's departmental gateway. > > Proposal > ======== > > The purpose of this section is to describe at a high-level the aspects > of a solution that would make the behaviors described above possible. > > ---Location concept---- > > The first element of the proposal is the introduction of the 'Location' > concept. This concept was already presented to the mailing list by > Andrei Cristian Niculae in thread > http://thread.gmane.org/gmane.comp.voip.sipx.devel/11931/focus=11969 and > is somewhat analogous to the existing 'User Groups' concept. In general > terms, a 'Location' is a logical entity used to associate elements that > share a common 'location' property. As an example, a 'Location' called > 'Ottawa' could be created to contain all the users and PSTN gateways > that are located in Ottawa for the purpose of creating a logical > association between them. Note that the term 'Location' does not > necessarily refer to a geographical location - looking at example #3 for > example, it could also be used to designate a department. > > For the purposes of this feature, a 'Location' would include the > following attributes: > - A name; > - An optional description; > - A list of 0 or more users associated with said location; > - An ordered list of 0 or more gateways associated with said location > with the highest priority gateway being at the top; > - An optional three-digit location code; > - Optional network topology information about the location (IP subnets). > > An administrator can create as many 'Locations' as it wants. > A user can be associated with at most one location but gateways can be > part of multiple locations for sharing purposes. > > ---Determining the location of a caller--- > > Within the sipXecs system, when a call is made, a series of evaluations > and look-ups are performed by the redirect server to determine the set > of contacts that the request will be redirected to. This proposal > proposes to enhance the redirect server to take into account the > 'location' of the user in its routing decision-making. The first task > of the enhanced redirect server is to determine the 'location' of the > requesting user. There are three tests used by the redirect server to > deduct the location of that user (shown in order of priority): > > #1 - Using three-digit location code: To accommodate roaming users or > users that want to appear as belonging to a 'location' that they are not > normally a part of for the duration of the call, 'locations' are can be > outfitted with an optional three-digit location code. By invoking a > location code as part of the dialed digits, a user can tell the redirect > server the location that it should use to make the routing decision. As > an example, dialing a digit string of the form <feature activation > code><location code><number to call> will tell the redirect server to > assume that the calling user belongs to the location designated by > <location code> when routing the call. The complete dial string could > look like this sip:[EMAIL PROTECTED] where "*70" is the > <feature activation code>, "123" is the <three-digit location code> and > "96135551212" is the number to route over a PSTN gateway. The redirect > server will look for a 'Location' that has a three-digit location code > of "123" and use that location's gateway list as candidates to route the > call. This location code mechanism seems to me to go way beyond what the original requirements called for. It adds quite a lot of complexity for little extra benefit. Personally, I dislike anything that requires that users be taught feature codes that explicitly control routing - and a feature code that controls routing through extra layers of indirection seems to me to be a nightmare waiting to happen. I'd suggest that this entire part of the proposal be removed. I will be amazed if any user notices its absence. > #2 - Using network topology information: if the call did not carry a > location code then the public IP address of the caller is compared > against the optional network topology information of each configured > location. If a match is found, the caller will be assumed to be part of > the matching location and will use the location's gateway list as > candidates to route the call. Here are two examples: > Example A- The devices in the R&D department are all part of the > 191.30.30.0/24 public network. A new Location "R&D Dept" is configured > on the system and the optional network topology is set to > 191.30.30.0/24. If a caller's public IP address is within the > 191.30.30.0-191.30.30.254 range then the caller will be assumed to be > located at the "R&D Dept" location. > Example B- The devices at the remote Ottawa branch are all in a private > network fronted by a NAT that has public IP address 100.0.0.1. A new > Location "Ottawa" is configured on the system and the optional network > topology is set to 100.0.0.1/32. If a caller's public IP address as > provided by the NAT traversal feature (and available for free) is > 100.0.0.1 then the caller will be assumed to be located at the "Ottawa" > location. Can you be more specific on the algorithm used to determine the IP address to be used in this comparison? Consider carefully the effect of multiple proxies - some of which are outside the sipXecs cluster. Are you going to search the Vias? Where in the list of Vias do you stop? I'm not convinced we need this part at all, but even if we do, I think we need to think hard about its priority relative to the location data associated with a User. This depends on whether or not you believe that the purpose of this location-sensitive routing is to: A. Always route calls to "local" gateways so as to reduce intra-site traffic. B. Route calls so that the caller-id information (which is associated with which gateway is used to PSTN) matches that desired for a given caller. I think that the answer is that for different kinds of calls, the answer is different. Two examples: * A is clearly more important if the call is an emergency call (your Example #1) * B is probably more important if you want the caller-id for a given sales person to always be their home number even when they happen to be visiting some site other than where they normally work. If the goal is A, and if we can derive a good set of rules for determining the "location" based on some address from the Vias, then I'm not sure that we need any User-based data at all, but certainly the IP data should take precedence as you've proposed. If the goal is B, then we probably don't need the IP-based mechanism to determine "location" at all, but may need to be able to indicate that some dial plans are exempt from location-based modification. Note that either strategy fails (routes calls to and/or changes caller-id for) if the most preferred gateway is not usable (all channels busy or crashed) and some remote gateway is also configured as a fallback. I'm not suggesting that remote gateways should not be configured as fallbacks because of this (my preference is always to provide as many ways as possible for a call to get to its destination), just pointing out that ultimately users will sometimes get results they don't expect, and it will often be difficult for them to understand why it happened. > #3 - Using Location's configured users list: if the call did not carry > a location code and the caller's IP address did not match any of the > locations' topologies, the redirect server will look for a signed > P-Asserted Identity header in the message. If one is found, the > redirect server will try to find a location that contains the user > identified by the header and use its gateway list as candidates to route > the call. > > Users that do not match any of the presented criteria are essentially > location-less and will, by default, fall into the 'Default' location > category. > ---The 'default' location--- > > By default, the sipXecs system will come pre-programmed with a default > location called 'default' and automatically includes all the gateways > that have not been explicitly associated with any location by the > administrator as well as gateways whose location has explicitly been > configured to 'default' by the administrator. This location can be > viewed as the default location for all the users that could not be > mapped to a specific location by either one of the three tests presented > in the section above. When a user falls in the 'default' location, that > location's gateway list is used as candidates to route the call. > > ---Deciding which gateways to use to route the calls--- > > So far, we have seen the machinery used to generate a list of gateways > that are _potential candidates_ to route the call based on the caller's > location. That list of candidate gateways needs to be intersected with > the list of gateways configured on the exercised dialplan to generate > the final list of gateways that the request will be redirected to. This > section details that intersection logic: > > Let A be a user making a call that will be routed using a PSTN gateway; > Let Loc(A) be the location that A belongs to; > Let DP(call) be the dialplan used to route the call; > Let GW(Loc(A)) be the ordered list of gateways belonging to loc(A); > Let GW(default) be the ordered list of gateways belonging to the > 'default' location; > Let GW(DP(call)) be the ordered list of gateways configured for > DP(call). > > The list of gateways that the call will ultimately be redirected to is > given by: > ( GW(Loc(A)) LOGICAL_AND GW(DP(call)) ) LOGICAL_OR ( GW(default) > LOGICAL_AND GW(DP(call)) ) > > To state it in words, the list of gateways that the call will be > redirected to will consist of all the gateways associated with the > user's location that are also found in the dialplan followed by all the > gateways belonging to the 'default' location that are also found in the > dialplan. This means that if a user does not belong to any location > then the list of gateways that the call will be redirected to will only > consist of all the gateways belonging to the default location that are > also found in the dialplan. I'd like to see an algorithmic description of how you create the ordered list given ordered lists for GW(default), GW(location), and GW(dialplan). Your formalism above selects which gateways, but doesn't formalize order. > So, for example, if a dialplan is configured to use the following > gateways: > GW_1_B > GW_1_A > GW_Elsewhere_A > GW_SomewhereElse_A > GW_Def_A > > ...and caller A's location includes the following gateways: > GW_1_A > GW_1_B > GW_1_C > > ...and the 'Default' location includes the following gateway: > GW_Def_A > GW_Def_B > > ...then a call made by caller A using this dialplan will be sent to the > following ordered list of gateways: > GW_1_A > GW_1_B > GW_Def_A > > Note from the previous example that if there are order discrepancies > between the dialplan and location gateway lists, the location's order > takes precedence. This explains why the resulting ordered list of > gateway in the example is {GW_1_A, GW_1_B, ...} even though the > dialplan's ordered list was {GW_1_B, GW_1_A, ...} > > ---Summary--- > > To summarize, this proposal delivers the following: > - a framework to address XECS-415 and to implement the three use-cases > sited at the beginning of the document > - embraces the 'location' concept which has the potential of bringing > more flexibility and simplicity to the management of sipXecs > - for users that do not know or care about 'locations', the system > continues to look, feel and operate the same way it used to. > - enables roaming users. _______________________________________________ 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
