Asterisk PJSIP transport change did not take effect

Define the exact transport symptom

Record the transport object name, protocol, address, port and option that was intended to change. Then classify the symptom: the object is absent from the running PJSIP inventory, the object is present with an old value, the intended address is not listening, a listener exists but the endpoint or registration chooses another transport, or signaling reaches the listener and fails later. These states have different causes.

Preserve the first startup or activation error with its timestamp. A form save, generated file, successful Apply Config banner, running Asterisk process and reachable SIP port are separate evidence. Do not start by repeating reloads or opening a firewall port when the object itself did not load.

Separate saved, loaded and listening state

Compare three artifacts: the configuration owned by the platform, the transport reported by the running Asterisk CLI, and the operating system's listener for the exact address, protocol and port. pjsip show transports and pjsip show transport <name> establish PJSIP's loaded view; a socket inventory establishes whether a process actually owns the intended local tuple. Neither proves that a particular endpoint or registration selects it.

If the object is absent, read the earliest res_pjsip load or bind error before inspecting later dependent failures. If it is loaded but no expected listener exists, verify protocol and address family as well as port. If another process owns the tuple, identify that owner rather than killing an unknown service or moving SIP blindly.

core show version
module show like res_pjsip
pjsip show transports
pjsip show transport transport-udp
pjsip show endpoint office-phone
pjsip show registrations

Check structural conflicts before activation

Asterisk documents that PJSIP transports cannot share the same IP-plus-port or IP-plus-protocol combination, and that multiple TCP or TLS transports of the same IP version are unsupported. The current reference defines bind as the local IP address plus optional port and lists UDP, TCP, TLS, WS, WSS and flow as different protocol values. Validate the complete tuple and address family for every enabled transport.

On FreePBX 17, also inventory any retained chan_sip listener. Sangoma's migration guidance explicitly requires checking bind ports for conflicts between channel drivers, applying the generated configuration and restarting Asterisk. A port collision is a local listener problem; it is not repaired by changing provider credentials, endpoint authentication or remote NAT policy.

Preserve the transport activation boundary

The current Asterisk reference says transport changes take effect on a complete restart rather than a module reload. It also exposes allow_reload, default no, and warns that reloading a transport can disrupt calls. The object-relationships guide says runtime reload requires that option. Treat the explicit option as a limited capability, not proof that a structural bind, protocol, certificate or removal change was rebuilt safely.

On FreePBX, keep Asterisk SIP Settings and generated configuration authoritative. Submit and Apply Config first, inspect generation errors, then schedule the required Asterisk restart through the platform's operational controls. Do not edit generated transport files or enable transport reload merely to avoid a maintenance window.

Prove which consumer selected the transport

A loaded listener does not force every request to use it. Asterisk's object documentation says an endpoint with no explicit transport uses the first configured transport valid for the target URI. Its transport-selection guide further separates explicit from implicit selection, UDP from connection-oriented protocols, DNS results, address family, multihomed source choice and reuse of existing TCP or TLS connections.

Inspect the exact endpoint or outbound registration and one message path. Record whether the object names a transport, whether a persistent connection already exists, and the actual local and remote signaling tuples. If more than one compatible transport exists, make ownership explicit in the supported configuration instead of depending on incidental load order.

Run one controlled restart and acceptance sequence

Before disruption, preserve the authoritative configuration and a known-good rollback, identify active calls and registrations, and define the expected listeners and consumers. During the maintenance window, perform one supported restart, then confirm module load, every intended transport, exact listener tuples, registration recovery and the first bounded test flow. For TLS, verify certificate presentation and peer trust separately; for media, confirm both directions rather than inferring RTP from SIP success.

Retest a neighboring unaffected route and document interruption time. If the expected object or listener is missing, stop at the first specific generation, parse, bind, certificate or dependency error and roll back through the same configuration owner. No PBX, generated file, process, socket, endpoint, registration, trunk, certificate, network path, media stream or live call was inspected or tested for this guide.

Start from the FreePBX Asterisk SIP Settings owner

When FreePBX generated the transport, the Asterisk SIP Settings guide preserves the submitted value, Apply Config, generated object and restart boundary before this diagnostic compares the loaded object, listener and selected consumer.