Robert, This is exactly what I was looking for when feature request was made.
Also, while it wasn't in the initial feature request, I think the option code is great to have in there for the roaming user scenario. This feature will also have huge benefits in a testing/debugging scenario where the Admin may want to test calling from a particular location. As others have suggested, I believe this needs to be on a per dial plan basis. The admin may want LD calls to route totally different than local calls. Thanks, Mike > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:sipx-dev- > [EMAIL PROTECTED] On Behalf Of Robert Joly > Sent: Thursday, October 16, 2008 10:02 AM > To: [email protected] > Subject: [sipX-dev] User-based gateway selection feature proposal > (XECS-415) > > 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. > > #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. > > #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. > > 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. > > Thank you in advance for reviewing this proposal and providing > comments. > > Cheers, > bob > > > The first > > _______________________________________________ > 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
