Routing
This document describes how OmniMSC by Omnitouch analyses called numbers, selects routes, and delivers calls to their destinations. It covers the number analysis pipeline, the route table, supported destination types, the GMSC function, and route management interfaces.
For call flow diagrams showing how routing integrates with call setup, see Call Flow Diagrams. For route table configuration parameters, see Configuration Reference. For SIP peer health monitoring, see SIP Trunking. For ISUP trunk group details, see ISUP Trunking. For route management via the control panel, see Control Panel Guide.
Number Analysis
When a call is initiated, OmniMSC classifies the called number to determine its type and normalize it to E.164 format. The classification follows a priority order and uses the routing configuration for the deployment (country code, national prefix, international prefix, emergency numbers, and short codes).
Classification Order
The number analysis engine evaluates the called number against the following categories in order. The first match wins.
| Priority | Number Type | Detection Rule | Normalization |
|---|---|---|---|
| 1 | Emergency | Exact match against the configured emergency number list (default ["112", "911", "110"]; operator-configurable) | Unchanged; the route hint is set to :emergency |
| 2 | Short code | Exact match against the configured short code table, where each code maps to a service type (operator assistance, directory enquiry, etc.) | Unchanged; the route hint is set to the service type atom |
| 3 | International | Number begins with "+" or with the configured international prefix (default "00") | Stripped of the international prefix and prepended with "+" to produce E.164 |
| 4 | National | Number begins with the configured national prefix (default "0") | National prefix is stripped, then the country code is prepended with "+" to produce E.164 |
| 5 | Local | Any remaining number that does not match the above | Country code and area code are prepended with "+" to produce E.164 |
After classification, the normalized E.164 number is passed to the route table for longest-prefix matching.
Route Table
The route table is an ETS-backed data structure that maps number prefixes to destinations. It is the central decision point for all outbound call routing in OmniMSC.
Longest-Prefix Matching
When a number is presented for routing, the route table iterates from the full number length down to a single digit, checking for a matching prefix at each step. The first (longest) match found is used. If no prefix-specific match is found, the table falls back to the default route (prefix is the empty string). If no default route exists, the call fails with a no-route-to-destination error.
Priority Ordering
Each route entry carries a numeric priority value. Higher values take precedence. Priority is used when the route table is displayed and when managing overlapping entries. Emergency routes should be configured with the highest priority (e.g., 100) to ensure they are never shadowed by less-specific entries.
Example Route Table
The following table illustrates how the route table resolves different called numbers.
| Prefix | Type | Destination | Priority | Purpose |
|---|---|---|---|---|
| 000 | :sip | SIP peer "Default-GW" | 100 | Emergency number — route must match psap_address |
| 04 | :local | VLR subscriber | 50 | Australian mobile numbers |
| 0412 | :sip | SIP peer "Mobile-GW" | 50 | Specific mobile prefix routed to a SIP gateway |
| 001 | :sip | SIP peer "International-GW" | 10 | International dialing prefix |
| 07 | :isup | Trunk group "Mobile-Interconnect" | 10 | Mobile interconnect via SS7 |
| 08 | :sip_with_failover | Primary: SIP peer "Primary-SIP-GW", Failover: ISUP trunk "Backup-ISUP" | 10 | SIP with automatic ISUP fallback |
| 09 | :sip_i | SIP-I peer "MSC-02-SIP-I" | 10 | SIP with encapsulated ISUP to a peer MSC |
| (empty) | :sip | SIP peer "Default-GW" | 1 | Catch-all default route |
With this table in place:
| Dialed Number | Matching Prefix | Destination | Reason |
|---|---|---|---|
| 000 | 000 | SIP: Default-GW | Exact match on emergency prefix |
| 0412345678 | 0412 | SIP: Mobile-GW | Longest match (4 digits beats the 2-digit "04" entry) |
| 0498765432 | 04 | Local VLR subscriber | Matches "04" but not "0412" |
| 0011234567 | 001 | SIP: International-GW | Longest match (3 digits) |
| 0312345678 | (empty) | SIP: Default-GW | No prefix match; falls to default |
Route Types
OmniMSC supports the following destination types in the route table.
Emergency Calls
Emergency calls are not a separate route type. The MSC detects emergency calls from the CC Emergency Setup message type (3GPP TS 24.008 §9.3.8, message type 0x0E) and the CM Service Request type (:emergency). Authentication is attempted but the call proceeds regardless of the outcome. Ciphering is established if authentication succeeds; otherwise the call proceeds without it.
Emergency Setup messages do not carry a Called Party BCD Number — the handset sends only an optional Bearer Capability IE and Emergency Service Category IE. The MSC uses the psap_address from the Emergency configuration as the called number for route table lookup. This number is then routed through the normal route table like any other call. The route entry it matches can be any type (:sip, :isup, :sip_i, etc.).
Example: To route emergency calls to a SIP peer named "Default-GW":
# Route table — psap_address "000" will match this entry
%{prefix: "000", type: :sip, peer: "Default-GW", priority: 100}
# Emergency config — psap_address is used as the called number
config :omnimsc, Omnimsc.Emergency,
psap_address: "000"
If authentication fails, the caller's IMEI is used as the calling party number instead of the MSISDN. Emergency numbers are also detected during number analysis and can trigger emergency handling even before the route table is consulted.
:local
Routes the call to a subscriber registered in the local VLR. The MSC looks up the called MSISDN in the VLR, pages the subscriber via the appropriate BSC or RNC, and establishes the call over the A-interface or Iu-CS interface.
:sip
Routes the call to a configured SIP peer by sending a SIP INVITE. The route entry specifies the peer by name; the peer's IP address, port, transport, and codec configuration are resolved from the SIP peer table. The Trunk Router verifies that the peer is reachable (status is not "down") and that the peer has available channels before routing.
:isup
Routes the call via an SS7 ISUP trunk group. The route entry specifies the trunk group name, destination point code, and CIC (Circuit Identification Code) range. The Trunk Router allocates an idle circuit from the trunk group, constructs an Initial Address Message (IAM), and sends it via the M3UA/SCTP transport to the remote exchange.
:sip_i
Routes the call to a SIP-I peer, where the full ISUP message is encapsulated within the SIP body. SIP-I preserves all ISUP information elements during interworking, avoiding the information loss that can occur with standard SIP-ISUP conversion. For protocol details, see SIP-I Trunking.
:sip_with_failover
Attempts the call via a primary SIP peer first. If the SIP peer is unreachable, returns a 5xx error, or times out, the Trunk Router automatically retries the call via a configured ISUP failover trunk group. This destination type requires both a SIP peer name (primary) and an ISUP trunk group with point code (failover).
:gmsc
Invokes the Gateway MSC function. The MSC sends a MAP SendRoutingInfo request to the HLR to obtain the MSRN (Mobile Station Roaming Number) for the called subscriber, then routes the call to the serving MSC using the returned MSRN. See the GMSC Function section below for details.
:transit
Routes the call as a transit call between trunk types without instantiating a full Call Control FSM. Transit routes are used for ISUP-to-SIP gateway operation, SIP-to-ISUP interworking, ISUP-to-ISUP tandem switching, and SIP-to-SIP proxy transit. Transit routes include source context (the incoming trunk type and name) to match incoming calls from specific trunks.
Route Table Management
Web UI
The Routes and Trunks page in the OmniMSC Control Panel provides a tabbed interface for managing routes, ISUP trunk groups, and SIP peers. From the Route Table tab, operators can add, edit, and delete routes through modal forms. Route changes take effect immediately without requiring a restart. Routes loaded from configuration at startup can be overridden at runtime. For details on the web interface, see Control Panel Guide.
REST API
Routes can also be managed programmatically through the REST API.
| Method | Endpoint | Description |
|---|---|---|
| GET | /api/routes | List all routes in the table |
| POST | /api/routes | Add a route. Request body includes prefix, type, peer (for SIP types), and priority. |
| DELETE | /api/routes/{id} | Remove a route by its prefix (the id path parameter is the route prefix) |
Route Lookup Testing
The route lookup endpoint allows operators and integration systems to test routing decisions without placing a call.
| Method | Endpoint | Description |
|---|---|---|
| GET | /api/routes/lookup/:number | Returns the destination that would be selected for the given called number, or a no-route indication if no match exists |
GMSC Function
When OmniMSC receives a call for a mobile subscriber who is not registered in the local VLR, it can act as a Gateway MSC (GMSC) per 3GPP TS 23.018. The GMSC function bridges the gap between the calling network and the visited MSC where the subscriber is currently registered.
MT Call Routing Flow
- An incoming call arrives from a PSTN trunk or SIP gateway with the subscriber's MSISDN as the called number.
- The route table lookup returns the :gmsc destination type for this prefix.
- OmniMSC sends a MAP SendRoutingInfo (SRI) request to the subscriber's HLR, providing the called MSISDN.
- The HLR identifies the serving VLR and instructs it to allocate a Mobile Station Roaming Number (MSRN).
- The HLR returns the MSRN to OmniMSC in the SRI response.
- OmniMSC routes the call to the serving MSC using the MSRN, either via an ISUP IAM or a SIP INVITE depending on the interconnect type.
- The serving MSC pages the subscriber and completes the MT call setup.
MSRN Pool
OmniMSC maintains a pool of MSRNs for allocation during MT call routing. When a subscriber is paged at the local MSC, an MSRN is allocated from the pool, associated with the subscriber's IMSI, and returned to the querying GMSC. The MSRN is released back to the pool once the incoming call arrives or the allocation times out.
Pool-Aware Routing
When MSC pool mode is active (see MSC Pool and NRI), the routing module considers the NRI embedded in the subscriber's TMSI during MT call routing. If a subscriber's TMSI contains a foreign NRI (belonging to another pool member), the MSC can relay the subscriber to the owning MSC via MAP SendIdentification, re-register the subscriber locally if the owning MSC is unreachable, or route MT calls to the owning MSC if the subscriber has not yet re-registered locally.
NRI-based routing is automatic when pool mode is enabled and does not require explicit route table entries.
Number Analysis Flow
The full routing decision flow, from called number to destination, proceeds through the following stages:
- Call barring check -- if the subscriber is barred from this call type, the call is rejected with a GSM cause code.
- CAMEL trigger check -- if a CAMEL service key matches, an InitialDP is sent to the SCP. The SCP may modify the called number, connect to a different destination, or release the call.
- Number analysis -- the called number is classified and normalized as described above.
- Route table lookup -- longest-prefix match against the route table.
- Destination dispatch -- the call is handed to the appropriate handler based on the matched destination type.
- Failover (if applicable) -- for :sip_with_failover routes, a failed SIP attempt triggers automatic retry via the ISUP fallback trunk.
ISUP Trunk Groups
Each ISUP trunk group represents a bundle of voice circuits to a remote SS7 exchange. Trunk groups are identified by name and configured with a destination point code and CIC range. When routing selects an ISUP trunk group, the Trunk Router allocates the first idle circuit found in the trunk group and sends an IAM.
Trunk groups support priority levels: primary (first choice), overflow (used when primary circuits are exhausted), and last-resort. Only active trunk groups are selected for routing; inactive or congested trunk groups are skipped.
Each trunk group tracks seizure, answer, busy, congestion, and release counters for operational monitoring.
SIP Peer Selection
SIP peers represent remote VoIP gateways, IMS nodes, or SIP trunking providers. Each peer is configured with an address, port, transport (UDP, TCP, or TLS), supported codecs, and maximum concurrent channels.
Peer health is monitored via periodic SIP OPTIONS keepalives. If a peer stops responding, its status transitions to "down" and the peer is excluded from routing. When a route specifies a SIP peer by name, the Trunk Router verifies the peer is reachable and has available capacity before routing the call.
3GPP Specification References
| Specification | Title | Relevance |
|---|---|---|
| TS 23.018 | Basic Call Handling | GMSC function, MT call routing, number analysis |
| TS 29.002 | MAP Specification | MAP SendRoutingInfo, MSRN allocation |
| TS 23.078 | CAMEL Phase 4 | CAMEL trigger handling in the routing flow |