idnits 2.17.1
draft-johnston-sipping-cc-uui-07.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 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 seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (February 12, 2009) is 5550 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'RFCXXXX' is mentioned on line 635, but not defined
-- Obsolete informational reference (is this intentional?): RFC 2976
(Obsoleted by RFC 6086)
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SIPPING WG A. Johnston, Ed.
3 Internet-Draft J. McMillen
4 Intended status: Informational Avaya
5 Expires: August 16, 2009 February 12, 2009
7 Transporting User to User Call Control Information in SIP for ISDN
8 Interworking
9 draft-johnston-sipping-cc-uui-07
11 Status of this Memo
13 This Internet-Draft is submitted to IETF in full conformance with the
14 provisions of BCP 78 and BCP 79.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that
18 other groups may also distribute working documents as Internet-
19 Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt.
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 This Internet-Draft will expire on August 16, 2009.
34 Copyright Notice
36 Copyright (c) 2009 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (http://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document.
46 Abstract
48 Several approaches to transporting the ITU-T Q.931 User to User
49 Information Element (UU IE) data in SIP have been proposed. As
50 networks move to SIP it is important that applications requiring this
51 data can continue to function in SIP networks as well as the ability
52 to interwork with this ISDN service for end-to-end transparency.
53 This document discusses requirements and approaches and recommends a
54 new header field be standardized. This extension will also be used
55 for native SIP endpoints implementing similar services and
56 interworking with ISDN services. Example use cases include an
57 exchange between two user agents, retargeting by a proxy, and
58 redirection. An example application is an Automatic Call Distributor
59 (ACD) in a contact center.
61 Table of Contents
63 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
65 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
66 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
67 4.1. User Agent to User Agent . . . . . . . . . . . . . . . . . 5
68 4.2. Proxy Retargeting . . . . . . . . . . . . . . . . . . . . 6
69 4.3. Redirection . . . . . . . . . . . . . . . . . . . . . . . 6
70 4.4. Referral . . . . . . . . . . . . . . . . . . . . . . . . . 8
71 5. Possible Mechanisms . . . . . . . . . . . . . . . . . . . . . 9
72 5.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 9
73 5.2. MIME body Approach . . . . . . . . . . . . . . . . . . . . 10
74 5.3. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 10
75 5.4. Header Field Approach . . . . . . . . . . . . . . . . . . 11
76 6. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
77 7. Appendix - Syntax for UUI Header Field . . . . . . . . . . . . 12
78 7.1. IANA Considerations . . . . . . . . . . . . . . . . . . . 13
79 7.1.1. Registration of Header Field . . . . . . . . . . . . . 13
80 7.1.2. Registration of Header Field Parameter . . . . . . . . 14
81 7.1.3. Registration of SIP Option Tag . . . . . . . . . . . . 14
82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
84 10. Informative References . . . . . . . . . . . . . . . . . . . . 15
85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
87 1. Overview
89 This document describes the transport of User to User Information
90 (UUI) in ISDN interworking scenarios using SIP [RFC3261].
91 Specifically, we discuss the transport of call control related ITU-T
92 Q.931 User to User Information Element (UU IE) [Q931] and ITU-T Q.763
93 User to User Information Parameter [Q763] data in SIP. UUI is widely
94 used in the PSTN today in contact centers and call centers which are
95 transitioning away from ISDN to SIP. This extension will also be
96 used for native SIP endpoints implementing similar services and
97 interworking with ISDN services.
99 Part of the definition of this ISDN service is that the UUI
100 information is not known and understood by the ISDN network that
101 transports it. This is for two reasons. Firstly, this supports a
102 strict layering of protocols and data. Providing information and
103 understanding of the data to the transport layer would not provide
104 any benefits and instead could create cross layer coupling and
105 increase the complexity of the system. Secondly, either the
106 originator or terminator of the service might be a simple PSTN
107 gateway designed for scalability and lowest cost. As a result, it is
108 neither feasible nor desirable for this device to understand the
109 information but instead the goal is to pass the information as
110 efficiently as possible to another application which does understand
111 the data. Both of these arguments still apply to SIP, especially
112 when one or both endpoints are gateways.
114 In the future, where both endpoints are intelligent SIP user agents,
115 it may be possible for them to understand and interpret the UUI data.
116 There may be some cases where the UUI information is relevant to SIP.
117 In this case, it might be worthwhile attempting to map UUI data to an
118 appropriate SIP header field or to standardize a new header field.
119 However, the requirements and use cases for this are different enough
120 from those described in this document that these two situations
121 should be examined separately. This document looks only at the
122 requirements and mechanisms for replicating the existing, widely used
123 and deployed ISDN UUI service.
125 First, the requirements are discussed with use cases. Five different
126 use case call flows are discussed. Then, three mechanisms are
127 discussed and compared. The Appendix contains a header field
128 definition which meets all the requirements.
130 2. Terminology
132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
134 document are to be interpreted as described in BCP 14, RFC 2119
135 [RFC2119].
137 3. Requirements
139 This section discusses the requirements for the transport of call
140 control related user to user information (UUI). We define call
141 control UUI as information that is generated, transported, and
142 consumed at the time of call setup (i.e. during a pending INVITE
143 transaction). The information can be used for call routing,
144 alerting, call distribution, or simply rendering. The exact usage
145 and semantics of call control UUI is out of scope - SIP is simply
146 providing the transport function for this, in the same manner as ISDN
147 Provides in the PSTN. Non-call control UUI can be sent using the
148 INFO method and not using the extensions described in this
149 specification.
151 REQ-1: The mechanism will allow user agents (UAs) to insert and
152 receive ITU-T Q.931 User to User Information Element and Q.763 User
153 to User Information Parameter (referred to as UUI) data in SIP call
154 setup requests and responses.
156 SIP messages covered by this include INVITE requests and end-to-
157 end responses to the INVITE, which includes 18x and 200 responses.
159 REQ-2: The mechanism will allow UAs to insert and receive ITU-T Q.931
160 User to User Information Element (referred to as UUI) data in SIP
161 call teardown requests and responses.
163 Q.931 UUI supports inclusion in release and release completion
164 messages. SIP messages covered by this include BYE and 200 OK
165 responses to a BYE.
167 REQ-3: The mechanism will allow UUI to be inserted and retrieved in
168 SIP redirects to INVITEs.
170 SIP messages covered by this include 3xx responses to INVITE and
171 REFER requests.
173 REQ-4: The mechanism will allow UUI to be able to survive proxy
174 retargeting.
176 Retargeting is a common method of call routing in SIP, and must
177 not result in the loss of user to user information.
179 REQ-5: The mechanism should not require processing entities to
180 dereference a URL to retrieve the UUI information.
182 Passing a pointer or link to the UUI information will not meet the
183 real-time processing considerations and will complicate
184 interworking with the PSTN.
186 REQ-6: The mechanism will minimize reliance on SIP extensions or
187 uncommon SIP behavior.
189 REQ-7: The mechanism will allow the inserter of UUI to be sure that
190 the recipient understands the call control UUI mechanism.
192 Understanding the mechanism means that the UAS will extract and
193 utilize the UUI information transported. Understanding the
194 protocol, format, and nature of the actual UUI data is not covered
195 by this requirement. Note that this requirement is not strictly
196 needed to implement the UUS 1 implicit service, but maps more
197 accurately to the UUS 1 explicit service. However, having an
198 option tag is good design for high reliability systems, and the
199 dynamic and heterogeneous nature of SIP interconnection (as
200 opposed to the PSTN's static trunking) makes this option tag much
201 more important and hence relevant to even the UUS 1 implicit
202 service.
204 4. Use Cases
206 This section discusses four use cases for the transport of call
207 control related user to user information. What is not discussed here
208 is the transport of non-call control UUI which can be done using the
209 SIP INFO method. These use cases help explain the requirements from
210 the previous section.
212 4.1. User Agent to User Agent
214 In this scenario, the originator UA includes UUI in the INVITE sent
215 through a proxy to the terminating UA. The terminator can use the
216 UUI in any way. If it is an ISDN gateway, it could map the UUI into
217 the appropriate Q.931 or Q.763 element. Alternatively, it might
218 render the information to the user, or use it for alerting or as a
219 lookup for a screen pop. In this case, the proxy does not need to
220 understand the UUI mechanism, but normal proxy rules should result in
221 the UUI being forwarded without modification. This call flow is
222 shown in Figure 1.
224 Originator Proxy Terminator
225 | | |
226 | INVITE (UUI) F1 | |
227 |------------------->| INVITE (UUI) F2 |
228 | 100 Trying F3 |------------------->|
229 |<-------------------| 200 OK F4 |
230 | 200 OK F5 |<-------------------|
231 |<-------------------| |
232 | ACK F6 | |
233 |------------------->| ACK F7 |
234 | |------------------->|
236 Figure 1. Call flow with UUI exchanged between Originator and
237 Terminator.
239 This call flow utilizes REQ-1.
241 4.2. Proxy Retargeting
243 In this scenario, the originator UA includes UUI in the INVITE sent
244 through a proxy to the terminating UA. The proxy retargets the
245 INVITE, sending it to a different termination UA. The UUI
246 information is then received and processed by the terminating UA.
247 This call flow is shown in Figure 2.
249 Originator Proxy Terminator 2
250 | | |
251 | INVITE (UUI) F1 | |
252 |------------------->| INVITE (UUI) F2 |
253 | 100 Trying F3 |------------------->|
254 |<-------------------| 200 OK F4 |
255 | 200 OK F5 |<-------------------|
256 |<-------------------| |
257 | ACK F6 | |
258 |------------------->| ACK F7 |
259 | |------------------->|
261 Figure 2. Call flow with Proxy Retargeting.
263 This call flow utilizes REQ-1 and REQ-4.
265 4.3. Redirection
267 In this scenario, UUI is inserted by a redirect server. The UUI is
268 then included in the INVITE sent by the Originator to the Terminator.
269 In this case, the Originator does not necessarily need to support the
270 UUI mechanism but does need to support the SIP redirection mechanism
271 used to include the UUI information. Two examples of UUI with
272 redirection (transfer and diversion) are defined in [ANSII] and
273 [ETSI].
275 Note that this case may not precisely map to an equivalent ISDN
276 service use case. This is because there is no one-to-one mapping
277 between elements in a SIP network and elements in an ISDN network.
278 Also, there is not an exact one-to-one mapping between SIP call
279 control and ISDN call control.
281 In redirection scenarios, if the Redirect Server is not in the same
282 administrative domain as the Terminator, the Redirect Server MUST NOT
283 remove or replace any UUI in the initial INVITE. In Figure 3, this
284 means that if F1 included UUI, the Redirect Server could not modify
285 or replace the UUI in F2. However, if the Redirect Server and the
286 Terminator are part of the same administrative domain, they may have
287 a policy allowing the Redirect Server to modify or rewrite UUI
288 information. In fact, many UUI uses within an Enterprise rely on
289 this feature to work today in ISDN.
291 Originator Redirect Server Terminator
292 | | |
293 | INVITE F1 | |
294 |------------------->| |
295 | 302 Moved (UUI) F2 | |
296 |<-------------------| |
297 | ACK F3 | |
298 |------------------->| |
299 | INVITE (UUI) F4 | |
300 |---------------------------------------->|
301 | 200 OK F5 |
302 |<----------------------------------------|
303 | ACK F6 |
304 |---------------------------------------->|
306 Figure 3. Call flow with UUI exchanged between Redirect Server and
307 Terminator
309 This call flow utilizes REQ-1 and REQ-3.
311 A common application of this call flow is an Automatic Call
312 Distributer (ACD) in a PSTN contact center. The originator would be
313 a PSTN gateway. The ACD would act as a Redirect Server, inserting
314 UUI based on called number, calling number, time of day, and other
315 information. The resulting UUI would be passed to the agent's
316 handset which acts as the Terminator. The UUI could be used to
317 lookup information rendered to the agent at the time of call
318 answering.
320 4.4. Referral
322 In this scenario, a Referrer UA causes an INVITE to be generated
323 between the Originator and Terminator with UUI information inserted
324 by the Referrer UA. Note that this REFER [RFC3515] could be part of
325 a transfer operation or it might be unrelated to an existing call,
326 such as out-of-dialog REFER call control. In some cases, this call
327 flow is used in place of the redirection call flow, but where
328 immediately upon answer, the REFER is sent. This scenario is shown
329 in Figure 4.
331 Originator Referrer Terminator
332 | | |
333 | REFER (UUI) F1 | |
334 |<-------------------| |
335 | 202 Accepted F2 | |
336 |------------------->| |
337 | NOTIFY (100 Trying) F3 |
338 |------------------->| |
339 | 200 OK F4 | |
340 |<-------------------| |
341 | INVITE (UUI) F5 | |
342 |---------------------------------------->|
343 | 200 OK F6 |
344 |<----------------------------------------|
345 | ACK F7 |
346 |---------------------------------------->|
347 | NOTIFY (200 OK) F8 | |
348 |------------------->| |
349 | 200 OK F9 | |
350 |<-------------------| |
352 Figure 4. Call flow with transfer after answer.
354 Some scenarios involving referral have been proposed to use a REFER
355 sent during an early dialog. This NOT RECOMMENDED call flow is shown
356 in Figure 5. This flow is not recommended due to the number of
357 messages exchanged (due to the REFER, CANCEL, and 487 responses) and
358 the sending of the REFER in the early dialog. Also, there are race
359 conditions that can occur if a 200 OK to the INVITE is received by
360 the Originator while the REFER is in progress.
362 Originator Referrer Terminator
363 | | |
364 | INVITE F1 | |
365 |------------------->| |
366 | 180 Ringing F2 | |
367 |<-------------------| |
368 | REFER (UUI) F3 | |
369 |<-------------------| |
370 | 202 Accepted F4 | |
371 |------------------->| |
372 | NOTIFY (100 Trying) F5 |
373 |------------------->| |
374 | 200 OK F6 | |
375 |<-------------------| |
376 | INVITE (UUI) F7 | |
377 |---------------------------------------->|
378 | 200 OK F8 |
379 |<----------------------------------------|
380 | ACK F9 |
381 |---------------------------------------->|
382 | NOTIFY (200 OK) F10| |
383 |------------------->| |
384 | 200 OK F11 | |
385 |<-------------------| |
386 | CANCEL F12 | |
387 |------------------->| |
388 | 200 OK F13 | |
389 |<-------------------| |
390 | 487 Request Terminated F14 |
391 |<-------------------| |
392 | ACK F15 | |
393 |------------------->| |
395 Figure 5. NOT RECOMMENDED call flow showing REFER prior to answer.
397 5. Possible Mechanisms
399 Three possible mechanisms for transporting UUI will be described:
400 MIME body, URI parameter, and header field transport.
402 5.1. Why INFO is Not Used
404 Since the INFO method [RFC2976], was developed for ISUP interworking
405 of user-to-user information, it might seem to be the logical choice
406 here. For non-call control user-to-user information, INFO can be
407 utilized for end to end transport. However, for transport of call
408 control user-to-user information, INFO can not be used. As the call
409 flows in the previous section show, the information is related to an
410 attempt to establish a session and must be passed with the session
411 setup request (INVITE), responses to that INVITE, or session
412 termination requests. As a result, it is not possible to use INFO in
413 these cases.
415 5.2. MIME body Approach
417 One method of transport is to transport the UUI information as a MIME
418 body. This is in keeping with the SIP-T architecture [RFC3372] in
419 which MIME bodies are used to transport ISUP information. Since the
420 INVITE will normally have an SDP message body, the resulting INVITE
421 with SDP and UUI will be multipart MIME. The insertion of a UUI
422 message body by a redirect server or in a REFER is difficult. The
423 body would need to be encoded in the Contact URI of the 3xx response
424 or the Refer-To URI of a REFER. For example:
426
427 Contact:
429
431 Note that the tag convention from SIP Torture Test
432 Messages [RFC4475] is used to show that there are no line breaks in
433 the actual message syntax.
435 The MIME body approach meets REQs 1-5. However, it does not meet
436 REQ-6 as support for Multipart MIME and escaped bodies in URIs is
437 uncommon in SIP UAs.
439 5.3. URI Parameter
441 Another proposed approach is to encode the UUI as a URI parameter
442 into the Contact or Refer-To URI.
444
445 Contact:
447
449 An INVITE sent to this Contact URI would contain UUI in the Request-
450 URI of the INVITE. The URI parameter has a drawback in that a URI
451 parameter carried in a Request-URI will not survive retargeting by a
452 proxy as shown in Figure 2. That is, if the URI is included with an
453 Address of Record instead of a Contact URI, the URI parameter in the
454 Reqeuest-URI will not be copied over to the Contact URI, resulting in
455 the loss of the information. As a result, this approach does not
456 meet REQ-4. Note that if this same URI was present in a Refer-To
457 header field, the same loss of information would occur.
459 5.4. Header Field Approach
461 Another approach that has been proposed is to use a header field to
462 transport the UUI information. The header field would be included in
463 INVITE requests and responses and BYE requests and responses, and
464 would pass transparently through proxies. For redirection, the
465 header field would be escaped into the Contact or Refer-To URI. This
466 is commonly supported in UAs due to call transfer use cases. As a
467 result, the header field approach supports REQs 1-6. In order to
468 meet REQ-7, a SIP feature tag is needed which can be included in
469 Supported and Require header fields.
471 The Call-Info header field is related to the UUI information.
472 However, there are a number of important differences:
474 Call-Info is typically used for rendering to the user. While some
475 of the UUI information may ultimately be rendered to the user,
476 most of the UUI information will be consumed by the end device or
477 by an application server.
479 Call-Info usually contains a URI pointer to the information
480 instead of the actual information itself which does not meet
481 REQ-5. It could be possible to use a data URI to carry the UUI
482 directly in this header field.
484 The use of Call-Info for interworking to and from ISDN networks
485 seems problematic.
487 Overall, the overloading of the Call-Info header field for carrying
488 interworked UUI does not seem like a good idea. A separate header
489 field allows for clear policy and authorization rules to be used.
490 For these reasons, a separate header field needs to be defined,
491 described here as User-to-User. For example, here is an example
492 User-to-User header field from message F1 in Figure 1:
494 User-to-User: 56a390f3d2b7310023a;encoding=hex
496 For example, here is an escaped User-to-User header field from the
497 redirection response F2 of Figure 3:
499
500 Contact:
502
504 The resulting INVITE F5 would contain:
506 User-to-User: 56a390f3d2b7310023a;encoding=hex
508 An escaped User-to-User header field from the REFER message response
509 F1 of Figure 4:
511
512 Refer-To:
514
516 This would result in the INVITE F4 containing:
518 User-to-User: 56a390f3d2b7310023a;encoding=hex
520 6. Recommendation
522 The recommendation is to define a new SIP header field "User-to-User"
523 to transport UUI information in ISDN interworking applications since
524 this mechanism best supports the requirements. A SIP feature tag
525 "uui" also needs to be defined so that it can be used in Supported
526 and Require header fields to meet REQ-7.
528 The format of the UUI information is a topic of future
529 standardization. Currently, UUI is proprietary, requiring
530 coordinated configuration between servers. Standardizing the format
531 or providing content tags would provide additional benefits.
533 7. Appendix - Syntax for UUI Header Field
535 Editor's Note: Eventually this text will move to a SIP Working Group
536 document to define the new header field.
538 The User-to-User header field can be present in INVITE requests and
539 responses only and in BYE requests and responses.
541 Current usage is to interoperate with ISDN User to User Signaling
542 (UUS), a supplementary service in which manufacturer specific
543 information is transported via the codeset 0 User-to-user Information
544 IE. Three services are defined: service 1, service 2, and service 3.
545 This draft only addresses the SIP equivalent of service 1 although it
546 could easily be expanded later to address services 2 and 3. UUS
547 Service 1 involves user to user signaling exchanged during call setup
548 and clearing within the following Q.931 call control messages: SETUP,
549 ALERT, CONNECT, DISCONNECT, RELEASE, and RELEASE COMPLETE. For SS7,
550 user-to-user information may be exchanged within the following Q.763
551 messages: INITIAL ADRESS MESSAGE, ADDRESS COMPLETE MESSAGE, CALL
552 PROGRESS, CONNECT, ANSWER, and RELEASE. UUS Service 2 involves user
553 to user signaling exchanged during call establishment (between ALERT
554 and CONNECT) via the USER INFORMATION message. This service usually
555 has a maximum of 2 USER INFORMATION messages in each direction. UUS
556 Service 3 involves user to user signaling exchanged on an active call
557 via the USER INFORMATION message.
559 The following syntax specification uses the augmented Backus-Naur
560 Form (BNF) as described in RFC 2234 and extends RFC 3261.
562 UUI = "User-to-User" HCOLON uui-data *(SEMI uui-param)
563 uui-data = token
564 uui-param = enc-param | generic-param
565 enc-param = "encoding=" ("hex" | token)
567 Only one User-to-User header field may be present in a request or
568 response.
570 The only defined parameter for the User-to-User header field is the
571 encoding parameter. "encoding=hex" is used to indicate that the UUI
572 information is encoded as hex digits per the ISDN specification. The
573 first octet is the protocol discriminator. Other encoding methods of
574 encoding MAY also be standardized.
576 The UUI data MUST be less than 129 octets in length. This is because
577 ISDN limits UUI to 128 octets in length plus the single octet
578 protocol discriminator. Transporting UUI longer than 128 octets will
579 result in interoperability failures when interworking with ISDN.
581 7.1. IANA Considerations
583 7.1.1. Registration of Header Field
585 This document defines a new SIP header field named "User-to-User".
587 The following row shall be added to the "Header Fields" section of
588 the SIP parameter registry:
590 +------------------+--------------+-----------+
591 | Header Name | Compact Form | Reference |
592 +------------------+--------------+-----------+
593 | User-to-User | | [RFCXXXX] |
594 +------------------+--------------+-----------+
596 Editor's Note: [RFCXXXX] should be replaced with the designation of
597 the eventual SIP Working Group document.
599 7.1.2. Registration of Header Field Parameter
601 This document defines a parameter for the header field defined in the
602 preceding section. The header field "User-to-User" can contain the
603 parameter "encoding".
605 The following rows shall be added to the "Header Field Parameters and
606 Parameter Values" section of the SIP parameter registry:
608 +------------------+----------------+-------------------+-----------+
609 | Header Field | Parameter Name | Predefined Values | Reference |
610 +------------------+----------------+-------------------+-----------+
611 | User-to-User | encoding | No | [RFCXXXX] |
612 +------------------+----------------+-------------------+-----------+
614 Editor's Note: [RFCXXXX] should be replaced with the designation of
615 the eventual SIP Working Group document.
617 7.1.3. Registration of SIP Option Tag
619 This specification registers a new SIP option tag, as per the
620 guidelines in Section 27.1 of [RFC3261].
622 This document defines the SIP option tag "uui".
624 The following row has been added to the "Option Tags" section of the
625 SIP Parameter Registry:
627 +------------+------------------------------------------+-----------+
628 | Name | Description | Reference |
629 +------------+------------------------------------------+-----------+
630 | uui | This option tag is used to indicate that | [RFCXXXX] |
631 | | a UA supports and understands the | |
632 | | User-to-User header field. | |
633 +------------+------------------------------------------+-----------+
635 Editor's Note: [RFCXXXX] should be replaced with the designation of
636 the eventual SIP Working Group document.
638 8. Security Considerations
640 User to user information can be exchanged over SIP on a hop-by-hop or
641 end-to-end basis. In some cases, UUI may carry privacy information
642 that would require confidentiality and message integrity. Standard
643 SIP security mechanisms, viz., based on TLS, offer these properties
644 per-hop. To preserve multi-hop or end-end confidentiality and
645 integrity, S/MIME profile MUST be utilized. Since the security
646 requirements and key management of the UUI information are likely to
647 be quite different from the SIP signaling transport, another approach
648 would be for the UUI information to be encrypted before being passed
649 to SIP for transport.
651 Received User-to-User information should only be trusted if it is
652 authenticated or if it is received within a trust domain. For
653 example, Spec-T, defined in [RFC3324] could be used to define a trust
654 domain. When utilized by a gateway to map information to or from
655 ISDN Q.931 and ISUP Q.763, appropriate policy should be applied based
656 on the PSTN trust domain.
658 9. Acknowledgements
660 Thanks to Spencer Dawkins, Keith Drage, Vijay Gurbani, and Laura
661 Liess for their review of the document. The authors wish to thank
662 Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, and
663 Mahalingam Mani for their comments.
665 10. Informative References
667 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
668 A., Peterson, J., Sparks, R., Handley, M., and E.
669 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
670 June 2002.
672 [Q931] "ITU-T Q.931 User to User Information Element (UU IE)",
673 http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
675 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part
676 formats and codes",
677 http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
679 [ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services
680 Digital Network (ISDN)-Explicit Call Transfer
681 Supplementary Service".
683 [ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services
684 Digital Network (ISDN); Diversion supplementary services".
686 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
687 Requirement Levels", BCP 14, RFC 2119, March 1997.
689 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
690 for Telephones (SIP-T): Context and Architectures",
691 BCP 63, RFC 3372, September 2002.
693 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976,
694 October 2000.
696 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
697 Method", RFC 3515, April 2003.
699 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted
700 Identity", RFC 3324, November 2002.
702 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
703 and H. Schulzrinne, "Session Initiation Protocol (SIP)
704 Torture Test Messages", RFC 4475, May 2006.
706 Authors' Addresses
708 Alan Johnston (editor)
709 Avaya
710 St. Louis, MO 63124
712 Email: alan@sipstation.com
714 Joanne McMillen
715 Avaya
717 Email: joanne@avaya.com