Skip to main content

SMSC — Short Message Service Centre

The SMSC (Short Message Service Centre) is the store‑and‑forward heart of SMS in the core. It accepts messages from the network — over SS7 (MAP) from the mobile side, over Diameter, and over SMPP from application front‑ends — then routes, translates and delivers them, holding on to anything it cannot deliver immediately and retrying until the message is delivered, expires or is dropped. Along the way it tracks the delivery state of every message, translates calling and called numbers, federates with peer SMSCs so a message can be handed to whichever node can reach the recipient, and drives bulk SMS campaigns. OmniWeb surfaces all of this — live message state, subscriber locations, front‑end registrations, Diameter and federation health, the routing and translation rule sets, and campaign management — from a single per‑instance page.

← Operations Guide

The SMSC is a per‑instance element page reached from the sidebar when one runs in the site's inventory, with a fleet view where several are deployed. All traffic goes through the OmniWeb backend proxy to the SMSC's API, so it stays behind the single authenticated gateway. The documentation link in the page header (the in‑context help button) opens this page. It is organised into tabs.

Overview​

The SMSC overview dashboard — message and delivery counters, node health and a per‑MSISDN search across messages and subscriber locations

The landing tab is a single‑screen health read for the node: current message counts and delivery state, front‑end and peer health at a glance, and a search by MSISDN that looks across both stored messages and subscriber locations — the quickest way to answer "what is happening to this subscriber's SMS right now" from one box.

Messages​

The Messages tab listing stored messages with sender, recipient, state, delivery attempts and age, filtered by state and SMSC

Every message the SMSC is holding or has processed, each row showing the sending and receiving numbers, the message state (pending, delivered, failed, expired, dropped or auto‑replied), the number of delivery attempts, and its age. Messages can be filtered by state, by SMSC, and to include dead‑letter or unrouted traffic, and searched by MSISDN, node name or message ID. Selecting a message opens its detail — including the decoded plaintext — and an operator can reroute a message to force it back through routing, for example after fixing a routing rule.

Frontends​

The Frontends tab listing the registered SMPP and application front‑ends with hostname, last‑seen and registration expiry

The application and SMPP front‑ends currently registered with the SMSC — the clients that submit and receive messages. Each entry shows its hostname, when it was last seen, and when its registration expires, so you can confirm the message‑handling front‑ends are connected and their registrations are live.

Locations​

The Locations tab listing subscriber locations by IMSI and MSISDN with their last known serving location

The subscriber locations the SMSC has learned — the last known serving location for each subscriber by IMSI and MSISDN. This is the information the SMSC uses to reach a recipient, and it can be searched by IMSI or MSISDN and filtered to include expired entries. It is where you confirm the SMSC knows where a subscriber is before it can deliver to them.

Diameter​

The Diameter tab listing the SMSC's Diameter peers with realm, IP, transport and connection state

The Diameter peer connections the SMSC uses for messaging, each row showing the peer's realm, IP address, transport, connection‑initiation direction, reported product name, negotiated application IDs and connection state. This is where you confirm the Diameter path the SMSC depends on is up.

Federation​

The Federation tab showing this node, healthy/degraded/unhealthy peer counts, discovery method and per‑peer health

The federation view shows how this SMSC cooperates with peer SMSCs so a message can be handed to whichever node can reach the recipient. It reports this node, the count of healthy, degraded and unhealthy peers, the number of cached federated messages (highlighted when non‑zero), the discovery method in use (DNS domain or static peers), and a per‑peer table of node name, status, recent failures, last successful health check and the front‑ends each peer offers. It is the fastest way to see whether the SMSCs in a federation are talking to each other.

Routing​

The Routing tab listing SMS routing rules by priority with calling/called match, source, destination and enabled state

The SMS routing rules that decide where each message goes, listed by priority. Each rule matches on a calling and called number pattern (and optionally a source SMSC or source type such as SS7 or circuit‑switched), and resolves to a destination — a target SMSC or an ENUM lookup — with a description and an enabled state. Rules are fully editable: an operator can add, edit, enable, disable or delete them, and the rule set can be exported and re‑imported.

Translations​

The Translations tab listing number‑translation rules by priority with calling and called match, source SMSC and enabled state

The number‑translation rules that rewrite calling and called numbers as messages pass through — normalising formats, applying prefixes and the like. Each rule is listed by priority with its calling and called match, optional source SMSC, a continue flag (so several rules can apply in sequence), a description and an enabled state. As with routing, the rules are editable — add, edit, enable, disable, delete — and can be exported and re‑imported.

Campaigns​

The Campaigns tab listing bulk SMS campaigns with name, state and progress, plus the new‑campaign form

Bulk SMS campaigns are created and driven from this tab. A New Campaign is defined with a name and description, a sender number, the source SMSC, a recipient list, an audience (active recipients only or everyone in the list), a drip rate in messages per second, a message validity window, an optional deliver‑after time and the message template. Once created, a campaign is controlled from here — start, pause, resume or cancel — and its targets can be inspected to see the per‑recipient send and delivery state as the campaign progresses.

Campaign Lists​

The Campaign Lists tab listing recipient lists with name and description, and the append‑recipients form

The recipient lists that campaigns send to. Lists are fully managed here — create a New Recipient List with a name, description and an initial set of recipients, append more recipients later, edit, or delete a list. Recipients are supplied as CSV, so an existing contact list can be imported directly rather than entered by hand.

NAPTR Test​

The NAPTR Test tab — a form taking an E.164 number and an ENUM domain, and a table of the returned NAPTR records with order, preference, flags, service, regexp, replacement and the resolved result domain

The NAPTR Test tab is an operator tool for resolving an E.164 number (or domain) through ENUM/NAPTR DNS to see how the SMSC will route a message towards it. You enter the phone number and the ENUM domain to query (e164.arpa by default) and submit; nothing is fetched until you do. The SMSC reverses the number's digits into the ENUM zone, looks up the NAPTR records published there, and returns them in order and preference — each with its flags, service, the rewrite regexp and replacement, and the resolved result domain the record points the message at. It is where you confirm the ENUM data behind a routing rule really resolves a number to the URI or route you expect, before you rely on it in production.

MWI​

The MWI tab — a form to send a Message Waiting Indication update for a subscriber, with destination and source MSISDN, indication type, an active on/off toggle and an optional message body

The MWI tab sends a Message Waiting Indication update for a subscriber — the notification that sets or clears the "waiting messages" flag on a handset, typically after a voicemail is left or collected. You give the destination MSISDN to notify and the source MSISDN it comes from, pick the indication type (voicemail, fax, email or other), and set whether the indicator should be active (on) or cleared (off), with an optional message body and originating SMSC. It is a submit form: the update is only sent when you post it, making it the direct way to raise or clear a subscriber's waiting‑message indicator by hand.

System Logs​

The System Logs tab showing the SMSC's API‑backed log view with level and limit filters

The System Logs tab is the SMSC's own API‑backed log view. It can be filtered by level (debug, info, warning, error) and by a limit on the number of lines returned, so you can pull just the recent errors or a fuller trace when investigating a specific problem — without leaving OmniWeb.

More tools​

Alongside the tabs above, the SMSC page offers a few focused tools:

  • Submit — a form to send a one‑off SMS directly from OmniWeb (from, to and message text), for testing delivery to a specific recipient.
  • Operations — node‑wide maintenance actions, including clearing the registered front‑ends, stored messages, routing rules and translation rules. Each is a destructive action and asks for confirmation first.

Logs​

The Logs tab tails the SMSC's live log output for troubleshooting a single node without leaving OmniWeb. For a filtered, API‑backed view of the same node, use System Logs above.

Monitoring​

Message throughput, delivery‑success rates, queue depth and other time‑series for the SMSC are presented as Grafana dashboards, reached from the element page — OmniWeb does not duplicate those charts natively.

  • HSS — holds the subscriber data and routing information the SMSC's deliveries resolve against.
  • The DRA — relays the Diameter signalling the SMSC uses for messaging.
  • STP — the SS7 signalling path over which the SMSC exchanges MAP messages with the mobile network.
  • The CSCF/TAS — the IMS side that originates and terminates messaging for VoLTE subscribers.
Last updated on