3.12.4 Support for ICE

ICE is supported for ONNET calls only, for OFFNET it is disabled. The ICE framework provides a mechanism for finding the most efficient media path. The preference is set for direct peer to peer calls between users.

 Call request is sent from client A to B using SIP through voipswitch. When answered by B both dialers start sending packets to one another trying direct path – to their NATs IP addresses, and the path via media relay server. In most cases (more than 95% of NATs) the peer to peer path will be established successfully. If for some reasons the direct path cannot be established the ICE framework will seamlessly connect through the server.

The ICE framework comprises a set of mechanisms which not only help to find the best route but also are the most efficient in NAT traversing. ICE has been selected also by the WebRTC and is now obligatory in their standard.

In our RCS clients the media relay server can be either voipswitch or a TURN server configured in the clients explicitly. It depends only on your deployment plan.

In the case when voipswitch is used as media relay server the RCS client A gathers only reflexive (IP of NAT as seen from the server side) and host ICE candidates. It does not establish any binding with server. When the ICE candidates are sent in SDP in the INVITE request the voipswitch checks the SDP and if the ICE relay candidate is missing it adds own IP address and port as the relay candidate which is sent to client B. The same with 200 OK from B, before it is forwarded to A the relay voipswitch candidate is added.

Another method is to use separate TURN server. In this case the softphone has to have the IP or FQDN of TURN server added to its settings. This configuration has to be done on the client application before it is compiled. When TURN is used the client during ICE candidates gathering procedure sends binding request to the TURN server which responds with IP and port which should be passed to B as the relay candidate.