RFC 5768

Part 1 of 2 🎀

Okay bestie, RFC 5768 is giving SIP meets ICE energy 💅 Let's get into it ✨

Title Block 🌸

This one is RFC 5768, called Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP). It was written by J. Rosenberg (jdrosen.net) and it's a Standards Track doc, published in April 2010. Its ISSN is 2070-1721. It doesn't obsolete or update any other RFCs, so no drama there 🙈

Abstract ✨

Okay so this spec defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP) 🦋 The media feature tag lets a User Agent (UA) tell its registrar that it supports ICE. The option tag lets a UA require ICE support before a call can go ahead 💅

Status of This Memo 💜

This is an Internet Standards Track document. It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, and it got public review and was approved by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741.

Info about the current status, any errata, and how to send feedback lives 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) as they are in effect on the date of publication. Please read these carefully, bestie, because they spell out your rights and restrictions for this doc. Code Components pulled from this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come 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 🎀

Okay so RFC 3264 [RFC3264] defines a two-phase exchange of Session Description Protocol (SDP) [RFC4566] messages to set up multimedia sessions. This offer/answer mechanism gets used by protocols like the Session Initiation Protocol (SIP) [RFC3261] 💖

Offer/answer protocols are honestly kind of a struggle to run through Network Address Translators (NAT). Their whole purpose is to set up a flow of media packets, so they tend to carry IP addresses inside their messages, and that's known to be problematic through NAT [RFC3235]. To fix this, an SDP extension called Interactive Connectivity Establishment (ICE) was defined [RFC5245]. ICE sets out procedures for agents to gather a bunch of addresses, put 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 find a valid address ✨

This spec defines a media feature tag, sip.ice, and a SIP option tag, ice, for SIP User Agents that use ICE 🦋 Section 3 explains why we need the media feature tag and option tag, and Section 4 and Section 5 define them formally.

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 main reasons for defining an option tag and a media feature tag. One is support for gateways, and the other is requiring ICE for a call 🧠

3.1. Gateways 🚪

Unfortunately, ICE needs both endpoints to support it before it can be used. Inside a domain, you'll usually have User Agents that do support ICE and ones that don't 😭 So to help ICE roll out, domains are expected to use gateways that act as ICE agents on one side and non-ICE agents on the other. That way, a call from domain A into domain B can use ICE even if the device in domain B doesn't support it yet. But when domain B gets a call, it needs to know whether the call has to go through one of those gateways, or whether it can go straight to the terminating UA.

To figure that out, this spec defines a media feature tag, sip.ice, which can be included in the Contact header field of a REGISTER request [RFC3840]. This lets the registrar track whether a UA supports ICE or not. A proxy can access that info to decide whether a call needs to route through a gateway 👑

3.2. Mandating Support for ICE 🔥

Okay, so ICE has a built-in fallback to non-ICE operation when the answerer doesn't support it. But sometimes the offerer would rather abort the call than go ahead without ICE 🙅‍♀️ Usually that's because they want to pick a different m/c-line address for a non-ICE peer than they'd pick for an ICE-capable peer.

To do that, 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's either a lite or full implementation, which means it can include 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 an INVITE response. Doing so is redundant, though, since the ICE attributes in the SDP already say the same thing 🙄 When an INVITE leaves out an offer, the presence or absence of the media feature tag in the Contact header field can't be used by the callee (who will be the offerer) to figure out whether the caller supports ICE. In third-party call control [RFC3725] cases, 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 together with the Supported header field (this SHOULD NOT include responses to OPTION requests). The media feature tag is the one and only mechanism for indicating ICE support. The option tag is meant to be used only with the Require header field. When it's in the Require header field of an INVITE request, it means the User Agent Server (UAS) must support ICE in order to process the call 💅 An agent supports ICE if it's either a full or lite implementation, which means it can include candidate attributes in an SDP offer or answer for at least one transport protocol ✨

---

⏭️ Part 2 picks up at Section 6 (Security Considerations) 🔥

Author's Address 💌

Last stop, bestie! Here's how to reach the author, Jonathan Rosenberg 🧚

Jonathan Rosenberg
jdrosen.net
Monmouth, NJ
US

EMail: jdrosen@jdrosen.net
URI:   http://www.jdrosen.net

That's the whole RFC, babe! 🦋 Now you know where to find the person who wrote it 💜