SIP Fundamentals

IPv4 vs IPv6 in SIP / VoIP

SIP and RTP both run over IP, so IPv4 vs IPv6 is a real deployment choice — not a corner case. SIP carries IP addresses inside its message bodies (Via, Contact, SDP c= line), so IP-version mismatches between endpoints break calls in subtle ways. This is the IP-layer side of running production VoIP in 2026.

Where IP version shows up in SIP

A single SIP call references IP addresses in at least four places. All four must agree on family (IPv4 or IPv6) end-to-end — or a translating SBC has to bridge between them.

Where	Field	Family must match
SIP routing	Via: hop list	Each hop transport
SIP contact	Contact: URI	Endpoint family
SDP connection	c=IN IP4 ... or c=IN IP6 ...	Media path
SDP media address	per-stream override	Media path

SDP example with IPv6

v=0
o=- 12345 1 IN IP6 2606:4700::1
s=-
c=IN IP6 2606:4700::1                  # IPv6 connection line
t=0 0
m=audio 16384 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000

Note IP6 instead of IP4 after IN. Endpoints that don't speak IPv6 will reject this SDP with 488 Not Acceptable Here or, worse, accept it and silently drop RTP because they can't reach the address.

Realistic dual-stack scenarios

1. Customer PBX is IPv4-only, carrier is dual-stack: works fine if the carrier's SIP FQDN resolves AAAA + A and the carrier's SBC negotiates per-leg. DIDHub trunks default to this.
2. Both ends are IPv6-only: works only if every hop in between is IPv6-clean. Many corporate firewalls and home routers still drop IPv6 SIP. Test before you commit.
3. One end IPv4-only, other end IPv6-only: needs a translating SBC. SIP-ALG style NAT64/DNS64 alone is not enough — SDP rewriting is required.
4. WebRTC clients on mobile networks: increasingly arrive over IPv6 (T-Mobile US, Reliance Jio, most German + French carriers). The SBC must accept IPv6 candidates from ICE.

Common breakage patterns

• Half-IPv6 SIP, IPv4 RTP: caller and callee speak SIP over IPv6 but advertise IPv4 in c=. Result: silence, calls connect with no audio. Fix: align transport at the transport layer.
• DNS preference flip: a stack that prefers AAAA over A will suddenly pick IPv6 after a routine OS upgrade. If your firewall has IPv6 rules that drop SIP, calls die. Check both stacks.
• STUN/TURN single-stack: a STUN server with only an IPv4 address can't help an IPv6-only client discover its public address. Use dual-stack STUN/TURN.
• SBC vendor quirks: Sangoma SBC ignores IPv6 candidates by default; Avaya SBCE prior to 8.x doesn't speak IPv6 at all. Check release notes.

Configuration: Asterisk pjsip dual-stack

[transport-udp-v4]
type=transport
protocol=udp
bind=0.0.0.0:5060

[transport-udp-v6]
type=transport
protocol=udp
bind=[::]:5060

[transport-tls-v4]
type=transport
protocol=tls
bind=0.0.0.0:5061

[transport-tls-v6]
type=transport
protocol=tls
bind=[::]:5061

pjsip will pick the transport whose family matches the destination. Endpoints with both A and AAAA records get whichever is preferred by getaddrinfo on the host.

Configuration: Kamailio dual-stack

listen=udp:0.0.0.0:5060
listen=udp:[::]:5060
listen=tls:0.0.0.0:5061
listen=tls:[::]:5061

# Use $sndaf to detect which family the request arrived on
if ($sndaf == "INET6") {
    xlog("L_INFO", "Inbound on IPv6 from $si\n");
}

Performance and reachability

• RTP latency: IPv6 packets are slightly larger (40-byte header vs 20). For G.711 (160-byte payload) overhead jumps from 11.1% to 20%. Negligible on modern links; matters for satellite or 2G fallback.
• Mobile reach: in 2026, ~45% of US mobile traffic and ~55% of European 5G is IPv6-only by default (carriers using NAT64). IPv4-only PSTN endpoints lose direct reachability for this traffic.
• Public IP scarcity: renting IPv4 IPs costs $0.005/hour on most clouds (~$3.60/mo per static v4). IPv6 is free. Multi-tenant SBCs benefit.

DIDHub IPv6 support

DIDHub SIP infrastructure is dual-stack. The sip.didhub.io FQDN resolves both A and AAAA. Every PoP terminates SIP+RTP on both IPv4 and IPv6. Customers can pin IP-ACL rules to either family, or both. WebRTC clients arriving over IPv6 are first-class.

Recommendation: always run dual-stack on your PBX. Single-stack IPv6 is risky until corporate / carrier middle-boxes catch up — budget that transition over 2-3 years.

References

• RFC 4566 / RFC 8866 — SDP (defines IP4 / IP6 address types)
• RFC 6157 — IPv6 Transition in SIP
• RFC 6724 — IPv6 Address Selection (the rules getaddrinfo follows)

Related terms