Can’t Hear Me Now? Let’s Fix Your CUCM Audio Issues — Together.

Ever been on a VoIP call that connected just fine, but… silence? You can see the call timer ticking, but nobody can hear anything. Super frustrating, right?

If you’re running Cisco Unified Communications Manager (CUCM) and everything looks like it’s working — signaling, ringing, connections — but there’s one-way audio (or no audio at all), chances are the problem isn’t with CUCM itself. One-way audio and no-way audio in CUCM (Cisco Unified Communications Manager) environments are extremely common and often frustrating. Fortunately, most of the root causes boil down to firewall, NAT, routing, or configuration issues. However, more often than not, it’s your firewall playing tricks on you.

Let’s talk about what’s really happening — and how Sideview’s CDR Reporting & Analytics App can help you get to the root of the problem fast:

First, Let’s Break Down How Calls Actually Work

So here’s the deal:

• Signaling (like SIP or SCCP) is what sets up the call. CUCM handles this part.

  • Think of it as the ​“handshake” – CUCM says, ​“Hey, here’s your call!”

• Media, aka the audio you hear (RTP), actually flows outside of CUCM — directly between the phones or devices.

That’s why your call can connect just fine (signaling works), but the actual voice (media) doesn’t get through. If your firewall is blocking media ports or mangling IP addresses, it’s like CUCM handed you a working phone… but nobody’s on the other end.

Let’s Troubleshoot This — Is It One-Way or No-Way Audio?

Start simple. Ask:

• Can only one person hear the other? That’s one-way audio.

• Can neither side hear anything? That’s no audio at all.

This will help you figure out where to look first.

Check Those Firewall Rules

Here’s what you need open:

• UDP ports 16384 – 32767, both directions, between all your VoIP stuff — phones, gateways, SIP trunks, Expressway, you name it.

A lot of folks open SIP ports (like ⁵⁰⁶⁰⁄₅₀₆₁) and think they’re done. Nope. That just covers signaling. If those RTP ports are blocked, you’ll still have silent calls.

Let’s Talk About SIP ALG (aka The Silent Killer)

SIP ALG is supposed to help by ​“fixing” SIP packets as they pass through your firewall. But spoiler alert — it usually does more harm than good.

It rewrites SIP headers in ways that confuse your endpoints. Suddenly your phone thinks it’s talking to one IP, but traffic’s coming from another. Sound disappears. Chaos ensues.

Pro Tip: Just disable SIP ALG. Unless you know you need it — and most people don’t — you’re better off without it.

Dig Into Those SIP Packets (It’s Easier Than It Sounds)

Fire up Wireshark or run debug ccsip messages on your Cisco devices. Look inside the SDP section of the SIP messages. You’re looking for:

• Private IPs being advertised when they shouldn’t be

• Incorrect IPs caused by bad NAT configurations

These are the breadcrumbs that’ll lead you to what’s really going wrong.

Using Expressway? Don’t Forget ICE and TURN

If you’re dealing with Mobile and Remote Access (MRA) through Expressway, make sure:

• TURN and STUN settings are in place

• ICE negotiation is completing properly

If ICE doesn’t finish, your media path won’t get set up, and — yep, you guessed it — no audio.

How Sideview’s Cisco CDR Reporting and Analytics app can jump start your understanding.

If you have our app running, go right now to ​“Investigate Calls” and click the ​“Edit Fields” button. Add the following fields: origIpAddr, destIpAddr, destMediaTransportAddress_​IP, destMediaTransportAddress_​Port, origMediaTransportAddress_​IP, origMediaTransportAddress_​Port. The latter four actually represent the IP addresses of the UDP traffic. You also might make sure that the orig_​gateway and dest_​gateway fields are selected as well, just to double check them. Last but not least add the quality field and perhaps one of: numberPacketsSent, numberPacketsReceived and/​or CS_​total (total concealed seconds). If you see any packets received or the CMR is showing concealed seconds, this can help differentiate severe intermittent quality issues from true one-way audio issues.

Even better, if you see the smoking gun there, you can just click the values to add them as search terms and if you’re lucky (unlucky?) combining search terms here, you might find this issue has been happening a lot more often than people think!

Don’t Forget These Tools

You’ve got options:

• Sideview CDR App + Splunk — Your command center for call analytics

• Wireshark — For the packet-level nerding out

• Cisco tools — debug ccsip messages, RTMT logs, and more

Final Checks (Run Through This List!)

Before you start swapping cables or blaming your provider, double-check:

• Are UDP ports 16384 – 32767 open both ways?

• Is NAT set up properly?

• Did you disable SIP ALG?

• Are RTP IPs in the SIP messages accurate and reachable?

• Is Expressway configured right?

• Have you looked at the CDR data in Sideview’s App?

Bonus Tip: Don’t Just Monitor — Alert!

Set up automatic alerts in Splunk with Sideview’s app. Get notified when:

• RTP quality drops (e.g., MOS < 3.5)

• Signaling errors pop up

• Call failures hit a certain threshold

Catch issues before users flood your inbox.

Wrapping It Up

Firewall misconfigurations are behind a ton of VoIP audio problems — and they’re sneaky. But once you understand how signaling and media actually work, and once you have tools like Sideview’s CDR App and Wireshark, you’re in control.

You don’t have to guess. You can see it. Fix it. And move on.

Ready to make troubleshooting less painful?

📞 Request a demo or learn more at SideviewApps​.com

Let’s Not Forget QoS — Because the Network Matters Too

Even if your firewall is squeaky clean and your NAT settings are flawless, bad audio can still sneak in.

Why? Because your VoIP packets are fighting for space on the network — and sometimes, they lose.

That’s where Quality of Service (QoS) comes in.

What is QoS?

QoS is like the VIP rope at a concert. It tells your network, ​“These voice packets? They go first.”

Without it, your VoIP traffic is treated the same as someone streaming cat videos or downloading a 500MB Windows update. And that’s how you end up with choppy audio, jitter, or dropped calls.

What You Should Be Doing

• Mark voice traffic with DSCP EF (Expedited Forwarding – DSCP 46)

• Prioritize RTP over SIP (media > signaling)

• Apply QoS policies on:

  • Switch ports (especially access ports where phones plug in)

  • WAN routers

  • Firewalls (if they inspect traffic)

• Monitor for:

  • Latency

  • Jitter

  • Packet loss

Just remember: QoS can’t fix a bad network — it only helps good networks prioritize what matters.

And Yes — You Can Track QoS Too

Guess what? Sideview’s CDR Reporting & Analytics App lets you see packet loss, jitter, and MOS scores right alongside your call records. That means you can catch degradation before it turns into a help desk ticket.

You can even filter:

• All calls with jitter over 30ms

• All calls with packet loss over 1%

• Any call with MOS under your quality threshold (e.g., 3.8)

The goal? Turn your CDR logs into a real-time quality dashboard.

Updated Troubleshooting Checklist

Let’s revise that checklist one more time:

• RTP Ports 16384 – 32767 open and bidirectional?

• NAT traversal working right?

• SIP ALG disabled?

• SDP IPs correct and reachable?

• Expressway settings verified?

• QoS tags in place and honored across the network?

• MOS/​jitter/​packet loss tracked in Sideview App?

Final Thought

Think of VoIP audio like a relay race. CUCM starts the handoff, firewalls can drop the baton, and your network needs to clear a smooth path for the runner (RTP). QoS makes sure nobody cuts in line.

Add tools like Sideview and Wireshark to the mix, and you’re not just troubleshooting — you’re running the show.