Hi, The purpose of this e-mail is to capture the outcome of a conversation that was held between Scott, Damian and myself on the topic of user-based gateway selection (XECS-415). That conversation took place to help speed up the resolution of technical issues & gaps and to ensure alignment on the feature's purpose and scope. That e-mail is meant to present the our collective view of the feature and describe the approach taken to implement it.
Before diving into the detail, here is a recap of the feature's purpose and scenarios in which it can be useful: 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 - 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 #2: - 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 Example #3: - 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 should be routed to the user's departmental gateway. [NOTE: this feature is not meant to provide a comprehensive 911 solution but may be used for 911 support in some scenarios where a better alternative does not exist] Scope of the solution ===================== The original proposal for this feature contained three mechanisms by which location-based decisions are made. Referring back to http://thread.gmane.org/gmane.comp.voip.sipx.devel/13110/focus=13170, these mechanisms were 1) Location code dialing; 2) routing based on topology data about a location; and 3) routing based on a user's location attribute. After a healthy debate between Scott, Damian and I and we chose to scale back the feature that the technology team is offering in the following ways: Feature proposal for 4.0 timeframe =================================== 1- Location Code Dialing: [REMOVED] We chose to remove that from the offering. Basically, there are very few realistic scenarios in which end-users would actually benefit from such a mechanism, hence it is difficult to justify the added complexity and implementation effort. Based on comments received on the mailing list, the perceived value of this mechanism was mainly testability, i.e. the ability for an admin to validate its location configuration by making calls from every 'location' simply by dialing the proper location code. It was highlighted in during the meeting that equivalent testability capabilities could be achieved by having a multi-line test phone configured with lines populated with test users from different locations (e.g. line #1 = Ottawa test user; line #2 = Calgary test users; ...). Through such a scheme, the admin can verify its location configuration just as easily as it could with location codes. 2- Routing based on topology data of a location: [OPPORTUNISTIC] On the mailing list, reservations were expressed as to the ability for sipXproxy to extract enough reliable IP address information from the caller to actually provide such a feature and make it predictable. After more healthy debate, it was concluded that for almost all all-sipX deployments, it would be possible for the feature to extract reliable caller IP address information to make the feature work as intended. The logic would go like this: upon receiving a dialog-forming INVITE request, sipXproxy would inspect the Via stack from top to bottom in search of a "Received" tag. If one is found, the IP address it contains is considered the caller's "most public" IP address and would be used to route the call based on location topology. If the end of the Via stack is reached without finding a "Received" tag, the bottom Via's sent-by parameter is used instead to route the call based on location topology. Although we convinced ourselves that this feature can be reliably provided, it has inherent complexities and test implications that make it a challenge for 4.0. As a result, this feature is classified as opportunistic for 4.0. 3- Routing based on a user's location attribute: [COMMITTED] This is the simplest part of the original offer and covers most of the use-cases (roaming users are not covered though). Management of the feature ========================= The purpose of this section is to present the management changes that this feature will require. Every user will have a new attribute called location. In this field, the administrator will have to possibility of designating a user a being part of at most one location. It has not been decided yet whether or not groups also have a location attribute that the group members inherit. Every gateway has two new attributes. The first attribute is used to associate the gateway with one or more locations that it serves. The second is to indicate whether or not that gateway is 'shareable'. A shareable gateway is defined as a gateway that is associated with some locations {X} but can be used by users of other locations not found in {X} as fallback. Every dialplan rule has a new attribute which indicates whether or not user-based routing applies for that rule. For example, if an administrator crafts a dialplan rule whose sole purpose is to provide toll bypass then disabling user-based routing for that dialplan may be in order to ensure that calls get routed to the 'inexpensive' gateway no matter who originated it. Feature Design ============== Up to now, all the discussions about this feature focused our the concept rather than the implementation. Now that we are converging on the concept, it is now appropriate to discuss the implementation of the feature. #1- SipXconfig will be modified to offer the new attributes described in the previous section #2- A new location database will be generated by sipXconfig which maps a user's identity to its location. #3- A new format will be introduced for fallbackrules.xml that will allow it to express location information. Basically, sipXconfig will do much of the dialplan gateway processing to generate fallback rules that have the gateway lists organized and ordered by location for each rule. This means that sipXconfig takes it upon itself to look at the list of gateways provisioned for a given dialplan rule and generate a corresponding fallbackrules.xml entry that will contain an explicit ordered list of gateways to use for each location. That will relieve the SIP Redirect server from having to recalculate that list on the fly on every call based on the user's location. For a given dialplan rule, the list of gateways given by sipXconfig for location 'X' will first contain the subset of gateways that are associated with location 'X' followed by the gateways that are not associated with location 'X' but are 'shareable'. #4- A new private version of UrlMapping.cpp will be created to understand the new fallbackrules.xml format and offer methods to match based on a supplied location. That private copy is used to shield the rest of the system from changes made to UrlMapping.cpp - this is a temporary measure taken to limit the risk. #5- Currently, the Mapping and Fallback redirector plug-ins share the same code. With the introduction of user-based routing, there isn't enough commonality between the mapping and fallback rules to justify them sharing the same implementation. Fallback will be split off as its own redirector plug-in specializing on performing routing based on user location and gateway tables found in fallback rules whereas Mapping will continue to be the redirector that performs mappings based on mappingrules.zml and enforce source permissions. The Plan ======== -Scott will propose the new fallback rules schema during this sprint -Bob will provide decoding for new schema and implement the new fallback redirect plug-in that is ready to perform routing based on user location. Bob will also provide hooks to do topology-based routing opportunistically (i.e. if enough time is available during this sprint) -Damian and the sipXconfig team to schedule the config work in upcoming sprints. Open Questions ============== One open question that was noted during the meeting is the behavior of the system when a user is not tied to any location. Which gateways should it use when making a PSTN call. One answer could be that all configured gateways get used regardless of their location setting. Another approach could be that only 'shareable' gateways get used. It is believed that the answer will become apparent once we start playing with the feature. Another open question is the following: Should groups also have a location attribute that the group members inherit? Scott and Damian, please feel free to highlight any omissions or to correct misrepresented information. Cheers, bob _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
