Cluster Partitioning
When georedundant clusters become partitioned from one another and cannot communicate over the network, both sites continue to operate 'normally,' in a split-brain configuration.
Recall that the ICE Server is unaware that it is even executing across different clusters. A partitioning event simply means each site will see the other as idle (generating no messages or configuration changes). End users connected to either site will be unaware that anything has happened on the other site. Configuration changes or signaling initiated on one site will not propagate to the other and this will have the following observable side effects:
Site A to Site B Telephony Disconnected
Private telephone call from a user on Site A to a user connected to Site B will not go through. The calling party will hear ring-back but the callee will not observe an incoming call. As soon as the sites reconnect, these signaling messages will be delivered. During a brief partition, this may manifest itself in a delay between when the call is placed and when the receiving party rings. If the call attempt is made and then aborted while the sites remain partitioned, the callee may experience a brief 'ring' / 'call declined' state on their device as both enqueued messages are eventually delivered, back-to-back.
Public telephone calls placed or received may be delayed or fail.
The ICE Telephony component—Instant Connect’s bridge to the telephone network—attaches itself to one cluster or the other. Thus, all telephone calls to the PSTN are treated as terminating on one site. Calls placed or received from the site opposite that which ICE Telephony is attached will fail in the same way described for private calls.
At this time, ICE does not support georedundant telephony integration.
An intercom established between users of different sites will not immediately appear on all dashboards.
Until the sites reestablish their link, the message indicating a user has been added to an intercom will not be delivered to users connected to another site. The initiating user will be unaware that the other users' dashboards have not been updated with the intercom channel.
Configuration changes made on one site will not appear to users of the other.
Any changes to system configuration (including channels or users that are added, removed or modified) that are made on one site will not be visible to users on the other. When modifying a channel configuration, this can result in different users utilizing different configuration values—Rallypoint, encryption mode, etc—and this may result in a partitioning of audio traffic even when the audio's bearer network is not itself partitioned.
Users may see inconsistent presence and location information.
Online/offline status indications as well as users' GPS location visible on the map will diverge between users connected to different sites. For example, consider a scenario in which Bill (connected to Site A) shares a channel with Brenda (connected to Site B). At some point, the sites become partitioned and while they are partitioned, Bill logs out of ICE. Brenda will continue to see Bill’s status as 'online' since the message that Bill logged out cannot be delivered to Brenda’s site.