Reference12r1:Concept ICE

Applies To

This information applies to

• all innovaphone devices from V12r1

Overview

ICE is a protocol for finding and selecting a working network path between two media endpoints. The basic idea is that each endpoint discovers all its addresses that could be used to receive media. Those by priority sorted candidates are sent to the other endpoint. Then all combinations of local and remote candidates are tested. The first working combination is used for the actual media stream. If there is no working combination, the call will be disconnected.

ICE is designed to solve the following problems:

NAT traversal

If an endpoint is behind NAT, ICE creates a NAT mapping using STUN. Even if both sides are behind NAT, ICE can successfully establish a connection.

Avoid no media / one-way media

Only network paths are chosen for media that work in both directions. So there is no risk of one-way media. If there is no appropriate path, the call can be disconnected automatically.

IPv4 and IPv6

ICE also selects the IP version that is supported by both endpoints. This is good news for migrating from IPv4 to IPv6 because there is no extra configuration change to be done if more and more endpoints support IPv6.

Candidate types

ICE supports different types of candidates:

Host

The local address of a network interface.

Server reflexive

The address as seen by the STUN server. If the endpoint is behind NAT this candidate reflects a NAT mapping.

Peer reflexive

The address as seen by the remote endpoint. If the endpoint is behind NAT this candidate reflects a NAT mapping.

Relay

The address of an allocated channel on a public TURN server. This candidate should always work.

Each SRFLX, PRFLX or RELAY candidate is related to a single HOST candidate.

Protocol flow

Gathering

When a call is started the local endpoint needs to discover all the IP addresses and ports it can use for receiving media. This process is called gathering. It is done for all components of the call (RTP, RTCP, T.38). Endpoints that are behind NAT create NAT mappings using requests to a STUN server that are sent from the same port that will be used for the media stream. If TURN is configured, the endpoint also allocates a relay channel on the TURN server. Each endpoint generates a priority-sorted list of possible paths.

innovaphone endpoints return the following candidates for each network interface, if given:

• HOST candidates (addresses of local network interfaces)
  • IPv4
  • IPv6 SiteLocal
  • IPv6 Global
• SRVFLX candidates (NAT mappings)
  • IPv4
• RELAY candidates (channels on TURN server)
  • IPv4

Transmission of the candidates

The local candidates are sent to the other endpoint using the signalling protocol as part of the offer or answer. If an endpoint has got both the local and remote candidates it starts the connectivity checks.

Connectivity checks

Each endpoint pairs up the local and remote candidates with the same IP version. Then it starts checking all the candidate pairs by sending special STUN requests to the remote party. If it receives the corresponding STUN response it knows that the network path works.

During the connectivity checks the endpoint might learn additional peer reflexive candidates of the remote endpoints. Checks for that candidates are added dynamically.

Nomination

ICE defines roles for the two endpoints of a connection: controlling and controlled. The controlling endpoint nominates one of the working candidate pairs that should be used for media. This is done by another STUN request that contains a special attribute.

Media establishment

After nominating a working candidate pair the media stream is started. If no working path was discovered after a timeout the call is terminated.

Configuration

ICE is the default call establishment mechanism, so it does not have to be enabled.

However some SIP providers can't handle the ICE parameters correctly. In that case you can deactivate ICE for specific SIP interfaces using the "No ICE" checkmark.

STUN and TURN servers

The STUN and TURN servers can be configured at the following places:

• For many boxes using the DHCP Server (on page IP4/ETHx/DHCP-Server)
• For an individual box (on page IP4/General/STUN)

The STUN server is used for gathering server reflexive candidates.

The TURN server is used for gathering relay candidates.

See Reference12r1:IP4/General/STUN for configuration details.

Tracing

Activation

Traces for debugging ICE can be activated at the signalling module. The trace flags are also available on the debug.xml page.

config add H323 /ice-trace on
config add SIP /ice-trace on
config add TSIP /ice-trace on
config add SIPS /ice-trace on

Reading traces

When a new call is started the local candidates are gathered. In the trace this process starts with the Initialize line and ends with Initialized followed by the gathered candidates.

 ICE.0: Initialize STUN1(151.80.245.241:3478, :::0) STUN2(:::0, :::0)
 ICE.0: Found HOST address 172.16.13.44 (registration)
 ICE.0: STUN :::16398 -> 151.80.245.241:3478 Request
 ICE.0: STUN :::16399 -> 151.80.245.241:3478 Request
 ICE.0: TURN Allocate req
 ICE.0: Found HOST address 172.16.13.44 (interface)
 ICE.0: Found HOST address fec0:9033:0:8:290:33ff:fe30:b4 (interface)
 ICE.0: Found HOST address 2002:91fd:9d04:0:290:33ff:fe30:b4 (interface)
 ICE.0: Gathering HOST candidates finished
 ICE.0: STUN 172.16.13.44:16399 <- 151.80.245.241:3478 Response
 ICE.0: STUN 172.16.13.44:16398 <- 151.80.245.241:3478 Response
 ICE.0: Found SRFLX address 145.253.157.7
 ICE.0: Gathering SRFLX candidates finished
 ICE.0: TURN Allocate result Unauthorized: re-authorizing
 ICE.0: TURN Allocate req after Unauthorized
 ICE.0: TURN Allocate result parsing error
 ICE.0: TURN Allocate res
 ICE.0: Found RELAY address 151.80.245.241
 ICE.0: Gathering RELAY candidates finished
 ICE.0: Initialized local candidates RTP(172.16.13.44:16398) RTCP(172.16.13.44:16399) T38(172.16.13.44:0)
       CANDIDATES:LOCAL,count(5),fingerprint(447af6c5cfe3b66cf0901d9143f6824d4c5d0ba2ee8bd9d0ed9b9f69680277d0),usr(ofPn),pwd(10HnDJzxftsRScljuXfX8G)
      :HOST addr([172.16.13.44]:16398/16399) prio(2130569471/2130569726)
      :HOST addr([fec0:9033:0:8:290:33ff:fe30:b4]:16398/16399) prio(2121610495/2121610750)
      :HOST addr([2002:91fd:9d04:0:290:33ff:fe30:b4]:16398/16399) prio(2119051007/2119051262)
      :SRFLX addr([145.253.157.7]:21692/21693) related([172.16.13.44]:16398/16399) prio(1693083903/1693084158)
      :RELAY addr([151.80.245.241]:18034/18035) related([172.16.13.44]:16398/16399) prio(16642815/16643070)

In this example the STUN server 151.80.245.241:3478 is used. In the end ICE gathered candidates for 5 different IP addresses. One of them is the server reflexive address returned by the STUN server. Another one is the relay address returned by the TURN server.

In some cases the signaling protocol has to change the STUN username and password to avoid confusion after renegotiation. This is shown in the trace with the Update line followed by the updated candidates. The candidates are the same as the candidates from Initialized but with changed usr and pwd.

 ICE.0: Update local candidates
       CANDIDATES:LOCAL,count(5),fingerprint(),usr(6SsK),pwd(qUm/LVgK7XatqY7mMZ2p71)
      :HOST addr([172.16.13.44]:16398/16399) prio(2130569471/2130569726)
      :HOST addr([fec0:9033:0:8:290:33ff:fe30:b4]:16398/16399) prio(2121610495/2121610750)
      :HOST addr([2002:91fd:9d04:0:290:33ff:fe30:b4]:16398/16399) prio(2119051007/2119051262)
      :SRFLX addr([145.253.157.7]:21692/21693) related([172.16.13.44]:16398/16399) prio(1693083903/1693084158)
      :RELAY addr([151.80.245.241]:18034/18035) related([172.16.13.44]:16398/16399) prio(16642815/16643070)

When the call is answered, both sides start doing their connectivity checks. The controlling endpoint also nominates the candidate pair that should actually be used for sending media. This process starts with the Connect line and the remote candidates. When the ICE handshake is finished the used Checklist and Candidates are shown in the trace. In the end the connection state and the Conclusion is shown.

 ICE.0: Connect media=audio role=controlling stun=standard
       CANDIDATES:REMOTE,count(4),fingerprint(),usr(uy5m),pwd(hLwy6Y0VTasqGnW7sBoWfO)
      :HOST addr([172.16.13.45]:16386/16387) prio(2130569471/2130569726)
      :HOST addr([fec0:9033:0:8:290:33ff:fe2f:688a]:16386/16387) prio(2121610495/2121610750)
      :HOST addr([2002:91fd:9d04:0:290:33ff:fe2f:688a]:16386/16387) prio(2119051007/2119051262)
      :SRFLX addr([145.253.157.7]:21704/21705) related([172.16.13.45]:16386/16387) prio(1693083903/1693084158)
 ICE.0: RTP check RTP(172.16.13.44:16398 -> 172.16.13.45:16386 in-progress), RTCP(172.16.13.44:16399 -> 172.16.13.45:16387 frozen)
 ICE.0: STUN 172.16.13.44:16398 -> 172.16.13.45:16386 Request
 ICE.0: STUN 172.16.13.44:16398 <- 172.16.13.45:16386 Response
 ICE.0: RTP checked RTP(172.16.13.44:16398 -> 172.16.13.45:16386 succeeded), RTCP(172.16.13.44:16399 -> 172.16.13.45:16387 frozen)
 ICE.0: STUN 172.16.13.44:16398 -> 172.16.13.45:16386 Request
 ICE.0: STUN 172.16.13.44:16398 <- 172.16.13.45:16386 Response
 ICE.0: RTP nominated RTP(172.16.13.44:16398 -> 172.16.13.45:16386 succeeded), RTCP(172.16.13.44:16399 -> 172.16.13.45:16387 frozen)
 ICE.0: STUN 172.16.13.44:16399 -> 172.16.13.45:16387 Request
 ICE.0: STUN 172.16.13.44:16398 <- 172.16.13.45:16386 Request
 ICE.0: STUN 172.16.13.44:16398 -> 172.16.13.45:16386 Response
 ICE.0: STUN 172.16.13.44:16399 <- 172.16.13.45:16387 Request
 ICE.0: STUN 172.16.13.44:16399 -> 172.16.13.45:16387 Response
 ICE.0: STUN 172.16.13.44:16399 <- 172.16.13.45:16387 Response
 ICE.0: RTCP nominated RTP(172.16.13.44:16398 -> 172.16.13.45:16386 nominated), RTCP(172.16.13.44:16399 -> 172.16.13.45:16387 nominated)
 ICE.0: Checklist
      +RTP(172.16.13.44:16398 -> 172.16.13.45:16386 nominated), RTCP(172.16.13.44:16399 -> 172.16.13.45:16387 nominated)
      -RTP(fec0:9033:0:8:290:33ff:fe30:b4:16398 -> fec0:9033:0:8:290:33ff:fe2f:688a:16386 waiting), RTCP(fec0:9033:0:8:290:33ff:fe30:b4:16399 -> fec0:9033:0:8:290:33ff:fe2f:688a:16387 frozen)
      -RTP(fec0:9033:0:8:290:33ff:fe30:b4:16398 -> 2002:91fd:9d04:0:290:33ff:fe2f:688a:16386 waiting), RTCP(fec0:9033:0:8:290:33ff:fe30:b4:16399 -> 2002:91fd:9d04:0:290:33ff:fe2f:688a:16387 frozen)
      -RTP(2002:91fd:9d04:0:290:33ff:fe30:b4:16398 -> fec0:9033:0:8:290:33ff:fe2f:688a:16386 waiting), RTCP(2002:91fd:9d04:0:290:33ff:fe30:b4:16399 -> fec0:9033:0:8:290:33ff:fe2f:688a:16387 frozen)
      -RTP(2002:91fd:9d04:0:290:33ff:fe30:b4:16398 -> 2002:91fd:9d04:0:290:33ff:fe2f:688a:16386 waiting), RTCP(2002:91fd:9d04:0:290:33ff:fe30:b4:16399 -> 2002:91fd:9d04:0:290:33ff:fe2f:688a:16387 frozen)
      -RTP(172.16.13.44:16398 -> 145.253.157.7:21704 waiting), RTCP(172.16.13.44:16399 -> 145.253.157.7:21705 frozen)
      -RTP(151.80.245.241:18034 -> 172.16.13.45:16386 waiting), RTCP(151.80.245.241:18035 -> 172.16.13.45:16387 frozen)
      -RTP(151.80.245.241:18034 -> 145.253.157.7:21704 waiting), RTCP(151.80.245.241:18035 -> 145.253.157.7:21705 frozen)
 ICE.0: Candidates
       CANDIDATES:LOCAL,count(5),fingerprint(447af6c5cfe3b66cf0901d9143f6824d4c5d0ba2ee8bd9d0ed9b9f69680277d0),usr(ofPn),pwd(10HnDJzxftsRScljuXfX8G)
      :HOST addr([172.16.13.44]:16398/16399) prio(2130569471/2130569726)
      :HOST addr([fec0:9033:0:8:290:33ff:fe30:b4]:16398/16399) prio(2121610495/2121610750)
      :HOST addr([2002:91fd:9d04:0:290:33ff:fe30:b4]:16398/16399) prio(2119051007/2119051262)
      :SRFLX addr([145.253.157.7]:21692/21693) related([172.16.13.44]:16398/16399) prio(1693083903/1693084158)
      :RELAY addr([151.80.245.241]:18034/18035) related([172.16.13.44]:16398/16399) prio(16642815/16643070)
       CANDIDATES:REMOTE,count(4),fingerprint(),usr(uy5m),pwd(hLwy6Y0VTasqGnW7sBoWfO)
      :HOST addr([172.16.13.45]:16386/16387) prio(2130569471/2130569726)
      :HOST addr([fec0:9033:0:8:290:33ff:fe2f:688a]:16386/16387) prio(2121610495/2121610750)
      :HOST addr([2002:91fd:9d04:0:290:33ff:fe2f:688a]:16386/16387) prio(2119051007/2119051262)
      :SRFLX addr([145.253.157.7]:21704/21705) related([172.16.13.45]:16386/16387) prio(1693083903/1693084158)
 ICE.0: Connected successfully RTP(172.16.13.44:16398 -> 172.16.13.45:16386, 0 retries) RTCP(172.16.13.44:16399 -> 172.16.13.45:16387, 0 retries)
 ICE.0: Conclusion SUCCESS

If ICE fails the trace shows the following lines.

 ICE.0: Connection failed (no working network path found)
 ICE.0: Conclusion FAILED

If ICE was aborted because of termination or renegotiation of the call the trace shows the following lines.

 ICE.0: Connection aborted (ICE might have failed at remote endpoint)
 ICE.0: Conclusion ABORTED

There might be some retransmissions and additional checks after ICE is finished. They can be ignored.

 ICE.0: STUN 172.16.13.44:16398 <- 172.16.13.45:16386 Request
 ICE.0: STUN 172.16.13.44:16398 -> 172.16.13.45:16386 Response
 ICE.0: STUN 172.16.13.44:16399 <- 172.16.13.45:16387 Request
 ICE.0: STUN 172.16.13.44:16399 -> 172.16.13.45:16387 Response
 ICE.0: TURN Refresh req after timeout
 ICE.0: TURN Refresh req after timeout
 ICE.0: TURN Refresh res
 ICE.0: TURN Refresh res

Incoming STUN requests before the Connect are answered with an error message. This is normal behaviour and can be ignored. It happens because both endpoints do not start ICE excactly at the same time.

 ICE.0: STUN 172.16.4.62:16390 <- 172.16.0.11:16922 Request
 ICE.0: STUN 172.16.4.62:16390 -> 172.16.0.11:16922 Error
 ICE.0: Connect media=audio role=controlling

Recommendation: To find out if ICE was successful, look for the line Conclusion.

Known limitations

• ICE trickling is not supported. This is by design of the underlying H.323 and SIP signalling.

References

• Reference12r1:IP4/General/STUN
• RFC5245 - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
• RFC5389 - Session Traversal Utilities for NAT (STUN)
• RFC5766 - Traversal Using Relays around NAT (TURN)