Frequently Asked Questions

Premium routes are chosen for call quality and caller ID (CLI) delivery, typically through direct or tier-one paths. Standard routes are priced for cost with acceptable quality. We tell you which you are buying for each destination; they are not mixed silently.

Our wholesale service is for carriers, ITSPs, aggregators and other licensed voice businesses that interconnect switch to switch. We do not sell retail calling plans.

Voice interconnects use SIP over IP. Codec, signalling and capacity details are agreed during onboarding; see SIP interconnection.

We carry traffic to international destinations except countries and parties under UN, US (OFAC), EU or UK sanctions. Ask us for the current list of destinations for the route type you need.

Send an interconnection request with your destinations, expected monthly minutes and whether you need termination, origination or both. After commercial terms and company and sanctions checks, both sides exchange SIP signalling and media IP addresses, configure codecs, number format and capacity, and place test calls before live traffic. See SIP interconnection for the technical details.

Route quality is monitored per destination. Traffic, call detail records (CDRs) and statements are visible through our web interface, and our technical support team handles faults and changes through the contacts agreed during onboarding.

Carrier interconnects are normally authenticated by IP address on both sides, with traffic accepted only from the addresses exchanged during onboarding. The method is confirmed in the interconnection form.

G.711 is the common baseline for wholesale interconnects; compressed codecs such as G.729 are agreed per partner. We confirm the codec list during onboarding.

It depends mostly on paperwork and testing on both sides. The technical set-up is short once IP addresses and codecs are exchanged; test calls then confirm routing, audio and caller ID before live traffic.

Yes. One SIP interconnection can carry traffic in both directions, each with its own rate plan.

SIP signalling IP addresses and ports (UDP or TCP), RTP media IP ranges, the codec list (normally including G.711), the number format (E.164, with any technical prefix agreed in advance) and concurrent-call and calls-per-second limits. Access is controlled by IP-based lists on both sides.

Voice engineers at carriers, ITSPs (internet telephony service providers) and aggregators who connect their switch or session border controller (SBC) to Wise Network for termination, origination or both.

A DID (direct inward dialling number) is a phone number that routes calls to a specific endpoint on a customer's network rather than to a single phone line. In wholesale terms, it is the number inventory behind voice origination.

Yes. Most carriers use the same SIP interconnection for both directions, with separate rate plans for outbound minutes and for numbers and inbound minutes.

Usually as a monthly charge per number plus a per-minute rate for inbound calls, which depends on the country and number type. Some number types carry set-up charges.

Yes. Many countries require proof of address or business registration before numbers are assigned. We tell you the requirements per country before ordering.

It means one provider can deliver calls to every international destination code, rather than a handful of countries. Rates, quality and route type are still set per destination.

Per minute and per destination, published on a rate deck. Rates for the same destination differ by route type (premium or standard) and can change as supplier costs change; rate changes are notified in advance under the agreement.

On premium routes, caller ID (CLI) delivery is a selection criterion for suppliers. On standard routes it is not guaranteed for every destination; we state this on the rate deck.

Both sides keep call detail records. Our platform produces CDRs and rates traffic live, and partners can see their traffic and statements through the web interface.

Wholesale SMS is the bulk sale of SMS delivery between messaging businesses: aggregators, CPaaS platforms, carriers and operators. Prices are per message and per destination network, and connections are system-to-system over SMPP or HTTP rather than through a retail web portal.

Every country except those under UN, US (OFAC), EU or UK sanctions. Coverage is confirmed per destination network, because route options and sender ID rules differ by operator. Ask us for the current coverage list.

No. We use direct and approved routes only, and we do not use SIM farms or P2P bypass to terminate A2P traffic. We also build the SMS firewalls operators use to block such routes.

In many countries, yes, but rules vary: some require sender ID registration, some allow only numeric senders, and some replace unregistered sender IDs. We explain the rule for each destination before traffic starts.

SMS aggregators, CPaaS platforms, enterprises and mobile operators that need international A2P delivery on direct and approved routes. Connections are system-to-system, so you need a messaging platform or application that can submit messages; the connection method is agreed during onboarding.

Send an interconnection request with your destinations, expected monthly volume, traffic type (OTP, transactional or marketing) and the protocol your platform supports. We reply by email, agree terms, complete company and sanctions checks, issue connection details and run test messages before live traffic. The technical steps are on SMPP connectivity.

Each message returns a delivery report (DLR) from the delivering network. We monitor delivery rates and latency per destination network and per supplier, and move traffic to another approved route when quality falls.

SMS pumping, also called artificially inflated traffic (AIT), is fraud in which attackers trigger large numbers of OTP requests to number ranges that share revenue with them. The sender pays for messages no real user asked for. Rate limits per number range and country, and watching the ratio of codes sent to codes entered, are the main defences.

It depends on the destination network and route. We monitor latency per destination and route, and steer OTP traffic to routes that deliver quickly, not just reliably. We do not publish a single guaranteed time because it varies by country and operator.

For some markets and devices it improves completion and cost. Compare the two methods in FlashCall vs SMS OTP.

SMPP 3.4, the version used by almost all A2P messaging connections today.

A transceiver bind sends and receives on one session and is the simplest choice. Separate transmitter and receiver binds are also supported where your platform needs them.

Each account has an agreed messages-per-second limit. Messages above it receive a throttling error, and your system should slow down and retry rather than reconnect.

Send enquire_link at a regular interval and answer ours. A session that stops responding is closed and must re-bind.

Your expected throughput in messages per second, destinations, traffic type and the public IP addresses you will connect from. Binds are accepted only from registered IP addresses, so list every address your platform uses, including failover servers.

After credentials are issued and your IP addresses are opened, test messages to agreed numbers confirm delivery, sender ID handling and delivery receipts. Throughput limits are then set and live traffic starts.

Bulk SMS usually means a retail web tool for sending campaigns. Aggregation is the wholesale layer underneath: system-to-system delivery of large volumes for platforms and enterprises.

In some countries, yes. Registration rules, lead times and accepted formats vary by country and operator. We tell you the rule per destination and help with registrations where the operator requires them.

Delivery rates and latency are monitored per destination network. When a route degrades, traffic is moved to an alternative approved route.

The destination networks, price, sender ID support, and an honest description of how the traffic reaches the destination operator. We test routes before live traffic and do not accept SIM farm or P2P bypass routes.

With test messages to handsets on the destination network. We check that the message arrives, how long it takes, whether the sender ID is preserved, which SMSC delivered it and whether the delivery report matches what actually happened.

Each side keeps records of messages exchanged; invoices are reconciled against them. Where we both buy and sell with the same partner, amounts can be netted under the agreement.

Yes. The firewalls, honeypot and FlashCall detection are designed, built and supported by Wise Network.

Yes. Each product works on its own. They share data when deployed together, for example honeypot evidence feeding SMS firewall rules.

Both models are possible, and the choice usually depends on regulation, data residency and the operator's operations team. It is agreed during the assessment.

Not in themselves. FlashCall is a legitimate verification method used by apps and CPaaS platforms. The issue for operators is commercial: a missed call is usually not billed on termination, so verification traffic uses the network without paying an A2P rate. Some flash-call traffic does arrive through bypass routes, and that part can be treated as fraud.

By their pattern on voice trunks: call attempts released before answer, often within a second or two, in large volumes, from calling numbers that rotate within ranges used to carry codes. Detection works on signaling and CDR data and separates them from ordinary short or missed calls.

They can be allowed on a dedicated FlashCall termination trunk and billed per attempt under an agreement with the provider, the same principle as A2P SMS monetization.

Blocking can stop users receiving verification calls from apps they use. That is why detection comes first, followed by a choice per source: bill on an agreed trunk, redirect to SMS, or block.

Both are decoys that attract activity so it can be observed. An IT honeypot imitates a vulnerable server. A telecom honeypot uses phone numbers that look like ordinary subscribers, so that messages and calls routed to them show how traffic actually travels.

No. A honeypot sees the routes that deliver to its trap numbers. Bypass that targets other numbers, or that changes quickly, may not be captured. That is why honeypot evidence is combined with SMS firewall inspection of live traffic and with revenue assurance audits.

Messages are sent through commercial SMS routes in the normal way, as any sender would. The difference is that we control the receiving numbers and capture every detail of delivery.

It supports SMS firewall rules, discussions with interconnect partners whose traffic arrives on grey paths, and revenue claims under A2P agreements. Each capture is stored with its route, timestamp and delivery details.

Typically SMS CDRs or SMSC logs for a defined period, A2P agreements and rate cards, and interconnect settlement statements. Where an SMS firewall is in place, its logs make the picture much clearer. Data handling is agreed in writing before the audit starts.

A firewall acts on traffic in real time. An audit looks back over a period, measures what was lost and why, and checks that blocked traffic actually returned through paid routes.

Yes. Flash calls move verification traffic from billed SMS to voice trunks, so they belong in the same revenue picture. See FlashCall monetization.

Most networks still run 2G and 3G for roaming, voice fallback and SMS, and interconnect with partners over SS7. A weakness in any generation of the network can be used against subscribers on all of them.

FS.11 groups SS7 messages by where they may legitimately come from. Category 1 messages should only come from inside the same network or bilateral partners. Category 2 messages should only come from a subscriber's home network. Category 3 messages should only come from the network the subscriber is actually visiting, which requires checking location plausibility.

It stops SMS fraud that relies on signaling abuse, such as faked origin addresses and illegitimate routing queries. Grey routes that use legitimate signaling are better handled by the SMS firewall, which looks at the message itself.

Our firewall covers SS7/SIGTRAN, Diameter and GTP. Ask us about 5G (HTTP/2 and SEPP) interconnect requirements for your network.

An SMPP firewall governs the SMPP connections that partners use to submit A2P traffic: binds, throughput, sender IDs and content per account. An operator SMS firewall inspects all SMS arriving at the network, including mobile-terminated SMS from foreign networks over SS7 or SIGTRAN, to stop grey routes and spoofing. Operators often use both.

It complements them. SMSC account settings are usually limited to credentials and a rate limit. The firewall adds per-partner sender ID and content policy, pattern detection and central reporting across all SMSCs and gateways.

Aggregators and SMS hubs that accept SMPP traffic from many customers use it to control customer accounts, block prohibited content and stop compromised accounts from flooding their routes.

No. The firewall classifies traffic first. Genuine person-to-person (P2P) messages from other subscribers and roaming partners pass as normal. Rules target commercial A2P traffic that arrives on paths priced for P2P, messages with spoofed or faked origins, and known spam or phishing content.

A signaling firewall protects the network against SS7, Diameter and GTP attacks such as location tracking, interception and subscriber impersonation. An SMS firewall focuses on the messages themselves: who sent them, through which route, with what sender ID and content. Many operators run both; our two products share threat data.

Usually not. The firewall sits on the signaling path, at or behind the STP or SIGTRAN gateway, and can use SMS home routing so that inbound mobile-terminated SMS is delivered to it first. Integration is planned with your core and SMSC teams during the assessment.

It combines several signals: whether the sender ID is alphanumeric or numeric, whether the originating SMSC and Global Title match the claimed sender, message velocity and fan-out from one origin, content templates repeated across many recipients, and evidence from honeypot trap numbers. No single signal is enough on its own.

Yes. Blocking grey routes is how A2P traffic is pushed back onto your commercial termination agreements. The firewall's reports show which senders and partners were affected, which supports new A2P agreements and pricing.

Mobile network operators that receive international SMS over SS7/SIGTRAN interconnects and want to stop grey-route A2P traffic, spoofed sender IDs and spam, while genuine person-to-person messages pass as normal.

With a traffic assessment, so your team can see the expected impact before anything is blocked. Operators who prefer to start from numbers can begin with an A2P traffic audit of past traffic. Request a demo to discuss your network.

Not necessarily. A mobile operator or MVNO that delivers SMS to its own subscribers needs an SMSC. An aggregator, bank or reseller that sends A2P traffic through other networks needs a gateway. Operators that also sell A2P access to enterprises often run the gateway in front of the SMSC.

Yes. Both are designed, built and supported by our engineering team, which means protocol adaptations and customer-specific integrations are handled by the people who wrote the code.

Throughput and latency depend on traffic mix, message classes, redundancy and hardware. We size each deployment from your expected traffic and confirm it in a written sizing document rather than quoting a generic figure.

Request an Operator SMSC demo or an Enterprise SMPP Gateway demo and describe your expected traffic, the networks or suppliers you connect to and the integrations you need. Capacity is sized from your expected traffic, so volumes and message types help us prepare.

Both are software that runs on standard Linux servers or virtual machines, with no proprietary signaling hardware. Deployment options for the SMSC are described on the Operator SMSC page.

The SMPP firewall protects an operator's existing SMSC from the partners that bind to it. The gateway is a complete routing platform for aggregators and enterprises, with customer accounts, supplier routes, resends and reports, and it includes its own ESME firewall.

Yes. Reseller (admin) accounts manage their own users, routes and reports in isolation from other tenants.

No. It delivers through upstream SMSCs over SMPP, which can include our Operator SMSC for on-network termination.

SMPP v3.4, HTTP/REST, HLR-assisted routing and alerting are core. SMPP over TLS, SMPP v5.0, P2A messaging and cost-based routing are confirmed per deployment. Throughput is set in a sizing document for each deployment.

SMS aggregators, banks, resellers and the enterprise units of MVNOs that accept A2P traffic from many business customers and need to police and route it. Mobile operators that deliver to their own subscribers need an SMSC instead.

Yes. A full or thick MVNO can run the Operator SMSC on SIGTRAN links agreed with its host network, which gives it control over its own messaging services, routing, billing records and A2P products.

No. Firewall functions are a separate product, so operators can protect any SMSC, including ours. The SMSC can run with our SMS firewall inline when both are deployed.

MAP over SIGTRAN, SMPP v3.4, SMPP over TLS, SIP/IMS and HTTP are core capabilities. SMS over Diameter SGd, SMPP v5.0 and geographic redundancy are confirmed per deployment.

Standard Linux servers or virtual machines, on-premise, in colocation or in a private or public cloud. No proprietary signaling hardware is required.

The app asks for the user's number, then requests verification from a FlashCall provider. The provider places a call to that number from a calling number whose last digits are the code, and releases it before it is answered. The app reads the incoming number, or the user types the last digits, and the code is checked.

iOS does not let apps read incoming call logs, so on iPhones the user has to type the digits shown in the missed call. Many verification flows use FlashCall on Android and SMS OTP elsewhere.

Not everywhere on the same terms. Some mobile operators block flash calls or require them on a dedicated, billed trunk. We deliver FlashCall only on routes where it is sanctioned and tell you which destinations support it.

Because verification moved from SMS to unbilled calls costs operators A2P revenue. Operators increasingly detect flash calls and either bill them on a dedicated trunk or redirect verification back to SMS. See FlashCall detection and monetization.

The portfolio depends on the market and is put together with our international technology suppliers and local multimedia content providers. Contact us with your market and we will describe what is available.

Yes. Our white-label applications support integration with billing systems, so services can be charged through the operator.