VoIP.info Guide

Asterisk PJSIP channel RTP context: address, direct media, security and hold

Read one PJSIP media stream without confusing Asterisk-local and remote RTP addresses, a direct-media destination, stream encryption, hold restriction, SDP or observed packets.

Reviewed 2026-10-16Current Asterisk branch 23 CHANNEL documentation, Asterisk bridge and PJSIP troubleshooting guidance, and RFC 3264, RFC 3711 and RFC 6337 reviewed October 14, 2026; CHANNEL(rtp,...) reports media data for the exact current PJSIP channel and selected audio or video stream, while installed release, loaded modules, bridge technology, negotiated SDP, NAT translation, direct-media transition, keying, packet flow and audible result remain deployment specific; no PBX, module, endpoint, channel, bridge, SDP body, key, packet, media stream or call was inspected or testedAdvancedDocumentation based · not lab tested

Bind every value to one channel and stream

CHANNEL(rtp,...) is documented for the current PJSIP channel. Record CHANNEL(channeltype), name, unique ID, linked ID, call direction, bridge state, selector, media type and timestamp together. A caller channel, outbound callee, Local-channel half and bridge peer can participate in one call while exposing different media state.

The optional media type is audio or video; audio is the default. An omitted media type must not be treated as an inventory of every stream. A blank value can reflect the wrong technology, leg, stream or observation time rather than a failed packet path.

Keep src, dest and direct separate

CHANNEL(rtp,src,media_type) retrieves the local RTP address for the selected stream. dest retrieves its remote RTP address. direct is a separate value: when direct media is enabled it is the remote address used for RTP. Preserve all three labels instead of flattening them into a generic media IP.

These values are channel runtime evidence. They are not substitutes for SIP signaling sockets, URI hosts, DNS answers, an endpoint name, every address in SDP, the source observed by a remote capture or proof that packets reached either address.

Place the address in the active bridge topology

Asterisk documents core, local native and remote native bridge paths. In a core bridge Asterisk has direct access to media. In a remote native bridge, commonly called direct media for SIP channels, media flows outside Asterisk between the devices. Bridge technology can change during a call as features or participants change.

Read the RTP selector at the same moment as bridge evidence. An address captured before a re-INVITE, transfer, conference, recording feature, hold or direct-media change may be historically correct but no longer describe the active path.

Treat secure as per-stream encryption evidence

CHANNEL(rtp,secure,media_type) returns zero or one for whether that media stream is encrypted. Keep it separate from CHANNEL(pjsip,secure), which describes signaling transport, and from bridge requirements such as secure_bridge_media.

A value of one does not by itself identify the SRTP profile, key source, certificate or peer identity, intermediary termination, protection on another call leg, or end-to-end coverage. RFC 3711 defines SRTP and SRTCP protection, but the channel flag remains the narrower Asterisk runtime observation.

Treat hold as current media restriction

CHANNEL(rtp,hold,media_type) reports whether the selected stream is currently restricted due to call hold. It is not proof that a human pressed a hold key, which party initiated the transition, that music is audible, or that resume restored two-way media.

Keep the flag beside the offer and answer, media direction, bridge state and packets. SIP hold, local music generation, peer-facing hold passthrough and a media path that happens to be silent remain different observations.

Compare runtime, SDP and packets in order

Preserve the negotiated offer and answer before comparing the channel value. RFC 3264 permits address and port changes in a later offer-answer exchange, so record which exchange was current when the selector was read. Then verify packets on the correct interface and direction, including any NAT or relay boundary.

Use RTCP statistics for counters, loss, jitter and round-trip evidence rather than inferring quality from an RTP address alone. Acceptance requires agreement among channel leg, media type, bridge phase, SDP interval and packet observation; it does not imply audible success. No runtime value or call was tested for this guide.

Attach jitter evidence to the exact channel and stream

The Asterisk jitter-buffer diagnostic correlates channel, SSRC, tuple, direct-media state and local versus remote RTP statistics.

Follow media onto the surviving optimized path

The Local optimization diagnostic keeps topology success separate from packet flow and audible media.

Do not treat topology snapshots as media proof

The AMI channel snapshots guide keeps Status formats, bridge membership, packets and audible media separate.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.