Freeze the first mismatch
Record timestamp and timezone, installed Asterisk release, channel technology, name, unique ID and linked ID, call direction, bridge state, selector, explicit media type and returned value. Classify the symptom as empty src or dest, unexpected direct, wrong address or port, unexpected secure, unexpected hold, or disagreement with SDP or a packet capture.
Do not begin by changing NAT, direct-media or encryption settings. First preserve which channel and media interval produced the value.
Prove technology, leg and stream
Confirm CHANNEL(channeltype) is PJSIP and that dialplan is executing on the intended caller or callee leg. If video is requested, prove that the channel has the relevant video stream; if the media type is omitted, remember that Asterisk defaults to audio.
A blank value can be expected on another channel technology, the opposite leg, a stream that does not exist, or before the runtime state is available. Move the observation to the correct leg and interval before treating emptiness as a media failure.
Match the selector to its documented meaning
Compare src with the local RTP address and dest with the remote RTP address for that stream. Treat direct as its own direct-media remote address rather than a second spelling of dest. If direct media is not active, an empty direct value is not evidence that ordinary anchored RTP is broken.
Keep RTP addresses separate from CHANNEL(pjsip,local_addr) and remote_addr, which describe SIP INVITE sockets, and from URI, endpoint, Contact and DNS data.
Align bridge phase with SDP and packets
Determine whether the observation occurred before or after answer, re-INVITE, UPDATE, hold, resume, transfer, conference entry or a direct-media transition. Compare the offer-answer pair current at that time. RFC 3264 allows later exchanges to change media addresses and ports.
Capture at the interface that can actually see the expected path. With remote native bridging, endpoint-to-endpoint media may be outside Asterisk, so an Asterisk-host capture is not universal negative proof.
Keep encryption and hold conclusions narrow
For secure, compare the selected stream with negotiated media protection and observed SRTP evidence, while keeping signaling TLS, identity validation and the other bridge leg separate. For hold, compare the flag with SDP direction, current bridge behavior, RTP and the audible outcome.
A one flag proves neither end-to-end security nor successful hold audio. A zero flag does not identify which policy, negotiation, keying or topology stage caused the result.
Correct one demonstrated owner and repeat
Correct only the proven mismatch: observation leg, media type, dialplan timing, SDP address or port, NAT translation, endpoint policy, bridge feature, direct-media eligibility, encryption negotiation or hold workflow. Preserve the previous configuration and rollback.
Repeat the affected case and one known-good control. Acceptance requires the expected selector value on the exact stream plus matching SDP and packet evidence; separately verify two-way audible media. No PBX, channel, SDP body, key, packet or call was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk CHANNEL dialplan function ↗
- Asterisk bridge media paths ↗
- Asterisk PJSIP troubleshooting guide ↗
- RFC 3264: SDP offer-answer model ↗
- RFC 3711: Secure RTP ↗
- RFC 6337: SIP usage of offer-answer ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.