RFC 4508

RFC 4508: Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method 🎀

Okay, title block tea first 🫖 This is from the Network Working Group, and it's a Standards Track doc dated May 2006. The authors are Orit Levin (Microsoft Corporation) and Alan Johnston (Avaya). Its header doesn't list anything it obsoletes or updates. 💅

---

Status of This Memo ✨

This doc is an Internet standards track protocol spec for the Internet community, and it's asking for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🌸

Copyright Notice 🦋

Copyright (C) The Internet Society (2006).

Abstract 🔥

Okay so the SIP "Caller Preferences" extension from RFC 3840 lets a SIP request carry info about the originator's capabilities and how they'd like that request handled. 🧚 The SIP REFER method from RFC 3515 lets one party basically nudge another party into starting a SIP request. This doc extends REFER so it can use the RFC 3840 mechanism. That means the sender of a REFER can tell the recipient what the target is like, meaning the characteristics the induced request is expected to reach. It's giving teamwork ✨

Table of Contents 🍓

1. Introduction ....................................................2
2. Terminology .....................................................2
3. Definitions .....................................................3
4. Examples ........................................................3
   4.1. isfocus Feature Tag Usage ..................................3
   4.2. Voice and Video Feature Tags Usage .........................3
   4.3. Example with URI parameters and multiple feature tags ......3
5. Security Considerations .........................................4
6. Acknowledgements ................................................4
7. Normative References ............................................4

1. Introduction 💖

This doc extends the SIP [2] REFER method (defined in RFC 3515 [3]) so it works with the feature parameters defined in RFC 3840 [4]. 🦋

Feature tags are how a UA tells another UA about its capabilities and features. A UA can share this info in a bunch of ways, like REGISTER requests and responses and OPTIONS responses. It can also share it inside a dialog, by including it with a remote target URI (Contact URI). 🌈

Feature tag info is super useful, especially before a session even gets set up! 🙈 Say a UA learns (through an OPTIONS query, for example) that the remote UA handles both video and audio. The calling UA might call and offer video in the SDP. Another example: a UA finds out the remote UA is acting as a focus and hosting a conference. In that case, the UA might subscribe to the conference URI first and check the details before it sends an INVITE to join. Very strategic 👑

This REFER extension is how the REFER-Issuer passes that info along about the REFER-Target's capabilities and functionality to the REFER-Recipient. It does this by putting feature tags in the Refer-To header field of a REFER request. ✨

2. Terminology 🫶

In this doc, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in RFC 2119 [1]. 📚

To make REFER and its extensions easier to talk about, three new terms show up all over the doc:

• REFER-Issuer: the UA issuing the REFER request 💌
• REFER-Recipient: the UA receiving the REFER request 📬
• REFER-Target: the UA designated in the Refer-To URI 🎯

3. Definitions 🌸

Here's the Refer-To BNF from RFC 3515:

Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec )
                 *(SEMI generic-param)

And here's how it gets extended:

Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec )
                 *(SEMI refer-param)
refer-param = generic-param / feature-param

where feature-param is defined in Section 9 of RFC 3840 [4]. 🧚

Heads up! If any URI parameters are present, the entire URI must be enclosed in "<" and ">". If the "<" and ">" aren't there, every parameter after the URI counts as a header parameter, not a URI parameter. Don't skip this one 🙈

4. Examples 🎀

4.1. isfocus Feature Tag Usage 👑

This one shows how the REFER-Issuer can use the "isfocus" feature tag to tell the REFER-Recipient that the REFER-Target is a conference focus. That also means sending an INVITE will bring the REFER-Recipient into the conference. 🎪

Refer-To: sip:conf44@example.com;isfocus

4.2. Voice and Video Feature Tags Usage 📞

Here the REFER-Issuer tells the REFER-Recipient that the REFER-Target supports audio and video. So a video and audio session can get set up by sending an INVITE to the REFER-Target. Main character energy 🎬

Refer-To: "Alice's Videophone" <sip:alice@videophone.example.com>
                ;audio;video

4.3. Example with URI parameters and multiple feature tags 🦋

This example has the REFER-Issuer telling the REFER-Recipient that the REFER-Target is a voicemail server. Note that the transport URI parameter sits inside "<" and ">", so it isn't misread as a header parameter. Obsessed with how precise this is 😭

Refer-To: <sip:alice-vm@example.com;transport=tcp>
                ;actor="msg-taker";automata;audio

5. Security Considerations 🔒

Feature tags can leak sensitive info about a user or a UA, so be careful 💀 RFC 3840 warns against handing sensitive info to another party. Once it's out there, anyone can do anything with it, including passing it on to a third party like this spec allows.

A REFER-Issuer MUST NOT create or guess feature tags. Instead, a feature tag in a REFER SHOULD be discovered through an authenticated and secure method (like an OPTIONS response, or from a remote target URI in a dialog), straight from the REFER-Target. No vibes-based feature tags please 🙅‍♀️

It is RECOMMENDED that the REFER-Issuer include in the Refer-To header field all the feature tags listed in the most recent Contact header field of the REFER-Target. ✨

A feature tag from a REFER-Issuer can't be authenticated or certified from the REFER request alone. So the REFER-Recipient MUST treat the info as a hint. If the REFER-Recipient's application logic or the user's action depends on a feature being there, the feature tag can be verified. For example, the REFER-Recipient can send an OPTIONS query directly to the REFER-Target over a secure connection (like one that's mutually authenticated and integrity-protected). That protects the REFER-Recipient from incorrect or malicious feature tags. Protect yourself, bestie 🛡️💜

6. Acknowledgements 🫶

The authors want to thank Jonathan Rosenberg for his helpful guidance on this work. 🌷

7. Normative References 📚

• [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [2] 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.
• [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
• [4] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.

Authors' Addresses 🌈

Here's how to find the authors (contact info kept exact):

Orit Levin
Microsoft Corporation
One Microsoft Way
Redmond, WA  98052
USA

Phone: 425-722-2225
EMail: oritl@microsoft.com


Alan Johnston
Avaya
St. Louis, MO 63124

EMail: ajohnston@ipstation.com

Full Copyright Statement 💅

Copyright (C) The Internet Society (2006).

This doc is subject to the rights, licenses, and restrictions in BCP 78. Except as BCP 78 says, the authors keep all their rights.

This doc and the info in it are provided "AS IS". THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED. That includes, but isn't limited to, any warranty that using the info won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. 😭

Intellectual Property 🔥

The IETF doesn't take a position on whether any Intellectual Property Rights or other rights claimed to cover the tech in this doc are valid or in scope. It also doesn't say whether any license under those rights might be available, and it hasn't made any independent effort to find those rights. Info on how rights work for RFC documents is in BCP 78 and BCP 79.

Copies of IPR disclosures sent to the IETF Secretariat, and any assurances of licenses, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr. That's also where you'd find the result of any attempt to get a general license or permission for implementers or users of this spec.

The IETF invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to ietf-ipr@ietf.org. 🫶

Acknowledgement 🌸

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🎀