]> Network Resonance

2483 E. Bayshore #212 Palo Alto CA 94303 USA ekr@networkresonance.com

Interactive Connectivity Establishment (ICE) is a technique for discovering a set of addresses which two peers can use to communicate, even in the face of topological obstacles such as NATs. Because the topologies in which ICE may be used are complex, a full ICE implementation is also fairly complex. Implementation which will only be deployed in settings where they have public addresses (e.g., SIP-PSTN gateways) can, however, be substantially simpler. This document describes a subset of ICE suitable for such implementations.

Network Address Translation (NAT) devices are a major obstacle to protocols in which a pair of network elements need to form a direct connection. In many cases, such elements are able to talk to each other directly using a signalling protocol such as SIP but for efficiency reasons want to send data (e.g., media over RTP ) directly. A number of techniques are available for traversing NATs, but entities need a mechanism for discovering which technique will work in its specific environment (and its peer's environment). Internet Connectivity Establishment (ICE) is such a technique. The basic principle behind ICE is that each entity collects all the addresses on which it might potentially be able to send and receive data. These may include its local address, addresses discovered via STUN or addresses provided by media relays . The peers then exchange these candidate addresses and try each potential pairing in priority order until they find one that is satisfactory. During the design of ICE, many implementors expressed concern about the complexity of the protocol and the difficulty of implementing it. This draft specifies a compatible simplified subset of ICE called "Passive ICE" which is suitable for implementations which will always be operated with public IP addresses. One particular environment where Passive ICE is intended to be useful is in SIP-PSTN gateways which are generally directly connected to the Internet.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The security considerations for this document are the same as those for full ICE.

This document has no actions for IANA.

This document is intended to mostly relieve the implementor of a passive-only ICE implementation from the burden of having to read and understand all of RFC XXXX [[Insert ICE RFC # here] . However, it is not intended to be a standalone document. Rather it is intended to be read in conjunction with RFC XXXX. We assume that the reader is roughly familiar with how ICE works and has read at least Sections 1-3 of RFC XXXX. Section , contains a description of the responsibilities of a POII (POII). Each section follows the same pattern: expository text followed by a pointer to the relevant section of RFC XXXX.

A POII behaves much like a normal ICE implementation, with three major differences: It only gathers candidate addresses from its own interfaces. It cannot be a controlling endpoint. It does not generate periodic checks but only responds to periodic checks from other endpoints. A POII can interoperate with a normal ICE implementation. Two POIIs will interoperate but will not do ICE.

Like any ICE implementation, a POII gathers candidates. However, unlike full ICE implementations, a POII gathers them only from its locally attached interfaces (host candidates). Other kinds of candidates are not necessary because a POII by definition has a public IP address. See: Sections 2.1 (paragraphs 1,2), 5.1 (paragraphs 1, 2, 3)

As with full-mode ICE, the candidates must be prioritized. However, a POII will only have one candidate type: host. The type preference SHOULD be set to 126. The endpoint SHOULD set the local preferences counting down from 65535. Thus, a dual-homed endpoint SHOULD use the values 65535 and 65534. The component IDs are set as in RFC XXXX. Using these settings, a singly-homed endpoint which wished to do RTP only would have a single candidate with priority 2130706431 (0x7effffff) A dual-homed endpoint which preferred interface A to interface B and wanted to do both RTP and RTCP would have: InterfaceProtocolPriority ARTP2130706431 (0x7effffff) ARTCP2130706430 (0x7efffffe) BRTP2130706175 (0x7efffefe) BRTCP2130706174 (0x7efffefe) See: Section 5.2.

Once the candidates are gathered, a POII must encode them in an SDP offer or answer. All candidates MUST be marked as host candidates. In addition, a POII must set the "a=ice-passive" session-level attribute in order to indicate that it is not a full ICE implementation. See: Sections 5.4, 6.7

[TODO]

During ICE discovery, a POII will Binding Requests on the bases of some or all of the candidates it included in its most recent offer or answer. When such a Binding Request is received, the POII MUST: Generate a STUN binding response. If the candidate pair is not currently on the check list add it to the check list and start a triggered check for this candidate pair. See: Sections 8.2 (paragraphs 1-6).

See: Section 8.1.

A POII may not be a controlling ICE endpoint. Therefore, from its perspective ICE terminates when each component has at least one Valid candidate pair marked selected (i.e., a check on that candidate pair has been received with the USE-CANDIDATE attribute set). See: Section 9.

&RFC1889; &RFC2119; &I-D.ietf-mmusic-ice; &RFC3261; &RFC3489; &I-D.ietf-behave-turn;