Inventory the address families the service must actually use
Record the running Asterisk branch, configuration owner, local interfaces, routing tables, listening sockets and every endpoint, registration or proxy that must use IPv4, IPv6 or both. Separate signaling from media and inbound listening from outbound reachability. A host owning an IPv6 address does not prove that its firewall, upstream route, DNS, provider or RTP policy supports the same path.
Preserve the exact SIP URI and resolved destination. RFC 3986 places an IPv6 literal inside brackets in the URI host syntax; do not copy an unbracketed interface or log representation into a URI and treat the resulting parse failure as a network failure.
Give each address family a matching PJSIP transport
Asterisk documents IPv6 by binding a PJSIP transport to a specific bracketed IPv6 address or to :: for the first available IPv6 interface. Its transport-selection process chooses a transport matching both the required transport type and address family when no explicit object is supplied. An endpoint that names a transport uses that object for a new connection.
For a dual-stack service, Asterisk's documented strategy is separate IPv4 and IPv6 transports. Preserve protocol, bind address and port for each object and the endpoint or registration that selects it. Do not infer that one UDP, TCP or TLS listener covers another address family.
Do not use one wildcard IPv6 transport as a dual-stack shortcut
Asterisk explicitly warns that binding one wildcard IPv6 transport for both families can produce IPv4-mapped IPv6 addresses that PJSIP does not support, causing SIP message parsing failure. Treat that warning as a configuration boundary rather than a prediction about every operating system's socket behavior.
When both families are required, define and inspect the separate transport objects and their real listeners. A successful process reload or a transport name in configuration is not proof that the intended address and port were bound or that traffic can traverse the host firewall and upstream network.
Follow URI, DNS and transport selection in order
PJSIP first parses the URI, including its transport parameter; absent an explicit parameter, Asterisk documents UDP as the default for this selection process, while SIPS switches to TLS. DNS then supplies a target when applicable, and the resolved target's address family constrains transport selection. Preserve the effective URI, SRV or address answer, selected remote address and local transport as one timestamped chain.
An AAAA answer is a candidate, not proof of IPv6 reachability. An A answer is not proof that an IPv4 transport exists. If an endpoint pins a transport, confirm that the object's family matches the selected destination instead of changing DNS to hide a transport mismatch.
Keep signaling family, TLS identity and RTP evidence distinct
Asterisk's IPv6 guide says RTP follows the signaling address family for the endpoint: IPv6 signaling uses IPv6 media and IPv4 signaling uses IPv4 media. That documented default does not prove a provider advertised a reachable media address, that ICE or NAT policy is correct, or that a firewall permits the negotiated ports. Inspect the offer, answer and packets for the affected call.
For TLS, preserve the URI name, SNI behavior where applicable, certificate identity, trust path and selected remote address separately. Replacing a hostname with an IP literal can change identity validation and DNS discovery, so it is a bounded diagnostic only when the service owner supports it.
Rehearse one family at a time with a rollback
Define acceptance for listener reachability, REGISTER or OPTIONS, inbound and outbound INVITE, media in both directions, DTMF, hangup and restoration. Test IPv4 and IPv6 as separate cases, then the intended dual-stack selection, using provider-approved targets and a maintenance window. Record the exact remote and local tuples rather than reporting only Registered or a completed call.
Correct the demonstrated boundary through the configuration owner, then rerun the same evidence path. Do not disable IPv6 system-wide, remove a healthy transport, change production DNS or restart the PBX merely to force a preferred result. No host, network path, provider service or call was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk res_pjsip IPv6 configuration ↗
- Asterisk PJSIP transport-selection process ↗
- RFC 3986: URI generic syntax ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.