idnits 2.17.1 draft-ietf-cuss-sip-uui-isdn-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 == Line 859 has weird spacing: '...ats and codes...' -- The document date (February 14, 2014) is 3717 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 595, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-cuss-sip-uui-12 -- 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 CUSS K. Drage, Ed. 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track A. Johnston 5 Expires: August 18, 2014 Avaya 6 February 14, 2014 8 Interworking ISDN Call Control User Information with SIP 9 draft-ietf-cuss-sip-uui-isdn-07 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 defines 20 a usage (a new package) 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 The package is identified by a new value "isdn-uui" of the "purpose" 28 header field parameter. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 18, 2014. 47 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 . . . . . . . . . . . . . . . . . . . . . 12 78 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 80 16. Changes since previous versions . . . . . . . . . . . . . . . 14 81 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 17.1. Normative References . . . . . . . . . . . . . . . . . . . 18 83 17.2. Informative References . . . . . . . . . . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 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, this 248 approach is not reasonable. Instead, the better approach is to 249 interwork the ISDN UUI using the native SIP UUI transport mechanism, 250 the User-to-User header field. The rest of this document describes 251 this approach. 253 5. Transition away from ISDN 255 This interworking usage of the SIP UUI mechanism will likely begin 256 with one User Agent being an ISDN gateway while the other User Agent 257 is a native SIP endpoint. As networks transition away from ISDN, it 258 is possible that both User Agents could become native SIP endpoints. 259 In this case, there is an opportunity to transition away from this 260 ISDN usage to a more general usage of [I-D.ietf-cuss-sip-uui]. 262 The SIP UUI mechanism provides a way to achieve this transition. As 263 an endpoint moves from being an ISDN gateway to a native SIP 264 endpoint, and a package for some form of enhanced UUI has been 265 standardized, the endpoint can carry the UUI data both as ISDN and as 266 some other package in parallel, and in the same messages or in 267 different messages depending on the needs of the application. This 268 will permit the other endpoint to use the UUI according to the ISDN 269 package if it is an ISDN gateway or the enhanced package if it is a 270 native SIP endpoint. 272 6. ISDN Usage of the User-to-User Header Field 274 This document defines the package for the ISDN interworking of UUI 275 which is to interoperate with ISDN User to User Signaling (UUS), a 276 supplementary service in which the user is able to send/receive a 277 limited amount of information to/from another ISDN user over the 278 signalling channel in association with a call to the other ISDN user. 280 Two examples of ISDN UUI with redirection (transfer and diversion) 281 are defined in [ANSII] and [ETSI]. 283 One objective of the design of this package has been to keep the 284 functionality at the interworking point as simple as possible. 285 Therefore responsibility for respecting the limits has been 286 transferred to the end UA. If an interworking point is reached, and 287 the limitations are not met, then the UUI data will not be 288 transferred, although the SIP request will otherwise be interworked. 289 As a result there is also only one encoding value specified. 291 The general principals of this package of the UUI mechanism are 292 therefore as follows: 294 That the sending application is expected to limit their sending 295 requirements to the subset provided by the ISDN UUI service. 297 That the SIP UA will not allow the reception of more that one 298 User-to-User header field relating to the "isdn-uui" package in 299 the same SIP request or response, and will only allow it in a 300 request or response of the appropriate method (INVITE or BYE). 301 What happens to User-to-User header fields relating to other 302 packages is outside the scope of this document. 304 That an interworking point trying to interwork UUI data that is 305 too long will discard the UUI data, but proceed with the 306 interworking. There is no notification of such discard back to 307 the sending user. If the SIP user knows that it is interworking 308 with the ISDN, then the UUI application at the SIP endpoint should 309 limit its communication to 128 octet packets plus the protocol 310 discriminator, in the knowledge that discard will occur if it does 311 not. The UUI application at the SIP endpoint has complete control 312 over what occurs. It should be noted that this was exactly the 313 envisaged operation when early ISDN implementations that only 314 supported 32 octets interworked with those supporting 128 octets. 315 It also corresponds to the interworking with ISDNs that do not 316 support the supplementary service at all, as discard will occur in 317 these circumstances as well. Note that failure to include the 318 user-user data into the ISDN SETUP message (when discard occurs) 319 will result in the service being unavailable for the remainder of 320 the call when UUS1 implicit operation is used. 322 7. UAC requirements 324 The UAC MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in 325 addition to the requirements defined in this document. 327 The UAC MUST only use this package of the UUI mechanism extension in 328 association with the initial INVITE method and the BYE method 329 relating to an INVITE dialog. Usage on transactions associated with 330 any other type of dialog, or on methods not associated with a dialog 331 is precluded. Usage on other methods within the INVITE dialog, and 332 on re-INVITE transactions with the INVITE dialog, is also precluded. 334 If the UAC wishes to use or permit the sending of UUI data at any 335 point in the dialog, the UAC MUST include in the INVITE request for 336 that dialog a User-to-User header field. The UAC SHOULD set the 337 "purpose" header field parameter to "isdn-uui". Non-inclusion of the 338 "purpose" header field parameter is permitted, but this is primarily 339 to allow earlier implementations to support this package. This 340 initial header field constitutes the implicit request to use the UUI 341 service, and is therefore included even when there is no data except 342 the protocol discriminator octet to send at that point in time. 344 The UAC MUST NOT include the User-to-User header field with a 345 "purpose" header field parameter set to "isdn-uui", or with no 346 "purpose" header field parameter", in any message of an INVITE dialog 347 if the original INVITE request did not include the User-to-User 348 header field, either with a "purpose" header field parameter set to 349 "isdn-uui", or with no "purpose" header field parameter included. 351 When sending UUI for the ISDN package, if the "purpose" header field 352 is included, the UAC MUST set the User-to-User "purpose" header field 353 parameter to "isdn-uui". The UAC MUST NOT include more than one 354 User-to-User header field for this package in any SIP request or 355 response. 357 When receiving UUI, when multiple User-to-User header fields are 358 received in the same response with the "purpose" header field 359 parameter to "isdn-uui", or with no "purpose" header field parameter, 360 or with some combination of these, the UAS MUST discard all these 361 header fields. There are no mechanisms for determining which was the 362 intended data packet so all are discarded. 364 The application designer will need to take into account the ISDN 365 service restrictions; failure to do so can result in information 366 being discarded at any interworking point with the ISDN. This 367 document makes no further normative requirements based on those 368 constraints, because those constraints may vary from one ISDN to 369 another. It is reasonable to expect that a limitation of 128 octets 370 (plus a protocol discriminator) can be imposed by the ISDN, and 371 therefore UUI data longer than this will never reach the destination 372 if such interworking occurs. Note that the 128 octet limit (plus a 373 protocol discriminator) applies before the encoding (or after the 374 decoding) using the "hex" encoding. The "hex" encoding is defined in 375 [I-D.ietf-cuss-sip-uui]. 377 [I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the 378 UUI mechanism extension. Because for the ISDN UUI service, the 379 service is service 1 implicit, the inclusion of the "uui" option tag 380 in a Supported header field conveys no additional information over 381 and above the presence, in the INVITE request, of the User-to-User 382 header field with the "purpose" header field parameter set to "isdn- 383 uui". While there is no harm in including the "uui" option tag, and 384 strictly it should be included if the extension is supported, it 385 performs no function. The presence of the "uui" option tag in the 386 Require header field of an INVITE request will cause the request to 387 fail if it reaches a UAS or ISDN interworking gateway that does not 388 support this extension; such a usage is not precluded although it 389 does not form part of the package. 391 8. UAS requirements 393 The UAS MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in 394 addition to the requirements defined in this document. 396 The UAS MUST only use this package of the UUI mechanism extension in 397 association with the initial INVITE method and the BYE method 398 relating to an INVITE dialog. Usage on transactions associated with 399 any other type of dialog, or on methods not associated with a dialog 400 is precluded. Usage on other methods within the INVITE dialog, and 401 on re-INVITE transactions with the INVITE dialog, is also precluded. 403 The UAS MUST NOT include the User-to-User header field with a 404 "purpose" header field parameter set to "isdn-uui", or with no 405 "purpose" header field parameter", in any message of an INVITE dialog 406 if the original INVITE request did not include the User-to-User 407 header field, either with a "purpose" header field parameter set to 408 "isdn-uui", or with no "purpose" header field parameter included. 410 The UAS MAY include the User-to-User header field in responses to the 411 initial INVITE request, or the BYE requests or responses for the 412 dialog, only where the original INVITE request included a User-to- 413 User header field with the "purpose" header field parameter set to 414 "isdn-uui", or where no "purpose" header field parameter was 415 included. When sending UUI for the ISDN package, the UAS SHOULD set 416 the User-to-User "purpose" header field parameter to "isdn-uui". 417 Non-inclusion of the "purpose" header field parameter is permitted, 418 but this is primarily to allow earlier implementations to support 419 this package. 421 When sending UUI for the ISDN package, if the "purpose" header field 422 is included, the UAS MUST set the User-to-User "purpose" header field 423 parameter to "isdn-uui". The UAS MUST NOT include more than one 424 User-to-User header field for this package in any SIP request or 425 response. 427 The "isdn-interwork" value for purpose parameter was used in 428 Internet-Drafts that have led to the publication of the present 429 document. Although these documents had no other status than "work in 430 progress", this value is implemented by some vendors. While not 431 defined by this document, implementations could find it useful for 432 interoperability purposes to support parsing and interpreting "isdn- 433 interwork" the same way as "isdn-uui" when receiving messages. 435 Where the UAS is acting as a redirect server, the UAS MUST NOT 436 include the User-to-User header field in the header URI parameter in 437 a 3xx response to an incoming request. 439 When receiving UUI, when a User-to-User header field is received in a 440 request that is not from the originating user with the "purpose" 441 header field parameter to "isdn-uui", or with no "purpose" header 442 field parameter, the UAS MUST discard this header field. 444 When receiving UUI, when multiple User-to-User header fields are 445 received from the originating user in the same request with the 446 "purpose" header field parameter to "isdn-uui", or with no "purpose" 447 header field parameter, or with some combination of these, the UAS 448 MUST discard all these header fields. There are no mechanisms for 449 determining which was the intended data packet so all are discarded. 451 9. UUI contents 453 These requirements apply when the "purpose" header field parameter is 454 set to "isdn-uui", or with no "purpose" header field parameter. 455 Processing for User-to-User header fields sent or received with 456 values other than this value are outside the scope of this document, 457 and the appropriate package document for that value applies. 459 The default and only content defined for this package is "isdn-uui". 460 When sending UUI, the sending SIP entity MAY, but need not, include a 461 "content" header field with a value set to "isdn-uui". A receiving 462 SIP entity MUST ignore a received User-to-User header field if the 463 "content" header field parameter is present and the value is some 464 other value than "isdn-uui". 466 The default and only encoding defined for this package is "hex". 467 When sending UUI, the sending SIP entity MAY, but need not, include 468 an "encoding" header field with a value set to "hex". A receiving 469 SIP entity MUST ignore a received User-to-User header field if the 470 "encoding" header field parameter is present and the value is some 471 other value that "hex". 473 When sending UUI, the sending application MUST include a protocol 474 discriminator octet, conforming to table 4-26 of ITU-T Recommendation 475 Q.931 [Q931] as the first octet of the UUI data. It is up to the 476 receiving application what it does with this value. This document 477 places no other normative requirement on the use of the protocol 478 discriminator; it is required at interworking gateways to allow 479 mapping into the appropriate fields in the ISDN protocols, but 480 otherwise the usage is entirely up to the application, and outside 481 the scope of this document. Valid values are identified and 482 documented by ITU-T, and there is no IANA registry for these values. 484 10. Considerations for ISDN interworking gateways 486 ISDN interworking gateways MUST support the requirements defined for 487 UAS and UAC operation. 489 ISDN interworking gateways MUST support only the "isdn-uui" package 490 on dialogs that are interworked. 492 ISDN interworking gateways will take octet structured data from the 493 ISDN side and encode it using the "hex" encoding scheme defined in 494 [I-D.ietf-cuss-sip-uui] for inclusion as the uui-data in the User-to- 495 User header field. In the reverse direction, it will take valid uui- 496 data according to the "hex" encoding scheme, and decode it to octet 497 structured data for sending to the ISDN side. 499 When mapping data content from the ISDN to the SIP signalling, or 500 from SIP signalling to the ISDN, the gateway needs to assume that all 501 content is octet structured binary, irrespective of the value of the 502 received protocol discriminator. There are no requirements in the 503 ISDN to ensure that the content matches the value of the protocol 504 discriminator, and it is for the application usage to sort out any 505 discrepancy. The same applies to the ISDN protocol discrimination 506 defined table 4-26 of ITU-T Recommendation Q.931 [Q931] as the first 507 octet of the UUI data; the interworking gateway will not perform any 508 additional checking of this value. 510 [I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the 511 UUI mechanism extension. The option tag is not interworked at an 512 ISDN interworking gateway. The ISDN interworking gateways MUST NOT 513 take the omission of the "uui" option tag in a received INVITE 514 request to indicate that interworking of a received header field is 515 not to be performed. 517 11. Coding requirements 519 This document defines "isdn-uui" as a new value of the User-to-User 520 "purpose" header field parameter. The following ABNF adds to the 521 production in [I-D.ietf-cuss-sip-uui] 523 pkg-param-value =/ "isdn-uui" 525 This document defines "isdn-uui" as a new value of the User-to-User 526 "content" header field parameter. A content value of "isdn-uui" 527 indicates that the contents have a first octet that is a protocol 528 discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931] 529 followed by uui-data that can be subject to a length limitation 530 (before encoding or after decoding) that is generally 128 octets. 531 The following ABNF adds to the production in [I-D.ietf-cuss-sip-uui] 533 cont-param-value =/ "isdn-uui" 535 12. Media Feature Tag 537 This document defines a new media feature tag "sip.uui-isdn". This 538 feature tag indicates that this UUI package is supported by the 539 sender, and its usage is entirely in accordance with RFC 3840 540 [RFC3840]. This document makes no additional provisions for the use 541 of this feature tag. 543 13. IANA Considerations 545 This document adds the following row to the "UUI packages" sub- 546 registry of the SIP parameter registry: 548 Value: isdn-uui 550 Description: The associated application is being used with 551 constraints suitable for interworking with the ISDN user-to-user 552 service, and therefore can be interworked at ISDN gateways. 554 Reference: RFCXXXX 556 Contact: 558 This document adds the following row to the "UUI content" subregistry 559 of the SIP parameter registry: 561 Value: isdn-uui 563 Description: The associated contents conforms to the content 564 associated with the ISDN user-to-user service. In the presence of 565 the "purpose" header field parameter set to "isdn-uui" (or the 566 absence of any "purpose" header field parameter) this is the 567 default meaning and therefore need not be included in this case. 569 Reference: RFCXXXX 571 Contact: 573 This document defines the following media feature tag which is added 574 to the features.sip-tree of the Media Feature tags registry: 576 Media feature-tag name: sip.uui-isdn 578 ASN.1 Identifier: 1.3.6.1.8.4.x 580 Summary of the media feature indicated by this tag: This media 581 feature-tag when used in a Contact header field of a SIP request 582 or a SIP response indicates that the entity sending the SIP 583 message supports the UUI package "uui-isdn". 585 Values appropriate for use with this feature-tag: none 587 Examples of typical use: Indicating that a mobile phone supports 588 SRVCC for calls in alerting phase. 590 Related standards or documents: RFCXXXX 592 Security Considerations: Security considerations for this media 593 feature-tag are discussed in section 11.1 of RFC 3840 [RFC3840] 595 Editor's Note: [RFCXXXX] should be replaced with the designation of 596 this document. 598 14. Security Considerations 600 This document contains no specific requirements in regard to security 601 over and above those specified in [I-D.ietf-cuss-sip-uui]. The 602 overlying use case will define the security measures required. The 603 underlying user-to-user extension provides a number of tools that can 604 meet certain security requirements. As a level of guidance, data 605 that is used to assist in selecting which SIP UA should respond to 606 the call would not be expected to carry any higher level of security 607 than a media feature tag. Information that might otherwise reveal 608 private information about an individual, or where a level of 609 authenticity needs to be guaranteed, may need a higher level of 610 protection, and may indeed not be suitable for this package, 611 particularly taking into account the statement in the following 612 paragraph. 614 As this capability is defined to interwork with the ISDN, if the ISDN 615 forms part of the route, any usage needs to assume that the security 616 level of the ISDN is the highest level of security available. As the 617 ISDN security is itself not definable on an end-to-end basis, this 618 can be an unknown quantity. This is because ISDN security exists on 619 a hop-by-hop basis, and is only as secure as the least secure 620 component. This can be high in some places (e.g. it can require 621 physical access to a secure building) and in other places it can be 622 low (e.g. the point where an ISDN access enters a building). If this 623 level of security is not sufficient, then either a different user-to- 624 user package, or indeed, a different method of data transfer, needs 625 to be selected by the application user. 627 15. Acknowledgements 629 Joanne McMillen was a major contributor and co-author of earlier 630 versions of this document. 632 Thanks to Spencer Dawkins, Vijay Gurbani, and Laura Liess for their 633 review of earlier versions of this document. The authors wish to 634 thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen 635 Jennings, Mahalingam Mani and Celine Serrut-Valette for their 636 comments. 638 16. Changes since previous versions 640 Note to RFC editor: This section is to be deleted before final 641 publication. 643 Changes since made in the creation of the 644 draft-ietf-cuss-sip-uui-isdn-07 version from the 645 draft-ietf-cuss-sip-uui-isdn-06 version. 647 In the UAS requirements section, a new requirement has been added 648 to set the purpose parameter to "uui-isdn" if it is included. 649 This matches an equivalent requirement for the UAC. 651 In the UAS requirements section, two instances of UAC have been 652 corrected to UAS. 654 Changes since made in the creation of the 655 draft-ietf-cuss-sip-uui-isdn-06 version from the 656 draft-ietf-cuss-sip-uui-isdn-05 version. 658 A new paragraph of informative material has been added in section 659 8 relating to older implementations generating "ISDNinterwork" as 660 a purpose value. 662 A number of editorial changes have been made. 664 Changes since made in the creation of the 665 draft-ietf-cuss-sip-uui-isdn-05 version from the 666 draft-ietf-cuss-sip-uui-isdn-04 version. 668 ABNF provided for definition of values of package and content to 669 correspond to ABNF in current version of [I-D.ietf-cuss-sip-uui] 671 Changes since made in the creation of the 672 draft-ietf-cuss-sip-uui-isdn-04 version from the 673 draft-ietf-cuss-sip-uui-isdn-03 version. 675 Change of the "package" header field parameter back to the 676 "purpose" header field parameter in alignment with change in 677 draft-ietf-cuss-sip-uui. 679 Identification of the package name in the abstract. 681 Minor change to IANA registration of "content" header field 682 parameter value to align with main text such that absence of 683 "package" header field parameter and absence of "content" header 684 field parameter implies this package and therefore this content, 685 as a default. 687 Changes since made in the creation of the 688 draft-ietf-cuss-sip-uui-isdn-03 version from the 689 draft-ietf-cuss-sip-uui-isdn-02 version. 691 Clarification added that the default content is "isdn-uui". 693 Clarification added that the default encoding is "hex". 695 Changeout of "payload" terminology to "UUI data". 697 Changes since made in the creation of the 698 draft-ietf-cuss-sip-uui-isdn-02 version from the 699 draft-ietf-cuss-sip-uui-isdn-01 version. 701 The inclusion of the "package" header field parameter has be 702 downgraded to "RECOMMENDED", with the purpose stated as being for 703 interworking. Changes have been made to the procedures at the 704 receiving side to allow for the non-inclusion of the "package" 705 header field parameter. The effect of this is that the absence of 706 the "package" header field parameter means by default the use of 707 the "uui-isdn" package. 709 Clarification that the package is not to be used on re-INVITE 710 transactions or on other transations within an INVITE dialog. 712 Further clarification on using this package in conjunction with 713 other packages. 715 Closure of the remaining open issue relating to use of UUS1 in 716 conjunction with the ISDN conference service - UUS1 is not 717 possible after the conference is created. 719 A number of editorial changes have been made. 721 Changes since made in the creation of the 722 draft-ietf-cuss-sip-uui-isdn-01 version from the 723 draft-ietf-cuss-sip-uui-isdn-00 version. 725 QSIG does not define a UUS service. As such changes are made to 726 indicate that it is possible to support a proprietary service on 727 QSIG based on the public ISDN standards, and interworking with 728 such proprietary versions is supported. The associated 729 contributors note regarding interactions with other QSIG services 730 has therefore been removed with this amendment. 732 Added additional paragraph above the objectives of the 733 interworking design. 735 Made clear that the 128 octets apply before encoding in "hex". 736 Reference added to the generic UUI document for the ecoding of 737 "hex". 739 Indicated that it is the "content" header field parameter set to 740 "isdn-uui" that defines the structure of the uui-data, with the 741 first octet being a protocol discriminator and the remaining 742 octets potentially being limited to 128 octets. 744 Aligned the IANA registration section with the registries created 745 by the generic UUI document. 747 Added reference to the generic UUI document to the security 748 considerations section. 750 Changes since made in the creation of the 751 draft-ietf-cuss-sip-uui-isdn-00 version from the 752 draft-drage-cuss-sip-uui-isdn-01 version. 754 Removed overburdening of the word "application". Changed the name 755 of the "app" header field parameter in the mechanism draft to 756 "package" header field parameter. This had a consequential impact 757 on the ISDN document. The word "application" is now solely 758 reserved for the name of the functionality that passes the UUI to 759 the SIP functionality to send, and to which the UUI is delivered 760 on receipt by the SIP functionality. As well as the change of the 761 name of the header field parameter, this resulted in a number of 762 instances of the word "application" becoming "package". A couple 763 of instances relating to the coding of the "content" header field 764 parameter have become "SIP entity". 766 Section 5 needed substantial rewording as it no longer applied in 767 this manner. Modified the text to indicate that if one wants to 768 use an enhanced UUI where both endpoints are SIP, but still work 769 with the ISDN, then one will have to same information using two 770 different packages, one the ISDN one, and the other some enhanced 771 package. 773 In section 8, a couple of requirements relating to the "content" 774 header field parameter really related to the "package" header 775 field parameter (formerly "app" header field parameter). These 776 are corrected. 778 Updated references from "draft-johnston-cuss-sip-uui" to 779 "draft-ietf-cuss-sip-uui". 781 Made clear throughout the document that the UUI payload is a 782 protocol discriminator plus 128 octets of data. 784 Made clearer that it is the initial INVITE request and responses 785 and the BYE request and responses only that carry the information 786 in this package. 788 Made clear that there are no normative requirements on the 789 protocol discriminator. In particular text is added to the end of 790 section 9. 792 Removed the following text from section 7, as it is a duplicate of 793 the text in section 9: 795 " When sending UUI, the sending application MUST include a 796 protocol discriminator octet, conforming to table 4-26 of ITU-T 797 Recommendation Q.931 [Q931] as the first octet of the payload 798 information." 800 Defined a media feature tag specific for the package. It has been 801 proposed to do this for all packages. "sip.uui-isdn" has been 802 added. 804 Corrected the short title for the draft. 806 Changes since made in the creation of the 807 draft-drage-cuss-sip-uui-isdn-01 version from the 808 draft-drage-cuss-sip-uui-isdn-00 version. 810 Closure of a number of open issues identified in the -00 version 811 and the creation of appropriate procedures for the UAC, the UAS, 812 and the ISDN interworking gateway. 814 17. References 816 17.1. Normative References 818 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 819 Requirement Levels", BCP 14, RFC 2119, March 1997. 821 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 822 A., Peterson, J., Sparks, R., Handley, M., and E. 823 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 824 June 2002. 826 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 827 for Telephones (SIP-T): Context and Architectures", 828 BCP 63, RFC 3372, September 2002. 830 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 831 "Indicating User Agent Capabilities in the Session 832 Initiation Protocol (SIP)", RFC 3840, August 2004. 834 [I-D.ietf-cuss-sip-uui] 835 Johnston, A. and J. Rafferty, "A Mechanism for 836 Transporting User to User Call Control Information in 837 SIP", draft-ietf-cuss-sip-uui-12 (work in progress), 838 January 2014. 840 [Q931] "ITU-T Recommendation Q.931: Digital subscriber Signalling 841 System No. 1 - Network layer; ISDN user-network interface 842 layer 3 specification for basic call control", 843 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 845 17.2. Informative References 847 [RFC6567] Johnston, A. and L. Liess, "Problem Statement and 848 Requirements for Transporting User-to-User Call Control 849 Information in SIP", RFC 6567, April 2012. 851 [Q957.1] "ITU-T Recommendation Q.957.1: Digital subscriber 852 Signalling System No. 1 - Stage 3 description for 853 supplementary services using DSS 1; Stage 3 description 854 for additional information transfer supplementary services 855 using DSS 1: User-to-User Signalling (UUS)", 856 http://www.itu.int/rec/T-REC-Q.957.1-199607-I . 858 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part 859 formats and codes", 860 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 862 [ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services 863 Digital Network (ISDN)-Explicit Call Transfer 864 Supplementary Service". 866 [ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services 867 Digital Network (ISDN); Diversion supplementary 868 services". 870 Authors' Addresses 872 Keith Drage (editor) 873 Alcatel-Lucent 874 Quadrant, Stonehill Green, Westlea 875 Swindon 876 UK 878 Email: keith.drage@alcatel-lucent.com 880 Alan Johnston 881 Avaya 882 St. Louis, MO 63124 883 United States 885 Email: alan.b.johnston@gmail.com