OpenSIPS in front of VICIdial: registration and dialog ownership

Choose one registration owner

Fast answer: decide whether OpenSIPS or Asterisk owns carrier registration. OpenSIPS can act as an SBC (session border controller); when a carrier requires digest authentication continuity and strict Via-header hiding, that SBC may need to own each SIP REGISTER request and its authentication state.

Some SIP vocabulary this article leans on throughout. SIP messages set up and tear down calls: REGISTER tells the server where a phone currently is, INVITE starts a call and BYE ends it. A dialog is the relationship between the two ends for one call, lasting from the INVITE through the BYE. Record-Route is a header a proxy adds to keep itself in the path for the rest of that dialog instead of dropping out once setup finishes. Digest authentication is the challenge-response method SIP uses to prove a password without sending it in the clear. Topology hiding means rewriting messages so the outside world cannot see your internal addresses. An SBC is the device doing all of this at the edge of your network, which here is OpenSIPS.

Do not leave both systems registering the same account. Alternating contacts create intermittent inbound routing and misleading carrier dashboards.

A concrete case for choosing OpenSIPS as the owner: a carrier that issues one trunk per DID rather than one shared trunk, where you want a single point registering every one of those accounts and presenting one consistent identity outward, instead of configuring dozens of separate registrations directly on Asterisk. Another: fronting more than one Asterisk server behind one carrier-facing identity, where the carrier should see one signaling peer no matter which VICIdial server actually answers. Neither case is the default — most VICIdial deployments register directly with a carrier and never need this layer at all — so treat an SBC as a deliberate answer to one of these specific needs, not a default hardening step.

See vicidial-terminology-for-complete-beginners for the rest of this glossary.

Draw the ownership map before configuration

A beginner-friendly design names one owner for registration, one next hop for inbound dialogs and one next hop for outbound dialogs. It also says whether media stays direct or passes through an approved relay; signaling and media are different paths.

The media-path line matters as much as the signaling lines above it, and it is the one most designs skip. If OpenSIPS relays media, every call's audio depends on a second process staying healthy alongside the signaling path, and a NAT'd agent or carrier leg can produce one-way audio that has nothing to do with registration at all. If media stays direct between the carrier and Asterisk, OpenSIPS never touches the audio and cannot be the cause of a one-way-audio report, no matter how tempting it is to suspect the newest thing added to the path. Decide which model you are building before the first test call, not while debugging the first one that sounds wrong.

Complete the worksheet with role names, not deployed addresses or credentials. REGISTER owner must have exactly one value, and the rollback route must already be known.

REGISTER owner: OpenSIPS or Asterisk (choose one)Inbound next hop: approved VICIdial/Asterisk roleOutbound next hop: approved carrier roleDialog state owner: OpenSIPS or AsteriskMedia path: direct or approved relayRollback route: prior reviewed signaling path

Preserve dialog and transaction state

Record-route dialog-forming requests, keep transaction handling explicit and apply topology hiding consistently to requests and replies. Stateless forwarding is not enough for mid-dialog routing.

Skipping Record-Route is the single most common way this design breaks in a way that looks fine at first. Without it, OpenSIPS forwards the initial INVITE, and the call appears to set up normally, but every later in-dialog request — a re-INVITE for hold or resume, and critically, the BYE that ends the call — is addressed straight between the carrier and Asterisk's own Contact header, bypassing OpenSIPS entirely. The symptom is calls that connect fine and then never show a clean hangup where you are watching for one, not a call that fails to set up at all — which is exactly why it is easy to miss in a quick test and only shows up once a real call runs its full length.

Validate advertised addresses, Contact rewriting and media policy from outside the private network, starting from the Asterisk side you already have read-only access to.

asterisk -rx 'pjsip show transports'ss -lnup | grep asterisk

Test a complete signaling matrix

Exercise inbound and outbound calls with answer, reject, cancel, transfer and long-duration hangup paths. Check that BYE traverses the same dialog route and that carrier and Asterisk see the expected identities.

Registration state, a successful OPTIONS response and one test call are separate checks. Require all of them before declaring the SBC ready.

• Inbound and outbound calls both answer, and both hang up cleanly from either side.
• A call placed on hold and resumed keeps its audio path and its dialog route intact.
• A rejected or cancelled call tears down without leaving a registration or dialog behind.
• DTMF sent mid-call reaches the far end unchanged, not just the initial signaling.

Reverse the route without leaving two owners

Stop expansion on registration flapping, one-way dialog routing, missing BYE, unexpected identity rewriting or media loss. Drain only the controlled test dialogs, then restore the prior reviewed next hop and single registration owner.

After rollback, verify that OpenSIPS and Asterisk do not both retain registration attempts and that a fresh synthetic call completes on the old path. Preserve only sanitized response classes, timings and configuration hashes.

Soak a change longer than one test call proves out before calling it stable. Registration flapping and missing-BYE symptoms both tend to appear intermittently under real traffic patterns rather than on every single call, so a route that passed the test matrix once still deserves a monitored period — watching registration re-attempt counts and completed-versus-abandoned call ratios specifically — before you consider the prior route's rollback plan no longer needed.

• Return REGISTER ownership to the documented prior component.
• Confirm no controlled dialog remains on the abandoned route.
• Re-run inbound, outbound, cancel and hangup checks after reversal.