idnits 2.17.1
draft-ietf-cuss-sip-uui-12.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (January 25, 2014) is 3738 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFCXXXX' is mentioned on line 581, but not defined
== Outdated reference: A later version (-11) exists of
draft-ietf-cuss-sip-uui-isdn-06
** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224)
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group A. Johnston
3 Internet-Draft Avaya
4 Intended status: Standards Track J. Rafferty
5 Expires: July 29, 2014 Human Communications
6 January 25, 2014
8 A Mechanism for Transporting User to User Call Control Information in
9 SIP
10 draft-ietf-cuss-sip-uui-12
12 Abstract
14 There is a class of applications which benefit from using SIP to
15 exchange User to User Information (UUI) data during session
16 establishment. This information, known as call control UUI data, is
17 a small piece of data inserted by an application initiating the
18 session, and utilized by an application accepting the session. The
19 rules which apply for a specific application are defined by a UUI
20 package. This UUI data is opaque to SIP and its function is
21 unrelated to any basic SIP function. This document defines a new SIP
22 header field, User-to-User, to transport UUI data, along with an
23 extension mechanism.
25 Status of this Memo
27 This Internet-Draft is submitted to IETF in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at http://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on July 29, 2014.
42 Copyright Notice
44 Copyright (c) 2014 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 3. Requirements Discussion . . . . . . . . . . . . . . . . . . . 3
62 4. Normative Definition . . . . . . . . . . . . . . . . . . . . . 5
63 4.1. Syntax for UUI Header Field . . . . . . . . . . . . . . . 5
64 4.2. Hex Encoding Definition . . . . . . . . . . . . . . . . . 7
65 4.3. Source Identity of UUI data . . . . . . . . . . . . . . . 7
66 5. Guidelines for UUI Packages . . . . . . . . . . . . . . . . . 9
67 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10
68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
69 6.1. Registration of User-to-User Header Field . . . . . . . . 11
70 6.2. Registration of User-to-User Header Field Parameters . . . 11
71 6.3. Registration of UUI Packages . . . . . . . . . . . . . . . 11
72 6.4. Registration of UUI Content Parameters . . . . . . . . . . 12
73 6.5. Registration of UUI Encoding Parameters . . . . . . . . . 12
74 6.6. Registration of SIP Option Tag . . . . . . . . . . . . . . 13
75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
76 8. Appendix - Other Possible Mechanisms . . . . . . . . . . . . . 14
77 8.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 14
78 8.2. Why Other Protocol Encapsulation UUI Mechanisms are
79 Not Used . . . . . . . . . . . . . . . . . . . . . . . . . 14
80 8.3. MIME body Approach . . . . . . . . . . . . . . . . . . . . 15
81 8.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 16
82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
84 10.1. Informative References . . . . . . . . . . . . . . . . . . 17
85 10.2. Normative References . . . . . . . . . . . . . . . . . . . 18
86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
88 1. Overview
90 This document describes the transport of User to User Information
91 (UUI) data using SIP [RFC3261]. A mechanism is defined for the
92 transport of general application UUI data and for the transport of
93 call control related ITU-T Q.931 User to User Information Element (UU
94 IE) [Q931] and ITU-T Q.763 User to User Information Parameter [Q763]
95 data in SIP. UUI data is widely used in the PSTN today for contact
96 centers and call centers. There is also a trend for the related
97 applications to transition from ISDN to SIP. The UUI extension for
98 SIP may also be used for native SIP UAs implementing similar services
99 and to interwork with ISDN services. Note that in most cases, there
100 is an a priori understanding between the UAs in regard to what to do
101 with received UUI data.
103 This mechanism was designed to meet the use cases, requirements, and
104 call flows for SIP call control UUI detailed in [RFC6567]. All
105 references to requirement numbers (REQ-N) and figure numbers refer to
106 this document.
108 The mechanism is a new SIP header field, along with a new SIP option
109 tag. The header field carries the UUI data, along with parameters
110 indicating the encoding of the UUI data, the UUI package, and
111 optionally the content of the UUI data. The package definition
112 contains details about how a particular application can utilize the
113 UUI mechanism. The header field can be included (sometimes called
114 "escaped") into URIs supporting referral and redirection scenarios.
115 In these scenarios, History-Info is used to indicate the inserter of
116 the UUI data. The SIP option tag can be used to indicate support for
117 the header field. Support for the UUI header field indicates that a
118 UA is able to extract the information in the UUI data and pass it up
119 the protocol stack. Individual packages using the UUI mechanism can
120 utilize SIP media feature tags to indicate that a UA supports a
121 particular UUI package. Guidelines for defining UUI packages are
122 provided.
124 2. Terminology
126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
128 "OPTIONAL" in this document are to be interpreted as described in BCP
129 14, RFC 2119 [RFC2119].
131 3. Requirements Discussion
133 This section describes how the User-to-User header field meets the
134 requirements in [RFC6567]. The header field can be included in
135 INVITE requests and responses and BYE requests and responses, meeting
136 REQ-1 and REQ-2.
138 For redirection and referral use cases and REQ-3, the header field is
139 included (escaped) within the Contact or Refer-To URI. The details
140 of this mechanism as it applies for redirection and referral use
141 cases are covered in Section 4.1.
143 Since SIP proxy forwarding and retargeting does not affect header
144 fields, the header field meets REQ-4.
146 The UUI header field will carry the UUI data and not a pointer to the
147 data, so REQ-5 is met.
149 Since the basic design of the UUI header field is similar to the ISDN
150 UUI service, interworking with PSTN protocols is straightforward and
151 is documented in a separate specification
152 [I-D.ietf-cuss-sip-uui-isdn], meeting REQ-6.
154 Requirements REQ-7, REQ-8, and REQ-10 relate to discovery of the
155 mechanism and supported packages, and hence applications. REQ-7
156 relates to support of the UUI header field, while REQ-8 relates to
157 routing based on support of the UUI header field. REQ-7 is met by
158 defining a new SIP option tag 'uui'. The use of a Require:uui in a
159 request, or Supported:uui in an OPTIONS response could be used to
160 require or discover support of the mechanism. The presence of a
161 Supported:uui or Require:uui header field can be used by proxies to
162 route to an appropriate UA, meeting REQ-8. However, note that only
163 UAs are expected to understand the UUI data - proxies and other
164 intermediaries do not. REQ-10 is met by utilizing SIP feature tags
165 [RFC3840]. For example, the feature tag 'sip.uui-isdn' could be used
166 to indicate support of the ISDN UUI package, or 'sip.uui-pk1' could
167 be used to indicate support for a particular package, pk1.
169 Proxies commonly apply policy to the presence of certain SIP header
170 fields in requests by either passing them or removing them from
171 requests. REQ-9 is met by allowing proxies and other intermediaries
172 to remove UUI header fields in a request or response based on policy.
174 Carrying UUI data elements of at least 129 octets is trivial in the
175 UUI header field, meeting REQ-11. Note that very large UUI data
176 elements should be avoided, as SIP header fields have traditionally
177 not been large.
179 To meet REQ-12 for the redirection and referral use cases, History-
180 Info [I-D.ietf-sipcore-rfc4244bis] can be used. In these retargeting
181 cases, the changed Request-URI will be recorded in the History-Info
182 header field along with the identity of the element that performed
183 the retargeting.
185 The requirement for integrity protection in REQ-13 could be met by
186 the use of an S/MIME signature over a subset of header fields, as
187 defined in Section 23.4 of RFC 3261 "SIP Header Privacy and Integrity
188 using S/MIME: Tunneling SIP". The requirement of REQ-14 for end-to-
189 end privacy could be met using S/MIME or using encryption at the
190 application layer. Note that the use of S/MIME to secure the UUI
191 data will result in an additional body being added to the request.
192 Hop-wise Transport Layer Security (TLS) [RFC5246] allows the header
193 field to meet REQ-15 for hop-by-hop security.
195 4. Normative Definition
197 This document defines a new SIP header field "User-to-User" to
198 transport call control UUI data to meet the requirements in
199 [RFC6567].
201 To help tag and identify the UUI data used with this header field,
202 "purpose", "content", and "encoding" header field parameters are
203 defined. The "purpose" header field parameter identifies the package
204 which defines the generation and usage of the UUI data for a
205 particular application. For the case of interworking with the ISDN
206 UUI Service, the ISDN UUI Service interworking package is used. If
207 the "purpose" header field parameter is not present, interworking
208 with the ISDN UUI Service MUST be assumed. The "content" header
209 field parameter identifies the actual content of the UUI data. If
210 not present, the content MUST be assumed to be the default defined
211 for the package. Newly defined UUI packages MUST define or reference
212 at least a default "content" value. The "encoding" header field
213 parameter indicates the method of encoding the information in the UUI
214 data associated with a particular "content" value. This
215 specification only defines "encoding=hex". If the "encoding" header
216 field parameter is not present, the encoding MUST be assumed to be
217 the default defined for the package.
219 UUI data is considered an opaque series of octets. This mechanism
220 SHOULD NOT be used to convey a URL or URI; the Call-Info header field
221 [RFC3261] is used for this purpose.
223 4.1. Syntax for UUI Header Field
225 The User-to-User (UUI) header field can be present in INVITE requests
226 and responses and in BYE requests and responses. Note that when the
227 UUI header is used in responses, it can only be utilized in end-to-
228 end responses, e.g. 1xx (excluding 100), 2xx, and 3xx responses.
230 The following syntax specification uses the augmented Backus-Naur
231 Form (BNF) as described in RFC 5234 and extends RFC 3261 (where token
232 and quoted-string are defined).
234 UUI = "User-to-User" HCOLON uui-value *(COMMA uui-value)
235 uui-value = uui-data *(SEMI uui-param)
236 uui-data = token / quoted-string
237 uui-param = pkg-param / cont-param / enc-param / generic-param
238 pkg-param = "purpose" EQUAL pkg-param-value
239 pkg-param-value = token
240 cont-param = "content" EQUAL cont-param-value
241 cont-param-value = token
242 enc-param = "content" EQUAL enc-param-value
243 enc-param-value = token / "hex"
245 The rules for how many User-to-User header fields of each package may
246 be present in a request or a response are defined for each package.
247 Multiple User-to-User header fields MAY be present in a request or
248 response. Consistent with the rules of SIP syntax, the syntax
249 defined in this document allows any combination of individual User-
250 to-User header fields or User-to-User header fields with multiple
251 comma separated UUI data elements. Any size limitations on the UUI
252 data for a particular purpose must be defined by the related UUI
253 package.
255 UAs SHOULD ignore UUI data from packages or encoding that they do not
256 understand.
258 For redirection and referral use cases, the header field is included
259 (escaped) within the Contact or Refer-To URI. For example, if a UA
260 supports this specification, it SHOULD include any UUI data included
261 in a redirection URI (if the UUI data and encoding is understood).
262 Note that redirection can occur multiple times to a request.
263 Currently, UAs that support attended transfer support the ability to
264 include a Replaces header field [RFC3891] into a Refer-To URI, and
265 when acting upon this URI, add the Replaces header field to the
266 triggered INVITE. This sort of logic and behavior shall also be
267 utilized for the UUI header field (that is, the UUI header field is
268 included in the triggered INVITE). The UA processing the REFER or
269 the 3xx to the INVITE SHOULD support the UUI mechanism. If the REFER
270 or redirect target does not support UUI, the UUI header will be
271 discarded as per [RFC3261]. However, this may limit the utility of
272 use cases which depend upon the UUI being supported by all elements.
274 Here is an example of an included User-to-User header field from the
275 redirection response F2 of Figure 2:
277
278 Contact:
281
283 The resulting INVITE F4 would contain:
285 User-to-User: 56a390f3d2b7310023a2;encoding=hex;purpose=foo;content=bar
287 4.2. Hex Encoding Definition
289 This specification defines hex encoding of UUI data. The value of
290 "hex" for the "encoding" header field parameter is normatively
291 defined in this section. It is used to encode binary UUI data with a
292 length that terminates at an octet boundary. Each octet of binary
293 data to be represented in the hex encoding MUST be mapped to two
294 hexadecimal digits (represented by ASCII characters 0-9, A-F and
295 a-f), each representing four bits within the octet. The four bits
296 appearing first in the binary UUI data MUST be mapped to the first
297 hexadecimal digit and the four subsequent bits in the binary UUI data
298 MUST be mapped to the second hexadecimal digit. When mapping 4 bits
299 to a hexadecimal digit, the bit appearing first in the binary UUI
300 data shall be most significant. Thus, Hex encoded UUI data must have
301 an even number of hexadecimal digits, and MUST be considered invalid
302 if it has an odd number. Hex encoding is normally done as a token,
303 although quoted-string is permitted, in which case the quotes MUST be
304 ignored.
306 4.3. Source Identity of UUI data
308 It is important for the recipient of UUI data to know the identity of
309 the UA that inserted the UUI data. In a request without a History-
310 Info [I-D.ietf-sipcore-rfc4244bis] header field, the identity of the
311 entity which inserted the UUI data will be assumed to be the source
312 of the SIP message. For a SIP request, typically this is the UA
313 identified by the URI in the From header field or a P-Asserted-
314 Identity [RFC3325] header field. In a request with a History-Info
315 header field, the recipient needs to parse the Targeted-to-URIs
316 present (hi-targeted-to-uri) to see if any included User-to-User
317 header fields are present. If an included User-to-User header field
318 is present and matches the UUI data in the request, this indicates
319 that redirection has taken place, resulting in the inclusion of UUI
320 data in the request. The inserter of the UUI data will be the UA
321 identified by the Targeted-to-URI of the History-Info element prior
322 to the element with the included UUI data. In a response, the
323 inserter of the UUI data will be the identity of the UA that
324 generated the response. Typically, this is the UA identified in the
325 To header field of the response. Note that any updates to this
326 identity by use of the SIP Connected Identity extension [RFC4916] or
327 others will update this information.
329 For an example of History-Info and redirection, consider Figure 2
330 from [RFC6567] where the Originating UA is Carol, the Redirector Bob,
331 and the Terminating UA Alice. The INVITE F4 containing UUI data
332 could be:
334 INVITE sips:alice@example.com SIP/2.0
335 Via: SIP/2.0/TLS lab.example.com:5061
336 ;branch=z9hG4bKnashds9
337 To: Bob
338 From: Carol ;tag=323sf33k2
339 Call-ID: dfaosidfoiwe83ifkdf
340 Max-Forwards: 70
341 Contact:
342 Supported: histinfo
343 User-to-User: 342342ef34;encoding=hex
344 History-Info: ;index=1
345
346 History-Info: ;index=1.1;rc=1
348
350 Without the redirection captured in the History-Info, Alice would
351 conclude the UUI data was inserted by Carol. However, the History-
352 Info containing UUI data (index=1.1) indicates that the inserter was
353 Bob (index=1).
355 Note that the tag convention from SIP Torture Test
356 Messages [RFC4475] is used to show that there are no line breaks in
357 the actual message syntax.
359 To enable maintaining a record of the inserter identity of UUI data,
360 UAs supporting this mechanism SHOULD support History-Info
361 [I-D.ietf-sipcore-rfc4244bis] and include Supported: histinfo in all
362 requests and responses.
364 Border elements such as proxies or Back-to-Back User Agents (B2BUAs)
365 which anonymize a SIP URI in a History-Info header field SHOULD leave
366 the corresponding User-to-User parameter, if present, and the
367 corresponding User-to-User header field unchanged. Border elements
368 removing a History-Info header containing a User-to-User parameter
369 SHOULD NOT drop the corresponding User-to-User header. Otherwise,
370 the UA consuming the UUI data may not be able at SIP level to
371 identify the source of the UUI data.
373 5. Guidelines for UUI Packages
375 UUI packages defined using this SIP UUI mechanism MUST follow the
376 "RFC Required" guideline as defined in [RFC5226] and publish a
377 standards track RFC which describes the usage. Note that this
378 mechanism is not suitable for the transport of arbitrary data between
379 UAs. The following guidelines are provided to help determine if this
380 mechanism is appropriate or some other SIP mechanism should be used.
381 The SIP UUI mechanism is applicable when all of the following
382 conditions be met:
384 1. The information is generated and consumed by an application
385 during session setup using SIP, but the application is not
386 necessarily SIP aware.
388 2. The behavior of SIP entities that support it is not
389 significantly changed (as discussed in Section 4 of [RFC5727]).
391 3. User Agents (UAs) are the generators and consumers of the UUI
392 data. Proxies and other intermediaries may route based on the
393 presence of a User-to-User header field or a particular package
394 tag but do not otherwise consume or generate the UUI data.
396 4. There are no overriding privacy issues associated with the
397 information being transported (e.g., geolocation or emergency-
398 related information are examples of inappropriate UUI data).
400 5. The UUI data is not being utilized for user-to-user Remote
401 Procedure Call (RPC) calls.
403 UUI packages define the semantics for a particular application usage
404 of UUI data. The content defines the syntax of the UUI data, while
405 the encoding defines the encoding of the UUI data for the content.
406 Each content is defined as a stream of octets, which allows multiple
407 encodings of that content. For example, packages may define:
409 1. The SIP methods and responses in which the UUI data may be
410 present.
412 2. The maximum number of UUI data elements that may be inserted
413 into a request or response. (The default is one per encoding.)
414 Note that a UA may still receive a request with more than this
415 maximum number due to redirection. The package must define how to
416 handle this situation.
418 3. The default values for content and encoding if they are not
419 present. If the same UUI data may be inserted multiple times with
420 different encodings, the packages must state this. A package may
421 support and define multiple contents and their associated
422 encodings, and reuse contents defined by other packages.
424 4. Any size limitations on the UUI data. Size should be
425 specified in terms of the octet stream output of the content,
426 since the size of the resulting uui-data element will vary
427 depending on the encoding scheme.
429 A package MUST define a "purpose" header field value to identify the
430 package in the coding. A package MUST describe the new application
431 which is utilizing the UUI data and provide some use case examples.
432 The default "content" value MUST be defined or referenced in another
433 document for the package. Additional allowed contents MAY also be
434 defined or referenced. Any restrictions on the size of the UUI data
435 MUST be described. In addition, a package MAY define a Media Feature
436 tag per RFC 3840 [RFC3840] to indicate support for this UUI package.
437 For example, the media feature tag sip.uui-pk1 could be defined to
438 indicate support for a UUI package named pk1. The definition of a
439 new SIP option tag solely to identify support for a UUI package is
440 NOT RECOMMENDED unless there are additional SIP behaviors needed to
441 implement this feature.
443 For an example UUI package definition, see
444 [I-D.ietf-cuss-sip-uui-isdn].
446 5.1. Extensibility
448 New "content" values MUST describe the semantics of the UUI data,
449 valid encodings, and give some example use cases. A previously
450 defined UUI content value can be used in a new package. In this
451 case, the semantics and usage of the content by the new package is
452 defined within the new package. New UUI content types cannot be
453 added to existing packages - instead, a new package would need to be
454 defined. New content values defined are added to the IANA registry
455 with a standards track RFC, which needs to discuss the issues in this
456 section. If no new encoding value is defined for a content, the
457 encoding defaults to "hex" as defined in this document. In this
458 case, the "hex" value will be explicitly stated via the encoding
459 parameter as the encoding for the content.
461 New "encoding" values associated with a new content MUST reference a
462 specific encoding scheme (such as "hex" which is defined in this
463 specification) or define the new encoding scheme. A previously
464 defined UUI encoding value can be used with a newly defined content.
465 In this case, the usage of the encoding is defined by the content
466 definition. New UUI encodings cannot be added to existing contents -
467 instead, a new content would need to be defined. Newly defined
468 encoding values are added to the IANA registry with a standards track
469 RFC, which needs to discuss the issues in this section.
471 6. IANA Considerations
473 6.1. Registration of User-to-User Header Field
475 This document defines a new SIP header field named "User-to-User".
477 The following row shall be added to the "Header Fields" section of
478 the SIP parameter registry:
480 +------------------+--------------+-----------+
481 | Header Name | Compact Form | Reference |
482 +------------------+--------------+-----------+
483 | User-to-User | | [RFCXXXX] |
484 +------------------+--------------+-----------+
486 Editor's Note: [RFCXXXX] should be replaced with the designation of
487 this document.
489 6.2. Registration of User-to-User Header Field Parameters
491 This document defines the parameters for the header field defined in
492 the preceding section. The header field "User-to-User" can contain
493 the parameters "encoding", "content", and "purpose".
495 The following rows shall be added to the "Header Field Parameters and
496 Parameter Values" section of the SIP parameter registry:
498 +------------------+----------------+-------------------+-----------+
499 | Header Field | Parameter Name | Predefined Values | Reference |
500 +------------------+----------------+-------------------+-----------+
501 | User-to-User | encoding | hex | [RFCXXXX] |
502 +------------------+----------------+-------------------+-----------+
503 | User-to-User | content | | [RFCXXXX] |
504 +------------------+----------------+-------------------+-----------+
505 | User-to-User | purpose | | [RFCXXXX] |
506 +------------------+----------------+-------------------+-----------+
508 Editor's Note: [RFCXXXX] should be replaced with the designation of
509 this document.
511 6.3. Registration of UUI Packages
513 This specification establishes the uui-packages sub-registry under
514 http://www.iana.org/assignments/sip-parameters. New uui-packages
515 MUST follow the "Specification Required" guideline as defined in
517 [RFC5226].
519 The descriptive text for the table of uui-content is:
521 UUI Packages provides information about the usage of the UUI data in
522 a User-to-User header field [RFCXXXX].
524 +------------+------------------------------------------+-----------+
525 | Package | Description | Reference |
526 +------------+------------------------------------------+-----------+
528 6.4. Registration of UUI Content Parameters
530 This specification establishes the uui-content sub-registry under
531 http://www.iana.org/assignments/sip-parameters. New uui-content
532 values MUST follow the "Specification Required" guideline as defined
533 in [RFC5226].
535 The descriptive text for the table of uui-content is:
537 UUI Content provides information about the content of the UUI data in
538 a User-to-User header field [RFCXXXX].
540 +------------+------------------------------------------+-----------+
541 | Content | Description | Reference |
542 +------------+------------------------------------------+-----------+
544 6.5. Registration of UUI Encoding Parameters
546 This specification establishes the uui-encoding sub-registry under
547 http://www.iana.org/assignments/sip-parameters and initiates its
548 population with the table below. Additional uui-encoding values MUST
549 follow the "Specification Required" guideline as defined in
550 [RFC5226].
552 The descriptive text for the table of uui-encoding is:
554 UUI Encoding provides information about the encoding of the UUI data
555 in a User-to-User header field [RFCXXXX].
557 +-----------+-------------------------------------------+-----------+
558 | Encoding | Description | Reference |
559 +-----------+-------------------------------------------+-----------+
560 | hex | The UUI data is encoded using hexadecimal | [RFCXXXX] |
561 +-----------+-------------------------------------------+-----------+
563 6.6. Registration of SIP Option Tag
565 This specification registers a new SIP option tag, as per the
566 guidelines in Section 27.1 of [RFC3261].
568 This document defines the SIP option tag "uui".
570 The following row has been added to the "Option Tags" section of the
571 SIP Parameter Registry:
573 +------------+------------------------------------------+-----------+
574 | Name | Description | Reference |
575 +------------+------------------------------------------+-----------+
576 | uui | This option tag is used to indicate that | [RFCXXXX] |
577 | | a UA supports and understands the | |
578 | | User-to-User header field. | |
579 +------------+------------------------------------------+-----------+
581 Editor's Note: [RFCXXXX] should be replaced with the designation of
582 this document.
584 7. Security Considerations
586 User to user information can potentially carry sensitive information
587 that might require privacy or integrity protection from third parties
588 that may wish to read or modify the UUI data. [RFC6567] describes
589 three security models which may be applicable for the UUI mechanism.
591 One model treats the SIP layer as untrusted and requires end-to-end
592 integrity protection and/or encryption. This model can be achieved
593 by providing these security services at a layer above SIP. In this
594 case, applications are encouraged to use their own integrity and/or
595 encryption mechanisms before passing it to the SIP layer.
597 The second approach is for the application to pass the UUI without
598 any protection to the SIP layer and require the SIP layer to provide
599 this security. This approach is possible in theory, although its
600 practical use would be extremely limited. To preserve multi-hop or
601 end-to-end confidentiality and integrity of UUI data, approaches
602 using S/MIME or IPSec can be used, as discussed in the review of
603 REQ-13 and REQ-14 in section 3 of this document. However, the lack
604 of deployment of these mechanisms means that applications cannot in
605 general rely on them being present.
607 The third model utilizes a trust domain and relies on perimeter
608 security at the SIP layer. This is the security model of the PSTN
609 and ISDN where UUI is commonly used today. This approach uses hop-
610 by-hop security mechanisms and relies on border elements for
611 filtering and application of policy. Standard deployed SIP security
612 mechanisms such as TLS transport, offer privacy and integrity
613 protection properties on a hop-by-hop basis at the SIP layer.
615 If the UUI data was included by the UA originator of the SIP request
616 or response, normal SIP mechanisms can be used to determine the
617 identity of the inserter of the UUI data. If the UUI data was
618 included by a UA that was not the originator of the request, History-
619 Info can be used to determine the identity of the inserter of the UUI
620 data. UAs can apply policy based on the origin of the UUI data using
621 this information. In short, the UUI data included in an INVITE can
622 be trusted as much as the INVITE itself can be trusted.
624 8. Appendix - Other Possible Mechanisms
626 Two other possible mechanisms for transporting UUI data will be
627 described: MIME body and URI parameter transport.
629 8.1. Why INFO is Not Used
631 Since the INFO method [RFC6086], was developed for ISUP interworking
632 of user-to-user information, it might seem to be the logical choice
633 here. For non-call control user-to-user information, INFO can be
634 utilized for end to end transport. However, for transport of call
635 control user-to-user information, INFO can not be used. As the call
636 flows in [RFC6567] show, the information is related to an attempt to
637 establish a session and must be passed with the session setup request
638 (INVITE), responses to that INVITE, or session termination requests.
639 As a result, it is not possible to use INFO in these cases.
641 8.2. Why Other Protocol Encapsulation UUI Mechanisms are Not Used
643 Other protocols have the ability to transport UUI data. For example,
644 consider the ITU-T Q.931 User to User Information Element (UU IE)
645 [Q931] and the ITU-T Q.763 User to User Information Parameter [Q763].
646 In addition, NSS (Narrowband Signaling System) [Q1980] is also able
647 to transport UUI data. Should one of these protocols be in use, and
648 present in both User Agents, then utilizing these other protocols to
649 transport UUI data might be a logical solution. Essentially, this is
650 just adding an additional layer in the protocol stack. In these
651 cases, SIP is not transporting the UUI data; it is encapsulating
652 another protocol, and that protocol is transporting the UUI data.
653 Once a mechanism to transport that other protocol using SIP exists,
654 the UUI data transport function is essentially obtained without any
655 additional effort or work.
657 However, the CUSS working group believes, consistent with its
658 charter, that SIP needs to have its own native UUI data transport
659 mechanism. It is not reasonable for a SIP UA to have to implement
660 another entire protocol (either ISDN or NSS, for example) just to get
661 the very simple UUI data transport service. Of course, this work
662 does not preclude anyone from using other protocols with SIP to
663 transport UUI data.
665 8.3. MIME body Approach
667 One method of transport is to use a MIME body. This is in keeping
668 with the SIP-T architecture [RFC3372] in which MIME bodies are used
669 to transport ISUP information. Since the INVITE will normally have
670 an SDP message body, the resulting INVITE with SDP and UUI data will
671 be multipart MIME. This is not ideal as many SIP UAs do not support
672 multipart MIME INVITEs.
674 A bigger problem is the insertion of a UUI message body by a redirect
675 server or in a REFER. The body would need to be encoded in the
676 Contact URI of the 3xx response or the Refer-To URI of a REFER.
677 Currently, the authors are not aware of any UAs that support this
678 capability today for any body type. As such, the complete set of
679 semantics for this operation would need to be determined and defined.
680 Some issues will need to be resolved, such as, do all the Content-*
681 header fields have to be included as well? And, what if the included
682 Content-Length does not agree with the included body?
684 Since proxies cannot remove a body from a request or response, it is
685 not clear how this mechanism could meet REQ-9.
687 The requirement for integrity protection could be met by the use of
688 an S/MIME signature over the body, as defined in Section 23.3 of RFC
689 3261 "Securing MIME bodies". Alternatively, this could be achieved
690 using RFC 4474 [RFC4474]. The requirement for end-to-end privacy
691 could be met using S/MIME encryption or using encryption at the
692 application layer. However, note that neither S/MIME or RFC 4474
693 enjoys deployment in SIP today.
695 An example:
697
698 Contact:
700
702 As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5,
703 REQ-7, REQ-11, REQ-13, and REQ-14. Meeting REQ-12 seems possible,
704 although the authors do not have a specific mechanism to propose.
706 Meeting REQ-3 is problematic, but not impossible for this mechanism.
707 However, this mechanism does not seem to be able to meet REQ-9.
709 8.4. URI Parameter
711 Another proposed approach is to encode the UUI data as a URI
712 parameter. This UUI parameter could be included in a Request-URI or
713 in the Contact URI or Refer-To URI. It is not clear how it could be
714 transported in a responses which does not have a Request-URI, or in
715 BYE requests or responses.
717
718 Contact:
720
722 An INVITE sent to this Contact URI would contain UUI data in the
723 Request-URI of the INVITE. The URI parameter has a drawback in that
724 a URI parameter carried in a Request-URI will not survive retargeting
725 by a proxy as shown in Figure 2 of [RFC6567]. That is, if the URI is
726 included with an Address of Record instead of a Contact URI, the URI
727 parameter in the Reqeuest-URI will not be copied over to the Contact
728 URI, resulting in the loss of the information. Note that if this
729 same URI was present in a Refer-To header field, the same loss of
730 information would occur.
732 The URI parameter approach would meet REQ-3, REQ-5, REQ-7, REQ-9, and
733 REQ-11. It is possible the approach could meet REQ-12 and REQ-13.
734 The mechanism does not appear to meet REQ-1, REQ-2, REQ-4, and
735 REQ-14.
737 9. Acknowledgements
739 Joanne McMillen was a major contributor and co-author of earlier
740 versions of this document. Thanks to Paul Kyzivat for his
741 contribution of hex encoding rules. Thanks to Spencer Dawkins, Keith
742 Drage, Vijay Gurbani, and Laura Liess for their review of the
743 document. The authors wish to thank Roland Jesske, Celine Serrut-
744 Valette, Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen
745 Jennings, and Mahalingam Mani for their comments. Thanks to Scott
746 Kelly and Joel Halperin for their reviews.
748 10. References
749 10.1. Informative References
751 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part
752 formats and codes",
753 http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
755 [Q931] "ITU-T Q.931 User to User Information Element (UU IE)",
756 http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
758 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
759 for Telephones (SIP-T): Context and Architectures",
760 BCP 63, RFC 3372, September 2002.
762 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session
763 Initiation Protocol (SIP) INFO Method and Package
764 Framework", RFC 6086, January 2011.
766 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
767 and H. Schulzrinne, "Session Initiation Protocol (SIP)
768 Torture Test Messages", RFC 4475, May 2006.
770 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process
771 for the Session Initiation Protocol (SIP) and the Real-
772 time Applications and Infrastructure Area", BCP 67,
773 RFC 5727, March 2010.
775 [I-D.ietf-cuss-sip-uui-isdn]
776 Drage, K. and A. Johnston, "Interworking ISDN Call Control
777 User Information with SIP",
778 draft-ietf-cuss-sip-uui-isdn-06 (work in progress),
779 December 2013.
781 [Q1980] "ITU-T Q.1980.1 The Narrowband Signalling Syntax (NSS) -
782 Syntax Definition", http://www.itu.int/itudoc/itu-t/aap/
783 sg11aap/history/q1980.1/q1980.1.html .
785 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
786 Extensions to the Session Initiation Protocol (SIP) for
787 Asserted Identity within Trusted Networks", RFC 3325,
788 November 2002.
790 [RFC6567] Johnston, A. and L. Liess, "Problem Statement and
791 Requirements for Transporting User-to-User Call Control
792 Information in SIP", RFC 6567, April 2012.
794 10.2. Normative References
796 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
797 Requirement Levels", BCP 14, RFC 2119, March 1997.
799 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
800 A., Peterson, J., Sparks, R., Handley, M., and E.
801 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
802 June 2002.
804 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
805 Authenticated Identity Management in the Session
806 Initiation Protocol (SIP)", RFC 4474, August 2006.
808 [I-D.ietf-sipcore-rfc4244bis]
809 Barnes, M., Audet, F., Schubert, S., Elburg, H., and C.
810 Holmberg, "An Extension to the Session Initiation Protocol
811 (SIP) for Request History Information",
812 draft-ietf-sipcore-rfc4244bis-12 (work in progress),
813 October 2013.
815 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation
816 Protocol (SIP)", RFC 4916, June 2007.
818 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
819 "Indicating User Agent Capabilities in the Session
820 Initiation Protocol (SIP)", RFC 3840, August 2004.
822 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
823 Protocol (SIP) "Replaces" Header", RFC 3891,
824 September 2004.
826 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
827 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
829 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
830 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
831 May 2008.
833 Authors' Addresses
835 Alan Johnston
836 Avaya
837 St. Louis, MO 63124
839 Email: alan.b.johnston@gmail.com
840 James Rafferty
841 Human Communications
842 Norfolk, MA 02056
844 Email: jay@humancomm.com