Open CTI Standby URL implementation limitations and how to workaround them when the primary server is down.
|Knowledge Article Number||000232974|
|Description||Below are the couple of Open CTI Standby URL implementation limitations and how to workaround them when the primary server is down.|
|Resolution||1) Page reload is required when primary server is down. when the primary server is down it's required to reload the page for switch over to secondary.Salesforce doesn't provide notifications for server down.
Ans: The check for initialization and switchover to standby URL happens when the softphone is first loading. If the primary server goes down after it has already loaded then the softphone wouldn't know about it. Only when the page gets refreshed and the softphone tries to load again will it notice the primary server is unavailable after it timeouts, then it switches over to the standby URL. Or if they've customized it using the notifyInitializationComplete method, the same thing applies. We only wait for the call to notifyInitializationComplete during the loading of a softphone.
2) Clear SF cookies when primary is up again. When the salesforce loaded softphone from standby/secondary server ( and when primary server is up and running) it requires to clear cookies to take the primary again.
Ans: This is based on a session ID, so when you log out of Salesforce and then log back in, you should then reconnect to the primary server if it's back up. Because session ID is a cookie called "sid" deleting cookies would have the same effect as logging out. This is by design because if you are connected to a standby server then you refresh the page, you could lose any call info that might be stored on the standby server when you switch to the primary. So we only switch servers from standby back to primary after a session is definitely ended via logout.