Asterisk PJSIP direct media: policy, re-INVITE and final RTP path

Start with two Asterisk channel legs and one intended topology

Asterisk is a back-to-back user agent, so a phone-to-trunk call normally has a phone-facing PJSIP channel and a trunk-facing PJSIP channel. Record the exact loaded endpoint for each leg, bridge membership, initial SDP addresses and intended media owner before changing configuration. A global description such as ‘the call uses direct media’ can hide that only one controlled endpoint relationship is eligible.

Asterisk 22 documents direct_media as the endpoint policy that determines whether media may flow directly between endpoints, with a documented default of yes. The loaded value is a permission, not proof that a particular call moved media away from Asterisk. Preserve the running endpoint objects and the configuration system that owns them.

Follow the request that attempts to move media

Direct media is established through a new in-dialog offer/answer, normally a re-INVITE or UPDATE selected by direct_media_method. Keep Call-ID, tags, CSeq, request method, SDP offer, final response, SDP answer and ACK where required together. RFC 3264 makes the accepted offer and answer authoritative for the resulting session; an address merely proposed in a rejected or incomplete request never became the media destination.

Asterisk also documents direct_media_glare_mitigation. That control assigns how Asterisk handles competing direct-media requests; it is not a generic retry timer or a repair for every 491, 500 or silent call. Reconstruct the outstanding transaction and offer state before changing it.

Prove the final RTP path rather than inferring it from PBX silence

After the successful offer/answer, compare the final SDP connection address and media port with RTP observed from both endpoints. If the endpoints exchange media directly, a PBX-side capture can correctly stop seeing RTP. If Asterisk remains anchored, the same absence points to a different boundary. Record source, destination, time and direction at each observation point rather than relying on one packet counter.

The Asterisk CHANNEL() reference exposes RTP-related channel views on supported builds, but a runtime value remains one observation. It does not prove that the named destination receives, authenticates, decrypts, decodes or renders the stream. Preserve packet and endpoint evidence for both directions.

Keep direct media separate from NAT response and contact controls

The Asterisk NAT guide gives different jobs to transport local_net and external addresses, endpoint media_address, rtp_symmetric, force_rport, rewrite_contact and direct_media. The current endpoint reference also documents disable_direct_media_on_nat, which suppresses direct-media session refreshes when NAT obstructs the media session. None of those names establishes that Asterisk detected the deployment topology correctly for one call.

Draw the signaling source and destination, Contact and Via owners, final SDP owners, RTP senders and every translation or relay boundary. Correct only the owner supported by that evidence. Enabling every NAT option or opening broad media ranges can mask the first failure while changing unrelated call paths.

Account for recording, transcoding, encryption and feature ownership

Asterisk may need to stay in the media path to transcode, mix, record, provide music, enforce a relay design or terminate protected media on separate legs. Direct media can bypass those functions or require endpoints to negotiate protection directly. A completed recording, codec translation or encrypted leg is therefore separate acceptance evidence from direct RTP reachability.

Test hold, resume, blind and attended transfer, connected-line changes, session refresh and feature codes that apply to the deployment. Those actions can create later re-INVITEs or UPDATEs and can move media again. An ordinary answered call does not prove the post-feature path.

Change the managed owner and retest both media directions

On standalone Asterisk, preserve the responsible configuration source and confirm the endpoint reloaded with the intended value. On FreePBX, change the supported GUI or managed configuration owner, Apply Config, and compare generated and loaded endpoint state; do not patch generated PJSIP files. Preserve the previous policy and rollback path.

Create a fresh authorized call in each required direction. Retain initial and final SDP, the direct-media transaction, both RTP directions, hold and resume, transfer, recording where required, ordinary hangup and a control call that should remain anchored. No Asterisk host, FreePBX system, endpoint, trunk, bridge, NAT device, offer, answer, packet path, media stream or live call was tested for this guide.

Check the negotiated media address before and after direct media

The PJSIP media-address guide shows how endpoint and transport address controls affect the Asterisk-anchored leg. The diagnostic then accounts for a valid re-INVITE or UPDATE that moves RTP away from Asterisk.

Attribute each re-INVITE to its actual owner

The session-refresh diagnostic correlates application-triggered codec refresh, direct-media movement and post-answer RTP without flattening them into one re-INVITE event.

Do not label every hold re-INVITE as direct media

The MOH passthrough guide attributes hold and resume offers separately from direct-media movement, session refresh, transfer and connected-line updates.

Observe the direct-media address on the same leg and interval

The RTP context workflow keeps direct separate from ordinary src and dest, then binds it to the active bridge phase and packet path.

Verify that Asterisk still owns the media segment

The choppy-audio diagnostic first proves whether the affected RTP reaches an Asterisk channel; a buffer cannot change a bypassed direct-media segment.

Treat custom stream-DTMF features as media-path inputs

The custom dynamic features guide records Asterisk’s media-anchoring warning without inferring the final RTP path.