Troubleshooting Missing SIP UPDATE Packets in CXone Session Timers

How-To-Articles
1

Troubleshooting Missing SIP UPDATE Packets in CXone Session Timers

Executive Summary & Architectural Context

In a NICE CXone deployment utilizing BYOC (Bring Your Own Carrier) or custom SIP proxy integration, maintaining the state of a long-running call is critical.

SIP is inherently a stateless protocol at the transport layer (UDP). To prevent firewalls from silently dropping connections during long periods of silence (like when a caller is listening to 45 minutes of hold music), the SIP RFC 4028 dictates the use of Session Timers. The two endpoints agree to send a “keepalive” packet-usually a SIP UPDATE or re-INVITE-every 10 to 15 minutes.

If CXone expects a SIP UPDATE from your carrier, and your carrier’s firewall blocks it, CXone assumes the carrier has crashed. To protect platform resources, CXone will execute a brutal, non-negotiable drop of the call. This masterclass details how to diagnose Session Timer mismatches, read the CXone SIP traces, and configure your Session Border Controller (SBC) to prevent 481 Call Leg/Transaction Does Not Exist errors.

Prerequisites, Roles & Licensing

  • Licensing: NICE CXone with Voice/BYOC enabled.
  • Roles & Permissions: Access to the CXone Contact History for tracing, and deep administrative access to your corporate SBC (e.g., AudioCodes, Oracle, Cisco CUBE).

The Implementation Deep-Dive

1. Reading the Initial SDP (The Session-Expires Header)

The timer negotiation happens in the very first millisecond of the call.

  1. When an inbound call hits CXone from your carrier, your carrier sends a SIP INVITE.
  2. Look at the raw SIP headers (using Wireshark on your SBC, or the CXone trace logs).
  3. Find the Session-Expires header.
    • Example: Session-Expires: 1800;refresher=uac
  4. The Translation: This header means: “We agree this call will automatically die in 1800 seconds (30 minutes) UNLESS one of us sends a refresh packet. The UAC (User Agent Client - your carrier) is responsible for sending the refresh.”

2. The Failure Condition (The 15-Minute Drop)

If the header says 1800, why do calls drop at exactly 15 minutes?

  1. RFC 4028 dictates that the refresher must send the ping at the halfway point of the expiry time to be safe. Half of 1800 is 900 seconds (15 minutes).
  2. At exactly 15 minutes, your carrier’s SBC attempts to send a SIP UPDATE to CXone.
  3. The Block: If your corporate edge firewall has a strict UDP timeout of 10 minutes, the state table for that UDP stream was deleted 5 minutes ago. The firewall intercepts the UPDATE packet and silently drops it.
  4. CXone sits waiting. The 1800 second timer fully expires. CXone executes a BYE and terminates the call.

3. The Architectural Fix (SBC Configuration)

You have three methods to fix this, depending on your network topology.

Method A: Lower the Session Timer (Best Practice)
Force the SBC to ping CXone faster than the firewall timeout.

  • Log into your SBC (e.g., AudioCodes).
  • Navigate to the SIP Profile assigned to the CXone trunk.
  • Change the Session-Expires value from 1800 to 600 (10 minutes) or 300 (5 minutes).
  • Result: The SBC will now send a SIP UPDATE every 2.5 minutes, keeping the firewall state permanently active.

Method B: Change the Refresher (The CXone Push)
If your firewall drops outbound UPDATE packets from your SBC, make CXone do the work.

  • In your SBC, change the SIP Profile to mandate refresher=uas (User Agent Server).
  • This forces CXone to be the entity responsible for sending the UPDATE packet into your network.

Method C: Disable Session Timers (The Nuclear Option)
If you absolutely cannot get UPDATE packets to pass through a volatile VPN/Firewall topology, you can disable them entirely.

  • Warning: This is an architectural anti-pattern. If a call drops ungracefully (e.g., a power outage at your site), CXone will never receive a BYE. Without Session Timers, the “ghost” call will remain active on the CXone platform indefinitely, consuming a port license and destroying your AHT metrics until an administrator manually kills it via the platform API.
  • In your SBC, strip the Supported: timer header from the initial INVITE.

Validation, Edge Cases & Troubleshooting

Edge Case 1: UPDATE vs re-INVITE

Some legacy PBXs do not support the SIP UPDATE method (RFC 3311).

  • The Trap: If CXone tries to refresh the session using an UPDATE, and your legacy PBX replies with a 405 Method Not Allowed, the session timer will fail, and the call will drop at the expiry.
  • Solution: Ensure your SBC is configured to perform Method Translation. If CXone sends an UPDATE, the SBC should intercept it, translate it into a standard re-INVITE (which legacy PBXs understand), and forward it.

Edge Case 2: Media Transcoding Mid-Call

If a Session Timer refresh uses a re-INVITE with SDP (Session Description Protocol), it forces a re-negotiation of the audio codecs.

  • Troubleshooting: If you experience “Dead Air” exactly at the 15-minute mark, the re-INVITE was successful, but the audio negotiation failed. Ensure your SBC is configured to reply to re-INVITEs with the exact same codec (e.g., G.711) established at the start of the call, rather than offering a new, incompatible codec like G.729.

Official References