> 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.
Thank you for the prompt feedback. Perhaps you are right and I will let
Martin decide on its usefulness (or lack thereof). To better illustrate
where I'm coming from with this, let me propose a use case:
Joe works of a single sipXecs, multi-branch business and is a user based
out of Ottawa. He is part of the 'Ottawa' location which is configured
to route PSTN calls using gateways located in Ottawa. He is traveling
for two days to the Calgary to meet with a partner. Although he will
not be at that site, Joe knows that the business he works for has a
branch office in Calgary. Joe has a softphone on his laptop and is
expecting to have to make numerous Calgary-local calls. For the duration
of his stay in Calgary he would like to be able to call the business
across the street without having to make a long-distance call via the
Ottawa-based gateways. Instead, he would prefer making local calls
using his company's Calgary gateway facilities therefore saving on long
distance charges. Fortunately, when the company sent him his travel
approval confirmation, it included a cost-cutting tip on how to make
local calls from the various sites that the company has. Using the
right location code, he can make local calls in Calgary. He can also
make local calls in the Ottawa region (calling his wife for example) by
dialing as though he was sitting at his Ottawa desk.
Martin, the ball is in your court. Is there value in this feature?
> > #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?
No new mechanism is added here. The feature will simply re-use the
proprietary IP address mapping headers that the NAT traversal feature
already puts in the Contact header of the dialog-forming request. When
the NAT traversal feature was introduced on paper, it came with a
heuristic for plowing through the Vias but this was "reviewed out" of
the feature on complexity grounds favoring a much simpler, but less
error proof technique which simply looks at the topmost Via.
>
> 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.
Item A above was the main motivation behind the introduction of this
topology feature (I would argue that this is "must-have" if you consider
emergency calls). Leaving emergency calls aside, a more casual
motivation for the introduction of this feature was to facilitate the
support of roaming workers in their day-to-day activities. When User A
visits another branch, the feature can 'automagically' figure out the
location of the 'traveling phone instance' based on IP addresses and
apply the correct location-based routing rules for the user without any
additional user or admin intervention.
>
> 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.
I think that even if 'A' is the goal, IMO, the topology information can
never replace the user-based location data for the following reasons:
1- The topology information may sometimes be difficult to obtain when
you have users that have dynamic public IP addresses or when a user
connects from a Hotel room
2- Even if available, entering the topology information may be
intimidating to some administrator whereas adding users appears to be
simpler
>
> 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.
If such is your goal then the optional topology information can be left
blank. Exempting some dialplans from location-based routing would be
another approach.
>
> 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.
This will happen today with the current code for scenario B and we seem
to be able to live with it.
>
>
> > #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.
Taken from Dale's post on the topic:
( GW(Loc(A)) INTERSECT GW(DP(call)) )
FOLLOWED_BY
( GW(default) INTERSECT GW(DP(call)) )
>
> > 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
