Contact center agents need to reliably connect to the cloud service that delivers their calls, no matter where the agent is located or what network they are connected to. Unless the agent’s computer happens to be directly connected to the internet (nearly impossible), their connectivity depends upon being able to traverse a NAT device. In this case, special protocols are used to identify the addresses the endpoints must use when sending packets to each other.
Interactive Connectivity Establishment (ICE) uses STUN and TURN to help WebRTC endpoints traverse a NAT device. If ICE fails to do its job, endpoints can’t communicate and your agent won’t be able to initiate or receive calls.
If you’re interested in learning more about the importance of WebRTC in the call center, check out our white paper: Cloud-based Contact Centers: the WebRTC Story.
What is ICE Data?
ICE Data describes the stages of address negotiation that occur during the protocol’s operation, including:
Waiting: needs the IP address of the remote party.
In-progress: checking connectivity with the remote party's IP address.
Failed: no connectivity established with the IP address pair.
Succeeded: connectivity established.
We separate these into failed calls, established calls, and reestablished calls. For our purposes, we consider failed calls to be when no connectivity is established.
Failure: In the case of no connectivity, you can check your ICE data to identify whether your agent received any host, server reflexive, peer reflexive or relay candidates. With a configured TURN server, candidates should be relay type.
Established, but Fails: When there is connectivity, but network disruptions cause the call to fail, this is an established but failed call. Endpoints will subsequently choose a different candidate pair based on priority in the succeeded state from the set of candidate pairs and induce an ICE restart. The new candidate pair’s nominated field should be set to true to indicate it is the most recently used candidate pair.
Reestablishment of Calls: Reestablishment of calls is often caused by handovers, like when candidate pairs change from the mobile network to Wi-Fi. You can use this to identify disruptions in call quality from handovers. In this case, an ICE restart will most likely be necessary.
Some valuable ICE data worth taking a look at includes timestamp data, local address, remote address, RTT, state, priority, bytes sent and received, and the STUN interval. You can find additional ICE data here.
Why is ICE Data an Important Set of WebRTC Metrics for Contact Centers?
ICE data is invaluable when diagnosing call quality issues. If your agents are having trouble establishing connections with the cloud service, this is where you want to look first. ICE data gives multiple different metrics for the local and remote candidates, so you can see if the issue is on the cloud provider side or agent side.
As a contact center, you want to maintain high quality audio. But even more than that, you want to be able to resolve call quality issues as quickly as possible. It is inevitable that call quality issues will crop up, so you need to have the tools at your disposal to resolve them efficiently. ICE data gives you this ability. Resolve your call quality issues faster, so you can keep your customers happier.
Download our latest metrics report for more information on WebRTC metrics in the industry.