RFC 6809
Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)
RFC 6809: Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) 📋✨
Okay, the paperwork first! This one came from the IETF, and the authors are C. Holmberg and I. Sedlacek from Ericsson, plus H. Kaplan from Acme Packet. It's a Standards Track document, ISSN 2070-1721, dated November 2012. The title block doesn't list anything it obsoletes or updates.
Abstract 🎀
Here's the big idea: this spec adds a brand new SIP header field called Feature-Caps 💖. It carries feature-capability indicators that show which features and capabilities are supported by SIP entities that aren't represented by the URI in the Contact header field.
SIP entities that are represented by the URI in the Contact header field can already share media feature tags in that Contact header field to show what they support 🦋.
The spec also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", where you register them 🌸.
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, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. More info on Internet Standards is in Section 2 of RFC 5741.
Want the current status, any errata, or a way to send feedback? Check http://www.rfc-editor.org/info/rfc6809 🔗.
Copyright Notice ©️
Copyright (c) 2012 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 stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document need to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 📄.
Table of Contents 📚
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Definitions .....................................................4
4. Feature-Caps Header Field .......................................4
4.1. Introduction ...............................................4
4.2. User Agent and Proxy Behavior ..............................4
4.2.1. General .............................................4
4.2.2. B2BUA Behavior ......................................5
4.2.3. Registrar Behavior ..................................6
4.2.4. Proxy Behavior ......................................6
4.3. SIP Message Type and Response Code Semantics ...............7
4.3.1. General .............................................7
4.3.2. SIP Dialog ..........................................7
4.3.3. SIP Registration (REGISTER) .........................7
4.3.4. SIP Standalone Transactions .........................8
5. Feature-Capability Indicators ...................................8
5.1. Introduction ...............................................8
5.2. Registration Trees .........................................9
5.2.1. General .............................................9
5.2.2. Global Tree .........................................9
5.2.3. SIP Tree ............................................9
5.3. Feature-Capability Indicator Specification Requirements ...10
5.3.1. General ............................................10
5.3.2. Overall Description ................................10
5.3.3. Feature-Capability Indicator Values ................10
5.3.4. Usage Restrictions .................................11
5.3.5. Interoperability Considerations ....................11
5.3.6. Security Considerations ............................11
5.3.7. Examples ...........................................12
5.3.8. Other Information ..................................12
6. Syntax .........................................................12
6.1. General ...................................................12
6.2. Syntax: Feature-Caps Header Field .........................12
6.2.1. ABNF ...............................................12
6.3. Syntax: Feature-Capability Indicator ......................12
6.3.1. General ............................................12
6.3.2. ABNF ...............................................13
7. IANA Considerations ............................................13
7.1. Registration of the Feature-Caps Header Field .............13
7.2. Registration of the Feature-Caps Header Field Parameter ...13
7.3. Proxy-Feature Feature-Capability Indicator Trees ..........14
7.3.1. Introduction .......................................14
7.3.2. Global Feature-Capability Indicator
Registration Tree ..................................14
7.3.3. SIP Feature-Capability Indicator
Registration Tree ..................................15
8. Feature-Capability Indicator Registration Template .............16
9. Security Considerations ........................................17
10. Acknowledgements ..............................................17
11. References ....................................................18
11.1. Normative References .....................................18
11.2. Informative References ...................................181. Introduction ✨
The Session Initiation Protocol (SIP) [RFC3261] has an extension for indicating User Agent (UA) capabilities, defined in RFC 3840 [RFC3840]. It lets a SIP message share info about the originator's features and capabilities, using the Contact header field 🌈.
This spec adds a new SIP header field, Feature-Caps 💅. It carries feature-capability indicators that show support for features and capabilities of SIP entities that aren't represented by the URI in the Contact header field. That happens in these situations:
- The SIP entity acts as a SIP proxy.
- The SIP entity acts as a SIP registrar.
- The SIP entity acts as a Back-to-Back User Agent (B2BUA) [RFC3261], where the Contact header field URI represents another SIP entity.
SIP entities that are represented by the URI in the Contact header field can still share media feature tags there to show their features and capabilities 🦋.
Unlike media feature tags, feature-capability indicators are meant to be used only with SIP 🔥.
And yep, the spec also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for registering them 🎀.
2. Conventions 💜
Here are the BCP 14 key words, the ones with the special meaning: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". In this document, they're read the way BCP 14, RFC 2119 [RFC2119] describes 🧚.
3. Definitions 🍓
Downstream SIP entity: the SIP entity in the direction a SIP request is headed.
Upstream SIP entity: the SIP entity in the direction a SIP request comes from.
4. Feature-Caps Header Field 🌸
4.1. Introduction
The Feature-Caps header field is how SIP entities say what they support, by setting feature-capability indicators 💖. An indicator in a Feature-Caps header field tells you that a SIP entity in the SIP message signaling path supports that feature and capability.
4.2. User Agent and Proxy Behavior
4.2.1. General
Quick rule: if the URI in a Contact header field of a request or response represents a SIP entity, that entity MUST NOT indicate its supported features and capabilities with a Feature-Caps header field inside that same request or response 🙅♀️.
When a SIP entity gets a SIP request or response with one or more Feature-Caps header fields, the indicators tell it about the features and capabilities supported by entities along the SIP message signaling path ✨. How those features and capabilities get invoked is outside the scope of this spec, and individual feature-capability indicator specifications MUST describe it 📖.
A Feature-Caps header field value can't carry the address of the SIP entity that inserted it 🫣. If extra data about a supported feature needs to go along with it, like the address of the entity that indicated support for that feature, then the feature definition has to define a way to put that info into the value of its feature-capability indicator 💡.
When a SIP entity adds a Feature-Caps header field to a SIP message, it MUST put that header field before any existing Feature-Caps header fields in the message being forwarded, so the new one becomes the top-most one 👑. Then, when another SIP entity gets the request or response, the SIP feature-capability indicators in the top-most Feature-Caps header field show the features and capabilities that are "closest", from a SIP signaling point of view, to that entity 🫶.
Depending on features and policies, a SIP entity MAY drop a whole Feature-Caps header field from a SIP message 🗑️. A SIP entity MAY also drop a single feature-capability indicator from a Feature-Caps header field in a message. And a SIP entity SHOULD NOT shuffle the order of the Feature-Caps header fields in a message 🙈.
For any fc-value (see Section 6.2.1), the order of the feature-capability indicators doesn't matter 🌈. Like, "foo;bar" and "bar;foo" mean the exact same thing: the SIP entity that inserted that indicator supports the features and capabilities tied to the "foo" and "bar" feature-capability indicators 🥰.
(Part 1 of 4 is done! Part 2 starts with Section 4.2.2, B2BUA Behavior, so stay tuned 🦋💅)
4.2.2. B2BUA Behavior ✨
Okay so this part is for User Agents (UAs) [RFC3261] that live inside B2BUAs, the ones that show up in the message through a Record-Route header field instead of the URI in the Contact header field 💅
When one of these UAs sends a SIP request and wants to tell its downstream SIP entities what features and capabilities it supports, it adds a Feature-Caps header field to the request. That header holds one or more feature-capability indicators for the supported stuff, and it gets added before the request is forwarded 🎀
If the SIP request was triggered by another SIP request the B2BUA received, the UA MAY forward the received Feature-Caps header fields by copying them to the outgoing SIP request, kind of like a SIP proxy would. Then it adds its own Feature-Caps header field to the SIP request 🦋
Same energy on the way back. When this UA gets a SIP response and wants to tell its upstream SIP entities what it supports, it adds a Feature-Caps header field to the response, with one or more feature-capability indicators for those features and capabilities, before it forwards the response ✨
And if the SIP response was triggered by another SIP response the B2BUA received, the UA MAY forward the received Feature-Caps header fields by copying them to the outgoing SIP response, similar to a SIP proxy, before it adds its own Feature-Caps header field to the SIP response 💜
4.2.3. Registrar Behavior 🌸
If a SIP registrar wants to show its upstream SIP entities which features and capabilities it supports, it adds a Feature-Caps header field to a REGISTER response. That field carries one or more feature-capability indicators for those features and capabilities 🧚
4.2.4. Proxy Behavior 🍓
When a SIP proxy receives a SIP request and wants to tell its downstream SIP entities about its features and capabilities, it adds a Feature-Caps header field to the request. That field holds one or more SIP feature-capability indicators for the supported features and capabilities, and this happens before the request is forwarded 💖
When a proxy receives a SIP response and wants to tell its upstream SIP entities about its features and capabilities, it adds a Feature-Caps header field to the response. That field holds one or more SIP feature-capability indicators for the supported features and capabilities, and this happens before the response is forwarded 🫶
4.3. SIP Message Type and Response Code Semantics 🦋
4.3.1. General 📖
This section breaks down how the Feature-Caps header field gets used, and what it means, for different SIP message types and response codes 🌈
Section 6.2.1 is where the ABNF for the Feature-Caps header field lives 💅
4.3.2. SIP Dialog 💬
The Feature-Caps header field can show up in an initial SIP request for a dialog, in a target refresh SIP request, and in any 18x or 2xx response tied to those requests ✨
If a feature-capability indicator goes into a Feature-Caps header field of an initial request for a dialog, or into a response to that request, it tells the receivers that the feature behind the indicator is supported for the whole dialog. That lasts until a target refresh request is sent for the dialog, or until the dialog ends 🎀
Unless a feature-capability indicator is put into a Feature-Caps header field of a target refresh request, or into a response to one, the receivers take it to mean the feature is no longer supported for the dialog. So if you don't include it, it's gone 🙈
For a given dialog, a SIP entity MUST insert the same feature-capability indicators in all 18x and 2xx responses associated with a given transaction. No switching the vibe mid-transaction, bestie 😭
Here's the tea on SUBSCRIBE: 2xx responses to SIP SUBSCRIBE requests might not reach the User Agent Client (UAC) [RFC3261], because the request can fork. So entities need to indicate their supported features and capabilities in the SIP NOTIFY request that gets sent for each of the subscription dialogs that were created 🦋
4.3.3. SIP Registration (REGISTER) 📮
The Feature-Caps header field can be used in a SIP REGISTER request and in the 200 (OK) response to that request 💖
If a feature-capability indicator is carried in a Feature-Caps header field of a REGISTER request, or in an associated response, it tells the receivers that the feature is supported for the registration. That holds until the registration of the contact that was explicitly carried in the REGISTER request expires, or until that registered contact is explicitly refreshed and the refresh REGISTER request doesn't have the feature-capability indicator for that feature 🌸
A REGISTER response can include contacts that were registered as part of other registration transactions. Even so, support for any indicated feature only applies to requests sent to the contact(s) that were explicitly carried in the associated REGISTER request 🧚
This spec doesn't define any semantics for the Feature-Caps header field in pure registration binding fetching messages (see Section 10.2.3 of RFC 3261), where the REGISTER request has no Contact header field. Unless a future extension defines those semantics, fetching messages won't affect any previously indicated support for features and capabilities, and SIP entities MUST NOT insert a Feature-Caps header field in such messages 🙅♀️
If SIP outbound [RFC5626] is used, the rules above still apply. The difference is that supported features and capabilities only apply to the registration flow where support was explicitly indicated 🍓
4.3.4. SIP Standalone Transactions 🎈
The Feature-Caps header field can be used in a standalone SIP request and in any 2xx response to that request ✨
If a feature-capability indicator goes into a Feature-Caps header field of a standalone request, or into a response to that request, it tells the receivers that the feature is supported for the duration of the standalone transaction 💜
5. Feature-Capability Indicators 👑
5.1. Introduction 🌷
Feature-capability indicators are used by SIP entities that aren't represented by the URI of the Contact header field. They use them to show support for features and capabilities, in cases where media feature tags can't be used for that 💅
A value, or a list of values, that gives extra info about the supported feature or capability can be attached to a feature-capability indicator 🎀
5.2. Registration Trees 🌳
5.2.1. General 🌿
The subsections below define registration trees. You can tell them apart by their faceted names, which look like "tree.feature-name". The registration trees live in the IANA "Proxy-Feature Feature-Capability Indicator Trees" registry 📚
These trees are similar to the global tree and SIP tree defined for media feature tags in RFCs 2506 [RFC2506] and 3840 [RFC3840]. Other registration trees are outside the scope of this specification 🦋
Unlike RFCs 2506 and 3840, this specification only defines a global tree and a SIP tree. That's because those are the only trees from those RFCs that have actually been used to define SIP-specific media feature tags 💖
When a feature-capability indicator is registered in any registration tree, you don't use a leading "+" in the registration ✨
5.2.2. Global Tree 🌍
The global feature-capability indicator tree is similar to the media feature tag global tree defined in RFC 2506 [RFC2506] 🌈
A feature-capability indicator in the global tree gets the leading facet "g.". An organization can propose either a name that hints at the feature (like "g.blinktags"), or a faceted name that includes the organization name (like "g.organization.blinktags") 🫶
5.2.3. SIP Tree 📞
The SIP feature-capability indicator tree is similar to the media feature tag SIP tree defined in RFC 3840 🧚
A feature-capability indicator in the SIP tree gets the leading facet "sip." 🍓
5.3. Feature-Capability Indicator Specification Requirements 📝
5.3.1. General 🌸
A feature-capability indicator specification MUST address the issues defined in the following subsections, or document why an issue doesn't apply to that specific feature-capability indicator. A reference to the specification MUST be provided when the feature-capability indicator is registered with IANA (see Section 8) 💅
It's bad practice for feature-capability indicator specifications to repeat procedures (like the general rules for using the Feature-Caps header field and feature-capability indicators) that are already defined in this specification. The exception is when repeating them is needed for clarification or emphasis 🙄
A feature-capability indicator specification MUST NOT modify the Feature-Caps header field rules and semantics defined in Section 4 🚫
A feature-capability indicator specification MUST NOT weaken any behavior designated with "SHOULD" or "MUST" in this specification. However, a specification MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strength if the features and capabilities associated with the feature-capability indicator require it 💪
5.3.2. Overall Description 🎀
The feature-capability indicator specification MUST contain an overall description of the feature-capability indicator. That description covers how it's used to show support for a feature, what the feature is, any extra info (conveyed with one or more feature-capability indicator values) that can come along with the indicator, and how the associated feature MAY be exercised/invoked 🧠
5.3.3. Feature-Capability Indicator Values 🔢
A feature-capability indicator can have an associated value, or a list of values. The feature-capability indicator specification MUST define the syntax and semantics of any value defined for the indicator, including possible restrictions on using a specific value. It MUST define the value(s) in accordance with the ABNF defined in Section 6.3.2. It MUST also define whether the feature-capability indicator has a default value 🫶
If no values are defined for the feature-capability indicator, the feature-capability indicator specification MUST say so 📣
A feature-capability indicator value only applies to the feature-capability indicator it was defined for. For any other feature-capability indicators, the value has to be defined explicitly, even if the semantics are identical 🌟
It is strongly RECOMMENDED to not re-use a value that has already been defined for another feature-capability indicator, unless the semantics of the values are the same 💜
5.3.4. Usage Restrictions
okay bestie, if there are restrictions on how SIP entities can insert a feature-capability indicator, the feature-capability indicator specification MUST document those restrictions 💅✨
there might be restrictions on whether or not entities:
- are allowed to insert a feature-capability indicator in registration-related messages, standalone transaction messages, or dialog-related messages,
- are allowed to insert a feature-capability indicator in requests or responses,
- also need to support other features and capabilities before they can insert a feature-capability indicator, and
- are allowed to indicate support of a feature alongside another feature. 🧚
5.3.5. Interoperability Considerations
the feature-capability indicator specification MUST document any specific interoperability considerations that apply to the indicator 🫶
interop considerations can, e.g., include procedures for when an expected feature-capability indicator isn't there, or when it shows up with an unexpected value. the vibe is "plan for the mess" 🙈
5.3.6. Security Considerations
the feature-capability indicator specification MUST document any specific security considerations that apply to the indicator. this one is serious, bestie, so don't skip it 🔥
5.3.7. Examples
it is recommended that the feature-capability indicator specification include demonstrative message flow diagrams, paired with complete messages and message descriptions. pictures and full messages are literally the best way to understand a feature 🎀
note that example message flows are informative by definition, so they do not replace the normative text. examples are the pretty stuff, the rules are the actual rules ✨
5.3.8. Other Information
if there's extra information about the feature-capability indicator, it is recommended to describe it. that can include things like the names of related feature-capability indicators 🌸
6. Syntax 🎀
6.1. General
this section defines the ABNF for the Feature-Caps header field and for the feature-capability indicators. the ABNF in this spec is conformant to RFC 5234 [RFC5234], so the grammar is totally legit 💖
6.2. Syntax: Feature-Caps Header Field
6.2.1. ABNF
the ABNF for the Feature-Caps header field is:
Feature-Caps = "Feature-Caps" HCOLON fc-value
*(COMMA fc-value)
fc-value = "*" *(SEMI feature-cap)NOTE: the "*" value is there so we follow the syntax guidelines in RFC 4485 [RFC4485], and so the format stays consistent with RFCs 3840 [RFC3840] and 3841 [RFC3841]. it's giving "matching the family" 👑
6.3. Syntax: Feature-Capability Indicator
6.3.1. General
in a feature-capability indicator name (ABNF: fcap-name), dots can be used to build a feature-capability indicator tree hierarchy, like tree.feature.subfeature. the description of how that tree hierarchy gets used must be written down when it's registered 🦋
6.3.2. ABNF
the ABNF for the feature-capability indicator is:
feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list
/ fcap-string-value ) RDQUOT]
fcap-name = ftag-name
fcap-value-list = tag-value-list
fcap-string-value = string-value
;; ftag-name, tag-value-list, string-value defined in RFC 3840NOTE: compared to media feature tags, the "+" sign in front of the feature-capability indicator name is mandatory. don't forget the plus, bestie, it's not optional 🙅♀️
7. IANA Considerations 🌈
7.1. Registration of the Feature-Caps Header Field
this spec registers a brand new SIP header field, Feature-Caps, following the process in RFC 3261 [RFC3261]. iconic 👑
the registration for Feature-Caps in the "Header Fields" registry looks like this:
RFC Number: RFC 6809
Header Field Name: Feature-Caps7.2. Registration of the Feature-Caps Header Field Parameter
this spec also adds the Feature-Caps header field to the IANA "Header Field Parameters and Parameter Values" registry, following the process in RFC 3968 [RFC3968]. here's the table:
Predefined
Header Field Parameter Name Values Reference
--------------------------------------------------------------------
Feature-Caps +<fcap-name> * No [RFC6809]
* <fcap-name> denotes parameter names conforming to the
syntax <fcap-name> defined in RFC 6809. Valid
feature-capability indicators are registered in the
Proxy-Feature Feature-Capability Indicator Trees registry.7.3. Proxy-Feature Feature-Capability Indicator Trees
7.3.1. Introduction
this spec creates a new sub-registry under the IANA "Session Initiation Protocol (SIP) Parameters" registry, following the process defined in RFC 5226. the sub-registry is called "Proxy-Feature Feature-Capability Indicator Trees" 🧚
feature-capability indicators get sorted by their "leading facet," which is the prefix of the name made of every character up to and including the first ".". names with no "." at all count as having an empty ("") leading facet 💜
the "Proxy-Feature Feature-Capability Indicator Trees" registry holds sub-registries for groups (called 'trees') of indicators that share the same leading facet. each indicator gets registered in the tree that matches its leading facet. if no tree matches, the indicator cannot be registered. no tree, no entry, periodt 🙅♀️
new trees can be registered too. that registration must meet the "Standards Action" policies defined in RFC 5226 [RFC5226]. you need to provide a new name, a unique leading facet, and registration policies (as defined in RFC 5226) for the indicators in that tree ✨
this document defines the first two trees, "g." and "sip.". it does not define a tree for the empty leading facet 🌸
7.3.2. Global Feature-Capability Indicator Registration Tree
this spec creates a new feature-capability indicator tree in the IANA "Proxy-Feature Feature-Capability Indicator Trees" registry. the tree is called "Global Feature-Capability Indicator Registration Tree", its leading facet is "g.", and it's used for registering feature-capability indicators 🌍
when an indicator is registered in the global tree, it needs to meet the "Specification Required" policies defined in RFC 5226. a designated area expert reviews the proposal and consults with members of related mailing lists. the info needed for the registration is defined in Section 5.3 of this document 📝
all indicators registered in the global tree will have names starting with "g.". no leading "+" is used in the registrations in any of the feature-capability indicator registration trees, so that's a rule across the board 💅
the global tree looks like this:
Name Description Reference
------------------------------- Name contains the Feature-Capability Indicator Name, taken from the registration template.
- Description is taken from the registration template.
- Reference contains the Feature-Capability Indicator specification reference taken from the registration template.
no initial values are registered in the global tree. it's a blank slate, bestie 🫧
7.3.3. SIP Feature-Capability Indicator Registration Tree
this spec creates a new feature-capability indicator tree in the IANA "Proxy-Feature Feature-Capability Indicator Trees" registry. the tree is called "SIP Feature-Capability Indicator Registration Tree", its leading facet is "sip.", and it's used for registering feature-capability indicators 💖
when an indicator is registered in the SIP tree, it needs to meet the "IETF Review" policies defined in RFC 5226. the info needed for the registration is defined in Section 5.3 of this document 🦋
all indicators registered in the SIP tree will have names starting with "sip.". same rule as always: no leading "+" in any of the registration trees 🙅♀️
the SIP tree looks like this:
Name Description Reference
------------------------------- Name contains the Feature-Capability Indicator Name, taken from the registration template.
- Description is taken from the registration template.
- Reference contains the Feature-Capability Indicator specification reference taken from the registration template.
no initial values are registered in the SIP tree either 🌷
8. Feature-Capability Indicator Registration Template 📋
registration requests for the global tree are submitted by email to iana@iana.org 💌
registration requests for the SIP tree require submitting an Internet-Draft to the IESG 🧾
here's the template. all fields are mandatory, and the instructions are the lines starting with '|':
| Instructions are preceded by '|'. All fields are mandatory.
Feature-capability indicator name:
Description:
| The description should be no longer than 4 lines. More
| detailed information can be provided in the feature
| capability indicator specification.
Feature-capability indicator specification reference:
| The referenced specification must contain the information
| listed in Section 5.3 of RFC 6809.
Contact:
| Name(s) & email address(es) of person(s) to
| contact for further information.9. Security Considerations 🔐
okay, security time, and I'm not playing 🚨
the security issues for feature-capability indicators are pretty similar to the ones in RFC 3840 for media feature tags. media feature tags can reveal info about end users and their equipment, which can be used for industrial espionage 🕵️. knowing what end-user equipment can do can also be used to influence how applications behave. since feature-capability indicators aren't meant to convey capability info about end-user devices, those end-user security aspects of RFC 3840 do not apply to them 🙌
also, the security issue in RFC 3840 about an attacker using the SIP caller preferences extension [RFC3841] to affect routing decisions does not apply here, because the mechanism isn't defined to be used with feature-capability indicators 🛑
feature-capability indicators can, however, provide capability and characteristics info about the SIP entity, and some of it might be sensitive. malicious elements that look at the indicators might be able to figure out application deployment details or spot elements with exploitable feature implementation weaknesses. the Feature-Caps header field does not convey address information about SIP entities. however, individual feature-capability indicators might provide address information as indicator values. so, if the indicators provide information that requires data integrity or origin authentication, mechanisms for providing those MUST be provided. if confidentiality is required, then the specification MUST call for the use of Transport Layer Security (TLS) [RFC5246] at all hops. since there are no satisfactory middle-to-end or middle-to-middle SIP confidentiality mechanisms, TLS is as good as it gets, and specifications SHOULD NOT define feature-capability indicators that need confidentiality better than the hop-by-hop confidentiality TLS provides 🔒💀
10. Acknowledgements 🫶
Huge thanks to everyone in the SIP community who gave input and feedback on this spec. You all made it so much better ✨
11. References
11.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.
- [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
11.2. Informative References
- [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
- [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
- [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
- [RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
- [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", RFC 4485, May 2006.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
Authors' Addresses 💌
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: christer.holmberg@ericsson.com
Ivo Sedlacek
Ericsson
Scheelevaegen 19C
Lund 22363
Sweden
EMail: ivo.sedlacek@ericsson.com
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803
USA
EMail: hkaplan@acmepacket.com📦 where this page comes from
- ietf: rfc6809 2012-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms