Reference11r1:Concept ICE: Difference between revisions
Line 74: | Line 74: | ||
config add TSIPS /ice-trace on | config add TSIPS /ice-trace on | ||
=== Reading traces === | === Reading traces === | ||
When a new call is started the local candidates are gathered. In the trace this process starts with the <code>Initialize</code> line and ends with <code>Initialized</code> followed by the gathered candidates. | |||
ICE.0: Initialize STUN(145.253.157.4:3478, :::0) | |||
ICE.0: STUN :::16398 -> 145.253.157.4:3478 Request | |||
ICE.0: STUN :::16399 -> 145.253.157.4:3478 Request | |||
ICE.0: STUN 192.168.0.103:16399 <- 145.253.157.4:3478 Response | |||
ICE.0: Gathered RTCP server reflexive address 145.253.157.4:50688 | |||
ICE.0: STUN 192.168.0.103:16398 <- 145.253.157.4:3478 Response | |||
ICE.0: Gathered RTP server reflexive address 145.253.157.4:50687 | |||
ICE.0: Initialized RTP(172.16.147.1:16398) RTCP(172.16.147.1:16399) T38(172.16.147.1:0) | |||
CANDIDATES:AUDIO,count(4),fingerprint(),usr(ZNsU),pwd(iTpVC0n6X6lpgajUAghxVn) | |||
:HOST addr([192.168.0.103]:16398/16399) prio(2129289471/2129289470) | |||
:SRFLX addr([145.253.157.4]:50687/50688) related([192.168.0.103]:16398/16399) prio(1693081855/1693081854) | |||
:HOST addr([2002:95ac:69a:e472:290:33ff:fe2f:1d5]:16398/16399) prio(2119049471/2119049470) | |||
:HOST addr([172.16.147.1]:16398/16399) prio(2130569471/2130569470) | |||
In this example the STUN server <code>145.253.157.4:3478<code> is used. In the end ICE gathered candidates for 4 different IP addresses. One of them is the server reflexive address returned by the stun server. | |||
== Known limitations == | == Known limitations == |
Revision as of 15:59, 26 August 2014
Applies To
This information applies to
- all innovaphone devices from V11
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 candidates are sent to the other endpoint. Then all combinations of local and remote candidates are tested. The best working combination is used for the actual media stream. If there is no working combination, the call can 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.
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.
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
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.
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
Disabling ICE
From v11 ICE is the default call establishment mechanism, so it does not have to be activated. However if needed it can be deactivated using an interop config option.
config add H323 /ice-disabled config add SIP /ice-disabled config add SIPS /ice-disabled config add TSIP /ice-disabled config add TSIPS /ice-disabled
STUN
The STUN server is used for gathering server reflexive candidates. The server configuration is a string in one of the following formats:
- a single DNS name and an optional port (e.g.
stun.example.com:1234
). - a comma separated list of one or two IP addresses and optional ports (e.g.
172.16.13.1:1234,172.16.13.2
).
The STUN server string 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)
- For an individual registration (as part of the configuration of the registration)
If it is configured in more than one place, the more specific one is used. For example the configuration at the registration overwrites the DHCP config.
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 SIPS /ice-trace on config add TSIP /ice-trace on config add TSIPS /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 STUN(145.253.157.4:3478, :::0) ICE.0: STUN :::16398 -> 145.253.157.4:3478 Request ICE.0: STUN :::16399 -> 145.253.157.4:3478 Request ICE.0: STUN 192.168.0.103:16399 <- 145.253.157.4:3478 Response ICE.0: Gathered RTCP server reflexive address 145.253.157.4:50688 ICE.0: STUN 192.168.0.103:16398 <- 145.253.157.4:3478 Response ICE.0: Gathered RTP server reflexive address 145.253.157.4:50687 ICE.0: Initialized RTP(172.16.147.1:16398) RTCP(172.16.147.1:16399) T38(172.16.147.1:0) CANDIDATES:AUDIO,count(4),fingerprint(),usr(ZNsU),pwd(iTpVC0n6X6lpgajUAghxVn) :HOST addr([192.168.0.103]:16398/16399) prio(2129289471/2129289470) :SRFLX addr([145.253.157.4]:50687/50688) related([192.168.0.103]:16398/16399) prio(1693081855/1693081854) :HOST addr([2002:95ac:69a:e472:290:33ff:fe2f:1d5]:16398/16399) prio(2119049471/2119049470) :HOST addr([172.16.147.1]:16398/16399) prio(2130569471/2130569470)
In this example the STUN server 145.253.157.4:3478
is used. In the end ICE gathered candidates for 4 different IP addresses. One of them is the server reflexive address returned by the stun server.
Known limitations
- ICE trickling is not supported. This is by design of the underlying H.323 and SIP signalling.
- TURN is currently not supported.
- In v11r1 only candidates from the first network interface and the registration address are gathered.
References