A Mechanism for Transporting User-to-User Call Control Information in SIP
Extracted elements (32)
A MIME body approach was rejected because it would require multipart MIME INVITEs (many UAs don't support this), insertion of bodies by redirect servers is not supported by existing UAs, and proxies cannot remove bodies from requests making policy enforcement (REQ-9) impossible.
A URI parameter approach was rejected because a URI parameter in a Request-URI does not survive proxy retargeting—if the URI is an Address of Record rather than a Contact URI, the parameter is lost. This fails to meet REQ-1, REQ-2, REQ-4, and REQ-14.
INFO (RFC 6086) was not used because call control UUI data needs to be passed with the session setup request (INVITE), responses, or termination requests—INFO cannot carry information during session establishment and therefore cannot meet this requirement.
Protocol encapsulation (ISDN Q.931, Q.763, or NSS) was rejected because requiring SIP UAs to implement an entire additional protocol just to transport a small amount of UUI data is unreasonable. SIP needs its own native UUI transport mechanism.
The UUI mechanism is designed to interwork with PSTN/ISDN services. The default package 'isdn-uui' provides interworking with ITU-T Q.931 User-user information and Q.763 User-to-User information parameter; details are in RFC 7434.
A package MUST define a 'purpose' header field value to identify the package. A package MUST describe the new application and provide use case examples. The default 'content' value MUST be defined or referenced. Any restrictions on size of UUI data MUST be described.
A sender MAY include multiple User-to-User header fields, and a receiver MUST be prepared to receive multiple User-to-User header fields. Each package defines how many UUI header fields of each package may be present.
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.
If a UA supports this specification, it SHOULD include any UUI data found in a redirection URI in the triggered INVITE (if the UUI data and encoding is understood).
If the 'content' header field parameter is 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.
If the 'encoding' header field parameter is not present, the default encoding defined for the package MUST be used.
If the 'purpose' header field parameter is not present, the ISDN UUI package MUST be used (default purpose value is 'isdn-uui' as defined in RFC 7434).
New 'content' values MUST describe the semantics of the UUI data and valid encodings. New content values are added to the IANA registry with a Standards Track RFC. New UUI content types cannot be added to existing packages—a new package must be defined instead.
New 'encoding' values associated with a new content MUST reference a specific encoding scheme or define a new one. New UUI encodings cannot be added to existing contents—a new content must be defined. Newly defined encoding values are added to the IANA registry with a Standards Track RFC.
The definition of a new SIP option tag solely to identify support for a UUI package is NOT RECOMMENDED unless there are additional SIP behaviors needed to implement the feature.
This mechanism MUST NOT be used to convey a URL or URI, since the Call-Info header field in RFC 3261 already supports this use case.
To enable maintaining a record of the inserter identity of UUI data, UAs supporting this mechanism SHOULD support History-Info (RFC 7044) and include Supported: histinfo in all requests and responses.
UAs SHALL ignore UUI data from packages or encodings that they do not understand.
UUI packages defined using this SIP UUI mechanism MUST follow the 'Standards Action' guideline as defined in RFC 5226 and publish a Standards Track RFC that describes the usage.
Hex encoding ('encoding=hex') encodes UUI data using base16 encoding per RFC 4648 Section 8. The hex-encoded value is normally represented using the 'token' construction; if 'quoted-string' is used, the quotes MUST be ignored.
Source identity of inserted UUI data: without History-Info, the inserter is assumed to be the From header or P-Asserted-Identity. With History-Info, the inserter is identified by the Targeted-to-URI element prior to the one containing the included UUI data.
The SIP option tag 'uui' indicates that a UA supports and understands the User-to-User header field. It can be used in Require or Supported header fields to require or discover mechanism support, and proxies may use it to route to an appropriate UA.
The User-to-User header field can be present in INVITE requests and responses (1xx excluding 100, 2xx, 3xx) and BYE requests and responses. For redirection and referral use cases, the header is included (escaped) within the Contact URI or Refer-To URI respectively.
The User-to-User SIP header field carries UUI data along with 'purpose', 'content', and 'encoding' parameters. The 'purpose' parameter identifies the UUI package, 'content' identifies the actual content type, and 'encoding' indicates how the data is encoded.
IANA created the 'UUI Content Parameters' subregistry under the SIP parameter registry. Registration policy is 'Standards Action'. This registry tracks content types that describe the content of UUI data in the User-to-User header field.
IANA created the 'UUI Encoding Parameters' subregistry under the SIP parameter registry with initial entry 'hex' (base16 encoding per RFC 4648). Registration policy is 'Standards Action'.
IANA created the 'UUI Packages' subregistry under the SIP parameter registry. Registration policy is 'Standards Action'. This registry tracks packages that define semantics for particular application uses of UUI data.
IANA registered the User-to-User header field in the SIP Header Fields registry with parameters 'encoding' (predefined values: Yes), 'content' (predefined values: No), and 'purpose' (predefined values: No).
It is possible that the UUI mechanism could be used as a covert communication channel between UAs, conveying information unknown to the SIP network.
The trust level of UUI data in an INVITE equals the trust level of the INVITE itself. If a border element (proxy or B2BUA) removes a History-Info header field containing a User-to-User parameter, the consuming UA may not be able to identify the source of the UUI data at the SIP level.
UUI data can carry sensitive information requiring confidentiality or integrity protection. Three security models are described: (1) end-to-end protection above the SIP layer by the application, (2) SIP-layer protection via S/MIME or IPsec (limited deployment), and (3) trust-domain/perimeter security with hop-by-hop TLS as used in PSTN/ISDN environments.
The User-to-User header field ABNF: UUI = "User-to-User" HCOLON uui-value *(COMMA uui-value), where uui-value = uui-data *(SEMI uui-param), and uui-param includes pkg-param, cont-param, enc-param, or generic-param. The uui-data is a token or quoted-string.