Session Border Controller for MVNOs: AMR Transcoding, IMS Interconnect, and Multi-Carrier Termination
If you are standing up a mobile virtual network operator, you have voice network problems the average enterprise SBC vendor was not built to solve. Your subscribers’ calls leave the host MNO’s radio network encoded in AMR. Your wholesale termination carriers want G.711. In between, you need to bridge the codec gap, normalize SIP between an IMS core and a half-dozen SIP trunks, keep international revenue share fraud off your trunks, and do it at a price that does not eat the thin margins MVNO economics already give you.
That is a different shopping list from the one a managed service provider or contact center writes when they buy an SBC for their fixed-line voice-over-IP traffic. The signaling looks similar on the surface. The codecs, the fraud profile, the carrier interop work, and the deployment model are not.
This page covers what MVNOs specifically need at the voice edge, why most generic SBC marketing misses the requirements that matter, and how a ProSBC plus transcoding device combination actually maps to the MVNO architecture in production.
Why MVNOs Are a Different SBC Conversation
Most SBC marketing is written for business to business fixed-line voice: one company, one PBX, one or two SIP trunks, calls that are SIP/G.711 from end to end. The SBC handles security, normalization, and Teams Direct Routing if the customer wants it. That is a real market, and it is well served.
An MVNO does not look like that. The calls originate on a mobile device riding the host MNO’s radio network, carrying AMR over an air interface and then SIP/IMS once they hit the packet core. They terminate to anywhere on the global PSTN through a portfolio of wholesale carriers that the MVNO has negotiated rates with. The SBC sits in a place enterprise SBCs were not designed for, and it has to do work an enterprise SBC vendor rarely ships out of the box.
Not every MVNO needs an SBC
This is the first thing to settle. A light MVNO that is reselling the host MNO’s voice service end-to-end does not need its own SBC. The host operator’s network carries the call and handles everything from origination to termination. The MVNO’s value is in branding, billing, and the customer relationship.
The conversation changes for two specific MVNO profiles. A full MVNO that runs its own voice core (its own IMS, HLR/HSS, and call control) needs an SBC at the border between that core and external networks: the host MNO’s interconnect, wholesale termination carriers, and any direct interconnects to enterprise customers. An MVNE that hosts multiple MVNO brands on shared infrastructure needs an SBC for the same reasons, with multi-tenancy added on top because the platform serves many MVNO tenants from one deployment.
The codec gap is the first wall MVNOs hit
Mobile networks speak AMR. Wholesale termination carriers speak G.711. Some interconnects need G.722 for HD voice. Without a transcoding element somewhere in the path, calls do not connect, or they connect but with quality the subscriber will not tolerate.
One MVNO operator described his evaluation this way: “I went through the internet checking what kind of solutions can do this transcoding from AMR to G.711 or whatever we want to have. Then I found two companies basically.” That short list is real. Hardware-accelerated AMR transcoding at carrier scale is the requirement that narrows the SBC market sharply once an MVNO is past the lab phase. We will come back to how this gets solved.
The fraud profile is mobile, not enterprise
An enterprise SBC primarily defends against telephony denial of service, registration scanning, and the classic PBX toll fraud pattern where attackers compromise an extension and ring up calls to expensive destinations. MVNOs see those too, but the bigger financial exposure is International Revenue Share Fraud running through wholesale interconnects, and Wangiri-style missed-call scams targeting mobile subscribers. Both can run up six-figure losses in a single weekend if real-time detection is not in place at the SBC layer.
What MVNOs Should Look For in an SBC
The criteria below are the ones that actually separate suitable SBCs from unsuitable ones for an MVNO deployment. They are not the same criteria you would write down for an enterprise voice project.
AMR-NB and AMR-WB transcoding to G.711
Mobile-originating calls arrive in AMR. Wholesale carriers expect G.711. The SBC needs to bridge that gap reliably at the call volumes the MVNO plans for, not just the ones it has today.
AMR transcoding is a CPU-intensive operation that should, in high-volume, high-redundancy environments, be handled with dedicated transcoding devices that ensure carrier-grade performance. The TelcoBridges answer is to pair ProSBC for signaling, security, and routing with a transcoding device for the high-performance conversion of AMR to G.711. There is a detailed walkthrough of how SBC AMR-to-G.711 transcoding works for the engineering side of the decision.
IMS interconnect and VoLTE interworking
If you are a full MVNO running your own IMS core, the SBC has to talk SIP cleanly to that core. That means handling the SIP variants IMS uses (P-Asserted-Identity, P-Charging-Vector, Privacy headers, and SIP precondition handling), translating those into whatever the external carrier expects on the other leg, and presenting a stable interface that does not break every time the IMS vendor pushes an update.
VoLTE interworking is the same problem from the other side: subscribers on VoLTE-capable handsets place calls that traverse the IMS and need to reach legacy networks that may not be VoLTE-aware. The SBC normalizes the signaling so neither side has to know about the other’s quirks.
Wholesale carrier interop and least-cost routing
MVNOs rarely have one termination carrier. The economics of voice termination push them toward two, three, or five wholesale relationships, with rate sheets that change monthly and routing decisions that need to reflect destination, time of day, carrier capacity, and quality scores.
An SBC that helps with this exposes its call routing engine to the operator rather than hiding it behind a black-box optimizer. ProSBC’s API-based routing engine gives the operator direct access to 100-plus call parameters per route decision, with the ability to query external systems (rate engines, fraud databases, MNP lookups) inline and route on the result. The point is that the routing logic is yours, not the vendor’s, which matters when your carrier portfolio shifts.
Real-time fraud detection at the voice edge
For MVNOs the fraud question is not whether you will see an attack. It is how fast you can detect and stop one when it happens. IRSF runs hot for as long as the attacker can keep the trunk open. A multi-hour delay between attack onset and detection is the difference between a manageable incident and a six-figure loss.
The SBC sits at the right point in the network to do real-time detection because every call traverses it. ProSBC’s fraud detection integrates with TransNexus, YouMail, and SecureLogix (or any other third-party provider) for live scoring per call, supports the Somos RealNumber Do-Not-Originate list for caller ID validation, and offers policy-based routing that can throttle or block based on destination prefix, call rate per source, or geographic anomalies. The Real-Time Fraud Protection use case is one of ProSBC’s primary deployment patterns, not a checkbox.
MNP and intelligent number lookup
Routing a call to a ported number means looking up the actual current operator before deciding the termination route. MVNOs in regulated markets handle this constantly, and the lookup needs to happen during call setup with no perceptible latency.
The SBC is the right place for the lookup because it has the called number in hand and is about to make the routing decision anyway. ProSBC supports MNP lookups via HTTP query against external databases, with the result feeding directly into the routing engine. The VNPT deployment runs MNP integration as part of its baseline.
Multi-tenancy if you are an MVNE
If the architecture is one SBC serving one MVNO brand, multi-tenancy is not a hard requirement. If you are an MVNE platform serving multiple MVNO brands from shared infrastructure, it absolutely is, and the criteria look similar to what the SBC for MSPs conversation covers: logical separation per tenant, per-tenant routing rules, per-tenant CDRs for billing accuracy, and the ability to isolate one tenant’s problem from another tenant’s traffic.
Deployment flexibility and scale headroom
MVNOs typically start small and scale fast if the brand catches on. An SBC that serves you at 500 sessions and forces a forklift upgrade at 5,000 is the wrong choice. The platform should run on the infrastructure you actually use (KVM, Proxmox, VMware, AWS, Azure, or bare metal) and offer linear capacity expansion without re-architecting.
This is where the “Linux guys on Proxmox” reality of many MVNO operators matters. ProSBC ships as a virtual machine image for KVM, VMware, Hyper-V, and the major public clouds, scales from a 3-session lab license to 60,000 sessions per server (on the right hardware), and uses the same configuration model at every scale. The operational learning curve does not reset when you grow.
How ProSBC Fits the MVNO Architecture
The TelcoBridges answer to the MVNO use case is not one product. It is two, and the split is deliberate.
ProSBC handles everything that lives in the signaling and policy layer: SIP termination and re-origination as a full B2BUA, security at the network edge, routing across multiple carriers, fraud detection integration, STIR/SHAKEN signing where US MVNOs need it, MNP lookups, and the operational features (CDRs, monitoring, high availability) that keep a voice service running. ProSBC runs as software on standard infrastructure and scales linearly with sessions.
Ttrans transcoding devices handle the work that needs DSP silicon: AMR-NB and AMR-WB transcoding to and from G.711 and G.722 and hardware fax (T.38) interworking when an MVNO is reselling business voice. Ttrans is the answer to the codec problem because pure software AMR transcoding at carrier-grade densities is not yet a thing anyone ships honestly.
In practice the two work together at the MVNO edge. ProSBC owns the SIP, Ttrans owns the media transformations that need transcoding, and the operational interface is unified through the same monitoring stack. A small MVNO can run ProSBC alone for the signaling-only portion of its traffic and add Ttrans as soon as AMR transcoding becomes a production requirement rather than a lab question.
What this looks like operationally
The deployment pattern most full MVNOs land on is a pair of ProSBC instances in 1+1 high availability at the IMS-to-external border, with Ttrans gateways inline for codec transcoding when calls leave the mobile core for wholesale termination. The ProSBC pair handles all SIP, security, and routing decisions. The Ttrans handles AMR. High availability means a single instance failure does not drop calls in progress.
For MVNEs the pattern adds tenant isolation through Network Access Points (NAPs), with each MVNO brand mapped to its own NAP for routing, billing, and CDRs. ProSBC supports up to 1,024 NAPs per server, which gives a single platform meaningful headroom for tenant growth.
MVNO SBC deployment: a ProSBC 1+1 HA pair handles SIP, security, and routing at the IMS-to-external border, with Ttrans gateways inline for AMR-to-G.711 transcoding on the wholesale carrier side. Click to enlarge.
Where MVNO SBC Decisions Get Hard
The technical fit is one part of the decision. There are three places where the conversation gets harder, and they are worth surfacing before the evaluation rather than after.
The hardware question
AMR transcoding requires hardware. Ttrans is a hardware appliance, which means MVNOs that have committed to a cloud-only operating model have to confront the limits of that commitment. Some MVNOs decide to keep a hardware footprint at the voice edge specifically for the transcoding work and run everything else (ProSBC, IMS core components, billing) on virtualized infrastructure. Others delay the AMR question by keeping voice traffic on the host MNO’s existing transcoders, which works until volume justifies bringing it in-house.
STIR/SHAKEN for US-licensed MVNOs
If you operate as an MVNO in the United States, STIR/SHAKEN compliance is non-optional. The wrinkle for MVNOs specifically is that you typically do not own the underlying telephone number ranges your subscribers use (the host MNO does), which complicates attestation. You can default to B-level (partial) attestation, which means you know where the call originates but not the specific caller. You can implement A-level (full) attestation if you control the number assignment and can authenticate the calling party. The choice has commercial and reputational consequences because downstream carriers increasingly weight attestation level in their handling decisions.
The SBC’s role here is the same as for any voice service provider: integrate with a signing service (TransNexus ClearIP, Neustar, or another), sign at origination, and pass the Identity header downstream. ProSBC supports this through both deployed SIP-based and capability-path HTTPS integrations, with primary and secondary signing service redundancy. The deeper detail lives in the STIR/SHAKEN SBC implementation guide.
Managed vs self-operated
Most early-stage MVNOs run lean technical teams. One or two engineers who know voice deeply, a few more who know the rest of the stack. That works at launch and breaks the first time the voice expert takes a vacation during a fraud incident.
The two viable answers are to invest in deep voice expertise on the team or to use a managed SBC service that takes 24/7 monitoring, fraud response, and configuration changes off the team’s plate. The economics depend on session volume: at small scale, self-operating with TelcoBridges support is usually cheaper, but at the point where you need 24/7 coverage for the SBC alone, the managed option starts to look like the better trade. The deeper analysis lives in the managed SBC vs self-hosted SBC comparison.
Getting Started
The fastest way to evaluate an SBC for an MVNO deployment is to run it in a lab against a real SIP trunk, see how the routing engine handles the call decisions you actually care about, and (when you are ready) bring in a Ttrans for the AMR side of the test.
ProSBC Lab
A permanently free, three-session ProSBC license sized for testing. Self-serve, no sales call, runs on KVM (Proxmox), VMware, or Hyper-V. This is enough to validate SIP termination, configure routing logic against your real wholesale carriers, and test interop with your IMS core in a non-production environment.
30-day production trial
500 concurrent sessions for 30 days, no charge. This is the version to use when you need to validate at near-production scale, run real subscriber traffic through the SBC, and confirm the platform holds up under your actual load profile before committing to a license.
Ttrans evaluation
AMR transcoding requires hardware, which means a Ttrans evaluation is a different conversation than a software trial. The path is to scope a small Ttrans configuration with TelcoBridges (typically a low-density TMG800 or TMG3200 for evaluation) and validate the transcoding quality and capacity against your specific codec mix.
Managed service
For MVNOs that would rather not operate the voice edge themselves, TelcoBridges runs a fully managed service that covers ProSBC and Ttrans deployment, configuration, 24/7 monitoring, fraud response, and ongoing changes. The service is sized per the MVNO’s session count and traffic profile.
ProSBC and Ttrans are built by TelcoBridges, a Canadian telecom infrastructure company with over 20 years of SIP deployment experience and installations in more than 110 countries. ProSBC supports up to 60,000 sessions per server. Ttrans gateways are deployed at full MVNOs, MVNEs, and tier-one mobile carriers worldwide.
Frequently Asked Questions
Does an MVNO need its own SBC?
It depends on the MVNO model. A light MVNO that resells the host operator’s voice service end-to-end does not need its own SBC because the host operator’s network handles the call from origination to termination. A full MVNO that operates its own voice core (HLR/HSS, IMS, call control) needs an SBC at the border between that core and external networks: the host MNO interconnect, wholesale termination carriers, and direct enterprise interconnects. An MVNE platform serving multiple MVNO brands needs an SBC with multi-tenancy on top of the same requirements.
Can a software SBC handle AMR transcoding for an MVNO?
Pure software AMR transcoding can be done, but it consumes an extraordinary amount of CPU per call to scale economically beyond very low session counts. Most carrier-grade SBC vendors that advertise AMR transcoding actually deploy dedicated hardware underneath, even when the SBC software runs on commodity servers. The TelcoBridges approach uses ProSBC for SIP and routing in software, paired with Ttrans gateways for DSP-based AMR-to-G.711 and AMR-to-G.722 transcoding. This is more honest than software-only claims and reflects what production MVNO deployments actually require.
What is the biggest fraud risk for MVNO voice?
International Revenue Share Fraud (IRSF) is the dominant financial risk. Attackers compromise an MVNO SIP trunk or a downstream PBX and pump high call volumes to premium-rate international numbers that the attacker secretly owns or controls, splitting the revenue with the terminating operator. A single weekend of unchecked IRSF can produce six-figure losses. Wangiri (one-ring missed-call scams targeting mobile subscribers) is the second major risk and runs on the subscriber side rather than the trunk side. Both require real-time detection at the SBC layer because by the time monthly billing reconciliation surfaces the loss, the money is gone.
How does an SBC handle MNP for an MVNO?
The SBC performs an MNP lookup during call setup, before deciding the termination route. ProSBC supports MNP lookups via HTTP query against external number portability databases, with the result feeding into the routing engine alongside other parameters (destination prefix, time of day, carrier capacity, fraud score). The lookup happens in the signaling phase with no perceptible latency to the subscriber, and the resulting routing decision sends the call to the correct terminating network rather than the original assignment network.
What does a typical MVNO SBC deployment look like in production?
A pair of ProSBC instances configured in 1+1 high availability sits at the border between the MVNO’s IMS core and external networks. Ttrans gateways are deployed inline for AMR transcoding to and from G.711 on the wholesale carrier side. Routing logic is configured per wholesale carrier with least-cost routing, fraud screening, and MNP lookups inline. CDRs export to the MVNO’s billing system. For MVNE platforms, each MVNO brand is mapped to its own Network Access Point on the ProSBC for tenant isolation, per-tenant routing rules, and per-tenant billing accuracy. The same architecture scales from a few hundred concurrent sessions at launch to tens of thousands without re-platforming.
Evaluate ProSBC for Your MVNO
ProSBC Lab is free, sets up in roughly 20 minutes on KVM or Proxmox, and lets you validate SIP termination and routing against your real wholesale carriers before any commitment. When AMR transcoding becomes a production requirement, the Ttrans conversation comes next.