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