SIP Interoperability

This page describes the VSS platform’s signalling behavior from the outside: what a SIP device, customer PBX, or carrier SBC needs to be configured with, and what it can expect from us on the wire. It is the page to hand to a vendor’s interop team.

The network at a glance

Traffic	Where	Protocol
SIP signalling (both directions)	Your service IP, port 5060	UDP
RTP media (both directions)	The platform’s media addresses, ports 10000–20000	UDP

Two things follow from that table:

All signalling — inbound and outbound — uses one IP per tenant. Calls you send us target it; calls we send you come from it; registrations, subscriptions, and keepalives all terminate on it. One firewall rule, one allowlist entry at your carrier.
Media does not flow through the signalling IP. RTP runs directly between your endpoint and the media server handling the call, in the 10000–20000 UDP range (see the IP ranges page). If SIP works but audio is silent or one-way, this split is almost always why.

One IP, many sites — why you don’t get a backup IP

The service IP is an anycast address: it is announced over BGP from multiple sites at once, and each announcement is gated by a live health check. The internet’s own routing then delivers your packets to the nearest site that is currently healthy.

Site or node failure: the failed site’s announcement is withdrawn and the network reconverges onto the surviving sites — same IP, new location, typically within seconds. There is nothing to fail over to on your side: no secondary IP, no SRV priority list, no DNS TTL to wait out.
Within a site, several proxy nodes share the address behind equal-cost multipath (ECMP) routing, so load spreads across them and a single node failing removes only that node.
Established calls survive re-routing. The signalling layer is deliberately stateless for in-dialog traffic — any node at any site can correctly forward a mid-call request — and media runs to the media servers directly, unaffected by edge re-routing. The rare casualty is a call in the middle of setup on the exact failing node; a retry goes through the new path.

So the answer to “why don’t I have multiple IPs?” is: the redundancy you would build with a second IP is already built into the one IP, below the SIP layer, with faster failover than SRV/DNS schemes and no client configuration at all. Configure exactly one IP everywhere.

Devices (registration)

Devices register to the service IP with digest authentication (MD5, qop=auth — the standard scheme every SIP phone implements):

Setting	Value
Registrar / outbound proxy	Your service IP, UDP 5060
Auth username	The device name (e.g. `alice-desk`)
Realm / SIP domain	Your namespace’s `sip-realm`
Password	Minted via the platform — see Device Credentials

Registration behavior to expect:

Expiry: requested intervals are honored up to a maximum of 3600 seconds; longer requests are shortened. Anything from a few minutes up works — phone defaults (typically 300–3600 s) are fine.
Contacts: up to 10 simultaneous bindings per address-of-record.
Challenges: REGISTER is challenged against the To-header domain, calls against the From-header domain — both must carry your sip-realm, which is why the realm/domain field on the phone must be the realm, not the IP.
Registrations from unknown users or wrong passwords are re-challenged identically — a misconfigured phone sees an endless 401 loop, not a distinguishable error.

NAT

Devices behind NAT work without special configuration:

The platform enforces symmetric signalling (rport) and rewrites registered contacts based on the address a registration actually came from.
NATed registrations are pinged every 30 seconds with SIP keepalives to hold the NAT binding open; phone-side keepalives are harmless but not required.
Inbound calls to a NATed device are routed to the observed public address, not the private Contact.

The one thing to configure: disable any “SIP ALG” on the customer’s router or firewall. ALGs rewrite SIP payloads mid-flight and are the leading cause of registrations that work for a minute and then break, or calls with no audio.

IP trunks (customer PBXes and carriers)

A trunk peer is identified by source IP address — no registration, no digest. Two facts make up a trunk’s identity: the IP it sends from, and the service IP it targets. Both must match the trunk’s configuration, so one organization’s credentials can’t be replayed against another tenant’s IP.

Inbound to us: send INVITEs to the service IP from your configured signalling address(es). Expect a 100 Trying from the service IP immediately (well inside SIP’s 500 ms retransmit timer), followed by end-state responses relayed from call processing. A source IP we don’t recognize falls back to a digest challenge — a trunk suddenly getting 401s means its source address doesn’t match what’s configured.
Outbound from us: calls arrive at your systems from the same service IP your traffic targets. Allowlist that one IP for both directions; there are no other signalling sources to permit.
Keepalives: you may probe the service IP with OPTIONS (empty user part) at any rate reasonable for monitoring; it answers 200 directly from the edge. The platform does not send OPTIONS probes to vendor systems.

Session timers

Every INVITE we send offers RFC 4028 session timers: Session-Expires: 1800;refresher=uac, Min-SE: 90, Supported: timer. Endpoints that support them will refresh the session every ~15 minutes, letting both sides detect and clear dead calls (power loss, NAT expiry, networks that never deliver a BYE). Endpoints that don’t support RFC 4028 simply ignore the headers — calls work either way — but enabling session timers on your PBX/SBC is recommended: it is the mechanism that prevents stuck “forever” calls from accruing.

Standard proxy behavior otherwise applies: we Record-Route, so in-dialog requests must follow the received route set (every compliant stack does this automatically), and requests need a sane Max-Forwards.

Codecs, DTMF, and fax

Codec policy is per line/trunk profile, enforced in signalling: the SDP offer is filtered to the profile’s permitted set before it reaches call processing, and mid-call renegotiations (re-INVITE/UPDATE) are filtered against the same set — a call can’t escape its codec policy mid-dialog.

An offer containing no permitted codec is rejected with 488 Not Acceptable Here — the platform will not silently transcode around a policy mismatch at the edge. Offer at least one codec from your profile (your operator will tell you the set; G.711 µ-law/A-law is the safe baseline).
Video streams are stripped unless the profile explicitly permits video codecs.
DTMF is RFC 4733/2833 telephone-event, which is always preserved regardless of codec policy. Configure phones and trunks for RFC 2833-style DTMF, not SIP INFO or in-band.
T.38 fax re-invites pass through signalling untouched by codec policy.

Presence, BLF, and message-waiting

The same service IP accepts SUBSCRIBE for presence (presence, PIDF), busy-lamp-field (dialog), and message-waiting (message-summary — MWI) event packages, plus PUBLISH. Subscriptions authenticate with the same digest credentials as registration; accepted expiries range 30 s to 7200 s. Configure BLF keys and MWI against the same realm and credentials as the device’s registration.

What you’ll see from us

Server / User-Agent on everything the platform sends is the product identity: Cordboard VSS
Caller identity: outbound calls carry the configured caller ID; calls from subscribers with caller-ID blocking arrive as Anonymous with Privacy: id, with the network-use identity in P-Asserted-Identity. Forwarded calls carry the original caller’s ID plus a Diversion header naming the forwarding party.
STIR/SHAKEN: Identity headers (RFC 8224) you send us are preserved and verified; outbound calls carry an Identity PASSporT when the trunk’s signing policy calls for it.

Protective behaviors worth knowing

These are deliberate and occasionally surprising during interop testing:

Scanner traffic is silently dropped. Requests whose User-Agent matches common scanning tools (sipvicious, friendly-scanner, sipcli, …) get no response at all. If your test tool inherits such a UA string, it will look like a dead network.
Per-source-IP flood protection. A single IP sustaining thousands of requests per second is banned for ~5 minutes (silently — packets are dropped, not rejected). The threshold is far above legitimate bursts (roughly 1000 calls-per-second per source IP), so only genuine floods or runaway retransmit storms trip it.
Malformed SIP is dropped, and out-of-dialog methods other than REGISTER, INVITE, OPTIONS, CANCEL, and the presence methods answer 405 Method Not Allowed.

Interop troubleshooting

Symptom	Likely cause	Check
Endless `401` on REGISTER	Wrong password, or realm/domain field isn’t the `sip-realm`	Phone’s auth user = device name, domain = realm; re-mint the credential if in doubt
Trunk INVITEs suddenly challenged with `401`	Source IP doesn’t match the trunk’s configured address	NAT or egress change on your side; the trunk identity is (source IP → service IP)
`488 Not Acceptable Here`	No offered codec is permitted by the profile	Offer G.711 or the profile’s codec set
Calls set up, audio silent / one-way	RTP blocked — media doesn’t use the signalling IP	Open UDP 10000–20000 to/from the media addresses; disable SIP ALG
Registration works, then breaks after ~1 minute	SIP ALG rewriting packets	Disable the ALG on the router/firewall
Everything stops responding for ~5 minutes	Flood ban tripped (retransmit storm, load test from one IP)	Back off; spread test load across source IPs
Long-idle calls die at ~15–30 min	One side dropped its NAT/session state	Enable RFC 4028 session timers on your equipment
`480 Temporarily Unavailable` on a call to a subscriber	The target device isn’t registered	Check the device’s registration state