Asterisk PJSIP uses the wrong UDP, TCP or TLS transport

Define the exact request and observed path

Record whether the affected transaction is REGISTER, OPTIONS, INVITE, SUBSCRIBE or another request; identify the owning endpoint, AoR, registration or dialplan action; and capture the Request-URI, Route set, local and remote address, protocol and time. A registration succeeding over TLS does not prove an INVITE or qualification request followed the same object or connection.

Classify the symptom precisely: request left on UDP, no TCP or TLS connection opened, wrong local bind address, wrong address family, stale existing connection, proxy bypass, certificate failure or no request. Each has a different evidence path.

Reconstruct URI and DNS inputs

Inspect the effective URI rather than only the GUI or source file. Confirm SIP versus SIPS, any transport parameter, explicit port and final host. For a hostname without a port, capture current SRV and address answers and the remote target actually selected. For an invalid registration URI, Asterisk's troubleshooting guide shows that object allocation can fail before any network request is sent.

Do not repair a malformed URI by reordering transports, and do not repair a DNS target mismatch by changing certificates first. Preserve resolver and PJSIP logs for one bounded reproduction, then turn extra logging off.

Compare explicit selection with first-valid fallback

Read the loaded endpoint or registration object. If it names a transport, confirm that the object exists, is compatible with the URI protocol and address family, and is active. If it does not, enumerate loaded transports in configuration order and identify the first compatible choice. A transport farther down the file is not preferred merely because its name looks more specific.

For TCP or TLS, also determine whether PJSIP reused an existing connection to the resolved IP and port. A static expectation about a new source port is not enough evidence that the wrong transport object was selected.

Verify the correct proxy owner

If a proxy is required, inspect the endpoint's outbound_proxy for dialog requests, the AoR's proxy for qualification and the outbound registration's proxy for REGISTER. Confirm loose routing and correct configuration escaping. A proxy setting on only one object can produce a working registration while calls or OPTIONS take a direct path.

Keep proxy selection separate from inbound endpoint identification. Matching the source IP of an incoming request does not make the same object control an outbound request's proxy or local transport.

Correct one boundary and prove the new request

Correct only the demonstrated owner: URI scheme or parameter, explicit transport reference, transport order, address family, proxy placement, loose-routing parameter, DNS record or activation lifecycle. Use the dedicated transport-change diagnostic when the loaded object does not reflect the saved change. Avoid broad restarts until their effect on every registration and active call is understood.

Retest the same request and preserve the final URI, DNS target, local transport, socket, proxy route, SIP response and any certificate result. Then exercise the associated registration, qualification and call branch separately. No Asterisk host, transport, socket, connection, DNS answer, proxy, registrar, endpoint, certificate, request, media path, compatibility, availability, price or call was inspected or tested for this diagnostic.

If the transport is right but the remote target is old

Use the PJSIP DNS-change diagnostic to compare the URI-driven query, SRV and address answers, TTL, remote tuple and live connection before changing transport order.

When the mismatch is the address family

Use the IPv6 unreachable diagnostic to compare the selected A or AAAA target with the named PJSIP transport, real listener, source route, firewall and final SIP result.