Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)
Extracted elements (15)
The 'ice' option tag addresses the case where an offerer wishes to abort a call rather than fall back to non-ICE operation, typically because it needs to advertise a different media address for non-ICE peers than for ICE-capable ones.
The 'sip.ice' media feature tag is introduced to support gateway deployments: when some UAs in a domain do not support ICE, a registrar tracking the tag allows proxies to route calls through ICE-capable gateways only when the terminating UA lacks ICE support.
ICE inherently requires both endpoints to support it. Within a domain, gateways acting as ICE agents on one side and non-ICE agents on the other allow ICE to be used on inter-domain calls even when the terminating device does not support ICE.
In INVITE requests that omit an offer, the presence or absence of the 'sip.ice' media feature tag in the Contact header cannot be used by the callee (acting as offerer) to determine whether the caller supports ICE.
In third-party call control scenarios (RFC 3725), the caller may be a controller whose ICE support is independent of the answering UA's ICE support, so the media feature tag in the Contact header may not accurately reflect the actual media endpoint's capabilities.
An agent MAY include the 'sip.ice' media feature tag in the Contact header field of an INVITE or INVITE response, though doing so is redundant with ICE attributes already present in the SDP.
An agent that supports ICE SHOULD include the 'sip.ice' media feature tag in the Contact header field of its REGISTER requests and OPTIONS responses.
The 'ice' option tag SHOULD NOT be used in conjunction with the Supported header field (including in responses to OPTIONS requests); its sole intended use is in the Require header field.
When the 'ice' option tag is placed in the Require header field of an INVITE request, the UAS must support ICE (full or lite) in order to process the call; otherwise the call must fail.
The 'ice' SIP option tag identifies the ICE extension. When present in a Require header field of an INVITE, it signals that the UAS must support ICE to process the call.
The 'sip.ice' media feature tag indicates that a SIP UA supports ICE, either as a lite or full implementation, meaning it is capable of including candidate attributes in an SDP offer or answer for at least one transport protocol.
A new SIP option tag 'ice' is registered per RFC 3261 Section 27.1. Its description: identifies the ICE extension; when present in a Require header field, indicates that ICE is required by an agent.
A new SIP tree media feature tag 'sip.ice' is registered per RFC 3840 Section 12.1, with ASN.1 identifier 1.3.6.1.8.4.22. The tag takes a Boolean value and indicates that the device supports ICE.
A malicious intermediary could insert a Require header containing the 'ice' option tag into a SIP message, causing a call to fail on a UAS that does not support ICE. This attack applies to any SIP option tag and is prevented by the SIPS mechanism defined in RFC 3261.
An intermediary could strip the 'sip.ice' media feature tag from a REGISTER or OPTIONS request, causing a call to bypass ICE processing that would otherwise have been used. The SIPS mechanism prevents this attack.