Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)
Two small SIP labels that say whether a phone can do ICE, and let a caller insist on it.
Rosenberg, J., "Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)", RFC 5768, DOI 10.17487/RFC5768, April 2010, <https://www.rfc-editor.org/info/rfc5768>.
@misc{rfc5768,
series = {Request for Comments},
number = 5768,
howpublished = {RFC 5768},
publisher = {RFC Editor},
doi = {10.17487/RFC5768},
url = {https://www.rfc-editor.org/info/rfc5768},
author = {J. Rosenberg},
title = {{Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)}},
pagetotal = 6,
year = 2010,
month = apr,
} RFC text
Contents
Internet Engineering Task Force (IETF) J. Rosenberg
Request for Comments: 5768 jdrosen.net
Category: Standards Track April 2010
ISSN: 2070-1721
Indicating Support for Interactive Connectivity Establishment (ICE)
in the Session Initiation Protocol (SIP)
Abstract
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 User Agent (UA) to communicate to its registrar that it
supports ICE. The option tag allows a UA to require support for ICE
in order for a call to proceed.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5768.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Motivation ......................................................3
3.1. Gateways ...................................................3
3.2. Mandating Support for ICE ..................................3
4. Media Feature Tag Definition ....................................3
5. Option Tag Definition ...........................................4
6. Security Considerations .........................................4
7. IANA Considerations .............................................4
7.1. Option Tag .................................................4
7.2. Media Feature Tag ..........................................5
8. References ......................................................5
8.1. Normative References .......................................5
8.2. Informative References .....................................6
1. Introduction
RFC 3264 [RFC3264] defines a two-phase exchange of Session
Description Protocol (SDP) [RFC4566] messages for the purposes of
establishment of multimedia sessions. This offer/answer mechanism is
used by protocols such as the Session Initiation Protocol (SIP)
[RFC3261].
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 [RFC3235]. To
remedy this, an extension to SDP, called Interactive Connectivity
Establishment (ICE) has been defined [RFC5245]. 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 Session Traversal Utilities for NAT (STUN) [RFC5389]
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. Section 3 motivates the need for the media feature tag and
option tag, and Section 4 and Section 5 formally define them.
2. Terminology
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 [RFC2119].
3. Motivation
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.
3.1. Gateways
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 that
act as ICE agents on one side, and 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 [RFC3840]. This allows the
registrar to track whether or not a UA supports ICE. This
information can be accessed by a proxy in order to determine whether
or not a call needs to route through a gateway.
3.2. Mandating Support for ICE
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.
4. Media Feature Tag Definition
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 that 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 [RFC3725], the
caller may be a controller that does (or doesn't) support ICE, while
the answerer may be an agent that does (or doesn't) support ICE.
5. Option Tag Definition
This "ice" OPTION tag SHOULD NOT be used in conjunction with the
Supported header field (this SHOULD NOT include responses to OPTION
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 User
Agent Server (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.
6. Security Considerations
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.
7. IANA Considerations
This specification defines a new media feature tag and SIP option
tag.
7.1. Option Tag
This section defines a new SIP option tag per the guidelines in
Section 27.1 of RFC 3261.
Name: ice
Description: 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.
7.2. Media Feature Tag
This section registers a new media feature tag in the SIP tree,
defined in Section 12.1 of RFC 3840 [RFC3840].
Media feature tag name: sip.ice
ASN.1 Identifier: 1.3.6.1.8.4.22
Summary of the media feature indicated by this tag: This feature tag
indicates that the device supports Interactive Connectivity
Establishment (ICE).
Values appropriate for use with this feature tag: Boolean.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms:
This feature tag is most useful in a communications application,
for describing the capabilities of a device, such as a phone or
PDA.
Examples of typical use: Routing a call to a phone that can support
ICE.
Related standards or documents: RFC 5768
Security Considerations: Security considerations for this media
feature tag are discussed in Section 6 of this document.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
8.2. Informative References
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, April 2004.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
Author's Address
Jonathan Rosenberg
jdrosen.net
Monmouth, NJ
US
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net
AI ELI5
On this page
§1Why ICE Needs a Signal
SIP sessions are set up with the offer/answer exchange of Session Description Protocol (SDP) messages defined in RFC 3264. These messages carry IP addresses, which is a known problem through Network Address Translators (NATs). Interactive Connectivity Establishment (ICE), defined in RFC 5245, extends SDP so that agents gather several candidate addresses, put them all in the offer or answer, and use peer-to-peer STUN connectivity checks (RFC 5389) to find one that works.
This RFC adds two labels for SIP user agents that use ICE: a media feature tag named sip.ice and a SIP option tag named ice.
Some phones know a clever trick for getting calls through home routers. This RFC gives them a way to say so.
§3Gateways and Mandatory ICE
ICE needs both endpoints to support it. Inside one domain, some user agents will support ICE and some will not. To ease deployment, the RFC expects domains to use gateways that act as ICE agents on one side and as non-ICE agents on the other. A call from domain A into domain B could then use ICE even if the device in domain B does not. When domain B receives a call, though, it must know whether to send it through such a gateway or straight to the device. The sip.ice tag lets the registrar track that, and a proxy can use it to decide.
The second motivation is requiring ICE. ICE falls back to non-ICE operation when the answerer lacks it, but an offerer may prefer to abort the call. Typically that is because it would choose a different m/c-line address for a non-ICE peer than for an ICE-capable one. For this, the ice option tag can be placed in the Require header field of an INVITE.
A building might have a helper at the door who translates for visitors who do not speak the new language. The door needs to know which rooms need the helper. Also, a caller may say, "only connect me if you speak the new language."
§4The sip.ice Media Feature Tag
The sip.ice media feature tag, from the framework in RFC 3840, indicates support for ICE. An agent supports ICE if it is either a lite or full implementation and so can include candidate attributes in an SDP offer or answer for at least one transport protocol.
An agent that supports ICE SHOULD include the tag in the Contact header field of its REGISTER requests and OPTION responses. It MAY include it in an INVITE or INVITE response, but that is redundant with the ICE attributes in the SDP.
The tag cannot always be trusted to describe the other side. When an INVITE has no offer, the callee will be the offerer and cannot use the presence or absence of the tag to learn whether the caller supports ICE. With third-party call control (RFC 3725), the caller may be a controller that does or does not support ICE, while the answerer may be an agent that does or does not.
The flag goes on the phone's name tag when it signs in. It also works as a hint, but not a promise, about the other side of a call.
§5The ice Option Tag
The ice option tag is meant to be used only with the Require header field. When it is in the Require header field of an INVITE, the User Agent Server (UAS) must support ICE in order to process the call.
It SHOULD NOT be used with the Supported header field (this includes responses to OPTION requests). The media feature tag is the one and only mechanism for indicating support for ICE. The definition of support is the same as for the media feature tag: a full or lite implementation able to include candidate attributes for at least one transport protocol.
The option tag is a rule on the invitation: "you must know the trick to come to this party." It is never used to just say "I know the trick," because the other flag does that.
- sip.ice (media feature tag)Goes in the Contact header field of REGISTER requests and OPTION responses to say the agent supports ICE.
- ice (option tag)Goes in the Require header field of an INVITE to say the UAS must support ICE for the call to proceed.
§6Security Considerations
A malicious intermediary might insert a Require header field with the ice option tag. If the UAS does not support ICE, a call that would have worked fails. The RFC notes this is not specific to ICE and can be done with any option tag. The attack is prevented by using the SIPS mechanism from RFC 3261.
An intermediary might also remove the media feature tag from a REGISTER or OPTIONS request, which could make a call skip ICE processing it would otherwise use. The SIPS mechanism prevents this attack too.
Someone sneaky in the middle could scribble on the invitation or erase the flag. Sending the message over a protected path stops that.
§7IANA Registrations
The RFC registers the SIP option tag ice, described as identifying the ICE extension and, when present in a Require header field, indicating that ICE is required by an agent.
It also registers the media feature tag sip.ice in the SIP tree defined in RFC 3840. Its ASN.1 identifier is 1.3.6.1.8.4.22 and its value is Boolean. The typical use given is routing a call to a phone that can support ICE.
Both names are written into the official list so nobody else uses them for something different.