RFC 7433

A Mechanism for Transporting User-to-User Call Control Information in SIP

📅 published January 2015, from ietf

RFC 7433: A Mechanism for Transporting User-to-User Call Control Information in SIP 💖

Authors: A. Johnston (Avaya) and J. Rafferty (Human Communications) 🎀 Category: Standards Track ✨ ISSN: 2070-1721 Date: January 2015 🌸 Obsoletes/Updates: The title block doesn't list anything this RFC obsoletes or updates. 🧚

Abstract

okay so there's a whole class of apps that get major value from using SIP to swap User-to-User Information (UUI) during session setup 🦋 This info, called call control UUI data, is a small chunk of data that the app starting the session puts in, and the app accepting the session uses. The syntax and semantics for the UUI data a given app uses are defined by a UUI package. SIP treats this data as opaque, and it has nothing to do with any basic SIP function 💅 This document defines a new SIP header field, User-to-User, to carry UUI data, plus an extension mechanism.

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). More info on Internet Standards is in Section 2 of RFC 5741 📚

Info about the current status of this document, any errata, and how to give feedback on it is at http://www.rfc-editor.org/info/rfc7433 🍓

Copyright (c) 2015 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 in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 🫶 Code Components pulled out of this document must include Simplified BSD License text, as 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.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Requirements Discussion . . . . . . . . . . . . . . . . . . .   4
4.  Normative Definition  . . . . . . . . . . . . . . . . . . . .   5
  4.1.  Syntax for UUI Header Field . . . . . . . . . . . . . . .   6
  4.2.  Hex Encoding Definition . . . . . . . . . . . . . . . . .   7
  4.3.  Source Identity of UUI Data . . . . . . . . . . . . . . .   7
5.  Guidelines for UUI Packages . . . . . . . . . . . . . . . . .   9
  5.1.  Extensibility . . . . . . . . . . . . . . . . . . . . . .  10
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
  6.1.  Registration of User-to-User Header Field . . . . . . . .  11
  6.2.  Registration of User-to-User Header Field Parameters  . .  11
  6.3.  Registration of UUI Packages  . . . . . . . . . . . . . .  11
  6.4.  Registration of UUI Content Parameters  . . . . . . . . .  12
  6.5.  Registration of UUI Encoding Parameters . . . . . . . . .  12
  6.6.  Registration of SIP Option Tag  . . . . . . . . . . . . .  13
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  15
Appendix A.  Other Possible Mechanisms  . . . . . . . . . . . . .  17
  A.1.  Why INFO is Not Used  . . . . . . . . . . . . . . . . . .  17
  A.2.  Why Other Protocol Encapsulation UUI Mechanisms Are Not
        Used  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
  A.3.  MIME Body Approach  . . . . . . . . . . . . . . . . . . .  17
  A.4.  URI Parameter . . . . . . . . . . . . . . . . . . . . . .  18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  19
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1. Overview ✨

okay bestie, so this doc is all about moving UUI data around using SIP [RFC3261] 💜 It gives you a way to carry general app UUI data, and it also covers the call control UUI stuff from the ITU-T Recommendation Q.931 User-user information element [Q931] and the ITU-T Recommendation Q.763 User-to-User information parameter [Q763]. UUI is everywhere in the PSTN right now for contact centers and call centers, and the related apps are slowly moving from ISDN over to SIP 🦋 The UUI extension for SIP can also be used by native SIP User Agents (UAs) that offer similar services, and it can interwork with ISDN services too. Heads up: in most cases the UAs already have an a priori understanding of what to do with the UUI data they get. This document lets you define packages and related attributes that make those understandings way more explicit 🫶

The UUI mechanism is built to hit the use cases, requirements, and call flows for SIP call control UUI detailed in [RFC6567]. Every reference to a requirement number (REQ-N) or a figure number points to [RFC6567] 🎀

The mechanism is a new SIP header field plus a new SIP option tag 🌸 The header field carries the UUI data, along with parameters that say how the UUI data is encoded, which UUI package it belongs to, and optionally what the content of the UUI data is. The package definition explains how a particular app can use the UUI mechanism. The header field can be included, sometimes called "escaped", inside URIs for referral and redirection scenarios. In those scenarios, the History-Info header field is used to show who inserted the UUI data 👑 The SIP option tag can signal support for the header field. Support for the UUI header field means a UA can pull the info out of the UUI data and pass it up the protocol stack. Individual packages that use the UUI mechanism can use SIP media feature tags to show that a UA supports a particular UUI package. Guidelines for defining UUI packages are included too ✨

2. Terminology 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💅

Also, the <allOneLine> tag convention from SIP Torture Test Messages [RFC4475] is used to show that the actual message syntax has no line breaks 🙈

3. Requirements Discussion 🔥

This section breaks down how the User-to-User header field meets the requirements in [RFC6567] ✨ The header field can show up in INVITE requests and responses and in BYE requests and responses, which covers REQ-1 and REQ-2 💖

For the redirection and referral use cases and REQ-3, the header field is included (escaped) within the Contact or Refer-To URI. All the details for how this works in redirection and referral cases are in Section 4.1 🦋

SIP proxy forwarding and retargeting don't touch header fields, so the header field meets REQ-4 👑

The UUI header field carries the UUI data itself, not a pointer to it, so REQ-5 is met 🌈

Since the basic design of the UUI header field is similar to the ISDN UUI service, interworking with PSTN protocols is straightforward. That's documented in a separate spec [RFC7434], which meets REQ-6 🧚

REQ-7, REQ-8, and REQ-10 are all about discovering the mechanism and the supported packages, and so about applications 🫶 REQ-7 is about support for the UUI header field, and REQ-8 is about routing based on that support. REQ-7 is met by defining a new SIP option tag "uui". Using Require:uui in a request, or Supported:uui in an OPTIONS response, could be used to require or discover support for the mechanism. Proxies can use the presence of a Supported:uui or Require:uui header field to route to an appropriate UA, which meets REQ-8. But note that only UAs are expected to understand the UUI data. Proxies and other intermediaries do not 🙈 REQ-10 is met by using SIP feature tags [RFC3840]. For example, the feature tag sip.uui-isdn could indicate support for the ISDN UUI package, or sip.uui-pk1 could indicate support for a particular package, pk1 💜

Proxies usually apply policy to certain SIP header fields in requests, either passing them along or stripping them out 🍓 REQ-9 is met by letting proxies and other intermediaries remove UUI header fields from a request or response based on policy 💅

Carrying UUI data elements of at least 129 octets is easy with the UUI header field, which meets REQ-11 ✨ That said, it's a really good idea to avoid huge UUI data elements, because SIP header fields have traditionally not been large 😭

To meet REQ-12 for the redirection and referral use cases, the History-Info header field [RFC7044] can be used. In these retargeting cases, the changed Request-URI gets recorded in the History-Info header field, along with the identity of the element that did the retargeting 👑

REQ-13, the integrity protection requirement, could be met with an S/MIME signature over a subset of header fields. That's defined in "SIP Header Privacy and Integrity using S/MIME: Tunneling SIP", Section 23.4 of RFC 3261. Real talk though: S/MIME isn't really deployed with SIP, so in general, REQ-13 is not met 💀 REQ-14, the end-to-end privacy requirement, could be met using S/MIME or encryption at the application layer. Heads up that using S/MIME to secure the UUI data adds an additional body to the request 🌸 Hop-wise Transport Layer Security (TLS) [RFC5246] lets the header field meet REQ-15 for hop-by-hop security 🌈

4. Normative Definition ✨

okay bestie, this is the actual rulebook part 💅 This doc makes a brand new SIP header field called "User-to-User" 🎀 to carry call control UUI data, and that's how it meets the requirements in [RFC6567] 💖.

To tag and identify the UUI data, there are three header field parameters: "purpose", "content", and "encoding" 🧚. "purpose" tells you which package defines how the UUI data gets generated and used for a particular app. Its value is the package name, as registered in the "UUI Packages" subregistry defined in Section 6.3 🍓. When you're interworking with the ISDN UUI service, the ISDN UUI service interworking package is used. The default for "purpose" is "isdn-uui" as defined in [RFC7434]. If "purpose" isn't there, the ISDN UUI MUST be used.

"content" says what the UUI data actually is 🔥. If it's not present, the default content defined for the package MUST be used. Newly defined UUI packages MUST define or reference at least a default "content" value, so there's always a fallback 💜.

"encoding" says how the info in the UUI data for a specific "content" value gets encoded 🌸. This spec only defines "encoding=hex". If "encoding" isn't there, the default encoding defined for the package MUST be used.

UUI data is treated as an opaque series of octets 🦋. This mechanism MUST NOT be used to convey a URL or URI, since the Call-Info header field in [RFC3261] already handles that use case 💀.

4.1. Syntax for UUI Header Field

The UUI header field can show up in INVITE requests and responses, and in BYE requests and responses 📞. Note that when the UUI header is used in responses, it can only be utilized in end-to-end responses, e.g., 1xx (excluding 100), 2xx, and 3xx responses. Main character rules, literally 👑.

The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in RFC 5234 and extends RFC 3261 (where token, quoted-string, and generic-param are defined). Here's the grammar 🧾:

     UUI         = "User-to-User" HCOLON uui-value *(COMMA uui-value)
     uui-value   = uui-data *(SEMI uui-param)
     uui-data    = token / quoted-string
     uui-param   = pkg-param / cont-param / enc-param / generic-param
     pkg-param   = "purpose" EQUAL pkg-param-value
     pkg-param-value = token
     cont-param   = "content" EQUAL cont-param-value
     cont-param-value = token
     enc-param   = "encoding" EQUAL enc-param-value
     enc-param-value = token / "hex"

Each package defines how many User-to-User header fields of each package may be present in a request or a response 📦. A sender MAY include multiple User-to-User header fields, and a receiver MUST be prepared to receive multiple User-to-User header fields 🫶. Consistent with the rules of SIP syntax, the syntax defined in this document allows any combination of individual User-to-User header fields or User-to-User header fields with multiple comma separated UUI data elements 🌈. Any size limitations on the UUI data for a particular purpose are to be defined by the related UUI package.

UAs SHALL ignore UUI data from packages or encoding that they do not understand 🙈. Bye bye, unknown stuff.

For redirection use cases, the header field is included (escaped) within the Contact URI. For referral use cases, the header field is included (escaped) within the Refer-To URI. For example, if a UA supports this specification, it SHOULD include any UUI data included in a redirection URI (if the UUI data and encoding is understood) ✨.

Note that redirection can occur multiple times to a request 🔁. Currently, UAs that support attended transfer support the ability to include a Replaces header field [RFC3891] into a Refer-To URI, and when acting upon this URI, UAs add the Replaces header field to the triggered INVITE. This sort of logic and behavior is utilized for the UUI header field (that is, the UUI header field is included in the triggered INVITE) 🦋. The UA processing the REFER [RFC3515] or the 3xx response to the INVITE SHOULD support the UUI mechanism. If the REFER or redirect target does not support UUI, the UUI header will be discarded as per [RFC3261]. However, this may limit the utility of use cases that depend upon the UUI being supported by all elements 🥺.

Here is an example of an included User-to-User header field from the redirection response F2 of Figure 2 in [RFC6567] 🎀:

<allOneLine>
Contact: <sip:+12125551212@gateway.example.com?User-to-User=
56a390f3d2b7310023a2%3Bencoding%3Dhex%3Bpurpose%3Dfoo%3B
content%3Dbar>
</allOneLine>

The resulting INVITE F4 would contain:

User-to-User: 56a390f3d2b7310023a2;encoding=hex;purpose=foo;content=bar

4.2. Hex Encoding Definition

This specification defines hex encoding of UUI data 🍯. When the value of "hex" is used in the "encoding" parameter of a header field, the data is encoded using base16 encoding according to Section 8 of [RFC4648]. The hex-encoded value is normally represented using the "token" construction from RFC 3261, although the "quoted-string" construction is permitted, in which case the quotes MUST be ignored 🫧.

If a canonicalized version of a normally case-insensitive hex encoded UUI data object is needed for a digital signature or integrity checking, then the base16 encoding with all upper case MUST be used 🔐. Serious, but still iconic.

4.3. Source Identity of UUI Data

It is important for the recipient of UUI data to know the identity of the UA that inserted the UUI data 👀. In a request without a History-Info header field, the identity of the entity that inserted the UUI data will be assumed to be the source of the SIP message. For a SIP request, typically this is the UA identified by the URI in the From header field or a P-Asserted-Identity [RFC3325] header field.

In a request with a History-Info header field, the recipient needs to parse the Targeted-to-URIs present (hi-targeted-to-uri defined in [RFC7044]) to see if any included User-to-User header fields are present. If an included User-to-User header field is present and matches the UUI data in the request, this indicates that redirection has taken place, resulting in the inclusion of UUI data in the request. The inserter of the UUI data will be the UA identified by the Targeted-to-URI of the History-Info element prior to the element with the included UUI data 🕵️‍♀️.

In a response, the inserter of the UUI data will be the identity of the UA that generated the response. Typically, this is the UA identified in the To header field of the response. Note that any updates to this identity by use of the SIP connected identity extension [RFC4916] or other identity modifiers will update this information 💅.

For an example of History-Info and redirection, consider Figure 2 from [RFC6567] where the Originating UA is Carol, the Redirector Bob, and the Terminating UA Alice. The INVITE F4 containing UUI data could be:

INVITE sips:alice@example.com SIP/2.0
Via: SIP/2.0/TLS lab.example.com:5061
 ;branch=z9hG4bKnashds9
To: Bob <sips:bob@example.com>
From: Carol <sips:carol@example.com>;tag=323sf33k2
Call-ID: dfaosidfoiwe83ifkdf
Max-Forwards: 70
Contact: <sips:carol@lab.example.com>
Supported: histinfo
User-to-User: 342342ef34;encoding=hex
History-Info: <sips:bob@example.com>;index=1
<allOneLine>
History-Info: <sips:alice@example.com?Reason=SIP%3Bcause%3D302
   &User-to-User=342342ef34%3Bencoding%3Dhex>;index=1.1;rc=1
</allOneLine>

Without the redirection captured in the History-Info header field, Alice would conclude that the UUI data was inserted by Carol 😱. However, the History-Info containing UUI data (index=1.1) indicates that the inserter was Bob (index=1). Plot twist, it's giving detective 🔍.

To enable maintaining a record of the inserter identity of UUI data, UAs supporting this mechanism SHOULD support History-Info [RFC7044] and include Supported: histinfo in all requests and responses 🧠.

If a border element such as a proxy or a Back-to-Back User Agent (B2BUA) removes a History-Info header field containing a User-to-User parameter, the UA consuming the UUI data may not be able at the SIP level to identify the source of the UUI data. Not me losing track of who sent what 😭.

5. Guidelines for UUI Packages ✨

okay bestie, this section is basically the rulebook for making new UUI packages 💅 and the vibe is very "be careful, don't just shove random stuff in here." 🙈 So the first thing: any UUI package made with this SIP UUI mechanism MUST follow the "Standards Action" guideline from [RFC5226] and publish a Standards Track RFC that describes how it's used. 📜 The CUSS WG went with this really conservative policy while they figure out other registration options, so no shortcuts, periodt. Also, this mechanism is NOT suitable for sending arbitrary data between UAs 🚫 It's not a dumping ground, okay?

To check whether this mechanism is even the right tool, all of these conditions need to be met 🦋

  1. The information is generated and consumed by an application during session setup using SIP, but the application is not necessarily SIP aware. 🧚
  2. The behavior of SIP entities that support it is not significantly changed (as discussed in Section 4 of [RFC5727]). 🌸
  3. UAs are the generators and consumers of the UUI data. Proxies and other intermediaries may route based on the presence of a User-to-User header field or a particular package tag, but they don't otherwise consume or generate the UUI data. 💜
  4. There are no privacy issues associated with the information being transported (e.g., geolocation or emergency-related information are examples of inappropriate UUI data). 🙅‍♀️ Yikes, not that stuff.
  5. The UUI data is not being utilized for User-to-User Remote Procedure Calls (RPCs). 🚫

UUI packages define the semantics for one particular application usage of UUI data 🎀 The content defines the syntax of the UUI data, and the encoding defines how that UUI data gets encoded for the content. Each content is defined as a stream of octets, which means multiple encodings of that same content are possible ✨ For example, a package may define:

  1. The SIP methods and responses in which the UUI data may be present. 💖
  2. The maximum number of UUI data elements that may be inserted into a request or response. The default is one per encoding. Heads up: a UA may still receive a request with more than this maximum because of redirection 👀 The package needs to define how to handle that situation.
  3. The default values for content and encoding if they are not present. If the same UUI data may be inserted multiple times with different encodings, the package needs to say so. 🍓 A package can support and define multiple contents and their associated encodings, and it can also reuse contents defined by other packages.
  4. Any size limitations on the UUI data. Size needs to be specified in terms of the octet stream output of the content, since the size of the resulting uui-data element will vary depending on the encoding scheme. 📏

Now the must-dos for every package 💅

  • A package MUST define a "purpose" header field value to identify the package in the coding.
  • A package MUST describe the new application that is utilizing the UUI data and provide some use case examples.
  • The default "content" value MUST be defined or referenced in another document for the package.
  • Additional allowed contents MAY also be defined or referenced.
  • Any restrictions on the size of the UUI data MUST be described.
  • In addition, a package MAY define a media feature tag per [RFC3840] to indicate support for this UUI package. 🌈 For example, the media feature tag "sip.uui-pk1" could be defined to indicate support for a UUI package named pk1.
  • Defining a new SIP option tag just to identify support for a UUI package is NOT RECOMMENDED, unless there are additional SIP behaviors needed to implement this feature. 🙅‍♀️

For an example UUI package definition, see [RFC7434]. 🧚

5.1. Extensibility

Okay, this is the part where things get a little more intricate, so pay attention 🤓

New "content" values MUST describe the semantics of the UUI data and valid encodings, and give some example use cases. A previously defined UUI content value can be reused in a new package 🔁 In that case, how the new package uses the content is defined within the new package itself. New UUI content types cannot be added to existing packages. Instead, you'd need to define a whole new package 💀 New content values that get defined are added to the IANA registry with a Standards Track RFC, and that RFC needs to discuss the issues in this section. If no new encoding value is defined for a content, the encoding defaults to "hex" as defined in this document. In that case, the "hex" value will be explicitly stated via the encoding parameter as the encoding for the content 🦋

New "encoding" values associated with a new content MUST reference a specific encoding scheme (such as "hex", which is defined in this specification) or define the new encoding scheme. A previously defined UUI encoding value can be used with a newly defined content. In that case, the usage of the encoding is defined by the content definition. New UUI encodings cannot be added to existing contents. Instead, you'd need to define a new content 🌸 Newly defined encoding values are added to the IANA registry with a Standards Track RFC, which needs to discuss the issues in this section.

6. IANA Considerations 🎀

6.1. Registration of User-to-User Header Field

This document defines a new SIP header field named "User-to-User". 💖

The following row has been added to the "Header Fields" section of the SIP parameter registry:

              +------------------+--------------+-----------+
              | Header Name      | Compact Form | Reference |
              +------------------+--------------+-----------+
              | User-to-User     |              | [RFC7433] |
              +------------------+--------------+-----------+

6.2. Registration of User-to-User Header Field Parameters

This document defines the parameters for the header field defined in the preceding section. The header field "User-to-User" can contain the parameters "encoding", "content", and "purpose" ✨

The following rows have been added to the "Header Field Parameters and Parameter Values" section of the SIP parameter registry:

+------------------+----------------+-------------------+-----------+
| Header Field     | Parameter Name | Predefined Values | Reference |
+------------------+----------------+-------------------+-----------+
| User-to-User     | encoding       | Yes               | [RFC7433] |
+------------------+----------------+-------------------+-----------+
| User-to-User     | content        | No                | [RFC7433] |
+------------------+----------------+-------------------+-----------+
| User-to-User     | purpose        | No                | [RFC7433] |
+------------------+----------------+-------------------+-----------+

6.3. Registration of UUI Packages

This specification establishes the "UUI Packages" subregistry under <http://www.iana.org/assignments/sip-parameters>.

The descriptive text for this subregistry is:

UUI packages provide information about the usage of the UUI data in a User-to-User header field [RFC7433]. 🧚

The registration policy for this registry is "Standards Action" as defined in [RFC5226].

+------------+------------------------------------------+-----------+
| Package    | Description                              | Reference |
+------------+------------------------------------------+-----------+

6.4. Registration of UUI Content Parameters

This specification establishes the "UUI Content Parameters" subregistry under <http://www.iana.org/assignments/sip-parameters>.

The descriptive text for this subregistry is:

UUI content provides information about the content of the UUI data in a User-to-User header field [RFC7433]. 💜

The registration policy for this registry is "Standards Action" as defined in [RFC5226].

+------------+------------------------------------------+-----------+
| Content    | Description                              | Reference |
+------------+------------------------------------------+-----------+

6.5. Registration of UUI Encoding Parameters

This specification establishes the "UUI Encoding Parameters" subregistry under <http://www.iana.org/assignments/sip-parameters> and initiates its population with the table below.

The descriptive text for this subregistry is:

UUI encoding provides information about the encoding of the UUI data in a User-to-User header field [RFC7433]. 🌈

The registration policy for this registry is "Standards Action" as defined in [RFC5226].

+-----------+-------------------------------------------+-----------+
| Encoding  | Description                               | Reference |
+-----------+-------------------------------------------+-----------+
| hex       | The UUI data is encoded using hexadecimal | [RFC7433] |
+-----------+-------------------------------------------+-----------+

6.6. Registration of SIP Option Tag

This specification registers a new SIP option tag, as per the guidelines in Section 27.1 of [RFC3261]. 🦋

This document defines the SIP option tag "uui".

The following row has been added to the "Option Tags" section of the SIP Parameter Registry:

+------------+------------------------------------------+-----------+
| Name       | Description                              | Reference |
+------------+------------------------------------------+-----------+
| uui        | This option tag is used to indicate that | [RFC7433] |
|            | a UA supports and understands the        |           |
|            | User-to-User header field.               |           |
+------------+------------------------------------------+-----------+

7. Security Considerations ✨

okay bestie, this section is SERIOUS but also kinda iconic 💅 UUI data can carry sensitive info, so it might need confidentiality (privacy 🔒) and integrity protection from third parties who might wanna read it or mess with it 🙈. The three security models in [RFC6567] could apply to the UUI mechanism 💖

Model one treats the SIP layer as untrusted 🚫 and wants end-to-end integrity and/or encryption 🫶. You get this by providing the security above SIP, so applications are encouraged to use their own integrity and/or encryption mechanisms before handing the data to the SIP layer ✨

Model two is the app passing UUI with no protection to SIP and making SIP do the securing 🥺. Like, this is possible in theory, but its practical use would be extremely limited 💀. To keep multi-hop or end-to-end confidentiality and integrity of UUI data, you can use S/MIME or IPsec, as discussed in the review of REQ-13 and REQ-14 in Section 3 of this document 🌸. BUT, the lack of deployment of these mechanisms means applications cannot in general rely on them being present 😭

Model three uses a trust domain and relies on perimeter security at the SIP layer 🏰. This is the security model of the PSTN and ISDN, where UUI is commonly used today 📞. It uses hop-by-hop security mechanisms and relies on border elements for filtering and applying policy 🍓. Standard deployed SIP security mechanisms, like TLS transport, offer privacy and integrity protection on a hop-by-hop basis at the SIP layer 🔐

If the UUI data was included by the UA originator of the SIP request or response, normal SIP mechanisms can be used to figure out who inserted it 🕵️‍♀️. If a UA that wasn't the originator of the request included it, a History-Info header field can be used to find the inserter 📜. UAs can apply policy based on where the UUI data came from using this info 👑. Lowkey the big takeaway: the UUI data in an INVITE can be trusted as much as the INVITE itself can be trusted 💅✨

Also, heads up 👀: it's possible this mechanism could be used as a covert communication channel between UAs, conveying info unknown to the SIP network 🦋

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,
           <http://www.rfc-editor.org/info/rfc2119>.

[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, <http://www.rfc-editor.org/info/rfc3261>.

[RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
           Method", RFC 3515, April 2003,
           <http://www.rfc-editor.org/info/rfc3515>.

[RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
           "Indicating User Agent Capabilities in the Session
           Initiation Protocol (SIP)", RFC 3840, August 2004,
           <http://www.rfc-editor.org/info/rfc3840>.

[RFC3891]  Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
           Protocol (SIP) "Replaces" Header", RFC 3891, September
           2004, <http://www.rfc-editor.org/info/rfc3891>.

[RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
           Authenticated Identity Management in the Session
           Initiation Protocol (SIP)", RFC 4474, August 2006,
           <http://www.rfc-editor.org/info/rfc4474>.

[RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
           Encodings", RFC 4648, October 2006,
           <http://www.rfc-editor.org/info/rfc4648>.

[RFC4916]  Elwell, J., "Connected Identity in the Session Initiation
           Protocol (SIP)", RFC 4916, June 2007,
           <http://www.rfc-editor.org/info/rfc4916>.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
           (TLS) Protocol Version 1.2", RFC 5246, August 2008,
           <http://www.rfc-editor.org/info/rfc5246>.

[RFC7044]  Barnes, M., Audet, F., Schubert, S., van Elburg, J., and
           C. Holmberg, "An Extension to the Session Initiation
           Protocol (SIP) for Request History Information", RFC 7044,
           February 2014, <http://www.rfc-editor.org/info/rfc7044>.

[RFC7434]  Drage, K. and A. Johnston, "Interworking ISDN Call Control
           User Information with SIP", RFC 7434, January 2015,
           <http://www.rfc-editor.org/info/rfc7434>.

8.2. Informative References 🦋

[Q1980]    ITU-T, "The Narrowband Signalling Syntax (NSS) - Syntax
           Definition", ITU-T Recommendation Q.1980.1,
           <http://www.itu.int/itudoc/itu-t/aap/sg11aap/history/
           q1980.1/q1980.1.html>.

[Q763]     ITU-T, "Signalling System No. 7 - ISDN User Part formats
           and codes", ITU-T Recommendation Q.763,
           <http://www.itu.int/rec/T-REC-Q.763-199912-I/en>.

[Q931]     ITU-T, "ISDN user-network interface layer 3 specification
           for basic call control", ITU-T Recommendation Q.931,
           <http://www.itu.int/rec/T-REC-Q.931-199805-I/en>.

[RFC3325]  Jennings, C., Peterson, J., and M. Watson, "Private
           Extensions to the Session Initiation Protocol (SIP) for
           Asserted Identity within Trusted Networks", RFC 3325,
           November 2002, <http://www.rfc-editor.org/info/rfc3325>.

[RFC3372]  Vemuri, A. and J. Peterson, "Session Initiation Protocol
           for Telephones (SIP-T): Context and Architectures", BCP
           63, RFC 3372, September 2002,
           <http://www.rfc-editor.org/info/rfc3372>.

[RFC4475]  Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
           and H. Schulzrinne, "Session Initiation Protocol (SIP)
           Torture Test Messages", RFC 4475, May 2006,
           <http://www.rfc-editor.org/info/rfc4475>.

[RFC5727]  Peterson, J., Jennings, C., and R. Sparks, "Change Process
           for the Session Initiation Protocol (SIP) and the Real-
           time Applications and Infrastructure Area", BCP 67, RFC
           5727, March 2010,
           <http://www.rfc-editor.org/info/rfc5727>.

[RFC6086]  Holmberg, C., Burger, E., and H. Kaplan, "Session
           Initiation Protocol (SIP) INFO Method and Package
           Framework", RFC 6086, January 2011,
           <http://www.rfc-editor.org/info/rfc6086>.

[RFC6567]  Johnston, A. and L. Liess, "Problem Statement and
           Requirements for Transporting User-to-User Call Control
           Information in SIP", RFC 6567, April 2012,
           <http://www.rfc-editor.org/info/rfc6567>.

Appendix A. Other Possible Mechanisms 🎀

Two other possible mechanisms for transporting UUI data will be described: MIME body and URI parameter transport 🧚

A.1. Why INFO is Not Used 🙅‍♀️

Since the INFO method [RFC6086] was developed for ISDN User Part (ISUP) interworking of User-to-User Information, it might seem like the logical choice here 🤔. For non-call control User-to-User Information, INFO can be used for end-to-end transport. However, for transport of call control User-to-User Information, INFO can not be used 🙅‍♀️. As the call flows in [RFC6567] show, the information is related to an attempt to establish a session and needs to be passed with the session setup request (INVITE), responses to that INVITE, or session termination requests. As a result, it is not possible to use INFO in these cases 💀

A.2. Why Other Protocol Encapsulation UUI Mechanisms Are Not Used 🫠

Other protocols can transport UUI data too 💁‍♀️. For example, consider the ITU-T Recommendation Q.931 User-user information element [Q931] and the ITU-T Recommendation Q.763 User-to-User information parameter [Q763]. In addition, the Narrowband Signalling System (NSS) [Q1980] can also transport UUI data 🙌. Should one of these protocols be in use, and present in both User Agents, then using those protocols to transport UUI data might be a logical solution. Essentially, this is just adding an extra layer in the protocol stack 🥞. In these cases, SIP is not transporting the UUI data; it is encapsulating another protocol, and that protocol is transporting the UUI data. Once a mechanism to transport that other protocol using SIP exists, the UUI data transport function is basically obtained without any extra effort 🎉

However, the CUSS working group believes, consistent with its charter, that SIP needs its own native UUI data transport mechanism 💖. It is not reasonable for a SIP UA to have to implement another entire protocol (ISDN or NSS, for example) just to get the very simple UUI data transport service 😩. Of course, this work does not stop anyone from using other protocols with SIP to transport UUI data 🫶

A.3. MIME Body Approach 📦

One method of transport is to use a MIME body 💌. This is in keeping with the Session Initiation Protocol for Telephones (SIP-T) architecture [RFC3372], in which MIME bodies are used to transport ISUP information. Since the INVITE will normally have a Session Description Protocol (SDP) message body, the resulting INVITE with SDP and UUI data will be multipart MIME. This is not ideal, as many SIP UAs do not support multipart MIME INVITEs 😬

A bigger problem is inserting a UUI message body by a redirect server or in a REFER. The body would need to be encoded in the Contact URI of the 3xx response or the Refer-To URI of a REFER. Currently, the authors are not aware of any UAs that support this capability for any body type today 🤷‍♀️. As such, the complete set of semantics for this operation would need to be determined and defined. Some issues will need to be resolved, such as: do all the Content-* header fields have to be included as well? And what if the included Content-Length does not agree with the included body? 🤯

Since proxies cannot remove a body from a request or response, it is not clear how this mechanism could meet REQ-9 🤔.

The requirement for integrity protection could be met by using an S/MIME signature over the body, as defined in "Securing MIME bodies", Section 23.3 of RFC 3261 ✍️. Alternatively, this could be achieved using [RFC4474]. The requirement for end-to-end privacy could be met using S/MIME encryption or using encryption at the application layer 🔐. However, note that neither S/MIME nor RFC 4474 enjoys deployment in SIP today 😭

An example:

<allOneLine>
Contact: <sip:+12125551212@gateway.example.com?Content-Type=
application/uui&body=ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
</allOneLine>

As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5, REQ-7, REQ-11, REQ-13, and REQ-14 🙌. Meeting REQ-12 seems possible, although the authors don't have a specific mechanism to propose 🤞. Meeting REQ-3 is problematic but not impossible for this mechanism 😵. However, this mechanism does not seem to be able to meet REQ-9 💀

A.4. URI Parameter ✨

okay so the next idea people floated was sticking the UUI data right into the URI as a parameter 🎀 It could ride along in a Request-URI, or in the Contact URI, or in a Refer-To URI. The catch is that it's not clear how it would get carried in a response that doesn't have a Request-URI, or in BYE requests or responses 🥺

Contact: <sip:+12125551212@gateway.example.com;uui=ZeGl9i2icVqaNVailT
6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>

Here's how it plays out. An INVITE sent to that Contact URI would have the UUI data sitting in the Request-URI of the INVITE 💅 The problem is that a URI parameter in a Request-URI doesn't survive retargeting by a proxy, which is shown in Figure 2 of [RFC6567]. So if the URI shows up with an Address of Record instead of a Contact URI, the URI parameter in the Request-URI doesn't get copied over to the Contact URI, and the info just vanishes 😭 And if that same URI shows up in a Refer-To header field, the exact same info loss happens.

Honestly the URI parameter approach would hit REQ-3, REQ-5, REQ-7, REQ-9, and REQ-11 🙌 It might also hit REQ-12 and REQ-13, which is a maybe. But it doesn't look like it covers REQ-1, REQ-2, REQ-4, or REQ-14, so it's not the full glow-up 💀

Acknowledgments

Joanne McMillen was a major contributor and coauthor of earlier versions of this document 🫶 Huge thanks to Paul Kyzivat for the hex encoding rules 🍓 Thanks to Spencer Dawkins, Keith Drage, Vijay Gurbani, and Laura Liess for reviewing the document ✨ The authors also want to thank Roland Jesske, Celine Serrut-Valette, Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, and Mahalingam Mani for their comments 💖 And thanks to Scott Kelly and Joel Halpern for their reviews 🌸

Authors' Addresses

Alan Johnston Avaya St. Louis, MO 63124 United States

EMail: alan.b.johnston@gmail.com

James Rafferty Human Communications Norfolk, MA 02056 United States

EMail: jay@humancomm.com

📦 where this page comes from