idnits 2.17.1
draft-ietf-cuss-sip-uui-05.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 :
----------------------------------------------------------------------------
** There are 11 instances of too long lines in the document, the longest
one being 1 character in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 677 has weird spacing: '...ats and codes...'
== The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
does not include the phrase in its RFC 2119 key words list.
-- The document date (March 12, 2012) is 4428 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 526, but not defined
== Unused Reference: 'ETSI' is defined on line 683, but no explicit
reference was found in the text
== Unused Reference: 'RFC3324' is defined on line 724, but no explicit
reference was found in the text
** Downref: Normative reference to an Informational RFC: RFC 3324
** Downref: Normative reference to an Informational RFC: RFC 3325
** Downref: Normative reference to an Informational draft:
draft-ietf-cuss-sip-uui-reqs (ref. 'I-D.ietf-cuss-sip-uui-reqs')
** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224)
== Outdated reference: A later version (-12) exists of
draft-ietf-sipcore-rfc4244bis-06
Summary: 5 errors (**), 0 flaws (~~), 7 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: September 13, 2012 Dialogic
6 March 12, 2012
8 A Mechanism for Transporting User to User Call Control Information in
9 SIP
10 draft-ietf-cuss-sip-uui-05
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 certain 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 September 13, 2012.
42 Copyright Notice
44 Copyright (c) 2012 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. Source Identity of UUI data . . . . . . . . . . . . . . . 6
65 5. Guidelines for UUI Packages . . . . . . . . . . . . . . . . . 8
66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
67 6.1. Registration of User-to-User Header Field . . . . . . . . 10
68 6.2. Registration of User-to-User Header Field Parameters . . . 10
69 6.3. Registration of UUI Packages . . . . . . . . . . . . . . . 10
70 6.4. Registration of UUI Content Parameters . . . . . . . . . . 11
71 6.5. Registration of UUI Encoding Parameters . . . . . . . . . 11
72 6.6. Registration of SIP Option Tag . . . . . . . . . . . . . . 11
73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
74 8. Appendix - Other Possible Mechanisms . . . . . . . . . . . . . 12
75 8.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 12
76 8.2. Why Other Protocol Encapsulation UUI Mechanisms are
77 Not Used . . . . . . . . . . . . . . . . . . . . . . . . . 13
78 8.3. MIME body Approach . . . . . . . . . . . . . . . . . . . . 13
79 8.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 14
80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
82 10.1. Informative References . . . . . . . . . . . . . . . . . . 15
83 10.2. Normative References . . . . . . . . . . . . . . . . . . . 16
84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
86 1. Overview
88 This document describes the transport of User to User Information
89 (UUI) data using SIP [RFC3261]. A mechanism is defined for the
90 transport of general application UUI data and for the transport of
91 call control related ITU-T Q.931 User to User Information Element (UU
92 IE) [Q931] and ITU-T Q.763 User to User Information Parameter [Q763]
93 data in SIP. UUI data is widely used in the PSTN today for contact
94 centers and call centers. There is also a trend for the related
95 applications to transition from ISDN to SIP. The UUI extension for
96 SIP may also be used for native SIP UAs implementing similar services
97 and to interwork with ISDN services. Note that in most cases, there
98 is an a priori understanding between the UAs in regard to what to do
99 with received UUI data.
101 This mechanism was designed to meet the use cases, requirements, and
102 call flows for SIP call control UUI detailed in
103 [I-D.ietf-cuss-sip-uui-reqs]. All references to requirement numbers
104 (REQ-N) and figure numbers refer to this document.
106 The mechanism is a new SIP header field, along with a new SIP option
107 tag. The header field carries the UUI data, along with parameters
108 indicating the encoding of the UUI data, the UUI package, and
109 optionally the content of the UUI data. The package definition
110 contains details about how a particular application can utilize the
111 UUI mechanism. The header field can be included (sometimes called
112 "escaped") into URIs supporting referral and redirection scenarios.
113 In these scenarios, History-Info is used to indicate the inserter of
114 the UUI data. The SIP option tag can be used to indicate support for
115 the header field. Support for the UUI header field indicates that a
116 UA is able to extract the information in the UUI data and pass it up
117 the protocol stack. Individual packages using the UUI mechanism can
118 utlize SIP media feature tags to indicate that a UA supports a
119 particular UUI package. Guidelines for defining UUI packages are
120 provided.
122 2. Terminology
124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
126 document are to be interpreted as described in BCP 14, RFC 2119
127 [RFC2119].
129 3. Requirements Discussion
131 This section describes how the User-to-User header field meets the
132 requirements in [I-D.ietf-cuss-sip-uui-reqs]. The header field can
133 be included in INVITE requests and responses and BYE requests and
134 responses, meeting REQ-1 and REQ-2.
136 For redirection and referral use cases and REQ-3, the header field
137 shall be included (escaped) into the Contact or Refer-To URI.
138 Currently, UAs that support attended transfer support the ability to
139 include a Replaces header field into a Refer-To URI, and when acting
140 upon this URI add the Replaces header field to the triggered INVITE.
141 This logic and behavior is identical for the UUI header field. The
142 UA processing the REFER or the 3xx to the INVITE will need to support
143 the UUI mechanism, as UAs in general do not process unknown included
144 header fields.
146 Since SIP proxy forwarding and retargeting does not affect header
147 fields, the header field meets REQ-4.
149 The UUI header field will carry the UUI data and not a pointer to the
150 data, so REQ-5 is met.
152 Since the basic design of the UUI header field is similar to the ISDN
153 UUI service, interworking with PSTN protocols will be straightforward
154 and will be documented in a separate specification, meeting REQ-6.
156 Requirements REQ-7, REQ-8, and REQ-10 relate to discovery of the
157 mechanism and supported packages, and hence applications. REQ-7
158 relates to support of the UUI header field, while REQ-8 relates to
159 routing based on support of the UUI header field. REQ-7 is met by
160 defining a new SIP option tag 'uui'. The use of a Require:uui in a
161 request, or Supported:uui in an OPTIONS response could be used to
162 require or discover support of the mechanism. The presence of a
163 Supported:uui or Require:uui header field can be used by proxies to
164 route to an appropriate UA, meeting REQ-8. However, note that only
165 UAs are expected to understand the UUI data - proxies and other
166 intermediaries do not. REQ-10 is met by utlizing SIP feature tags
167 [RFC3840]. For example, the feature tag 'sip.uui-isdn' could be used
168 to indicate support of the ISDN UUI package, or 'sip.uui-pk1' could
169 be used to indicate support for a particular package, pk1.
171 Proxies commonly apply policy to the presence of certain SIP header
172 fields in requests by either passing them or removing them from
173 requests. REQ-9 is met by allowing proxies and other intermediaries
174 to remove UUI header fields in a request or response based on policy.
176 Carrying UUI data elements of at least 129 octets is trivial in the
177 UUI header field, meeting REQ-11. Note that very large UUI data
178 elements should be avoided, as SIP header fields have traditionally
179 not been large.
181 To meet REQ-12 for the redirection and referral use cases, History-
182 Info [I-D.ietf-sipcore-rfc4244bis] can be used. In these retargeting
183 cases, the changed Request-URI will be recorded in the History-Info
184 header field along with the identity of the element that performed
185 the retargeting.
187 The requirement for integrity protection in REQ-13 could be met by
188 the use of an S/MIME signature over a subset of header fields, as
189 defined in Section 23.4 of RFC 3261 "SIP Header Privacy and Integrity
190 using S/MIME: Tunneling SIP". The requirement of REQ-14 for end-to-
191 end privacy could be met using S/MIME or using encryption at the
192 application layer. Note that the use of S/MIME to secure the UUI
193 data will result in an additional body being added to the request.
194 Hopwise TLS allows the header field to meet REQ-15 for hop-by-hop
195 security.
197 4. Normative Definition
199 This document defines a new SIP header field "User-to-User" to
200 transport call control UUI data to meet the requirements in
201 [I-D.ietf-cuss-sip-uui-reqs].
203 To help tag and identify the UUI data used with this header field,
204 "package", "content", and "encoding" parameters are defined. The
205 "package" parameter identifies the package which defines the
206 generation and usage of the UUI data for a particular application.
207 For the case of interworking with the ISDN UUI Service, the ISDN UUI
208 Service interworking package is used. If the "package" parameter is
209 not present, interworking with the ISDN UUI Service MUST be assumed.
210 The "content" parameter identifies the actual content of the UUI
211 data. If not present, the content MUST be assumed to be unknown as
212 it is in the ISDN UUI Service. Newly defined UUI packages MUST
213 define a new "content" value. The "encoding" parameter indicates the
214 method of encoding the information in the UUI data. This
215 specification only defines "encoding=hex". If the "encoding"
216 parameter is not present, "hex" MUST be assumed.
218 UUI data is considered an opaque series of octets. This mechanism
219 SHOULD NOT be used to convey a URL or URI; the Call-Info header field
220 [RFC3261] is used for this purpose.
222 4.1. Syntax for UUI Header Field
224 The User-to-User header field can be present in INVITE requests and
225 responses only and in BYE requests and responses. Note that only
226 end-to-end responses can be used, e.g. 1xx (excluding 100), 2xx, and
227 3xx responses.
229 The following syntax specification uses the augmented Backus-Naur
230 Form (BNF) as described in RFC 5234 and extends RFC 3261.
232 UUI = "User-to-User" HCOLON uui-value *(COMMA uui-value)
233 uui-value = uui-data *(SEMI uui-param)
234 uui-data = token / quoted-string
235 uui-param = pkg-param / cont-param / enc-param / generic-param
236 pkg-param = "package" EQUAL token
237 cont-param = "content" EQUAL token
238 enc-param = "encoding" EQUAL ("hex" / token)
240 The rules for how many User-to-User header field of each package may
241 be present in a request or a response are defined for each package.
242 The syntax allows any combination of individual User-to-User header
243 fields or User-to-User header fields with multiple comma separated
244 UUI data elements. Multiple User-to-User header fields MAY be
245 present in a request or response. Any size limitations on the UUI
246 data for a particular purpose must be defined by the related UUI
247 package.
249 UAs SHOULD ignore UUI data from packages or encoding that they do not
250 understand.
252 If an element supports this specification, it SHOULD include any UUI
253 data included in a redirection URI. Note that redirection can occur
254 multiple times to a request.
256 Here is an example of an included User-to-User header field from the
257 redirection response F2 of Figure 3:
259
260 Contact:
263
265 The resulting INVITE F5 would contain:
267 User-to-User: 56a390f3d2b7310023a;encoding=hex;purpose=foo;content=bar
269 4.2. Source Identity of UUI data
271 It is important for the recipient of UUI data to know the identity of
272 the UA that inserted the UUI data. In a request without a History-
273 Info [I-D.ietf-sipcore-rfc4244bis] header field, the identity of the
274 entity which inserted the UUI data will be assumed to be the source
275 of the SIP message. For a SIP request, typically this is the UA
276 identified by the URI in the From header field or a P-Asserted-
277 Identity [RFC3325] header field. In a request with a History-Info
278 header field, the recipient needs to parse the Targeted-to-URIs
279 present (hi-targeted-to-uri) to see if any included User-to-User
280 header fields are present. If an included User-to-User header field
281 is present and matches the UUI data in the request, this indicates
282 that redirection has taken place, resulting in the inclusion of UUI
283 data in the request. The inserter of the UUI data will be the UA
284 identified by the Targeted-to-URI of the History-Info element prior
285 to the element with the included UUI data. In a response, the
286 inserter of the UUI data will be the identity of the UA that
287 generated the response. Typically, this is the UA identified in the
288 To header field of the response. Note that any updates to this
289 identity by use of the SIP Connected Identity extension [RFC4916] or
290 others will update this information.
292 For an example of History-Info and redirection, consider Figure 2
293 from [I-D.ietf-cuss-sip-uui-reqs] where the Originating UA is Carol,
294 the Redirector Bob, and the Terminating UA Alice. The INVITE F4
295 containing UUI data could be:
297 INVITE sips:alice@example.com SIP/2.0
298 Via: SIP/2.0/TLS lab.example.com:5061
299 ;branch=z9hG4bKnashds9
300 To: Bob
301 From: Carol ;tag=323sf33k2
302 Call-ID: dfaosidfoiwe83ifkdf
303 Max-Forwards: 70
304 Contact:
305 Supported: histinfo
306 User-to-User: 342342ef34;encoding=hex
307 History-Info: ;index=1
308
309 History-Info: ;index=1.1;rc=1
311
313 Without the redirection captured in the History-Info, Alice would
314 conclude the UUI data was inserted by Carol. However, the History-
315 Info containing UUI data (index=1.1) indicates that the inserter was
316 Bob (index=1).
318 Note that the tag convention from SIP Torture Test
319 Messages [RFC4475] is used to show that there are no line breaks in
320 the actual message syntax.
322 To enable maintaining a record of the inserter identity of UUI data,
323 UAs supporting this mechanism SHOULD support History-Info
324 [I-D.ietf-sipcore-rfc4244bis] and include Supported: histinfo in all
325 requests and responses.
327 5. Guidelines for UUI Packages
329 UUI packages defined using this SIP UUI mechanism MUST publish a
330 standards track RFC which describes the usage. Note that this
331 mechanism is not suitable for the transport of arbitrary data between
332 UAs. The following guidelines are provided to help determine if this
333 mechanism is appropriate or some other SIP mechanism should be used.
334 The SIP UUI mechanism is applicable when all of the following
335 conditions be met:
337 1. The information is generated and consumed by an application
338 during session setup using SIP, but the application is not
339 necessarily SIP aware.
341 2. The behavior of SIP entities that support it is not
342 significantly changed (as discussed in Section 4 of [RFC5727]).
344 3. User Agents (UAs) are the generators and consumers of the UUI
345 data. Proxies and other intermediaries may route based on the
346 presence of a User-to-User header field or a particular package
347 tag but do not otherwise consume or generate the UUI data.
349 4. There are no overriding privacy issues associated with the
350 information being transported (e.g., geolocation or emergency-
351 related information are examples of inappropriate UUI data).
353 5. The UUI data is not being utilized for user-to-user Remote
354 Procedure Call (RPC) calls.
356 UUI packages define the semantics for a particular application usage
357 of UUI data. The content defines the syntax of the UUI data, while
358 the encoding defines the encoding of the UUI data. Each content is
359 defined as a stream of octets, which allows multiple encodings of
360 that content. For example, packages may define:
362 1. The SIP methods and responses in which the UUI data may be
363 present.
365 2. The maximum number of UUI data elements that may be inserted
366 into a request or response. (The default is one per encoding.)
367 Note that a UA may still receive a request with more than this
368 maximum number due to redirection. The package must define how to
369 handle this situation.
371 3. The default values for content and encoding if they are not
372 present. If the same UUI data may be inserted multiple times with
373 different encodings, the packages must state this. A package may
374 support and define multiple encodings and contents, and reuse
375 encodings and contents defined by other packages.
377 4. Any size limitations on the UUI data. Size should be
378 specified in terms of the octet stream output of the content,
379 since the size of the resulting uui-data element will vary
380 depending on the encoding scheme.
382 New "package" values MUST describe the new application which is
383 utilizing the UUI data and provide some use case examples. The
384 default "content" value and other allowed contents MUST be defined or
385 referenced in another document for the package. Any restrictions on
386 the size of the UUI data must be described. In addition, a package
387 may define a Media Feature tag per RFC 3840 [RFC3840] to indicate
388 support for this UUI package. For example, the media feature tag
389 sip.uui-pk1 could be defined to indicate support for a UUI package
390 named pk1. The definition of a new SIP option tag solely to identify
391 support for a UUI package is NOT RECOMMENDED unless there are
392 additional SIP behaviors needed to implement this feature.
394 For an example UUI package definition, see
395 [I-D.drage-cuss-sip-uui-isdn].
397 This specification defines only the value of "hex" for the "encoding"
398 parameter. Hex encoding, as used for UUI data is defined to use only
399 the characters 0-9, A-F, or a-f. Hex encoded UUI data MUST have an
400 even number of octets, and is considered invalid if has an odd
401 number. Hex encoding is normally done as a token, although quoted-
402 string is permitted, in which case the quotes are ignored. Hex
403 encoding yields a sequence of octets, one octet per two hex digits,
404 in the same order, with the first digit of each pair defining the
405 high order four bits of the octet and the second digit providing the
406 low order four bits.
408 New "encoding" values MUST reference a common encoding scheme or
409 define the exact new encoding scheme. New values can be defined and
410 added to the IANA registry with a standards track RFC, which needs to
411 discuss the issues in this section.
413 New "content" values MUST describe the content of the UUI data and
414 give some example use cases. The default "encoding" and other
415 allowed encoding methods must be defined for this new content. Note
416 that a content value can be used by multiple UUI packages. In this
417 case, the semantics and usage of the content is defined by the
418 package.
420 6. IANA Considerations
422 6.1. Registration of User-to-User Header Field
424 This document defines a new SIP header field named "User-to-User".
426 The following row shall be added to the "Header Fields" section of
427 the SIP parameter registry:
429 +------------------+--------------+-----------+
430 | Header Name | Compact Form | Reference |
431 +------------------+--------------+-----------+
432 | User-to-User | | [RFCXXXX] |
433 +------------------+--------------+-----------+
435 Editor's Note: [RFCXXXX] should be replaced with the designation of
436 this document.
438 6.2. Registration of User-to-User Header Field Parameters
440 This document defines the parameters for the header field defined in
441 the preceding section. The header field "User-to-User" can contain
442 the parameters "encoding", "content", and "package".
444 The following rows shall be added to the "Header Field Parameters and
445 Parameter Values" section of the SIP parameter registry:
447 +------------------+----------------+-------------------+-----------+
448 | Header Field | Parameter Name | Predefined Values | Reference |
449 +------------------+----------------+-------------------+-----------+
450 | User-to-User | encoding | hex | [RFCXXXX] |
451 +------------------+----------------+-------------------+-----------+
452 | User-to-User | content | | [RFCXXXX] |
453 +------------------+----------------+-------------------+-----------+
454 | User-to-User | package | | [RFCXXXX] |
455 +------------------+----------------+-------------------+-----------+
457 Editor's Note: [RFCXXXX] should be replaced with the designation of
458 this document.
460 6.3. Registration of UUI Packages
462 This specification establishes the uui-packages sub-registry under
463 http://www.iana.org/assignments/sip-parameters. New uui-packages
464 shall be registered by standards track RFC publication.
466 The descriptive text for the table of uui-content is:
468 UUI Packages provides information about the usage of the UUI data in
469 a User-to-User header field [RFCXXXX].
471 +------------+-------------------------------------------+-----------+
472 | Package | Description | Reference |
473 +------------+-------------------------------------------+-----------+
475 6.4. Registration of UUI Content Parameters
477 This specification establishes the uui-content sub-registry under
478 http://www.iana.org/assignments/sip-parameters. New uui-content
479 values shall be registered by standards track RFC publication.
481 The descriptive text for the table of uui-content is:
483 UUI Content provides information about the content of the UUI data in
484 a User-to-User header field [RFCXXXX].
486 +------------+-------------------------------------------+-----------+
487 | Content | Description | Reference |
488 +------------+-------------------------------------------+-----------+
490 6.5. Registration of UUI Encoding Parameters
492 This specification establishes the uui-encoding sub-registry under
493 http://www.iana.org/assignments/sip-parameters and initiates its
494 population with the table below. Additional uui-encoding values
495 shall be registered by a standards track RFC publication.
497 The descriptive text for the table of uui-encoding is:
499 UUI Encoding provides information about the encoding of the UUI data
500 in a User-to-User header field [RFCXXXX].
502 +------------+-------------------------------------------+-----------+
503 | Encoding | Description | Reference |
504 +------------+-------------------------------------------+-----------+
505 | hex | The UUI data is encoded using hexadecimal | |
506 +------------+-------------------------------------------+-----------+
508 6.6. Registration of SIP Option Tag
510 This specification registers a new SIP option tag, as per the
511 guidelines in Section 27.1 of [RFC3261].
513 This document defines the SIP option tag "uui".
515 The following row has been added to the "Option Tags" section of the
516 SIP Parameter Registry:
518 +------------+------------------------------------------+-----------+
519 | Name | Description | Reference |
520 +------------+------------------------------------------+-----------+
521 | uui | This option tag is used to indicate that | [RFCXXXX] |
522 | | a UA supports and understands the | |
523 | | User-to-User header field. | |
524 +------------+------------------------------------------+-----------+
526 Editor's Note: [RFCXXXX] should be replaced with the designation of
527 this document.
529 7. Security Considerations
531 User to user information can potentially carry sensitive information
532 that might require privacy or integrity protection. Standard
533 deployed SIP security mechanisms such as TLS transport, offer these
534 properties on a hop-by-hop basis. To preserve multi-hop or end-to-
535 end confidentiality and integrity of UUI data, approaches using
536 S/MIME or IPSec can be used, as discussed in the draft. However, the
537 lack of deployment of these mechanisms means that applications can
538 not in general rely on them. As such, applications are encouraged to
539 utilize their own security mechanisms.
541 If the UUI data was included by the UA originator of the SIP request
542 or response, normal SIP mechanisms can be used to determine the
543 identity of the inserter of the UUI data. If the UUI data was
544 included by a UA that was not the originator of the request, History-
545 Info can be used to determine the indentity of the inserter of the
546 UUI data. UAs can apply policy based on the origin of the UUI data
547 using this information.
549 8. Appendix - Other Possible Mechanisms
551 Two other possible mechanisms for transporting UUI data will be
552 described: MIME body and URI parameter transport.
554 8.1. Why INFO is Not Used
556 Since the INFO method [RFC6086], was developed for ISUP interworking
557 of user-to-user information, it might seem to be the logical choice
558 here. For non-call control user-to-user information, INFO can be
559 utilized for end to end transport. However, for transport of call
560 control user-to-user information, INFO can not be used. As the call
561 flows in [I-D.ietf-cuss-sip-uui-reqs] show, the information is
562 related to an attempt to establish a session and must be passed with
563 the session setup request (INVITE), responses to that INVITE, or
564 session termination requests. As a result, it is not possible to use
565 INFO in these cases.
567 8.2. Why Other Protocol Encapsulation UUI Mechanisms are Not Used
569 Other protocols have the ability to transport UUI data. For example,
570 consider the ITU-T Q.931 User to User Information Element (UU IE)
571 [Q931] and the ITU-T Q.763 User to User Information Parameter [Q763].
572 In addition, NSS (Narrowband Signaling System) [Q1980] is also able
573 to transport UUI data. Should one of these protocols be in use, and
574 present in both User Agents, then utilizing these other protocols to
575 transport UUI data might be a logical solution. Essentially, this is
576 just adding an additional layer in the protocol stack. In these
577 cases, SIP is not transporting the UUI data; it is encapsulating
578 another protocol, and that protocol is transporting the UUI data.
579 Once a mechanism to transport that other protocol using SIP exists,
580 the UUI data transport function is essentially obtained without any
581 additional effort or work.
583 However, the authors believe that SIP needs to have its own native
584 UUI data transport mechanism. It is not reasonable for a SIP UA to
585 have to implement another entire protocol (either ISDN or NSS, for
586 example) just to get the very simple UUI data transport service. Of
587 course, this work does not preclude anyone from using other protocols
588 with SIP to transport UUI data.
590 8.3. MIME body Approach
592 One method of transport is to use a MIME body. This is in keeping
593 with the SIP-T architecture [RFC3372] in which MIME bodies are used
594 to transport ISUP information. Since the INVITE will normally have
595 an SDP message body, the resulting INVITE with SDP and UUI data will
596 be multipart MIME. This is not ideal as many SIP UAs do not support
597 multipart MIME INVITEs.
599 A bigger problem is the insertion of a UUI message body by a redirect
600 server or in a REFER. The body would need to be encoded in the
601 Contact URI of the 3xx response or the Refer-To URI of a REFER.
602 Currently, the authors are not aware of any UAs that support this
603 capability today for any body type. As such, the complete set of
604 semantics for this operation would need to be determined and defined.
605 Some issues will need to be resolved, such as, do all the Content-*
606 header fields have to be included as well? And, what if the included
607 Content-Length does not agree with the included body?
609 Since proxies cannot remove a body from a request or response, it is
610 not clear how this mechanism could meet REQ-9.
612 The requirement for integrity protection could be met by the use of
613 an S/MIME signature over the body, as defined in Section 23.3 of RFC
614 3261 "Securing MIME bodies". Alternatively, this could be achieved
615 using RFC 4474 [RFC4474]. The requirement for end-to-end privacy
616 could be met using S/MIME encryption or using encryption at the
617 application layer. However, note that neither S/MIME or RFC 4474
618 enjoys deployment in SIP today.
620 An example:
622
623 Contact:
625
627 As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5,
628 REQ-7, REQ-11, REQ-13, and REQ-14. Meeting REQ-12 seems possible,
629 although the authors do not have a specific mechanism to propose.
630 Meeting REQ-3 is problematic, but not impossible for this mechanism.
631 However, this mechanism does not seem to be able to meet REQ-9.
633 8.4. URI Parameter
635 Another proposed approach is to encode the UUI data as a URI
636 parameter. This UUI parameter could be included in a Request-URI or
637 in the Contact URI or Refer-To URI. It is not clear how it could be
638 transported in a responses which does not have a Request-URI, or in
639 BYE requests or responses.
641
642 Contact:
644
646 An INVITE sent to this Contact URI would contain UUI data in the
647 Request-URI of the INVITE. The URI parameter has a drawback in that
648 a URI parameter carried in a Request-URI will not survive retargeting
649 by a proxy as shown in Figure 2 of [I-D.ietf-cuss-sip-uui-reqs].
650 That is, if the URI is included with an Address of Record instead of
651 a Contact URI, the URI parameter in the Reqeuest-URI will not be
652 copied over to the Contact URI, resulting in the loss of the
653 information. Note that if this same URI was present in a Refer-To
654 header field, the same loss of information would occur.
656 The URI parameter approach would meet REQ-3, REQ-5, REQ-7, REQ-9, and
657 REQ-11. It is possible the approach could meet REQ-12 and REQ-13.
659 The mechanism does not appear to meet REQ-1, REQ-2, REQ-4, and
660 REQ-14.
662 9. Acknowledgements
664 Joanne McMillen was a major contributor and co-author of earlier
665 versions of this document. Thanks to Paul Kyzivat for his
666 contribution of hex encoding rules. Thanks to Spencer Dawkins, Keith
667 Drage, Vijay Gurbani, and Laura Liess for their review of the
668 document. The authors wish to thank Francois Audet, Denis
669 Alexeitsev, Paul Kyzivat, Cullen Jennings, and Mahalingam Mani for
670 their comments.
672 10. References
674 10.1. Informative References
676 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part
677 formats and codes",
678 http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
680 [Q931] "ITU-T Q.931 User to User Information Element (UU IE)",
681 http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
683 [ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services
684 Digital Network (ISDN); Diversion supplementary
685 services".
687 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
688 for Telephones (SIP-T): Context and Architectures",
689 BCP 63, RFC 3372, September 2002.
691 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session
692 Initiation Protocol (SIP) INFO Method and Package
693 Framework", RFC 6086, January 2011.
695 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
696 and H. Schulzrinne, "Session Initiation Protocol (SIP)
697 Torture Test Messages", RFC 4475, May 2006.
699 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process
700 for the Session Initiation Protocol (SIP) and the Real-
701 time Applications and Infrastructure Area", BCP 67,
702 RFC 5727, March 2010.
704 [I-D.drage-cuss-sip-uui-isdn]
705 Drage, K. and A. Johnston, "Interworking ISDN Call Control
706 User Information with SIP",
707 draft-drage-cuss-sip-uui-isdn-01 (work in progress),
708 September 2011.
710 [Q1980] "ITU-T Q.1980.1 The Narrowband Signalling Syntax (NSS) -
711 Syntax Definition", http://www.itu.int/itudoc/itu-t/aap/
712 sg11aap/history/q1980.1/q1980.1.html .
714 10.2. Normative References
716 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
717 Requirement Levels", BCP 14, RFC 2119, March 1997.
719 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
720 A., Peterson, J., Sparks, R., Handley, M., and E.
721 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
722 June 2002.
724 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted
725 Identity", RFC 3324, November 2002.
727 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
728 Extensions to the Session Initiation Protocol (SIP) for
729 Asserted Identity within Trusted Networks", RFC 3325,
730 November 2002.
732 [I-D.ietf-cuss-sip-uui-reqs]
733 Johnston, A. and L. Liess, "Problem Statement and
734 Requirements for Transporting User to User Call Control
735 Information in SIP", draft-ietf-cuss-sip-uui-reqs-09 (work
736 in progress), January 2012.
738 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
739 Authenticated Identity Management in the Session
740 Initiation Protocol (SIP)", RFC 4474, August 2006.
742 [I-D.ietf-sipcore-rfc4244bis]
743 Holmberg, C., Audet, F., Barnes, M., Elburg, H., and S.
744 Schubert, "An Extension to the Session Initiation Protocol
745 (SIP) for Request History Information",
746 draft-ietf-sipcore-rfc4244bis-06 (work in progress),
747 October 2011.
749 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation
750 Protocol (SIP)", RFC 4916, June 2007.
752 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
753 "Indicating User Agent Capabilities in the Session
754 Initiation Protocol (SIP)", RFC 3840, August 2004.
756 Authors' Addresses
758 Alan Johnston
759 Avaya
760 St. Louis, MO 63124
762 Email: alan.b.johnston@gmail.com
764 James Rafferty
765 Dialogic
767 Email: james.rafferty@dialogic.com