Pega Call UI Issues

General
1

We’re looking to compare notes with other contact centers using Pega Call (with Cisco ICM) around some phone UI stability behaviors we’ve been observing. We’re hoping the community can help confirm whether this is a common pattern or something environment‑specific.

Environment (High Level)

  • Pega Platform with embedded Pega Call

    • Websockets with long polling fallback

  • Cisco telephony backend:

    • Cisco ICM (server‑side integration)

  • Agents often remain logged in for long‑running sessions (30+ minutes)

  • Sessions may be idle, in ACW, or on long calls during these periods

What We’re Seeing (Observed Behavior)

  • Pega Phone UI like agent state and phone buttons being out of sync with Cisco ICM
  • Agents report it looks like they were logged out of the phone, pega still showing the transfer/conferencing options from the previous call, unable to change state or perform call functions.
  • However
    • Calls are not dropped
    • Agent stat and device state appear intact in Cisco
    • CTI and Pega Server logs generally look normal
  • We see on the console logs websockets being disconnected by code 1006
  • Access logs showing 3600 websocket connections and 137k long polling connections.
  • Non-phone Pega UI actions typically continue to work.

Early Signals / Hypotheses

1. UI Session vs CTI Session May Be the Key Difference

  • Cisco CTI sessions appear to remain active even when the Pega phone UI resets

  • This suggests the issue may be related more to the browser‑to‑Pega UI session than to CTI itself

2. Transport Behavior (WebSocket vs Long‑Poll) Might Matter

  • In access/network logs, we see a mix of WebSocket and long‑poll traffic

  • Long‑poll appears to be used when WebSocket connections fail or are closed

  • It’s unclear whether:

    • WebSockets are being closed upstream (LB, proxy, security device), or

    • The browser is switching transport modes under certain conditions

This behavior sits in an uncomfortable gray area:

  • CTI looks healthy

  • The application recovers

  • Agents are confused

  • Logs don’t show obvious hard failures

We’re trying to understand whether this is:

  • A known pattern with embedded CTI and long‑lived UI sessions

  • A common WebSocket / session management consideration

  • Something others have tuned around (timeouts, keep‑alives, UX patterns)

  • Or something unique to our environment

Questions for Others Using Pega Call

  • Have you seen similar “phone looks logged out but actually isn’t” behavior?

  • Does this typically correlate with long‑running or idle agent sessions?

  • Have you had to tune WebSocket idle timeouts or transport behavior specifically for Pega Call?

  • Are there best practices you’ve adopted to make this less visible to agents?

  • Is this considered “expected but manageable” in some call centers?

Any experiences, confirmations, or counter‑examples would be really helpful as we continue investigating.

Thanks in advance for any insights you’re willing to share.