You need to ensure you have the pegacti debug enabled and since we are dealing with screenpops you will need to enable client side debug. If you are using ocx control there is a screenpop log that can be setup, if its applet there is an applet log that can be set in the presence rule, or if its Long poll / http event you will need to a collect a F12 / console log (fiddler, wireshark, etc..).
Once you have all this in place you just need to recreate the behavior and then walk through the Pegacti log to see if the screenpop / alerting events ever hit PRPC and if so do they make it to the browser.
If you need more assistance than this I would suggest opening an SR.
I would use something like Task Manager to monitor the footprint of your Browser; perhaps there is a memory leak, and at some point the browser just gives up. If you see it increasing beyond reasonable bounds, this is a strong possibility.
If the user can run with Fiddler enabled and tracking, you can see if the Browser is attempting to contact the Server to manage the popup. The direct communication from the CTI server to the Browser will NOT show up in Fiddler, but Browser<==>Pega server will appear.
Finally, you might just do some JS debugging in pega_cti_callEventHandler.js
The listener "PhoneCallStateEvent" might not be getting registered. Or, there might have been a previous JS error in processing a previous callStateEvent, and this would have removed the listener. Or, the event might not be getting sent; do you see it in the CTI log?
You don't say what version of Pega you are running with, but see if your version of handleCallStateEvents encloses the bulk of the code in a try/catch block with a write to the screenpop log of "EXCEPTION Handling event" in case an exception occurs. If you don't have this, add it.