Define the failed transaction and selected family
Capture one bounded REGISTER, OPTIONS or INVITE attempt with timestamp, effective URI, proxy, DNS answers, selected remote IP and port, protocol and named local transport. State whether the failure is a timeout, immediate routing error, unsupported-transport warning, TLS failure, SIP response or media-only symptom. These stages have different owners.
Do not conclude that IPv6 caused the failure from the presence of an AAAA record. Confirm that the affected transaction actually selected that address and that a matching address-family transport was available.
Compare configured transports with real listeners
Inspect the loaded PJSIP transport objects and the operating system's listening sockets. For dual stack, expect separate IPv4 and IPv6 objects when following Asterisk's documented strategy. Check bind address, port, protocol, interface state and whether the endpoint or registration pins a transport.
Asterisk documents an unsupported-transport warning when no transport matches the required type or address family. It also warns against one wildcard IPv6 transport as an IPv4-and-IPv6 shortcut because mapped addresses can cause parsing failure. Correct that ownership boundary before changing remote DNS.
Prove local IPv6 routing and policy to the exact target
From the PBX host and the same network namespace, preserve the source address, route decision, neighbor discovery where local, firewall counters and a packet capture for the exact destination. A generic IPv6 ping to another host does not prove the SIP target, port, return path or upstream policy. Lack of ICMP response alone does not prove SIP is unreachable.
Keep local bind failure, no route, filtered traffic, remote refusal and no SIP response as separate outcomes. Coordinate active probes and packet capture with the service owner; do not scan provider infrastructure or relax a production firewall broadly.
Separate TLS and SIP rejection from IP reachability
If TCP connects, continue through TLS identity and trust, then the SIP response. Preserve the hostname expected by the service, certificate chain, validation result and final SIP status. An IPv6 socket connection can succeed while certificate identity or account policy rejects the request; changing to an IP literal can alter the very identity being tested.
If signaling completes, inspect the SDP addresses and RTP packets. Asterisk documents media family following signaling family, so a call that establishes over IPv6 but has no audio needs media-address, firewall and provider-path evidence rather than a transport-selection change by default.
Correct the smallest demonstrated boundary and retest
Correct only the evidenced owner: DNS publication, endpoint or registration transport, PJSIP bind, local address, route, firewall rule, TLS identity or provider service. Apply the change through standalone Asterisk or the FreePBX-managed interface that owns the generated configuration, with rollback and a maintenance window.
Repeat the same transaction and record DNS, selected address, local transport, socket or datagram, TLS result, SIP response and media. Verify both call directions and restoration on the intended families. No interface, route, firewall, provider path, registration, protected session or call was tested for this diagnostic.
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.