SIP Fundamentals

SIP Authentication (Digest vs IP-ACL vs mTLS)

SIP authentication is how a server proves a SIP request really comes from an authorized client. Digest authentication (RFC 8760, formerly RFC 2617/7616) is the SIP standard, but real-world deployments mix it with IP allow-lists, mTLS, and bearer tokens. Picking the right method dramatically changes your security posture and operational complexity.

The four methods you will actually encounter

Method	What it proves	Where it lives	NAT-friendly
Digest auth	Caller knows a shared secret	Authorization SIP header	Yes
IP ACL	Caller is sending from a trusted IP	Network layer / SBC	No (needs static public IP)
SIP over TLS + mTLS	Caller has a valid client cert	TLS handshake	Yes (over TCP)
Bearer token (OAuth)	Caller has a valid JWT/OAuth token	Authorization: Bearer header	Yes

Digest auth: how it actually works

Digest auth is a challenge-response handshake. The client never sends the password — it sends a hash that proves it knows the password.

1. Client sends REGISTER (or INVITE) without auth.
2. Server replies 401 Unauthorized with WWW-Authenticate: realm, nonce, qop, algorithm.
3. Client computes response = H(H(user:realm:pass) : nonce : nc : cnonce : qop : H(method:uri)).
4. Client retries with Authorization header containing the response hash.
5. Server independently computes the same hash. Match → 200 OK. Mismatch → 403 Forbidden.

Digest auth wire example

# Step 1 — client sends REGISTER, no auth
REGISTER sip:sip.didhub.io SIP/2.0
From: <sip:[email protected]>
To:   <sip:[email protected]>
CSeq: 1 REGISTER

# Step 2 — server challenges
SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest realm="sip.didhub.io",
  nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
  qop="auth", algorithm=SHA-256

# Step 3 — client computes response and retries
REGISTER sip:sip.didhub.io SIP/2.0
CSeq: 2 REGISTER
Authorization: Digest username="trunk_x", realm="sip.didhub.io",
  nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
  uri="sip:sip.didhub.io",
  algorithm=SHA-256, qop=auth, nc=00000001,
  cnonce="0a4f113b",
  response="6629fae49393a05397450978507c4ef1..."

# Step 4 — server verifies, accepts
SIP/2.0 200 OK

MD5 vs SHA-256 (and why it matters)

RFC 2617 (the original digest spec) used MD5. RFC 7616 added SHA-256 and SHA-512/256. RFC 8760 deprecated MD5 entirely in 2020.

Practical reality: most SIP stacks still default to MD5 for backwards compatibility. MD5 digest auth is broken against modern attackers — pre-computed rainbow tables crack the realm/user/pass hash in milliseconds. If your endpoint supports SHA-256, force it. DIDHub trunks accept both but log MD5 use as a soft warning.

IP ACL: simpler and often safer

IP ACL skips digest entirely — the server accepts SIP from a pre-registered list of source IPs. No password is exchanged.

Pros:

• No registration overhead (no REGISTER traffic, no nonce churn).
• No password to leak. The 'secret' is your IP allocation, which is harder to steal than a password.
• Far simpler to debug — either the IP matches or it doesn't.

Cons:

• Requires a static public IP. Useless behind dynamic IP / NAT without VPN.
• If your server is compromised, an attacker can spoof SIP from the trusted IP.

Recommended for cloud deployments and dedicated servers. Most carrier SBCs support both digest and IP ACL on the same trunk simultaneously, so dynamic-IP fallback is one click away.

SIP-TLS + mTLS

SIP-over-TLS encrypts the signaling. Mutual TLS (mTLS) adds client-cert authentication on top — the client presents a cert during the TLS handshake, and the server verifies it against a CA bundle.

# Asterisk pjsip TLS + mTLS
[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
cert_file=/etc/asterisk/keys/asterisk.crt
priv_key_file=/etc/asterisk/keys/asterisk.key
ca_list_file=/etc/asterisk/keys/ca-bundle.crt
verify_client=yes        # <-- this enables mTLS
require_client_cert=yes

Pros: strongest possible auth + encryption. No nonce churn. Cert revocation is centralized.

Cons: cert lifecycle management is heavier than rotating a password. Most SIP phones do not support client-certs natively.

Recommended for enterprise SBC-to-SBC interconnects. Overkill for most PBX trunks.

Bearer token / OAuth (the AI-voice frontier)

Newer SIP APIs (Vapi, Retell, LiveKit) accept JWT bearer tokens in the SIP Authorization header instead of digest hashes. The token is short-lived (typically 5-15 min), scoped (call create, no admin), and minted by your own backend.

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Pros: short token TTL means a leaked token expires fast. Per-call scope possible. No long-lived password to rotate.

Cons: not interoperable with classic SIP phones. Mostly limited to API-driven SIP services.

Which to use when

Scenario	Recommended auth	Why
Cloud PBX with static public IP	IP ACL	Simpler, no password to leak, no REGISTER chatter
On-prem PBX with dynamic IP / NAT	Digest (SHA-256)	Works through any NAT
SIP phones / softphones	Digest	Universal support
Enterprise SBC interconnect	SIP-TLS + mTLS	Strongest, encrypted, enterprise-grade
AI voice agents calling out	Bearer token	Short-lived, per-call scope
WebRTC softphone in browser	Digest over WSS	WebSocket carries digest auth fine

Hardening checklist

• Force SHA-256 (drop MD5) on any digest realm you operate.
• Use IP ACL whenever you have a static public IP — layer on digest as defense-in-depth.
• Rotate digest passwords on a schedule (90 days). Long, random, generated — not human-typed.
• Rate-limit failed auth: 5 fails in 60 seconds → 24-hour IP block. Stops credential-stuffing.
• Monitor 401/403 rates — sudden spikes mean a brute-force attempt is in progress.
• For high-value trunks, run TLS-only (drop UDP/TCP entirely) on port 5061.

References

• RFC 8760 — SIP Digest Access Authentication (modern)
• RFC 7616 — HTTP Digest with SHA-256
• RFC 3261 — SIP base spec, section 22 (Auth)
• RFC 5246 — TLS 1.2 (still common for SIP-TLS)

Related terms