Indicating Support for Interactive Connectivity Establishment
(ICE) in the Session Initiation Protocol (SIP)
Cisco
Edison NJ
US
jdrosen@cisco.com
http://www.jdrosen.net
RAI
SIP
SIP
NAT
This specification defines a media feature tag and an
option tag for use with the Session Initiation Protocol
(SIP). The media feature tag allows a UA to communicate to
its registrar that it supports ICE. The option tag allows
a User Agent (UA) to require support for ICE in order for
a call to proceed.
RFC 3264 defines a two-phase exchange of
Session Description Protocol (SDP) messages for the purposes of establishment
of multimedia sessions. This offer/answer mechanism is used by
protocols such as the Session Initiation
Protocol (SIP).
Protocols using offer/answer are difficult to
operate through Network Address Translators (NAT). Because their
purpose is to establish a flow of media packets, they tend to carry IP
addresses within their messages, which is known to be problematic
through NAT . To remedy this, an extension to
SDP, called Interactive Connectivity Establishment (ICE) has been
defined . ICE defines procedures
by which agents gather a multiplicity of addresses, include all of
them in an SDP offer or answer, and then use peer-to-peer Simple
Traversal Underneath NAT (STUN) connectivity checks to determine
a valid address.
This specification defines a media feature tag, "sip.ice", and a SIP
option tag, "ice", that can be used by SIP user agents that make use
of ICE. motivates the need for the media feature tag
and option tag, and and
formally define them.
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 RFC 2119.
There are two primary motivations for defining an option tag and a
media feature tag. They are support for gateways, and requiring ICE
for a call.
Unfortunately, ICE requires both endpoints to support it in order for
it to be used. Within a domain, there will typically be user agents
that do and do not support ICE. In order to
facilitate deployment of ICE, it is anticipated that domains will make
use of gateways which act as ICE agents on one side, an non-ICE agents
on the other side. This would allow a call from domain A into domain B
to make use of ICE, even if the device in domain B does not itself yet
support ICE. However, when domain B receives a call, it will need to
know whether the call needs to pass through such a gateway, or whether
it can go to the terminating UA directly.
In order to make such a determination, this specification defines a
media feature tag, "sip.ice", which can be included in the Contact
header field of a REGISTER request . This
allows the registrar to track whether a UA supports ICE or not. This
information can be accessed by a proxy in order to determine whether a
call needs to route through a gateway or not.
Although ICE provides a built in fall back to non-ICE operation when
the answerer doesn't support it, there are cases where the offerer
would rather abort the call rather than proceed without
ICE. Typically, this is because they would like to choose a different
m/c-line address for a non-ICE peer than they would for an ICE capable
peer.
To do this, the "ice" SIP option tag can be included in the Require
header field of an INVITE request.
The "sip.ice" media feature tag indicates support for ICE. An agent
supports ICE if it is either a lite or full implementation,
and consequently, is capable of
including candidate attributes in an SDP offer or answer for at least
one transport protocol. An agent that supports ICE SHOULD include this
media feature tag in the Contact header field of its REGISTER requests
and OPTION responses.
An agent MAY include the media feature tag in the Contact header
field of an INVITE or INVITE response; however, doing so is redundant
with ICE attributes in the SDP which indicate the same thing. In cases
where an INVITE omits an offer, the lack or presence of the media
feature tag in the Contact header field cannot be used by the callee
(which will be the offerer) to determine whether the caller supports
ICE. In cases of third party call control ,
the caller may be a controller that supports (or doesn't) ICE, while
the answerer may be an agent which does (or doesn't) support ICE.
This "ice" OPTION tag SHOULD NOT be used in conjunction with the
Supported header field (this SHOULD NOT includes responses to OPTIONS
requests) The media feature tag is used as the one and
only mechanism for indicating support for ICE. The option tag is meant
to be used only with the Require header field. When placed in the
Require header field of an INVITE request, it indicates that the UAS
must support ICE in order to process the call. An agent supports ICE
if it is either a full or lite implementation, and
consequently, is capable of including candidate attributes in an SDP
offer or answer for at least one transport protocol.
A malicious intermediary might attempt to modify a SIP message by
inserting a Require header field containing the "ice" option tag. If
ICE were not supported on the UAS, this would cause the call to fail
when it would otherwise succeed. Of course, this attack is not
specific to ICE, and can be done using any option tag. This attack is
prevented by usage of the SIPS mechanism as defined in RFC 3261.
Similarly, an intermediary might attempt to remove the media feature
tag from a REGISTER request or OPTIONS request, which might cause a
call to skip ICE processing when it otherwise might make use of
it. This attack is also prevented using the SIPS mechanism.
This specification defines a new media feature tag and SIP option
tag.
This section defines a new SIP option tag per the
guidelines in Section 27.1 of RFC 3261.
ice
This option tag is used to identify the
Interactive Connectivity Establishment (ICE) extension. When present
in a Require header field, it indicates that ICE is required by an
agent.
This section registers a new media feature tag in the SIP tree,
defined in Section 12.1 of RFC 3840 .
sip.ice
1.3.6.1.8.4.22
This
feature tag indicates that the device supports Interactive
Connectivity Establishment (ICE).
Boolean.
This
feature tag is most useful in a communications application, for
describing the capabilities of a device, such as a phone or PDA.
Routing a call to a phone that can
support ICE.
RFC XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]]
Security considerations for this
media feature tag are discussed in of
RFC XXXX . [[Note to IANA: Please replace XXXX with the RFC number of
this specification.]]