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
