Troubleshooting SIP Trunking and Voice Quality (MOS) in CXone

How-To-Articles
1

Troubleshooting SIP Trunking and Voice Quality (MOS) in CXone

Executive Summary & Architectural Context

When a contact center transitions to NICE CXone, the telephony architecture shifts from a local PBX (Private Branch Exchange) to a cloud-native SBC (Session Border Controller). This introduces the public internet-or dedicated MPLS circuits-as a critical failure point in the voice path.

If agents report “robotic voices,” “one-way audio,” or “dropped calls,” the issue is rarely the CXone routing engine. The root cause is almost always SIP (Session Initiation Protocol) signaling failures or RTP (Real-Time Transport Protocol) packet degradation.

To resolve these issues, engineers must abandon anecdotal agent complaints (“the call sounded bad”) and rely strictly on MOS (Mean Opinion Score) telemetry and SIP ladder diagrams. This masterclass details how to extract voice quality metrics in CXone, identify the exact network hop causing degradation, and troubleshoot common codec and firewall misconfigurations.

Prerequisites, Roles & Licensing

  • Platform: NICE CXone.
  • Roles & Permissions: Admin > Telephony or Reporting > Pre-built Reports.
  • Platform Dependencies:
    • A basic understanding of SIP response codes (e.g., 480, 503) and network latency metrics (Jitter, Packet Loss).

The Implementation Deep-Dive

1. Extracting the MOS (Mean Opinion Score)

MOS is a mathematical representation of call quality on a scale of 1.0 (unintelligible) to 5.0 (perfect clarity). In modern VoIP, a MOS below 3.5 is considered unacceptable and will generate agent complaints.

  1. In CXone, navigate to Reporting > Pre-built Reports.
  2. Run the Contact History report.
  3. This report provides the global MOS for the entire interaction.
  4. The Limitation: The Contact History MOS is an average. If a 10-minute call has 9 minutes of perfect audio (MOS 4.5) and 1 minute of severe robotic distortion (MOS 1.2), the average might still look acceptable (MOS ~4.0). You must dig deeper.

2. Isolating the Degraded Leg (Agent vs. Customer)

A contact center call consists of two distinct legs bridged by the CXone SBC:

  • Leg A: Customer to CXone SBC.
  • Leg B: CXone SBC to Agent (via WebRTC or physical SIP phone).

If a call has terrible MOS, you must identify which leg failed.

  1. Use the CXone Agent Leg Quality reports or the underlying APIs to extract the specific RTP metrics for the agent’s WebRTC connection.
  2. If Leg B (Agent) shows high jitter and packet loss, but Leg A (Customer) is clean, the issue is the agent’s local network (e.g., they are on weak Wi-Fi).
  3. If Leg A (Customer) is degraded, the issue lies with the PSTN carrier or the customer’s cell reception. CXone cannot fix a customer calling from a tunnel.

3. Diagnosing One-Way Audio

One-way audio (the agent can hear the customer, but the customer hears dead air) is the most common firewall issue in cloud telephony.

  • The Cause: SIP signaling establishes the call over Port 5060/5061, but the actual audio (RTP) traverses a massive range of dynamic UDP ports (typically 10000 - 20000). If a corporate firewall restricts outbound UDP traffic, the RTP packets from the agent’s browser will be blocked.
  • The Fix: The corporate IT team must strictly whitelist the CXone RTP port ranges and IP subnets. Stateful Packet Inspection (SPI) and SIP ALG (Application Layer Gateway) must be explicitly disabled on all corporate firewalls and agent home routers, as these protocols aggressively mangle SIP headers and drop UDP streams.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Codec Mismatches (G.711 vs G.729)

If calls are connecting but sound artificially compressed or “underwater,” you may have a codec mismatch.

  • Troubleshooting: CXone prefers G.711 (uncompressed, high bandwidth, high quality). If an agent is working remotely on a constrained DSL connection, their softphone might attempt to negotiate G.729 (highly compressed, low bandwidth).
  • Solution: Check the SIP INVITE trace (available via CXone support or your local SBC logs) to see the SDP (Session Description Protocol) offer. Ensure that your corporate network has sufficient bandwidth (at least 100kbps symmetrical per concurrent call) to support G.711 without falling back to compressed codecs.

Edge Case 2: The “Dropped Call” at Exactly 30 Minutes

If calls disconnect at precisely 15 or 30 minutes, this is a known SIP Session Timer failure.

  • The Cause: The SIP protocol periodically sends a Re-INVITE or UPDATE message to verify both parties are still connected. If a firewall or NAT router drops this mid-call update, the SBC assumes the endpoint is dead and forcibly terminates the call.
  • Solution: This requires a PCAP (Packet Capture) analysis. You must prove that the Session Timer UPDATE packet sent by the CXone SBC was dropped by the corporate firewall. IT must adjust the UDP timeout limits on the firewall edge.

Official References