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
