Asterisk PJSIP transport selection: URI, DNS, connection and object boundaries

Start with the request URI that PJSIP will parse

Asterisk documents a URI-driven selection process. The SIP or SIPS scheme, host, port and transport URI parameter are inputs before a named transport object is chosen. With no transport parameter, the type is assumed to be UDP for this process; a sips: URI causes TLS selection. A configured endpoint or registration object name is therefore not enough evidence of the protocol used by a request.

Preserve the effective request URI, endpoint, outbound registration, AoR contact or outbound proxy that created it. A hostname with an explicit port follows a different DNS path from one without a port. Likewise, sip:example.test;transport=tcp and sips:example.test are not interchangeable promises about certificate identity, proxy routing or media protection.

Keep DNS routing and local transport choice separate

When the host is not an IP address and the URI has no port, the documented process can use SRV resolution based on the selected transport type. For TCP or TLS SRV discovery, the URI needs the transport type unless the SIPS scheme selected TLS automatically. DNS produces remote targets; it does not choose the local bind address, certificate, endpoint policy or media route.

Record the resolver answers, TTLs, SRV priority and weight, target address family and final remote IP and port. Then record the local Asterisk transport object actually used. A successful lookup does not prove a socket opened, and an open connection does not prove the request reached the expected registrar or proxy.

Understand implicit and explicit transport objects

Without an explicit transport object, Asterisk says UDP can be selected through a matching hash, while connection-oriented requests first look for an existing connection to the resolved IP and port and otherwise use the first configured transport matching protocol type and address family. Its object-relationship guide similarly says an endpoint with no transport value defaults to the first valid configured transport for the URI. File order can therefore become part of behavior when configuration leaves selection implicit.

With an explicit object, that object is used to send or establish the connection. This narrows the local selection but does not override an incompatible URI, unavailable listener, DNS target, remote policy or certificate failure.

Treat TCP and TLS connection reuse as live state

For connection-oriented protocols, Asterisk documents reuse of an existing connection to the resolved IP and port when one exists. Even an explicit transport can reuse an existing connection of the specified transport type instead of creating a new one. A later request can therefore reflect connection state that is not visible in a static configuration diff.

Correlate the request with the local and remote socket, protocol, connection age and transport object. Restarting merely to erase that evidence is not a diagnosis. Preserve the failing request and compare a controlled new connection only after documenting the current state and the effect on registrations and calls.

Apply proxy settings to each request owner

Asterisk's proxy example adds outbound_proxy separately to the endpoint, AoR and outbound-registration objects because calls, OPTIONS qualification and REGISTER requests are owned by different objects. The proxy URI includes loose-routing lr; the documentation warns that omitting it can lead to a 404 from the proxy. The semicolon also needs escaping in configuration so it is not parsed as a comment.

Do not infer that a working REGISTER proves INVITE or OPTIONS uses the same route. Preserve the effective endpoint proxy, AoR proxy and registration proxy independently, along with the actual Route and Request-URI fields.

Bound reload and automatic TCP behavior

The Asterisk 22 transport reference retains the conservative statement that transport changes require a complete restart, while allow_reload is an opt-in control whose default is off. The existing transport-activation diagnostic covers that lifecycle. Transport selection and transport activation are related but different questions.

Asterisk also notes that disabling disable_tcp_switch can allow a large UDP message to switch automatically to TCP; this can fail when no TCP transport is configured or the remote side does not listen on TCP. Record message size, the system setting and the actual sent protocol before calling the behavior random. No transport, DNS, proxy, certificate, request, media path or call was tested for this guide.

Diagnose a large-message UDP-to-TCP changeover

Asterisk can change from UDP to TCP for a large outgoing message when policy allows, but the send still depends on a loaded compatible transport and a remote TCP listener. The large-message diagnostic preserves request size, target URI, selected object, connection and send result.

Follow a DNS change beyond SRV selection

When a request continues to use an earlier target, use the PJSIP DNS-change diagnostic to compare authoritative and recursive answers, the actual query path, TTL, connection reuse and registration retry without treating a PBX restart as proof of the cause.

Apply transport selection to IPv4 and IPv6

A resolved target's family constrains PJSIP transport selection. The dual-stack guide and IPv6 unreachable diagnostic preserve the URI, DNS answer, matching local bind, route and response as one evidence chain.

Do not mistake a parsed transport parameter for the selected transport

A returned transport_param is one URI component. The PJSIP_PARSE_URI guide keeps it separate from configured objects, DNS results, connection reuse and the transport used by the emitted request.

Compare selected transport with channel-level socket evidence

The PJSIP channel-context workflow keeps secure, local_addr and remote_addr separate from URI parameters, configured transports and RTP addresses.