> Of course the devil is in the details, that is, can we
> implement this scheme without doing too much violence to the
> architecture.
>
> On Thu, 2008-10-16 at 10:01 -0400, Robert Joly wrote:
> > - An optional three-digit location code;
>
> Presumably the length of the location code is settable.
Yes, that makes a lot of sense.
>
> > #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.
>
> I don't see what you mean by "the caller's public IP
> address". What bit of the SIP request are you examining?
That is simply re-using the public IP address information that the NAT
traversal adds to the Contact of dialog-forming requests via proprietary
Xsipx-pubcontact headers.
>
> > #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.
>
> Mention here the interaction of #3 with the current scheme of
> forcing all calls that appear to be from a defined user in
> the domain to providing auth credentials, from which a
> P-Asserted-Identity header is constructed.
There are no direct interactions. If the message happens to carry a PAI
that is properly signed, the feature will use it to find out the
location of the user without any regards to how that PAI found its way
into the message. One of the motivations for the introduction of PAI in
sipXproxy was to enable development of features that are conditional on
the caller.
>
> > Users that do not match any of the presented criteria are
> essentially
> > location-less and will, by default, fall into the 'Default'
> location
> > category.
>
> Actually, that is "INVITEs that do not match any of ...".
>
> > ---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, ...}
>
> So what you're really saying is (using operations that are
> aware of the orderings involved):
>
> Let C be a call that will be routed using a PSTN gateway; Let
> Loc(C) be the effective location for C; Let DP(C) be the
> dialplan used to route the call; Let GW(Loc(C)) be the
> ordered list of gateways belonging to loc(C); Let GW(default)
> be the ordered list of gateways belonging to the 'default'
> location; Let GW(DP(C)) be the *set* of gateways configured
> for DP(call).
>
> The list of gateways that the call will ultimately be
> redirected to is given by:
> ( GW(Loc(C)) INTERSECT GW(DP(C)) )
> FOLLOWED_BY
> ( GW(default) INTERSECT GW(DP(C)) )
>
> Where the ordering of the result of an intersection is the
> ordering of the elements in the first, ordered, argument.
Very good.
>
> I assume you also expect the 2nd and later occurrences of a
> single gateway to be deleted from the final list.
Indeed. The gateways would then be given by:
UNIQUE( ( GW(Loc(C)) INTERSECT GW(DP(C)) )
FOLLOWED_BY
( GW(default) INTERSECT GW(DP(C)) ) )
Where UNIQUE only keeps the first instance of a given entry and removes
duplicated ones.
>
> A couple of questions come to mind:
>
> - We probably want to be able to set the effective location
> of some calls to be different from others. E.g., we may want
> emergency calls to prefer the local gateways, but
> non-emergency outside calls to prefer a central gateway.
Different dialplans can involve different gateways that belong to
different locations. In addition, both Scott and Martin highlighted the
need to enable/disable location-based routing on a per dialplan basis.
>
> - Do we have a decent solution to the "multiple gateway
> routing problem"?
I felt ignorant for not knowing what the "multiple gateway routing
problem" was until google and sipxdev mailing list archive searches
returned no match. Please educate me. Is that related to error codes
retuned by gateways?
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
