idnits 2.17.1 draft-ietf-cuss-sip-uui-isdn-02.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 == Line 782 has weird spacing: '...ats and codes...' -- The document date (February 26, 2012) is 4443 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 571, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-cuss-sip-uui-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'Q931' Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Drage, Ed. 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track A. Johnston 5 Expires: August 29, 2012 Avaya 6 February 26, 2012 8 Interworking ISDN Call Control User Information with SIP 9 draft-ietf-cuss-sip-uui-isdn-02 11 Abstract 13 The motivation and use cases for interworking and transporting ITU-T 14 DSS1 User-user information element data in SIP are described in the 15 "Problem Statement and Requirements for Transporting User to User 16 Call Control Information in SIP" document. As networks move to SIP 17 it is important that applications requiring this data can continue to 18 function in SIP networks as well as the ability to interwork with 19 this ISDN service for end-to- end transparency. This document 20 defines a usage of the User-to-User header field to enable 21 interworking with this ISDN service. 23 This document covers the interworking with both public ISDN and 24 private ISDN capabilities, so the potential interworking with QSIG 25 will also be addressed. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 29, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Summary of the ISDN User-to-User Service . . . . . . . . . . . 3 64 3.1. The service . . . . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Impacts of the ISDN service on SIP operation . . . . . . . 5 66 4. Relation to SIP-T . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Transition away from ISDN . . . . . . . . . . . . . . . . . . 6 68 6. ISDN Usage of the User-to-User Header Field . . . . . . . . . 7 69 7. UAC requirements . . . . . . . . . . . . . . . . . . . . . . . 8 70 8. UAS requirements . . . . . . . . . . . . . . . . . . . . . . . 9 71 9. UUI contents . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 10. Considerations for ISDN interworking gateways . . . . . . . . 11 73 11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 11 74 12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 12 75 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 14. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 78 16. Changes since previous versions . . . . . . . . . . . . . . . 14 79 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 17.1. Normative References . . . . . . . . . . . . . . . . . . . 17 81 17.2. Informative References . . . . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in BCP 14, RFC 2119 89 [RFC2119]. 91 2. Overview 93 This document describes a usage of the User-to-User header field 94 defined in [I-D.ietf-cuss-sip-uui] to enable the transport of User to 95 User Information (UUI) in ISDN interworking scenarios using SIP 96 [RFC3261]. Specifically, this document discusses the interworking of 97 call control related ITU-T DSS1 User-user information element [Q931], 98 [Q957.1] and ITU-T Q.763 User-to-user information parameter [Q763] 99 data in SIP. UUI is widely used in the PSTN today in contact centers 100 and call centers which are transitioning away from ISDN to SIP. 102 This usage is not limited to scenarios where interworking will occur. 103 Rather it describes a usage where interworking is possible if 104 interworking is met. That does not preclude its usage directly 105 between two SIP terminals. 107 3. Summary of the ISDN User-to-User Service 109 3.1. The service 111 ISDN defines a number of related services. Firstly there is a user 112 signalling bearer service, which uses the information elements / 113 parameters in the signalling channel to carry the data, and does not 114 establish a related circuit-switched connection. For DSS1, this is 115 specified in ITU-T Recommendation Q.931 section 3.3 and section 7 116 [Q931]. It also defines a user-to-user signalling supplementary 117 service, which uses the information elements / parameters in the 118 signalling channel to carry additional data, but which is used in 119 conjunction with the establishment of a related circuit-switched 120 connection. This reuses the same information elements / parameters 121 as the user signalling bearer service, with the addition of other 122 signalling information, and for DSS1 this is specified in ITU-T 123 Recommendation Q.957.1 [Q957.1]. 125 ISDN defines three variants of the user-to-user signalling 126 supplementary service as follows: 128 UUS1: User-to-user information exchanged during the setup and 129 clearing phases of a call, by transporting User-to-user 130 information element within call control messages. This in itself 131 has two subvariants, UUS1 implicit and UUS1 explicit. UUS1 132 explicit uses additional supplementary service control information 133 to control the request and granting of the service, as in UUS2 and 134 UUS3. In UUS1 implicit, it is the presence of the user signalling 135 data itself that constitutes the request for the service. UUS1 136 explicit as a result also allows the requester to additionally 137 specify whether the parallel circuit-switched connection should 138 proceed if the UUS1 service cannot be provided (preferred or 139 required); 141 UUS2: User-to-user information exchanged from the sender's point of 142 view during call establishment, between the DSS1 ALERTING and DSS1 143 CONNECT messages, within DSS1 USER INFORMATION messages; and 145 UUS3: User-to-user information exchanged while a call is in the 146 Active state, within DSS1 USER INFORMATION messages. 148 The service is always requested by the calling user. 150 This document defines only the provision of the ISDN UUS1 implicit 151 supplementary service to interworking scenarios, this being the most 152 widely deployed and used of the various ISDN user-to-user services, 153 and indeed the one that matches the requirements specified in 154 draft-ietf-cuss-sip-uui-reqs [I-D.ietf-cuss-sip-uui-reqs]. 156 The above come from the ISDN specifications defined for public 157 networks. There are a parallel set of ISDN specifications defined 158 for private networks (QSIG}. These specifications do not define a 159 UUS1 implicit supplementary service. However, implementation of such 160 a UUS1 implicit supplementary service for private networks can 161 readily be constructed in a proprietary fashion based on the 162 specifications for public networks, and evidence suggests that some 163 vendors have done so. On this basis, there is no reason why this 164 package cannot also be used to support interworking with such a 165 private network service, on the assumption that the constraints are 166 exactly the same as those for the public network. 168 The ISDN UUS1 service has the following additional characteristics as 169 to the data that can be transported: 171 The maximum number of octets of user information that can be 172 transported in 128 octets plus a protocol discriminator. It is 173 noted that some early ISDN implementations had a limitation of 32 174 octets, but it is understood that these are not currently 175 deployed. While this package does not prohibit longer data 176 fields, the mechanism at any interworking point is to discard data 177 elements that are too long to handle. The handled length can 178 normally be assumed to be 128 octets. 180 The content of the user information octets is described by a 181 single octet protocol discriminator (see table 4-26 of ITU-T 182 Recommendation Q.931) [Q931]. That protocol descriminator may 183 describe the protocol used within the user data, the structure of 184 the user data, or leave it entirely open. Note that not all 185 values within the protocol discriminator necessarily make sense 186 for use in the user to user service, as the content is aligned 187 with the protocol discriminator that appears at the start of all 188 DSS1 messages (see table 4-1 of ITU-T Recommendation Q.931) 189 [Q931]. The protocol discriminator value has no impact on the 190 interworking capability. 192 Only a single user information can be transported in each message. 194 The ISDN service works without encryption or integrity protection. 195 The user trusts the intermediate network elements, and therefore 196 the operator of those elements, not to modify the data, and to 197 deliver all the data to the remote user. On a link by link basis, 198 message contents are protected at layer 2 by standard CRC 199 mechanisms - this allows loss on a link level basis to be 200 detected, but does not guard against fraudulent attacks on the 201 link itself. This does not prevent the use of additional 202 encryption or integrity protection within the payload itself, 203 although the limit on the size of the payload (128 octets) will 204 restrict this. 206 3.2. Impacts of the ISDN service on SIP operation 208 The ISDN service has the following impacts that need to be understood 209 within the SIP environment. 211 Call transfer ISDN call transfer cancels all user-to-user 212 supplementary services. In the ISDN, if user-to-user data is 213 required after call transfer, then UUS3 has to be renegotiated, 214 which is not provided by this SIP extension. The impact of this 215 restriction on the SIP environment is that UUI header fields 216 cannot be exchanged in transactions clearing down the SIP dialog 217 after call transfer has occurred. 219 Conference ISDN conferencing allows the user to still exchange user- 220 to-user data after the conference is created. As far as UUS1 is 221 concerned, it is not permitted. 223 The ISDN three-party supplementary service is similar in many ways 224 to conferencing, but is signalled using a different mechanism. 225 This means that on clearing, the controller using UUS1 implicit 226 does have the choice of sending data to either or both remote 227 users. Because SIP conferencing cannot completely emulate the 228 ISDN three-party supplementary service at the served user, UUS1 229 implicit is not possible. 231 Diversion When ISDN diversion occurs, any UUS1 user-to-user data is 232 sent to the forwarded-to-user (assuming that the call meets 233 requirements for providing the service - this is impacted by the 234 explicit service only). If the type of diversion is such that the 235 call is also delivered to the forwarding user, they will also 236 receive any UUS1 user-to-user data. 238 4. Relation to SIP-T 240 A method of transport of ISDN UUI is to use SIP-T [RFC3372] and 241 transport the UUI information end-to-end, as part of an ISUP message 242 or QSIG message) as a MIME body. If the SIP-T method of 243 encapsulation of ISDN instead of interworking is used, this is a 244 reasonable mechanism and does not require any extensions to existing 245 SIP-T. However, if true ISDN interworking is being done, this 246 approach is not reasonable. Instead, the better approach is to 247 interwork the ISDN UUI using the native SIP UUI transport mechanism, 248 the User-to-User header field. The rest of this document describes 249 this approach. 251 5. Transition away from ISDN 253 This interworking usage of the SIP UUI mechanism will likely begin 254 with one User Agent being an ISDN gateway while the other User Agent 255 is a native SIP endpoint. As networks transition away from ISDN, it 256 is possible that both User Agents could become native SIP endpoints. 257 In this case, there is an opportunity to transition away from this 258 ISDN usage to a more general usage of [I-D.ietf-cuss-sip-uui]. 260 The SIP UUI mechanism provides a way to achieve this transition. As 261 an endpoint moves from being an ISDN gateway to a native SIP 262 endpoint, and a package for some form of enhanced UUI has been 263 standardized, the endpoint can carry the UUI data both as ISDN and as 264 some other package in parallel, and in the same messages or in 265 different messages depending on the needs of the application. This 266 will permit the other endpoint to use the UUI according to the ISDN 267 package if it is an ISDN gateway or the enhanced package if it is a 268 native SIP endpoint. 270 6. ISDN Usage of the User-to-User Header Field 272 This document defines the package for the ISDN interworking of UUI 273 which is to interoperate with ISDN User to User Signaling (UUS), a 274 supplementary service in which the user is able to send/receive a 275 limited amount of information to/from another ISDN user over the 276 signalling channel in association with a call to the other ISDN user. 278 Two examples of ISDN UUI with redirection (transfer and diversion) 279 are defined in [ANSII] and [ETSI]. 281 One objective of the design of this package has been to keep the 282 functionality at the interworking point as simple as possible. 283 Therefore responsibility for respecting the limits has been 284 transferred to the end UA. If an interworking point is reached, and 285 the limitations are not met, then the UUI data will not be 286 transferred, although the SIP request will otherwise be interworked. 287 As a result there is also only one encoding value specified. 289 The general principals of this package of the UUI mechanism are 290 therefore as follows: 292 That the sending application is expected to limit their sending 293 requirements to the subset provided by the ISDN UUI service. 295 That the SIP UA will not allow the reception of more that one 296 User-to-User header field of the "isdn-uui" package in the same 297 SIP request or response, and will only allow it in a request or 298 response of the appropriate method (INVITE or BYE). What happens 299 to User-to-User header fields relating to different packages is 300 outside the scope of this document. 302 That an interworking point trying to interwork UUI data that is 303 too long will discard the UUI data, but proceed with the 304 interworking. There is no notification of such discard back to 305 the sending user. If the SIP user knows that it is interworking 306 with the ISDN, then the UUI application at the SIP endpoint should 307 limit its communication to 128 octet packets plus the protocol 308 discriminator, in the knowledge that discard will occur if it does 309 not. The UUI application at the SIP endpoint has complete control 310 over what occurs. It should be noted that this was exactly the 311 envisaged operation when early ISDN implementations that only 312 supported 32 octets interworked with those supporting 128 octets. 313 It also corresponds to the interworking with ISDNs that do not 314 support the supplementary service at all, as discard will occur in 315 these circumstances as well. Note that failure to include the 316 user-user data into the ISDN SETUP message (when discard occurs) 317 will result in the service being unavailable for the remainder of 318 the call when UUS1 implicit operation is used. 320 7. UAC requirements 322 The UAC MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in 323 addition to the requirements defined in this document. 325 The UAC MUST only use this package of the UUI mechanism extension in 326 association with the initial INVITE method and the BYE method 327 relating to an INVITE dialog. Usage on transactions associated with 328 any other type of dialog, or on methods not associated with a dialog 329 is precluded. Usage on other methods within the INVITE dialog, and 330 on re-INVITE transactions with the INVITE dialog, is also precluded. 332 If the UAC wishes to use or permit the sending of UUI data at any 333 point in the dialog, the UAC MUST include in the INVITE request for 334 that dialog a User-to-User header field. The UAC WSHOULD set the 335 "package" header field parameter to "isdn-uui". Non-inclusion of the 336 "package" header field parameter is permitted, but this is primarily 337 to allow earlier implementations to support this package. This 338 initial header field constitutes the implicit request to use the UUI 339 service, and is therefore included even when there is no data except 340 the protocol discriminator octet to send at that point in time. 342 The UAC MUST NOT include the User-to-User header field with a 343 "package" header field parameter set to "isdn-uui", or with no 344 "package" header field parameter", in any message of an INVITE dialog 345 if the original INVITE request did not include the User-to-User 346 header field, either with a "package" header field parameter set to 347 "isdn-uui", or with no "package" header field parameter included. 349 When sending UUI for the ISDN package, if the "package" header field 350 is included, the UAC MUST set the User-to-User "package" header field 351 parameter to "isdn-uui". The UAC MUST NOT include more than one 352 User-to-User header field for this package in any SIP request or 353 response. 355 When receiving UUI, when multiple User-to-User header fields are 356 received in the same response with the "package" header field 357 parameter to "isdn-uui", or with no "package" header field parameter, 358 or with some combination of these, the UAS MUST discard all these 359 header fields. There are no mechanisms for determining which was the 360 intended data packet so all are discarded. 362 The application designer will need to take into account the ISDN 363 service restrictions; failure to do so can result in information 364 being discarded at any interworking point with the ISDN. This 365 document makes no further normative requirements based on those 366 constraints, because those constraints may vary from one ISDN to 367 another. It is reasonable to expect that a limitation of 128 octets 368 (plus a protocol discriminator) can be imposed by the ISDN, and 369 therefore payloads longer than this will never reach the destination 370 if such interworking occurs. Note that the 128 octet limit (plus a 371 protocol discriminator) applies before the encoding (or after the 372 decoding) using the "hex" encoding. The "hex" encoding is defined in 373 [I-D.ietf-cuss-sip-uui]. 375 [I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the 376 UUI mechanism extension. Because for the ISDN UUI service, the 377 service is service 1 implicit, the inclusion of the "uui" option tag 378 in a Supported header field conveys no additional information over 379 and above the presence of the User-to-User header field with the 380 "package" header field parameter to "isdn-uui" in the INVITE request. 381 While there is no harm in including the "uui" option tag, and 382 strictly it should be included if the extension is supported, it 383 performs no function. The presence of the "uui" option tag in the 384 Require header field of an INVITE request will cause the request to 385 fail if it reaches a UAS or ISDN interworking gateway that does not 386 support this extension; such a usage is not precluded although it 387 does not form part of the package. 389 8. UAS requirements 391 The UAS MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in 392 addition to the requirements defined in this document. 394 The UAS MUST only use this package of the UUI mechanism extension in 395 association with the initial INVITE method and the BYE method 396 relating to an INVITE dialog. Usage on transactions associated with 397 any other type of dialog, or on methods not associated with a dialog 398 is precluded. Usage on other methods within the INVITE dialog, and 399 on re-INVITE transactions with the INVITE dialog, is also precluded. 401 The UAS MUST NOT include the User-to-User header field with a 402 "package" header field parameter set to "isdn-uui", or with no 403 "package" header field parameter", in any message of an INVITE dialog 404 if the original INVITE request did not include the User-to-User 405 header field, either with a "package" header field parameter set to 406 "isdn-uui", or with no "package" header field parameter included. 408 The UAS MAY include the User-to-User header field in responses to the 409 initial INVITE request, or the BYE requests or responses for the 410 dialog, only where the original INVITE request included a User-to- 411 User header field with the "package" header field parameter to "isdn- 412 uui", or where no "package" header field parameter was included. 413 When sending UUI for the ISDN package, the UAS SHOULD set the User- 414 to-User "package" header field parameter to "isdn-uui". Non- 415 inclusion of the "package" header field parameter is permitted, but 416 this is primarily to allow earlier implementations to support this 417 package. The UAS MUST NOT include more than one User-to-User header 418 field for this package in any SIP request or response. 420 Where the UAS is acting as a redirect server, the UAS MUST NOT 421 include the User-to-User header field in the header URI parameter in 422 a 3xx response to an incoming request. 424 When receiving UUI, when a User-to-User header field is received in a 425 request that is not from the originating user with the "package" 426 header field parameter to "isdn-uui", or with no "package" header 427 field parameter, the UAC MUST discard this header field. 429 When receiving UUI, when multiple User-to-User header fields are 430 received from the originating user in the same request with the 431 "package" header field parameter to "isdn-uui", or with no "package" 432 header field parameter, or with some combination of these, the UAC 433 MUST discard all these header fields. There are no mechanisms for 434 determining which was the intended data packet so all are discarded. 436 9. UUI contents 438 These requirements apply when the "package" header field parameter is 439 set to "isdn-uui", or with no "package" header field parameter. 440 Processing for User-to-User header fields sent or received with 441 values other than this value are outside the scope of this document, 442 and the appropriate package document for that value applies. 444 When sending UUI, the sending SIP entity MAY, but need not, include a 445 "content" header field with a value set to "isdn-uui". A receiving 446 SIP entity MUST ignore a received User-to-User header field if the 447 "content" header field parameter is present and the value is some 448 other value that "isdn-uui". 450 When sending UUI, the sending SIP entity MAY, but need not, include 451 an "encoding" header field with a value set to "hex". A receiving 452 SIP entity MUST ignore a received User-to-User header field if the 453 "encoding" header field parameter is present and the value is some 454 other value that "hex". 456 When sending UUI, the sending application MUST include a protocol 457 discriminator octet, conforming to table 4-26 of ITU-T Recommendation 458 Q.931 [Q931] as the first octet of the payload information. It is up 459 to the receiving application what it does with this value. This 460 document places no other normative requirement on the use of the 461 protocol discriminator; it is required at interworking gateways to 462 allow mapping into the appropriate fields in the ISDN protocols, but 463 otherwise the usage is entirely up to the application, and outside 464 the scope of this document. Valid values are identified and 465 documented by ITU-T, and there is no IANA registry for these values. 467 10. Considerations for ISDN interworking gateways 469 ISDN interworking gateways MUST support the requirements defined for 470 UAS and UAC operation. 472 ISDN interworking gateways MUST support only the "isdn-uui" package 473 on dialogs that are interworked. 475 ISDN interworking gateways will take octet structured data from the 476 ISDN side and encode it using the "hex" encoding scheme defined in 477 [I-D.ietf-cuss-sip-uui] for inclusion as the uui-data in the User-to- 478 User header field. In the reverse direction, it will take valid uui- 479 data according to the "hex" encoding scheme, and decode it to octet 480 structured data for sending to the ISDN side. 482 When mapping data content from the ISDN to the SIP signalling, or 483 from SIP signalling to the ISDN, the gateway needs to assume that all 484 content is octet structured binary, irrespective of the value of the 485 received protocol discriminator. There are no requirements in the 486 ISDN to ensure that the content matches the value of the protocol 487 discriminator, and it is for the application usage to sort out any 488 discrepancy. The same applies to the ISDN protocol discrimination 489 defined table 4-26 of ITU-T Recommendation Q.931 [Q931] as the first 490 octet of the payload information; the interworking gateway will not 491 perform any additional checking of this value. 493 [I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the 494 UUI mechanism extension. The option tag is not interworked at an 495 ISDN interworking gateway. The ISDN interworking gateways MUST NOT 496 take the omission of the "uui" option tag in a received INVITE 497 request to indicate that interworking of a received header field is 498 not to be performed. 500 11. Coding requirements 502 This document defines "isdn-uui" as a new value of the User-to-User 503 "package" header field parameter. 505 This document defines "isdn-uui" as a new value of the User-to-User 506 "content" header field parameter. A content value of "isdn-uui" 507 indicates that the contents have a first octet that is a protocol 508 discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931] 509 followed by uui-data that can be subject to a length limitation 510 (before encoding or after decoding) that is generally 128 octets. 512 12. Media Feature Tag 514 This document defines a new media feature tag "sip.uui-isdn". This 515 feature tag indicates that this UUI package is supported by the 516 sender, and its usage is entirely in accordance with RFC 3840 517 [RFC3840]. This document makes no additional provisions for the use 518 of this feature tag. 520 13. IANA Considerations 522 This document adds the following row to the "UUI packages" sub- 523 registry of the SIP parameter registry: 525 Value: isdn-uui 527 Description: The associated application is being used with 528 constraints suitable for interworking with the ISDN user-to-user 529 service, and therefore can be interworked at ISDN gateways. 531 Reference: RFCXXXX 533 Contact: 535 This document adds the following row to the "UUI content" subregistry 536 of the SIP parameter registry: 538 Value: isdn-uui 540 Description: The associated contents conforms to the content 541 associated with the ISDN user-to-user service. In the presence of 542 the "package" header field parameter set to "isdn-uui" this is the 543 default meaning and therefore need not be included in this case. 545 Reference: RFCXXXX 547 Contact: 549 This document defines the following media feature tag which is added 550 to the features.sip-tree of the Media Feature tags registry: 552 Media feature-tag name: sip.uui-isdn 554 ASN.1 Identifier: 1.3.6.1.8.4.x 556 Summary of the media feature indicated by this tag: This media 557 feature-tag when used in a Contact header field of a SIP request 558 or a SIP response indicates that the entity sending the SIP 559 message supports the UUI package "uui-isdn". 561 Values appropriate for use with this feature-tag: none 563 Examples of typical use: Indicating that a mobile phone supports 564 SRVCC for calls in alerting phase. 566 Related standards or documents: RFCXXXX 568 Security Considerations: Security considerations for this media 569 feature-tag are discussed in section 11.1 of RFC 3840 [RFC3840] 571 Editor's Note: [RFCXXXX] should be replaced with the designation of 572 this document. 574 14. Security Considerations 576 This document contains no specific requirements in regard to security 577 over and above those specified in [I-D.ietf-cuss-sip-uui]. The 578 overlying use case will define the security measures required. The 579 underlying user-to-user extension provides a number of tools that can 580 meet certain security requirements. As a level of guidance, data 581 that is used to assist in selecting which SIP UA should respond to 582 the call would not be expected to carry any higher level of security 583 than a media feature tag. Information that might otherwise reveal 584 private information about an individual, or where a level of 585 authenticity needs to be guaranteed, may need a higher level of 586 protection, and may indeed not be suitable for this package, 587 particularly taking into account the statement in the following 588 paragraph. 590 As this capability is defined to interwork with the ISDN, if the ISDN 591 forms part of the route, any usage needs to assume that the security 592 level of the ISDN is the highest level of security available. As the 593 ISDN security is itself not definable on an end-to-end basis, this 594 can be an unknown quantity. This is because ISDN security exists on 595 a hop-by-hop basis, and is only as secure as the least secure 596 component. This can be high in some places (e.g. it can require 597 physical access to a secure building) and in other places it can be 598 low (e.g. the point where an ISDN access enters a building). If this 599 level of security is not sufficient, then either a different user-to- 600 user package, or indeed, a different method of data transfer, needs 601 to be selected by the application user. 603 15. Acknowledgements 605 Joanne McMillen was a major contributor and co-author of earlier 606 versions of this document. 608 Thanks to Spencer Dawkins, Vijay Gurbani, and Laura Liess for their 609 review of earlier versions of this document. The authors wish to 610 thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen 611 Jennings, Mahalingam Mani and Celine Serrut-Valette for their 612 comments. 614 16. Changes since previous versions 616 Note to RFC editor: This section is to be deleted before final 617 publication. 619 Changes since made in the creation of the 620 draft-ietf-cuss-sip-uui-isdn-02 version from the 621 draft-ietf-cuss-sip-uui-isdn-01 version. 623 The inclusion of the "package" header field parameter has be 624 downgraded to "RECOMMENDED", with the purpose stated as being for 625 interworking. Changes have been made to the procedures at the 626 receiving side to allow for the non-inclusion of the "package" 627 header field parameter. The effect of this is that the absence of 628 the "package" header field parameter means by default the use of 629 the "uui-isdn" package. 631 Clarification that the package is not to be used on re-INVITE 632 transactions or on other transations within an INVITE dialog. 634 Further clarification on using this package in conjunction with 635 other packages. 637 Closure of the remaining open issue relating to use of UUS1 in 638 conjunction with the ISDN conference service - UUS1 is not 639 possible after the conference is created. 641 A number of editorial changes have been made. 643 Changes since made in the creation of the 644 draft-ietf-cuss-sip-uui-isdn-01 version from the 645 draft-ietf-cuss-sip-uui-isdn-00 version. 647 QSIG does not define a UUS service. As such changes are made to 648 indicate that it is possible to support a proprietary service on 649 QSIG based on the public ISDN standards, and interworking with 650 such proprietary versions is supported. The associated 651 contributors note regarding interactions with other QSIG services 652 has therefore been removed with this amendment. 654 Added additional paragraph above the objectives of the 655 interworking design. 657 Made clear that the 128 octets apply before encoding in "hex". 658 Reference added to the generic UUI document for the ecoding of 659 "hex". 661 Indicated that it is the "content" header field parameter set to 662 "isdn-uui" that defines the structure of the uui-data, with the 663 first octet being a protocol discriminator and the remaining 664 octets potentially being limited to 128 octets. 666 Aligned the IANA registration section with the registries created 667 by the generic UUI document. 669 Added reference to the generic UUI document to the security 670 considerations section. 672 Changes since made in the creation of the 673 draft-ietf-cuss-sip-uui-isdn-00 version from the 674 draft-drage-cuss-sip-uui-isdn-01 version. 676 Removed overburdening of the word "application". Changed the name 677 of the "app" header field parameter in the mechanism draft to 678 "package" header field parameter. This had a consequential impact 679 on the ISDN document. The word "application" is now solely 680 reserved for the name of the functionality that passes the UUI to 681 the SIP functionality to send, and to which the UUI is delivered 682 on receipt by the SIP functionality. As well as the change of the 683 name of the header field parameter, this resulted in a number of 684 instances of the word "application" becoming "package". A couple 685 of instances relating to the coding of the "content" header field 686 parameter have become "SIP entity". 688 Section 5 needed substantial rewording as it no longer applied in 689 this manner. Modified the text to indicate that if one wants to 690 use an enhanced UUI where both endpoints are SIP, but still work 691 with the ISDN, then one will have to same information using two 692 different packages, one the ISDN one, and the other some enhanced 693 package. 695 In section 8, a couple of requirements relating to the "content" 696 header field parameter really related to the "package" header 697 field parameter (formerly "app" header field parameter). These 698 are corrected. 700 Updated references from "draft-johnston-cuss-sip-uui" to 701 "draft-ietf-cuss-sip-uui". 703 Made clear throughout the document that the UUI payload is a 704 protocol discriminator plus 128 octets of data. 706 Made clearer that it is the initial INVITE request and responses 707 and the BYE request and responses only that carry the information 708 in this package. 710 Made clear that there are no normative requirements on the 711 protocol discriminator. In particular text is added to the end of 712 section 9. 714 Removed the following text from section 7, as it is a duplicate of 715 the text in section 9: 717 " When sending UUI, the sending application MUST include a 718 protocol discriminator octet, conforming to table 4-26 of ITU-T 719 Recommendation Q.931 [Q931] as the first octet of the payload 720 information." 722 Defined a media feature tag specific for the package. It has been 723 proposed to do this for all packages. "sip.uui-isdn" has been 724 added. 726 Corrected the short title for the draft. 728 Changes since made in the creation of the 729 draft-drage-cuss-sip-uui-isdn-01 version from the 730 draft-drage-cuss-sip-uui-isdn-00 version. 732 Closure of a number of open issues identified in the -00 version 733 and the creation of appropriate procedures for the UAC, the UAS, 734 and the ISDN interworking gateway. 736 17. References 737 17.1. Normative References 739 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 740 Requirement Levels", BCP 14, RFC 2119, March 1997. 742 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 743 A., Peterson, J., Sparks, R., Handley, M., and E. 744 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 745 June 2002. 747 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 748 for Telephones (SIP-T): Context and Architectures", 749 BCP 63, RFC 3372, September 2002. 751 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 752 "Indicating User Agent Capabilities in the Session 753 Initiation Protocol (SIP)", RFC 3840, August 2004. 755 [I-D.ietf-cuss-sip-uui] 756 Johnston, A. and J. Rafferty, "A Mechanism for 757 Transporting User to User Call Control Information in 758 SIP", draft-ietf-cuss-sip-uui-04 (work in progress), 759 October 2011. 761 [Q931] "ITU-T Recommendation Q.931: Digital subscriber Signalling 762 System No. 1 - Network layer; ISDN user-network interface 763 layer 3 specification for basic call control", 764 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 766 17.2. Informative References 768 [I-D.ietf-cuss-sip-uui-reqs] 769 Johnston, A. and L. Liess, "Problem Statement and 770 Requirements for Transporting User to User Call Control 771 Information in SIP", draft-ietf-cuss-sip-uui-reqs-09 (work 772 in progress), January 2012. 774 [Q957.1] "ITU-T Recommendation Q.957.1: Digital subscriber 775 Signalling System No. 1 - Stage 3 description for 776 supplementary services using DSS 1; Stage 3 description 777 for additional information transfer supplementary services 778 using DSS 1: User-to-User Signalling (UUS)", 779 http://www.itu.int/rec/T-REC-Q.957.1-199607-I . 781 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part 782 formats and codes", 783 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 785 [ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services 786 Digital Network (ISDN)-Explicit Call Transfer 787 Supplementary Service". 789 [ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services 790 Digital Network (ISDN); Diversion supplementary 791 services". 793 Authors' Addresses 795 Keith Drage (editor) 796 Alcatel-Lucent 797 Quadrant, Stonehill Green, Westlea 798 Swindon 799 UK 801 Email: keith.drage@alcatel-lucent.com 803 Alan Johnston 804 Avaya 805 St. Louis, MO 63124 806 United States 808 Email: alan.b.johnston@gmail.com