Label Routing
| Line 60: | Line 60: | ||
*[[Web_Portal_Tutorial_Guide_v2.7#Label_Routing|Label routing for v2.7]] | *[[Web_Portal_Tutorial_Guide_v2.7#Label_Routing|Label routing for v2.7]] | ||
*[[Web_Portal_Tutorial_Guide_v2.6#Label_Routing|Label routing for v2.6]] | *[[Web_Portal_Tutorial_Guide_v2.6#Label_Routing|Label routing for v2.6]] | ||
| − | + | ||
</div> | </div> | ||
== Useful links == | == Useful links == | ||
*[[Tmedia_Routing|Tmedia Routing]] | *[[Tmedia_Routing|Tmedia Routing]] | ||
Latest revision as of 02:07, 10 February 2020
Label Routing is an algorithm that combines Digit Analyzer and the concept of RouteSet. It is implemented as a RoutingScript in Toolpack Gateway. This algorithm allows complex routing rules, as normally available with RoutingScript, but on a very large number of destination numbers.
Contents |
Concept
The concept behind label routing is quite simple.
- A list of numbers (NPA-NXX) for a specific destination is assigned a RouteSet name. This list can be very large
- i.e., 514201,514202,514203, ... -> Montreal_Qc
- The list of routes for the destination is assigned the same RouteSet name. This list usually is limited to the number of network access points (NAP) in the system.
- i.e., Bell, Rogers, Videotron -> Montreal_Qc
Note: No matter how many destination numbers lead to a given destination, only a limited list of routes are selected. At this point, complex, yet efficient, routing rules can take place.
Implementation
As previously mentioned, routeset (label) routing is implemented as a RoutingScript. It was written as an optional filter, and can be used in any existing scripts. This filter is a before_filter, and reduces the amount of routes the routing script will work with.
Performance
Typically, there are only a few hundred labels (e.g. countries/states/regions/providers/cities identifiers) but there are hundred thousands and millions of actual numbers pointing to those labels. Each label will correspond to a dynamic route associating it to a destination NAP. The biggest portion of the data comes from the digitmap files. These million digit maps are loaded into binary trees when a configuration is applied allowing longest match algorithm to be performed with constant delay regardless of the number of digit map entries in memory. The only performance impact is upon the "Apply configuration" time, not on the call processing flow. Here are a few samples of configuration loading time on a TMG3200 running release 2.7:
| Nb of digitmap entries | Uncompressed digitmap filesize | Apply configuration time (s) |
|---|---|---|
| Not used |
- |
~6s |
| 250k |
4.4MB |
~7s |
| 500k |
8.8MB |
~8s |
| 5M |
88MB |
~17s |
Note that digit map files can be gzipped to reduce size before importing them in the File Db.
