A session border controller (SBC) is the checkpoint where your phone system meets an outside voice network: a carrier's SIP trunk, Microsoft Teams or another site. It decides which calls may cross, translates between systems that speak slightly different SIP, and protects the phone system from being reached directly. It can be an appliance or software.
An SBC sits at the edge of your voice network, in the same place a firewall sits at the edge of your data network. Every call that enters or leaves passes through it. On the way, it checks the call is one it should accept, rewrites whatever the other side needs to see, and carries the voice across.
The IETF, which wrote SIP, describes SBCs in RFC 5853 as SIP intermediaries deployed at network borders, and documents the functions operators rely on them for. Technically an SBC is a back-to-back user agent: it ends the call on one side and starts a new one on the other, as RFC 7092 sets out. That is the key to everything else it does. Because it is a party to both calls, it can change anything about them.
If you have just been told you need one, the reason is almost always one of three: you are connecting Microsoft Teams to the phone network, you are connecting a phone system to a carrier SIP trunk that does not quite match it, or someone wants the phone system off the public edge of the network.
A phone system that faces a carrier or the internet directly is a target. Attackers scan for SIP services, try passwords against extensions and, if one works, place calls to premium international numbers at the owner's expense. The GSMA's guidance on SIP security describes these attacks as an operator-level problem, not only an enterprise one.
The SBC changes the exposure. The outside world sees the SBC, never the PBX. It accepts signalling only from the peers it is configured for, such as your carrier or Microsoft, drops malformed requests, and can cap the number of simultaneous calls or calls per second so a compromised account cannot run up an unlimited bill.
NIST SP 800-58, older but still the standard US government reference on VoIP security, makes the underlying point: VoIP needs controls designed for voice traffic, because generic data controls either block calls or let too much through.
SIP is a standard, defined in RFC 3261, but vendors implement it with small differences. One expects the caller's number in one header, another in a different one. One sends numbers in international format, the other in local format. One holds a call by signalling "inactive", the other by "send only".
Each difference is minor. Any one of them can still break caller ID, transfers or hold music. Microsoft documents its own deviations from the SIP RFCs for Direct Routing, including hold handling, which is exactly the kind of detail an SBC absorbs.
This is the job that makes an SBC useful well beyond security. It is where number formats are normalised, where headers are rewritten, and where you fix the one problem that only appears with one carrier and one PBX together, without changing either.
Signalling sets a call up; the voice travels separately as media packets. Media is where networks cause trouble. Address translation on a firewall hides the real address the voice should go to, so calls connect and then carry silence in one or both directions.
The SBC solves this by anchoring the media: both sides send voice to the SBC, which relays it. Because it handles the media, it can also:
RFC 3711, on the Teams side of the call, while many carrier trunks deliver unencrypted RTP. The SBC converts between them.
in processing capacity.
media bypass lets voice flow between a Teams client and the SBC directly instead of through Microsoft's media processors, which keeps calls between an office and its local trunk inside the country.
Because every call crosses it, the SBC is a natural place to decide where calls go. Routing by number, by time or by which link is up; sending emergency calls to a specific trunk; failing over to a second carrier when the first stops answering. A phone system can do some of this, but the SBC sees all the systems it connects, not only one.
You need one for Microsoft Teams Direct Routing. Microsoft's protocol documentation describes the SBC as the component that talks to its SIP proxy over TLS and its media processors over SRTP, and only devices on its certified SBC list are supported. We explain where that fits among the four ways Teams reaches the phone network.
You probably want one when a phone system connects to more than one outside network, when the PBX should not be reachable from the carrier side, or when interoperability problems are already costing time.
You may not need one when a cloud phone system or a modern IP PBX connects to a carrier trunk it is tested with, on a link the carrier manages. Many do this reliably. If you are still deciding on the trunk itself, start with what a SIP trunk is and how one is bought here.
SBCs come as appliances and as software, and Microsoft certifies both. The trade-off is practical rather than technical.
An appliance suits a site that wants a dedicated box, and often adds analogue or ISDN ports for fax lines, door phones or a legacy PBX during migration. Ribbon is the typical choice where that matters. Software, such as anynode, runs on a virtual machine or a server you already have, and makes a second instance for resilience a licence and a VM rather than another appliance. Our page on SBC platforms we deploy in the UAE compares the options in more detail.
Whichever you choose, size it on simultaneous calls, not users, and count transcoded and encrypted calls separately, because they consume more capacity than calls that are simply relayed.
Two local facts shape SBC design here.
First, the trunk on the other side comes from a licensed operator. TDRA's FAQs treat VoIP as a telecommunications service and name e& and du as the telecommunications licensees. Your SBC therefore talks to an e& or du trunk, and its configuration follows that carrier's requirements for number format, codecs and how the trunk is delivered. du's Business SIP Trunk page also makes clear that du supplies the trunk and the numbers but not the phone system, so everything from the SBC inward is the customer's responsibility.
Second, Microsoft Calling Plans are not sold in the UAE, so Direct Routing is the usual way to give Teams users a UAE number. That makes the SBC a standard component of most Teams voice projects here, not an exotic one, and it makes certificate renewal, firmware updates and failover testing ordinary operational tasks to plan for.
For businesses with offices across the GCC, the same logic applies country by country: a local trunk in each market, and an SBC design that keeps each country's calls on its own trunk.
| Network firewall | PBX | Session border controller | |
|---|---|---|---|
| Main job | Allow or block traffic by address and port | Run extensions, queues and call features | Control voice sessions crossing a network boundary |
| Understands SIP calls | Little or not at all | Yes, for its own users | Yes, for every call crossing the border |
| Handles voice media | Opens ports for it | Terminates it for its users | Relays, encrypts or transcodes it |
| Fixes vendor SIP differences | No | Within its own trunk settings | Yes, through header and number rules |
| Required for Teams Direct Routing | No | No | Yes, from Microsoft's certified list |
No. A firewall decides which packets may pass. An SBC understands each call, so it can reject a malformed or unexpected call, fix how numbers are presented, and keep the voice path working through address translation. Most deployments use both.
Not always. Many IP PBXs and cloud platforms connect to a carrier trunk directly. You need one when the two sides cannot interoperate as they are, when the phone system should not face the carrier network directly, or when the platform requires it.
Direct Routing connects your own carrier trunk to Microsoft's cloud, and Microsoft only accepts that connection from a certified SBC using TLS for signalling and SRTP for media. In the UAE, where Direct Routing is the normal way to connect Teams to the phone network, that makes an SBC part of almost every Teams calling project.
Both are certified for Teams and both are common. Hardware suits a site that wants a dedicated appliance and analogue or ISDN ports. Software suits virtualised or cloud infrastructure, and makes a second instance for resilience easier to add.
Calls through it stop, so plan for it. A second SBC, a failover route at the carrier, or both are the normal designs. Test the failure before go-live, because the symptom users notice is a number that simply rings out.
Phone: +971 4 439 5754 | WhatsApp: +971 4 542 3229
Get a Free Consultation