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.
- 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 ↗
- Asterisk 23 JITTERBUFFER dialplan function ↗
- Asterisk ConfBridge configuration ↗
- Asterisk IP Quality of Service ↗
- Asterisk packet-loss concealment overview ↗
- Asterisk media-experience score implementation ↗
- Asterisk 23 AMI LocalOptimizeAway action ↗
- Asterisk 22 AMI LocalOptimizeAway action ↗
- Asterisk 23 AMI LocalOptimizationBegin event ↗
- Asterisk 23 AMI LocalOptimizationEnd event ↗
- Asterisk 23 AMI LocalBridge event ↗
- Asterisk AMI v2 specification: Local channel optimization ↗
- Asterisk Local channel optimization ↗
- Asterisk Local channel modifiers ↗
- Asterisk 23 AMI CoreShowChannelMap action ↗
- Asterisk 22 AMI CoreShowChannelMap action ↗
- Asterisk 23 AMI CoreShowChannelMapComplete event ↗
- Asterisk 22 AMI CoreShowChannelMapComplete event ↗
- Asterisk 23 AMI CoreShowChannels action ↗
- Asterisk 23 AMI CoreShowChannel event ↗
- Asterisk 23 AMI CoreShowChannelsComplete event ↗
- Asterisk 23 AMI Status action ↗
- Asterisk 23 AMI Status event ↗
- Asterisk 23 AMI StatusComplete event ↗
- Asterisk 23 AMI Newchannel event ↗
- Asterisk 23 AMI Rename event ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.