Bandwidth.com SBC Integration: How to Connect a Session Border Controller to Bandwidth SIP Trunks

Bandwidth.com is one of the largest SIP trunking and CPaaS providers in North America. If you are an MSP, contact center, ISP, or enterprise terminating Bandwidth voice traffic into your network, the SIP trunking integration looks simple on paper: point your trunk at the carrier IPs and start sending calls. In practice, Bandwidth has specific transport, packet-size, and redundancy requirements that have to match exactly on the customer side, or calls fail to set up at the SIP layer with no obvious error.
A Session Border Controller (SBC) is what makes the integration work. The SBC sits at the boundary between Bandwidth’s network and your downstream PBX, contact center, or UC platform, normalizing SIP, anchoring media, and enforcing security policy on every call. This article covers what Bandwidth.com requires from your SBC, why each requirement exists, how to configure each one, and what to plan for around STIR/SHAKEN attestation and fraud at the edge. Built on over 20 years of SIP deployment experience, modern software-based SBCs handle this role on commodity virtual or cloud infrastructure.

Why You Need an SBC for Bandwidth.com SIP Trunking

Bandwidth.com terminates customer-side traffic at a pair of carrier SBCs. Both IPs are active for signaling and media: calls can arrive from either one, and outbound calls go to either one. That dual-SBC pattern is built for redundancy, but it pushes complexity onto the customer side. Every downstream system has to know about both Bandwidth IPs, has to whitelist them, and has to handle clean failover when one of them goes quiet.
A customer-side SBC absorbs that complexity. It presents a single, controlled interconnection point upstream to Bandwidth, normalizes SIP on every call as defined in RFC 3261, anchors media so quality and recording policy are enforced at one place, hides internal topology from the carrier, and blocks fraud and DoS traffic before it reaches your telephony core.
Without an SBC, your PBX, contact center, or UC platform absorbs Bandwidth’s SIP dialect directly and sits exposed to public-internet traffic. One malformed REGISTER probe or one toll-fraud campaign reaches all the way into your switch.

Bandwidth.com Transport and Network Requirements

Bandwidth.com publishes specific network and protocol rules for any SBC integrating with their SIP trunks. These are non-negotiable: traffic that does not match will fail.

UDP-only transport

Bandwidth requires SIP signaling and audio over UDP. TCP is not supported on the standard SIP trunk product, and TLS is not the default transport for the trunk side. Your SBC has to terminate UDP/5060 on its Bandwidth-facing trunk group regardless of what transport you use downstream.

Maximum SIP message size of 1,350 bytes

SIP messages, particularly INVITEs with long header chains, large SDP bodies, or carrier-injected metadata, can exceed this limit and get fragmented or dropped. The SBC has to manage outbound message size: strip unnecessary P-headers, keep SDP compact, and remove proprietary extensions before the message hits the wire.

RFC 3261 conformance

Bandwidth’s stack rejects non-standard SIP behavior. Custom proprietary headers, malformed Via or Record-Route entries, or non-RFC method handling will cause INVITEs to fail. The SBC’s header manipulation engine has to enforce a clean, standards-compliant message profile on the Bandwidth-facing leg.

Dual-SBC redundancy

Bandwidth provides two SBC IPs for signaling redundancy. Both must be configured for inbound and outbound traffic on the customer side. The SBC’s trunk group should treat the pair as a primary/secondary route or as a load-balanced pair, never as a single endpoint with a single IP.

Configuring the SBC: Step-by-Step

The exact menus differ between SBC vendors, but the integration logic is the same on any RFC-3261-conformant SBC.

1. Add Bandwidth’s two SBC IPs as a paired upstream destinationMost SBCs call this a Network Access Point (NAP), trunk group, or peer entry. Create one NAP per Bandwidth SBC.
2. Set transport to UDP on port 5060Configure both peer entries with UDP transport on port 5060. Do not enable TLS or TCP on the Bandwidth-facing leg.
3. Cap outbound SIP message size below 1,350 bytesUse the SBC’s SIP header manipulation rules to strip P-headers, custom extensions, and any field your downstream stack injects that Bandwidth will not accept.
4. Configure the dial plan as E.164Use a leading + on every called and calling number, end-to-end. Inbound caller ID and outbound called number both have to be in E.164 format, as defined in ITU-T E.164.
5. Set route ordering for failoverConfigure primary and secondary, or active/active, so the SBC moves traffic to the second IP automatically when the first stops responding.
6. Enable SIP OPTIONS heartbeatsThe SBC continuously verifies reachability of both Bandwidth SBCs and triggers route advance the moment one stops responding.

Codecs and Media

Bandwidth supports standard PSTN codecs. G.711 µ-law and A-law are universally available, and G.729 is supported in some regions. Confirm the exact codec list against the latest Bandwidth integration guide for your service.
The SBC negotiates codec on each leg through the Session Description Protocol (SDP). Mismatched codec offers between Bandwidth and your downstream system will trigger transcoding on the SBC, or, if transcoding is not configured, call rejection at SDP negotiation.
Media anchoring at the SBC is the right default. Terminating RTP at the SBC keeps quality measurement, encryption boundary, and recording policy all enforced at one point. It also lets the SBC bridge transport security: for example, unencrypted UDP toward Bandwidth on the carrier leg, SRTP toward Microsoft Teams or a UCaaS platform on the customer leg, with the SBC handling key exchange independently on each side.
If your downstream stack uses non-G.711 codecs (Opus for WebRTC, AMR for mobile clients), plan transcoding capacity accordingly. Software transcoding for Opus and AMR is not available on every SBC platform and may require hardware transcoding support.

Security: What the SBC Has to Do at the Bandwidth Edge

A SIP trunk reachable on the public internet is a target. The SBC is the layered defense between Bandwidth’s network and your telephony core.

IP whitelisting

Restrict inbound SIP from Bandwidth’s two SBC IPs only and drop everything else at the SBC. Most SBCs implement this through dynamic access control lists tied to the trunk group definition.

DoS and DDoS protection

Public-facing SIP infrastructure attracts SIP scanning, registration floods, and volumetric signaling attacks. The SBC needs SIP-aware rate limiting per source IP and per trunk group, plus automatic detection and blocking of registration scan patterns. Generic network firewalls do not see SIP-layer behavior; SBC-layer protection is required.

Topology hiding

Strip private IP addresses from Contact, Via, and Record-Route headers on every outbound message to Bandwidth. The carrier should never see internal addressing, and your internal systems should never see Bandwidth’s upstream infrastructure.

Toll fraud detection

This is where the SBC earns its keep financially. International premium-rate dialing is the largest billing-exposure risk on any SIP trunk: a compromised SIP endpoint or a credential-stuffed SIP REGISTER can generate tens of thousands of dollars of fraudulent traffic in hours. Per-call risk scoring, considering destination prefix, call rate, time of day, and calling pattern, catches anomalies before they reach the trunk. Validated fraud-detection partners like TransNexus and YouMail integrate with the SBC over standard APIs.

STIR/SHAKEN Attestation and Bandwidth.com

Bandwidth.com is a STIR/SHAKEN signing provider for North American customers. As an originating service provider, they sign outbound calls with PASSporT identity tokens and attestation levels (A, B, or C) based on their direct knowledge of the calling party, in line with the FCC call authentication framework.
Customers who deliver calls to Bandwidth without their own direct relationship with the calling number receive a lower attestation than they might expect. Attestation policy has tightened over the past year, and a downgrade from A to C has direct revenue impact: lower answer rates, more “Spam Likely” labels, and reduced trust scoring at terminating carriers.
The customer-side SBC’s role in STIR/SHAKEN is not to sign. Bandwidth does the signing as the originating service provider. The SBC’s job is to populate accurate calling-party identity headers (P-Asserted-Identity, From) so that Bandwidth has the correct information to base attestation on, and to preserve any Identity header on calls that already carry one. Stripping or rewriting identity information at the SBC will silently degrade attestation outcomes.

Monitoring, CDRs, and Troubleshooting

Bandwidth provides Call Detail Records through their portal. Reconcile those CDRs against the customer-side SBC’s own CDR output to validate billing. Discrepancies between the two are the fastest signal that something is being routed or counted differently than expected.
The SBC should expose live SIP trace and Wireshark-style packet capture for trunk-level signaling debugging. The vast majority of “calls fail intermittently” tickets come down to a specific SIP message that one side is rejecting, and the only way to find it is to look at the wire.
MOS scoring on the SBC catches one-way audio, jitter, and codec-mismatch issues before they show up in user complaints. Dynamic dashboards and threshold-based alerts, available through products like Monitoring as a Service, are standard requirements for any production deployment.

Frequently Asked Questions

Conclusion

Bandwidth.com is a high-quality, large-scale SIP trunking and CPaaS provider, and the integration is achievable on any modern SBC. But the integration is specific. UDP transport, the 1,350-byte SIP message ceiling, RFC 3261 conformance, and dual-SBC IP redundancy all have to be configured correctly on the customer side. Layer in topology hiding, IP whitelisting, DoS protection, fraud scoring at the edge, and an awareness of how STIR/SHAKEN attestation flows through Bandwidth as the originating service provider, and you have a production-ready integration.
When evaluating an SBC for a Bandwidth.com deployment, the key factors are full B2BUA architecture, configurable per-trunk-group SIP header manipulation, comprehensive SIP-layer security, and the quality of debugging and monitoring tools that let you diagnose and tune the integration under production load.