SIP media path troubleshooting separates a successful call connection from successful voice delivery. A desk phone can show an active call while neither person hears anything. The call-control messages reached their destinations, but the audio may follow a different route.
This guide targets persistent silence in both directions on established calls. Its goal is a clear packet-path record, not a list of settings to toggle. You will compare advertised media destinations with actual traffic, then locate the first broken boundary.
Separate SIP Signaling From the RTP Media Path
Session Initiation Protocol (SIP) handles call setup, changes, and termination. Real-time Transport Protocol (RTP) carries the voice stream, usually over User Datagram Protocol (UDP). Each direction has its own packet flow.
A private branch exchange (PBX) manages calls between extensions and external providers. It may relay audio, or it may tell endpoints to exchange audio directly. Therefore, the SIP route does not prove the RTP route works.
Confirm the final successful response and the acknowledgment for the call setup. In a typical exchange, these are the 200 OK response and ACK. They confirm signaling progress, not audible speech.
The IETF RTP specification describes media transport independently of SIP. That separation explains why a registered phone can place a silent call.
If audio fails specifically during the transition from ringing to answer, use the ringback-to-answer diagnostic guide. Here, the narrower task is tracing a stable, established call with no conversation in either direction.
Prepare One Controlled Silent Call
Choose a test extension and an approved external destination. Avoid emergency numbers and active business conversations. Ask both participants to speak during the capture so silence suppression does not confuse packet counts.
- Record the start time, time zone, call direction, and affected extensions.
- Note whether internal calls work while external calls remain silent.
- Check mute controls, handset connections, and softphone audio devices.
- Record recent router, provider, PBX, or public-address changes.
- Save current settings and define a rollback before making changes.
Capture traffic only with authorization. Packet captures can contain phone numbers, credentials, and recoverable conversations. Limit the capture window, protect the files, and follow your retention policy.
Start with the PBX and firewall capture tools available in your environment. Simultaneous captures on both sides of a suspected boundary provide stronger evidence than one capture alone.
Build a SIP Media Path Troubleshooting Record
Session Description Protocol (SDP) describes the proposed media session inside signaling messages. Read the offer and answer for each call leg. A PBX often maintains separate phone-facing and provider-facing legs.
Do not stop at the first SDP message. A later re-INVITE or UPDATE can change media destinations during the same call.
| Evidence | What to record |
|---|---|
| Call identity | SIP Call-ID, timestamp, and corresponding PBX call identifiers |
| Advertised destination | Effective SDP connection address and audio port for each receiver |
| Media agreement | Codec mappings, media direction, and encryption requirements |
| Observed flow | Source and destination addresses, UDP ports, and packet counts |
| Boundary result | Whether matching traffic enters and leaves each capture point |
Related PBX legs may use different Call-IDs. Use PBX logs and matching timestamps to connect them rather than assuming one identifier covers everything.
For each direction, compare the intended receiver with the actual packet destination. This simple record turns “no audio” into a specific routing, translation, or processing question.
Check SDP Addresses Against NAT Behavior
Network address translation (NAT) maps private addresses and ports to addresses reachable across another network. SIP signaling can survive NAT while SDP still points audio toward an unreachable private address.
Inspect the SDP c= connection address and m=audio port. A media-level connection address overrides the session-level address for that stream. An audio port of zero rejects that media stream.
A private address is not automatically wrong. It can work between local phones or across a routed private network. It becomes suspect when the intended sender has no route to it.
- Compare the advertised public address with the active internet connection.
- Check PBX local-network definitions and external-media address settings.
- Look for double NAT between the PBX and provider.
- Confirm that port translation matches the actual receiving path.
A SIP application-layer gateway (ALG) can rewrite signaling and SDP. Compare captures before and after that gateway to identify unwanted changes. Do not toggle the ALG globally without a maintenance plan and a controlled comparison.
Find Where Firewall Pinholes Stop RTP
A firewall pinhole is a limited opening for expected traffic. Some systems create these openings from signaling inspection. Others rely on explicit rules, NAT mappings, and outbound UDP state.
Allowing SIP traffic does not automatically allow audio. Verify the configured RTP port range on the actual PBX, not a range copied from another installation.
- Confirm that the sender emits media toward the negotiated destination.
- Check whether those packets reach the firewall’s outside interface.
- Follow the translated destination through the inside interface.
- Confirm arrival at the PBX or endpoint that should receive them.
- Repeat the trace in the opposite direction.
Packets outside but not inside point toward filtering, translation, or routing at that boundary. Packets leaving the PBX but missing outside suggest an outbound path problem. Validate capture interfaces and filters before treating an empty capture as proof.
Provider media servers may differ from their SIP servers. Confirm approved media networks with the provider before restricting source addresses. Never expose every UDP port or disable the firewall as a diagnostic shortcut.
Verify Symmetric RTP Without Guessing
Symmetric RTP behavior lets a media endpoint send replies toward the source address and port of received media. This can help when NAT makes the observed source differ from SDP.
In Asterisk PJSIP, relevant options include rtp_symmetric, force_rport, and rewrite_contact. They serve different purposes. Symmetric RTP concerns media; the other two concern SIP response routing and contact handling.
Do not enable all three simply because a call lacks audio. First compare the SDP destination, observed RTP source, and return destination. Then check the applicable endpoint or trunk configuration.
Source-learning behavior cannot repair every failure. If neither side’s packets arrive, there may be nothing to learn. An unreachable destination or blocked firewall path still needs correction.
Consult the official Asterisk documentation for your channel driver and release. In FreePBX, use supported configuration controls rather than editing generated files that the system may overwrite.
Check Whether the PBX Anchors the Audio
Media anchoring means the PBX or another media relay stays between the two audio endpoints. Direct media allows endpoints to exchange voice without that relay.
Direct media can fail when each endpoint reaches the PBX but cannot reach the other endpoint. This often involves separate private networks, NAT boundaries, or provider routing restrictions.
Compare the original SDP with later signaling changes. If media destinations shift away from the PBX, verify reachability between those new destinations. The signaling server’s connectivity does not establish endpoint-to-endpoint connectivity.
For an approved test, disable direct media only on the relevant configuration scope. Then place a new call and confirm that both streams traverse the PBX. Record the previous setting and restore it if the test provides no benefit.
Anchoring adds media traffic and may require transcoding resources. Check capacity before adopting it broadly. Audio returning through the relay identifies a path dependency, not permission to skip the underlying network review.
Inspect Codecs When Packets Reach Both Sides
A codec encodes and decodes speech. If media packets reach both receivers, move from network delivery to media interpretation.
Compare negotiated codecs with actual RTP payload types. Dynamic payload numbers depend on the session’s SDP mappings; the number alone does not identify the codec.
- Check whether the PBX needs an available transcoding path between different codecs.
- Review SDP direction attributes such as
sendrecv,sendonly, orinactive. - Verify matching encryption requirements and successful key negotiation.
- Check endpoint receive counters, decoding errors, and audio-device selection.
Secure RTP (SRTP) protects media content. Encrypted packets can reach an endpoint even when authentication or decryption fails. A packet analyzer’s inability to play encrypted audio does not itself prove a call failure.
Use a mutually supported codec for a controlled comparison. Do not disable media encryption or broaden codec lists without understanding the security and interoperability effects.
Validate the Fix and Preserve the Evidence
Repeat the original call after one targeted change. Test both call directions, then check hold and resume because renegotiation can expose another path problem. Confirm audible speech both ways, not merely rising packet counters.
Keep the before-and-after SDP destinations, boundary observations, final settings, and rollback details. Remove temporary capture files and test rules according to your policy.
Good SIP media path troubleshooting ends with an explained failure boundary. If you need coordinated PBX, firewall, and provider access, professional remote help may be appropriate. Tech Rescue Ops LLC offers remote VoIP and PBX support for evidence-led diagnosis and controlled changes.