Why signaling success is not audio success
SIP can establish a dialog while RTP travels to an unreachable address or is blocked in one direction. The SDP offer and answer advertise media addresses and profiles; packet evidence shows what actually happened. NAT rewriting, symmetric RTP and direct media address different topology problems.
Safe verification
Use an authorized test call, capture only the negotiated address and port scope, and compare both legs. If SRTP is expected, verify the negotiated profile rather than disabling encryption. Protect captures because media and signaling may contain sensitive information.
Related engineering resources
Use a direction-first media workflow
State who cannot hear whom, then translate the symptom into the missing RTP direction. Compare the INVITE and 200 OK connection address and audio port, capture at the relevant NAT boundary and confirm whether packets reach the advertised destination. Do not toggle every NAT option or widen all UDP ports.
If A hears B but B cannot hear A, trace A-to-B media from A’s endpoint leg through Asterisk to B’s negotiated address. Repeat independently for the reverse direction. Each branch links to a stable heading in the NAT/RTP guide covering SDP, NAT options, packet workflow or the decision matrix.
Asterisk sending and receiving RTP does not prove an endpoint plays it; endpoint codec, encryption and playout still matter. Conversely, 200 OK and ACK prove only signaling. If a re-INVITE changes addresses after answer, compare the later session rather than relying on the initial offer.
Record the first boundary where expected packets disappear, not merely the last place audio was heard. Protect packet captures because payloads can contain voice. Stop debug promptly and roll back any temporary firewall or endpoint change that did not restore both directions.
Verify the selected branch with packets
The branch result is a hypothesis map. Validate it by writing the expected source and destination tuple for each media leg and capturing at the nearest authorized boundary. Packet counts should cover a deliberate speech interval; silence suppression can otherwise create misleading gaps. Confirm payload type and encryption profile as well as UDP direction.
After a correction, repeat offer/answer inspection because a re-INVITE or direct-media transition can move the path. Verify audio, DTMF and call release, then restore any temporary debug or firewall setting. If the first boundary remains unknown, collect evidence at the next boundary rather than applying more NAT flags.
Operational assurance
The diagnostic assumes the user can identify the listening symptom accurately. Confirm with both participants or a controlled audio source; “silence” can also be muted media, unsupported codec, SRTP failure or endpoint playout. Map A-to-B and B-to-A to named legs before capture. When Asterisk bridges two channels, each leg has its own SDP and packet tuple. A correction is accepted only when the same controlled call shows two-way packets and intelligible audio without an unapproved firewall expansion.
Limitations
The decision tree does not measure jitter, packet loss, transcoding quality or endpoint volume. If packets flow both ways but audio remains unusable, inspect negotiated payloads, SRTP authentication, jitter buffer and endpoint playout. Maintain the direction labels throughout the case; switching “caller” and “callee” between legs is a common source of incorrect firewall and NAT changes.
Authoritative references
Protocol context and safe closeout
The workflow follows RFC 3264 offer/answer, RFC 4566 SDP and RFC 3550 RTP concepts; device and Asterisk behavior still depends on the deployed version. After diagnosis, roll back temporary captures and firewall exceptions, remove sensitive evidence according to policy, and verify a controlled two-way call.
Implementation closure
Which party cannot hear, both SDP bodies, observed RTP directions, NAT boundaries, and permitted capture points.
Browser-only decision path; any later PBX or firewall change belongs to the linked implementation guide.
Choose the observed symptom, follow the direction-specific checks, and verify with scoped packets. No reload or restart applies in this tool.
The workflow identifies the missing RTP direction and the first boundary requiring verification.
If direction or SDP is unknown, collect those facts before selecting a configuration change.
Stop before broad firewall access, blind NAT-option changes, or unauthorized packet capture.
The suspected boundary is supported by SDP and packet evidence and the proposed correction has verification and rollback steps.