SIP one-way audio, missed inbound calls, and dropped calls: a diagnostic playbook

If you work in VoIP support, you hear the same complaints over and over:

"They can hear me, but I can't hear them."
"We can call out, but no one can call us."
"Calls drop after a while."

These three scenarios cover the majority of VoIP support volume. Each one has a predictable diagnostic path. This is that path.

One-way audio
Outbound works, inbound goes to voicemail, the PBX sees nothing
Dropped calls — fixed-time and random

1. One-way audio: only one side can hear

Symptom: Calls connect, but only one party hears audio. Often happens after a topology change, firewall change, or new ISP router.

1.1 Confirm the symptom and direction

Ask the user:

Who cannot hear — the caller, the callee, or both?
Does it happen on all calls or only certain routes or numbers?
Did anything change recently — new router, firewall, ISP, PBX update?

This narrows your focus immediately:

If internal-to-internal calls work but external calls have one-way audio, think NAT, firewall, or carrier.
If only certain phones have problems, think local network config or phone firmware.

1.2 Check SIP/SDP for media details

Capture the call on the PBX, SBC, or edge device and open it in Wireshark.

For the failing call:

Open the SIP INVITE — this is the caller's offer.
Open the 200 OK — this is the callee's answer.

Look at the SDP body in each:

c= line: the IP address where this side wants to receive media.
m=audio line: the port where it expects RTP to arrive.
Direction attributes: a=sendrecv, a=sendonly, a=recvonly, a=inactive.

Patterns that reveal the problem immediately:

If the side that cannot hear has a=recvonly or a=inactive, you already have a strong signal.
If SDP shows a private IP (192.168.x.x or 10.x.x.x) that the remote side cannot route to, you have a NAT or media relay problem.

1.3 Check NAT and firewall behavior

Most one-way audio problems come from NAT or firewalls. Look for:

Phones or the PBX behind NAT advertising private IPs in SDP — 192.168.x.x or 10.x.x.x going out to the internet.
Double NAT (ISP router + customer firewall) changing the source IP multiple times across legs.
UDP pinholes or NAT bindings that time out mid-call, silently cutting one direction of media.

Checks to run:

Is there an SBC or proper media relay between internal phones and the outside world?
Does the PBX have the correct external/public IP configured in its NAT settings?
Have any routers or firewalls been replaced or reconfigured recently?

1.4 Inspect RTP streams in Wireshark

In Wireshark, the VoIP Calls view gives you the fastest path to media analysis:

Go to Telephony → VoIP Calls, select the failing call, and open the flow sequence.
Open Telephony → RTP → RTP Streams to see each media leg separately.
Look at packet counts, loss percentage, and jitter on each stream.

What the numbers tell you:

One direction shows "0 packets" or 100% loss → that explains exactly which side has no audio.
RTP is present at the SBC but zero at the endpoint → the firewall or routing is dropping it in the last hop.
Both directions show packets but audio is distorted → congestion or codec mismatch rather than a missing path.

Wireshark also lets you play back each RTP stream — useful for confirming which direction is actually silent before spending time on root cause.

1.5 Check SIP ALG and RTP port ranges

Before closing the ticket, check the router and firewall:

Is SIP ALG enabled? SIP ALG rewrites SIP headers and SDP as packets pass through the firewall. It often introduces exactly the kind of IP and port corruption that causes one-way audio.
Are RTP port ranges (typically UDP 10000–20000) open bidirectionally between your network and the provider's media IPs?
Are UDP timeout values long enough to sustain long calls without the firewall closing the binding?

SIP ALG causes: one-way or no audio, failed registrations, and random dropped calls. The most common and effective fix is simply to disable SIP ALG and configure clean NAT with proper port forwarding.

2. Outbound works, inbound goes to voicemail, PBX sees nothing

Symptom: Users can call out normally. Inbound callers hit voicemail at the provider or in the cloud. The on-prem PBX — FreeSWITCH, Asterisk, 3CX, or similar — shows no incoming call attempts in its logs at all.

This pattern tells you two things immediately:

The provider is receiving inbound calls from the PSTN.
The provider is failing to deliver them to your PBX.

2.1 Check trunk registration and status

Start at the PBX:

Confirm the SIP trunk is registered and, more importantly, stays registered. A trunk that registers on startup but flaps afterward can look healthy until inbound traffic arrives.
Check PBX logs or the status page for the registration state and the last error code.

If registration flaps or fails intermittently:

The provider may mark your endpoint as unreachable and automatically route inbound calls to the failover destination — which is usually voicemail.
The fix is stable registration, not just registration on demand.

2.2 Verify DID routing at the provider

Log into the carrier portal or open a ticket with provider support:

Which trunk or destination is each DID mapped to?
Are there failover rules that route to voicemail when the trunk is unreachable or unregistered?

Quick tests to isolate:

Temporarily point the DID to a softphone or a cloud test destination and verify it rings through. This confirms the inbound path is working before your edge.
Check whether call forwarding or voicemail rules at the provider level are catching calls before they ever reach your SIP trunk.

2.3 Check inbound SIP visibility at the firewall and NAT boundary

If the provider confirms they are sending INVITEs to your public IP but your PBX logs show nothing, the problem is between the internet and the PBX:

Confirm SIP port forwarding (typically UDP/TCP 5060) points to the correct PBX internal IP.
Verify the PBX is actually listening on that IP and port — not bound to localhost or a different interface.
Check that no other device (an ATA, an old phone system, another instance of the PBX) is consuming the same public SIP port.

Also investigate the ISP router:

Is the ISP modem/router in bridge mode, giving your firewall a direct public IP? Or is there double NAT — the ISP device doing NAT and your firewall doing NAT again?
Is SIP ALG on the ISP-provided device intercepting inbound SIP before your firewall even sees it?

2.4 Compare working outbound with missing inbound using captures

Run packet captures at the firewall or PBX:

On outbound calls: note which source IP and port your PBX uses, and what the provider records in the Contact header. This is the address the provider stores as your registration endpoint.
On inbound calls: capture at the firewall edge and check whether any SIP packets arrive at all.

If outbound works but inbound does not:

Your registration NAT may only be healthy outbound — the Contact header's public IP may not be reachable inbound because of asymmetric NAT, a missing rule, or a port conflict.
If the Contact header or the registered public IP/port is wrong, the provider delivers inbound calls to a dead endpoint and falls back to voicemail.

Your target is alignment between three things:

Provider's view of your registration — what IP and port they have on record for you.
Actual reachable address on your PBX — what IP and port are listening.
Firewall rules and NAT behavior in between — whether packets addressed to your public IP:port actually reach the PBX.

3. Dropped calls: fixed-timer vs random failures

Symptom: Calls connect, then drop — either at a consistent time interval (exactly 15, 30, or 60 minutes) or at random points during the call.

Distinguish these two patterns early. The cause and fix are completely different.

3.1 Calls dropping at a fixed interval

Fixed-interval drops are almost always a timer problem:

SIP session timers — Look at the Session-Expires and Min-SE headers in the INVITE and the 200 OK. If the session timer requires a re-INVITE or UPDATE to refresh the session and that message is blocked, times out, or gets a rejection, the call terminates cleanly at the timer boundary. It looks like a normal BYE, but it's actually the timer firing.

Check in a capture:

Are re-INVITE or UPDATE messages being sent before the timer expires?
Do they receive a valid 200 OK response?
Or do they time out, return an error, or simply disappear?

NAT and firewall binding timeouts — Many firewalls close UDP sessions after 30 or 60 seconds of inactivity. SIP and RTP use UDP. If the firewall closes the NAT binding mid-call:

Keepalives from the PBX or phone can no longer get through.
The remote end sends a re-INVITE that gets no response.
One side eventually sends a BYE and the call drops cleanly.

Fixes:

Increase UDP and SIP-specific timeout values in the firewall for VoIP traffic — 3600 seconds minimum for established SIP sessions.
Configure the PBX and endpoints to send regular keepalives — SIP OPTIONS pings, CRLF blanks, or RTP comfort noise — to hold NAT bindings open.

3.2 Calls dropping at random times

Random drops mean something is failing non-deterministically: real network quality problems, routing instability, hardware errors, or QoS misconfiguration.

In Wireshark, open Telephony → RTP → RTP Streams on a call that dropped:

Look at the loss percentage over time. High loss spikes just before the drop point at congestion or a bad link.
Look at the jitter graph. Sudden jitter spikes often correlate with congestion events or routing changes.
Look at burst loss patterns — many small gaps scattered across the stream suggests queue-related drops; a single long gap suggests a routing or link event.

Beyond Wireshark:

Pull interface error counters from your switch and router. CRC errors, runts, and discards indicate physical or duplex issues.
Look at bandwidth graphs — NetFlow, SNMP polling, or your monitoring platform — for spikes that align with the drop times.
Check QoS configuration. If voice packets are not in a prioritized queue, they get dropped first under congestion, and the result is choppy audio followed by a call drop.

Field note: inbound calls to voicemail, FreeSWITCH sees nothing

Two client sites, same complaint: outbound calls working, inbound calls going straight to carrier voicemail. FreeSWITCH logs at both locations showed nothing — no incoming INVITE, no rejection, no registration failure. The calls didn't fail at the PBX. They never arrived.

Both sites were running SIP over UDP. Switching to TCP fixed it at both.

The problem is in the REGISTER, not the call itself. When a FreeSWITCH PBX registers over UDP, the Contact header tells the carrier where to send inbound calls — the public IP and port it can be reached on. ISP SIP ALG intercepts UDP SIP in transit and rewrites headers it thinks need correcting. When it corrupts the Contact — wrong IP, dead port mapping, private address leaked in place of the public one — the carrier stores that as the delivery endpoint for the trunk. Inbound calls get sent to a broken address. Nothing answers. The carrier routes to failover voicemail. FreeSWITCH is clean because the INVITE was never addressed to it.

TCP bypasses this. Most SIP ALG implementations are built specifically around UDP/5060 inspection. A TCP connection on the same port is tracked as an established session, not intercepted as a SIP flow to assist. The REGISTER goes through with the original Contact intact. The carrier stores the correct address. Inbound calls start landing.

One-way audio was also present at both sites and likely resolved by the same change. ALG implementations that rewrite Contact in REGISTER will generally also rewrite c= in SDP — the media IP in the INVITE that controls where RTP gets sent. One transport switch, two failure modes cleared.

Why a LAN capture won't show this

Capturing on the PBX interface shows the outbound REGISTER with the correct Contact. The corruption happens at the CPE or in the ISP's edge, after the capture point. The packets look right going out. The PBX receives a 200 OK and considers itself registered — it has no way to know the carrier stored a broken address.

The symptom is also an exact match for two unrelated problems: a misconfigured DID routing rule at the carrier, or a genuinely failed registration. All three look identical from inside the network. Without evidence from the carrier side, you're eliminating possibilities, not confirming one.

Where the proof lives

The carrier echoes back the Contact it stored in the 200 OK to the REGISTER. That response is the artifact to find.

→ REGISTER sip:carrier.example.com SIP/2.0
  Contact: <sip:[email protected]:5060;transport=udp>

← SIP/2.0 200 OK
  Contact: <sip:[email protected]:5060>

A private IP in the carrier's 200 OK Contact means the REGISTER was rewritten in transit. The carrier has no legitimate path to 192.168.1.5. That's the address inbound calls were going to. That's why voicemail answered.

If there are PCAPs from before the TCP fix, this is what to look for: the 200 OK to the last REGISTER before inbound calls stopped reaching FreeSWITCH. If the Contact in that response doesn't match the PBX's public IP, the chain is complete.

With no LAN capture from the registration period, a carrier SIP trace pulled for that timestamp will show the same thing — exactly what Contact they received and stored.

Open question: 480 errors on outbound

Some of the same sites have also been producing intermittent 480 Temporarily Unavailable responses from the carrier on outbound calls. The timing and affected locations overlap with the inbound problem. The plausible mechanism: SIP ALG rewriting the Via or Contact headers in an outbound INVITE badly enough that the carrier can't route a response back, and returns 480 instead of completing the call.

Not confirmed. A 480 has other legitimate explanations and I haven't pulled a carrier SIP trace for one of the failing outbound calls yet. That's the next piece of evidence needed before drawing a conclusion.

Next steps: proving it faster and building detection into NetHero

At the next site:

The cleanest proof is a dual capture — one interface on the PBX, one on the WAN side of the CPE — running simultaneously while a REGISTER goes out over UDP. Compare the Contact header at both points. If it changes between capture positions, the device in between is the rewriter. No inference required.

Where WAN access isn't available: request a carrier SIP trace for the registration timestamp and the first failed inbound call. The carrier's trace shows exactly what Contact they have on file for the trunk. That's the answer without needing physical access to anything.

For the 480 investigation: pull a carrier SIP trace on the next outbound 480 immediately. The trace will show what headers they received. If the From, Via, or Contact are malformed or contain private addresses, ALG is the likely cause. If the headers look correct, it's something else.

What to add to NetHero:

The current SIP OPTIONS probe passes cleanly even on affected sites. OPTIONS doesn't carry a Contact the carrier stores or SDP that ALG rewrites — it just tests whether the SIP stack responds. It's blind to this failure mode.

Two checks would close the gap.

First, a registration Contact comparison: send a REGISTER (or passively observe one from the PBX) and compare the Contact URI in the outbound request against what the carrier echoes in the 200 OK. Any mismatch is a finding.

Second, a dual-transport Via comparison: send SIP OPTIONS over both UDP and TCP, compare the received= parameter the server echoes back in the Via header. If UDP returns a private IP while TCP returns the correct public IP, something in the path is treating the two transports differently — consistent with SIP ALG targeting UDP specifically.

Together they'd produce output like this:

SIP Registration:
  [WARN]  Contact mismatch on UDP REGISTER
          Sent:     sip:[email protected]:5060
          Returned: sip:[email protected]:5060
          → Carrier stored a private IP as the inbound delivery address.
            Inbound calls will not reach the PBX.
            Switch PBX to TCP transport. Confirm with WAN capture or carrier trace.

SIP Transport:
  [WARN]  UDP OPTIONS Via received=192.168.1.5
  [PASS]  TCP OPTIONS Via received=203.0.113.45
          → UDP path shows private IP in Via — consistent with SIP ALG in path.

Both checks would have surfaced this in under five minutes. No packet capture, no carrier call, no weeks of intermittent complaints before someone notices the pattern.

References

RFC 3261 — SIP — SIP message types, response codes, session timer behavior
RFC 3264 — SDP Offer/Answer Model — how INVITE/200 OK SDP negotiation actually works; the spec behind every media IP exchange discussed above
RFC 3550 — RTP — RTP header format, RTCP, jitter calculation
RFC 4566 — SDP — full SDP specification; defines the c=, m=, and a= lines referenced throughout
Wireshark — VoIP Calls Analysis — VoIP Calls view, RTP stream inspection, call flow diagrams
SIP.US — SIP ALG and VoIP — how SIP ALG rewrites packets and why it breaks media paths
Cato Networks — VoIP Troubleshooting Guide — session timer and NAT binding behavior
PathSolutions — VoIP Packet Loss — RTP quality metrics and packet loss analysis

Going deeper

Tools

sngrep — ncurses SIP flow viewer that runs directly on a server or SBC. Shows SIP dialogs color-coded in real time, far faster than opening Wireshark for SIP-specific work. For the Contact header comparison in the field note above, this would have surfaced the corruption in seconds. Install it on every FreeSWITCH box you manage.

SIPVicious — SIP security scanner suite. svmap finds SIP devices on a network, svwar enumerates extensions, svcrack tests credentials against a SIP server. Understanding what this looks like in your logs — and in a packet capture — is the practical foundation for hardening any PBX that touches the public internet. Any FreeSWITCH instance with a public IP will see automated scans within hours of deployment.

Homer / SIPCAPTURE — production SIP capture and replay platform. FreeSWITCH and Kamailio can ship HEP-encapsulated SIP traffic to a Homer instance in real time, giving you a searchable SIP trace database with call flow diagrams, RTP quality stats, and replay. This is what serious VoIP operations teams use instead of ad-hoc tcpdump. Directly relevant to the registration Contact comparison and transport probe work planned for NetHero.

Books

SIP: Understanding the Session Initiation Protocol — Alan Johnston, Artech House. The reference book for the protocol. Dense and accurate, covers NAT traversal, Contact header behavior, and the offer/answer model in the depth that the RFCs require but don't explain well. Read this alongside RFC 3261 and RFC 3264 and the protocol stops being mysterious.

Hacking VoIP: Protocols, Attacks, and Countermeasures — David Endler and Mark Collett, O'Reilly. Dated (2007) but still the foundational text for the security angle. Covers toll fraud patterns, SIP scanning, credential attacks, and media interception in enough technical depth to understand the threat model behind every hardening decision. The attack techniques have not changed as much as the publication date implies.