idnits 2.17.1 draft-ietf-cuss-sip-uui-isdn-10.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 693 has weird spacing: '...ats and codes...' -- The document date (October 24, 2014) is 3470 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 597, 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: April 27, 2015 Avaya 6 October 24, 2014 8 Interworking ISDN Call Control User Information with SIP 9 draft-ietf-cuss-sip-uui-isdn-10 11 Abstract 13 The motivation and use cases for interworking and transporting ITU-T 14 DSS1 User to User information element data in SIP are described in 15 RFC 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 April 27, 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 internetworking 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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 80 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 16.1. Normative References . . . . . . . . . . . . . . . . . . . 15 82 16.2. Informative References . . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [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 to User information element Q931 98 [Q931], Q957.1 [Q957.1] and ITU-T Q.763 User to User information 99 parameter [Q763] data in SIP. UUI is widely used in the PSTN today 100 in contact centers and call centers which are transitioning away from 101 ISDN to SIP. 103 This usage is not limited to scenarios where interworking will occur. 104 Rather it describes a usage where interworking is possible if 105 interworking is met. That does not preclude its usage directly 106 between two SIP terminals. 108 3. Summary of the ISDN User to User Service 110 3.1. The service 112 ISDN defines a number of related services. Firstly there is a user 113 signalling bearer service, which uses the information elements / 114 parameters in the signalling channel to carry the data, and does not 115 establish a related circuit-switched connection. For DSS1, this is 116 specified in ITU-T Recommendation Q.931 section 3.3 and section 7 117 [Q931]. It also defines a User to User signalling supplementary 118 service, which uses the information elements / parameters in the 119 signalling channel to carry additional data, but which is used in 120 conjunction with the establishment of a related circuit-switched 121 connection. This reuses the same information elements / parameters 122 as the user signalling bearer service, with the addition of other 123 signalling information, and for DSS1 this is specified in ITU-T 124 Recommendation Q.957.1 [Q957.1]. 126 ISDN defines three variants of the User to User signalling 127 supplementary service as follows: 129 UUS1: User to User information exchanged during the setup and 130 clearing phases of a call, by transporting User to User 131 information element within call control messages. This in itself 132 has two subvariants, UUS1 implicit and UUS1 explicit. In UUS1 133 implicit, it is the presence of the user signalling data itself 134 that constitutes the request for the service. UUS1 explicit uses 135 additional supplementary service control information to control 136 the request and granting of the service, as in UUS2 and UUS3. 137 UUS1 explicit as a result also allows the requester to 138 additionally specify whether the parallel circuit-switched 139 connection should proceed if the UUS1 service cannot be provided 140 (preferred or required); 142 UUS2: User to User information exchanged from the sender's point of 143 view during call establishment, between the DSS1 ALERTING and DSS1 144 CONNECT messages, within DSS1 USER INFORMATION messages; and 146 UUS3: User to User information exchanged while a call is in the 147 Active state, within DSS1 USER INFORMATION messages. 149 The service is always requested by the calling user. 151 This document defines only the provision of the ISDN UUS1 implicit 152 supplementary service to interworking scenarios, this being the most 153 widely deployed and used of the various ISDN User to User services, 154 and indeed the one that matches the requirements specified in RFC6567 155 [RFC6567]. 157 The above come from the ISDN specifications defined for public 158 networks. There are a parallel set of ISDN specifications defined 159 for private networks (QSIG}. These specifications do not define a 160 UUS1 implicit supplementary service. However, implementation of such 161 a UUS1 implicit supplementary service for private networks can 162 readily be constructed in a proprietary fashion based on the 163 specifications for public networks, and evidence suggests that some 164 vendors have done so. On this basis, there is no reason why this 165 package cannot also be used to support interworking with such a 166 private network service, on the assumption that the constraints are 167 exactly the same as those for the public network. 169 The ISDN UUS1 service has the following additional characteristics as 170 to the data that can be transported: 172 The maximum number of octets of user information that can be 173 transported is 128 octets plus a protocol discriminator. It is 174 noted that some early ISDN implementations had a limitation of 32 175 octets, but it is understood that these are not currently 176 deployed. While this package does not prohibit longer data 177 fields, the mechanism at any interworking point is to discard data 178 elements that are too long to handle. The handled length can 179 normally be assumed to be 128 octets. 181 The content of the user information octets is described by a 182 single octet protocol discriminator (see table 4-26 of ITU-T 183 Recommendation Q.931) [Q931]. That protocol descriminator may 184 describe the protocol used within the user data, the structure of 185 the user data, or leave it entirely open. Note that not all 186 values within the protocol discriminator necessarily make sense 187 for use in the User to User service, as the content is aligned 188 with the protocol discriminator that appears at the start of all 189 DSS1 messages (see table 4-1 of ITU-T Recommendation Q.931) 190 [Q931]. The protocol discriminator value has no impact on the 191 interworking capability. 193 Only a single user information can be transported in each message. 195 The ISDN service works without encryption or integrity protection. 196 The user trusts the intermediate network elements, and therefore 197 the operator of those elements, not to modify the data, and to 198 deliver all the data to the remote user. On a link by link basis, 199 message contents are protected at layer 2 by standard CRC 200 mechanisms - this allows loss on a link level basis to be 201 detected, but does not guard against fraudulent attacks on the 202 link itself. This does not prevent the use of additional 203 encryption or integrity protection within the UUI data itself, 204 although the limit on the size of the UUI data (protocol 205 discriminator plus 128 octets) will restrict this. 207 3.2. Impacts of the ISDN service on SIP operation 209 The ISDN service has the following impacts that need to be understood 210 within the SIP environment. 212 Call transfer: ISDN call transfer cancels all User to User 213 supplementary services. In the ISDN, if User to User data is 214 required after call transfer, then UUS3 has to be renegotiated, 215 which is not provided by this SIP extension. The impact of this 216 restriction on the SIP environment is that UUI header fields 217 cannot be exchanged in transactions clearing down the SIP dialog 218 after call transfer has occurred. 220 Conference: ISDN conferencing allows the user to still exchange User 221 to User data after the conference is created. As far as UUS1 is 222 concerned, it is not permitted. The ISDN three-party 223 supplementary service is similar in many ways to conferencing, but 224 is signalled using a different mechanism. This means that on 225 clearing, the controller using UUS1 implicit does have the choice 226 of sending data to either or both remote users. Because SIP 227 conferencing cannot completely emulate the ISDN three-party 228 supplementary service at the served user, UUS1 implicit is not 229 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, and 246 therefore SIP-T would not otherwise be used, this approach is not 247 reasonable, because then implementation of the many elements of ISUP 248 syntax would be required to understand one element of data. Instead, 249 the better approach is to interwork the ISDN UUI using the native SIP 250 UUI transport mechanism, the User-to-User header field. The rest of 251 this document describes 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. As a 285 result there is also only one encoding value specified. 286 Responsibility for respecting the limits has been transferred to the 287 end UA. If an interworking point is reached, and the limitations of 288 the ISDN (see section 3.1) are not met, then the UUI data will not be 289 transferred, although the SIP request will otherwise be interworked, 290 rather than have the interworking point attempt to resolve the non- 291 compliance with the limitations of ISDN. 293 The general principals of this package of the UUI mechanism are 294 therefore as follows: 296 That the sending application is expected to limit their sending 297 requirements to the subset provided by the ISDN UUI service. 299 That the SIP UA will not allow the reception of more that one 300 User-to-User header field relating to the "isdn-uui" package in 301 the same SIP request or response, and will only allow it in a 302 request or response of the appropriate method (INVITE or BYE). 303 What happens to User-to-User header fields relating to other 304 packages is outside the scope of this document. 306 That an interworking point trying to interwork UUI data that is 307 too long will discard the UUI data, but proceed with the 308 interworking. There is no notification of such discard back to 309 the sending user. If the SIP user knows that it is interworking 310 with the ISDN, then the UUI application at the SIP endpoint should 311 limit its communication to 128 octet packets plus the protocol 312 discriminator, in the knowledge that discard will occur if it does 313 not. The UUI application at the SIP endpoint has complete control 314 over what occurs. It should be noted that this was exactly the 315 envisaged operation when early ISDN implementations that only 316 supported 32 octets interworked with those supporting 128 octets. 317 It also corresponds to the interworking with ISDNs that do not 318 support the supplementary service at all, as discard will occur in 319 these circumstances as well. Note that failure to include the 320 User to User data into the ISDN SETUP message (when discard 321 occurs) will result in the service being unavailable for the 322 remainder of the call when UUS1 implicit operation is used. 324 7. UAC requirements 326 The UAC MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in 327 addition to the requirements defined in this document. 329 The UAC MUST only use this package of the UUI mechanism extension in 330 association with the initial INVITE method and the BYE method 331 relating to an INVITE dialog. Usage on transactions associated with 332 any other type of dialog, or on methods not associated with a dialog 333 is precluded. Usage on other methods within the INVITE dialog, and 334 on re-INVITE transactions with the INVITE dialog, is also precluded. 336 If the UAC wishes to use or permit the sending of UUI data at any 337 point in the dialog, the UAC MUST include in the INVITE request for 338 that dialog a User-to-User header field. The UAC SHOULD set the 339 "purpose" header field parameter to "isdn-uui". Non-inclusion of the 340 "purpose" header field parameter is permitted, but this is primarily 341 to allow earlier implementations to support this package. This 342 initial header field constitutes the implicit request to use the UUI 343 service, and is therefore included even when there is no data except 344 the protocol discriminator octet to send at that point in time. 346 The UAC MUST NOT include the User-to-User header field with a 347 "purpose" header field parameter set to "isdn-uui", or with no 348 "purpose" header field parameter", in any message of an INVITE dialog 349 if the original INVITE request did not include the User-to-User 350 header field, either with a "purpose" header field parameter set to 351 "isdn-uui", or with no "purpose" header field parameter included. 353 When sending UUI for the ISDN package, if the "purpose" header field 354 is included, the UAC MUST set the User-to-User "purpose" header field 355 parameter to "isdn-uui". The UAC MUST NOT include more than one 356 User-to-User header field for this package in any SIP request or 357 response. 359 When receiving UUI, when multiple User-to-User header fields are 360 received in the same response with the "purpose" header field 361 parameter to "isdn-uui", or with no "purpose" header field parameter, 362 or with some combination of these, the UAC MUST discard all these 363 header fields. There are no mechanisms for determining which was the 364 intended UUI data so all are discarded. 366 The application designer will need to take into account the ISDN 367 service restrictions; failure to do so can result in information 368 being discarded at any interworking point with the ISDN. This 369 document makes no further normative requirements based on those 370 constraints, because those constraints may vary from one ISDN to 371 another. It is reasonable to expect that a limitation of 128 octets 372 (plus a protocol discriminator) can be imposed by the ISDN, and 373 therefore UUI data longer than this will never reach the destination 374 if such interworking occurs. Note that the 128 octet limit (plus a 375 protocol discriminator) applies before the encoding (or after the 376 decoding) using the "hex" encoding. The "hex" encoding is defined in 377 [I-D.ietf-cuss-sip-uui]. 379 [I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the 380 UUI mechanism extension. Because for the ISDN UUI service, the 381 service is UUS1 implicit, the inclusion of the "uui" option tag in a 382 Supported header field conveys no additional information over and 383 above the presence, in the INVITE request, of the User-to-User header 384 field with the "purpose" header field parameter set to "isdn-uui". 385 While there is no harm in including the "uui" option tag, and 386 strictly it should be included if the extension is supported, it 387 performs no function. The presence of the "uui" option tag in the 388 Require header field of an INVITE request will cause the request to 389 fail if it reaches a UAS or ISDN interworking gateway that does not 390 support this extension; such a usage is not precluded although it 391 does not form part of the package. 393 8. UAS requirements 395 The UAS MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in 396 addition to the requirements defined in this document. 398 The UAS MUST only use this package of the UUI mechanism extension in 399 association with the initial INVITE method and the BYE method 400 relating to an INVITE dialog. Usage on transactions associated with 401 any other type of dialog, or on methods not associated with a dialog 402 is precluded. Usage on other methods within the INVITE dialog, and 403 on re-INVITE transactions with the INVITE dialog, is also precluded. 405 The UAS MUST NOT include the User-to-User header field with a 406 "purpose" header field parameter set to "isdn-uui", or with no 407 "purpose" header field parameter", in any message of an INVITE dialog 408 if the original INVITE request did not include the User-to-User 409 header field, either with a "purpose" header field parameter set to 410 "isdn-uui", or with no "purpose" header field parameter included. 412 The UAS MAY include the User-to-User header field in responses to the 413 initial INVITE request, or the BYE requests or responses for the 414 dialog, only where the original INVITE request included a User-to- 415 User header field with the "purpose" header field parameter set to 416 "isdn-uui", or where no "purpose" header field parameter was 417 included. When sending UUI for the ISDN package, the UAS SHOULD set 418 the User-to-User "purpose" header field parameter to "isdn-uui". 419 Non-inclusion of the "purpose" header field parameter is permitted, 420 but this is primarily to allow earlier implementations to support 421 this package. 423 When sending UUI for the ISDN package, if the "purpose" header field 424 is included, the UAS MUST set the User-to-User "purpose" header field 425 parameter to "isdn-uui". The UAS MUST NOT include more than one 426 User-to-User header field for this package in any SIP request or 427 response. 429 The "isdn-interwork" value for purpose parameter was used in 430 Internet-Drafts that have led to the publication of the present 431 document. Although these documents had no other status than "work in 432 progress", this value is implemented by some vendors. While not 433 defined by this document, implementations could find it useful for 434 interoperability purposes to support parsing and interpreting "isdn- 435 interwork" the same way as "isdn-uui" when receiving messages. 437 Where the UAS is acting as a redirect server, the UAS MUST NOT 438 include the User-to-User header field in the header URI parameter in 439 a 3xx response to an incoming request. 441 When receiving UUI, when a User-to-User header field is received in a 442 request that is not from the originating user with the "purpose" 443 header field parameter to "isdn-uui", or with no "purpose" header 444 field parameter, the UAS MUST discard this header field. 446 When receiving UUI, when multiple User-to-User header fields are 447 received from the originating user in the same request with the 448 "purpose" header field parameter to "isdn-uui", or with no "purpose" 449 header field parameter, or with some combination of these, the UAS 450 MUST discard all these header fields. There are no mechanisms for 451 determining which was the intended UUI data so all are discarded. 453 9. UUI contents 455 These requirements apply when the "purpose" header field parameter is 456 set to "isdn-uui", or with no "purpose" header field parameter. 458 Processing for User-to-User header fields sent or received with 459 values other than this value are outside the scope of this document, 460 and the appropriate package document for that value applies. 462 The default and only content defined for this package is "isdn-uui". 463 When sending UUI, the sending SIP entity MAY, but need not, include a 464 "content" header field with a value set to "isdn-uui". A receiving 465 SIP entity MUST ignore a received User-to-User header field if the 466 "content" header field parameter is present and the value is some 467 other value than "isdn-uui". 469 The default and only encoding defined for this package is "hex". 470 When sending UUI, the sending SIP entity MAY, but need not, include 471 an "encoding" header field with a value set to "hex". A receiving 472 SIP entity MUST ignore a received User-to-User header field if the 473 "encoding" header field parameter is present and the value is some 474 other value that "hex". 476 When sending UUI, the sending application MUST include a protocol 477 discriminator octet, conforming to table 4-26 of ITU-T Recommendation 478 Q.931 [Q931] as the first octet of the UUI data. It is up to the 479 receiving application what it does with this value. This document 480 places no other normative requirement on the use of the protocol 481 discriminator; it is required at interworking gateways to allow 482 mapping into the appropriate fields in the ISDN protocols, but 483 otherwise the usage is entirely up to the application, and outside 484 the scope of this document. Valid values are identified and 485 documented by ITU-T, and there is no IANA registry for these values. 487 10. Considerations for ISDN internetworking gateways 489 ISDN interworking gateways MUST support the requirements defined for 490 UAS and UAC operation. 492 ISDN interworking gateways MUST support only the "isdn-uui" package 493 on dialogs that are interworked. 495 ISDN interworking gateways will take octet structured data from the 496 ISDN side and encode it using the "hex" encoding scheme defined in 497 [I-D.ietf-cuss-sip-uui] for inclusion as the uui-data in the User-to- 498 User header field. In the reverse direction, it will take valid uui- 499 data according to the "hex" encoding scheme, and decode it to octet 500 structured data for sending to the ISDN side. 502 When mapping data content from the ISDN to the SIP signalling, or 503 from SIP signalling to the ISDN, the gateway needs to assume that all 504 content is octet structured binary, irrespective of the value of the 505 received protocol discriminator. There are no requirements in the 506 ISDN to ensure that the content matches the value of the protocol 507 discriminator, and it is for the application usage to sort out any 508 discrepancy. The same applies to the ISDN protocol discrimination 509 defined table 4-26 of ITU-T Recommendation Q.931 [Q931] as the first 510 octet of the UUI data; the interworking gateway will not perform any 511 additional checking of this value. 513 [I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the 514 UUI mechanism extension. The option tag is not interworked at an 515 ISDN interworking gateway. The ISDN interworking gateways MUST NOT 516 take the omission of the "uui" option tag in a received INVITE 517 request to indicate that interworking of a received header field is 518 not to be performed. 520 11. Coding requirements 522 This document defines "isdn-uui" as a new value of the User-to-User 523 "purpose" header field parameter. The following ABNF adds to the 524 production in [I-D.ietf-cuss-sip-uui]: 526 pkg-param-value =/ "isdn-uui" 528 This document defines "isdn-uui" as a new value of the User-to-User 529 "content" header field parameter. A content value of "isdn-uui" 530 indicates that the contents have a first octet that is a protocol 531 discriminator (see table 4-26 of ITU-T Recommendation Q.931 [Q931]) 532 followed by uui-data that can be subject to a length limitation 533 (before encoding or after decoding) that is generally 128 octets. 534 The following ABNF adds to the production in [I-D.ietf-cuss-sip-uui]. 536 cont-param-value =/ "isdn-uui" 538 12. Media Feature Tag 540 This document defines a new media feature tag "sip.uui-isdn". This 541 feature tag indicates that this UUI package is supported by the 542 sender, and its usage is entirely in accordance with RFC 3840 543 [RFC3840]. This document makes no additional provisions for the use 544 of this feature tag. 546 13. IANA Considerations 548 This document adds the following row to the "UUI packages" sub- 549 registry of the SIP parameter registry: 551 Value: isdn-uui 552 Description: The associated application is being used with 553 constraints suitable for interworking with the ISDN User to User 554 service, and therefore can be interworked at ISDN gateways. 556 Reference: RFCXXXX 558 Contact: Keith Drage 560 This document adds the following row to the "UUI content" subregistry 561 of the SIP parameter registry: 563 Value: isdn-uui 565 Description: The associated contents conforms to the content 566 associated with the ISDN User to User service. In the presence of 567 the "purpose" header field parameter set to "isdn-uui" (or the 568 absence of any "purpose" header field parameter) this is the 569 default meaning and therefore need not be included in this case. 571 Reference: RFCXXXX 573 Contact: Keith Drage 575 This document defines the following media feature tag which is added 576 to the features.sip-tree of the Media Feature tags registry: 578 Media feature-tag name: sip.uui-isdn 580 ASN.1 Identifier: 1.3.6.1.8.4.x 582 Summary of the media feature indicated by this tag: This media 583 feature-tag when used in a Contact header field of a SIP request 584 or a SIP response indicates that the entity sending the SIP 585 message supports the UUI package "uui-isdn". 587 Values appropriate for use with this feature-tag: none 589 Examples of typical use: Indicating that a mobile phone supports 590 SRVCC for calls in alerting phase. 592 Related standards or documents: RFCXXXX 594 Security Considerations: Security considerations for this media 595 feature-tag are discussed in section 11.1 of [RFC3840] 597 Editor's Note: [RFCXXXX] should be replaced with the designation of 598 this document. 600 14. Security Considerations 602 This document contains no specific requirements in regard to security 603 over and above those specified in [I-D.ietf-cuss-sip-uui]. However, 604 since this capability is designed to interwork with the ISDN, the 605 general security considerations of SIP to ISUP (ISDN User Part) 606 interworking defined in [RFC3398] apply. Any SIP/PSTN gateway 607 implementing the ISDN UUI service should not blindly trust ISUP from 608 the PSTN. In general, the overlying use case will define the 609 security measures required. The underlying User to User extension 610 provides a number of tools that can meet certain security 611 requirements. 613 Information that might otherwise reveal private information about an 614 individual, or where a level of authenticity needs to be guaranteed, 615 may need a higher level of protection, and may indeed not be suitable 616 for this package, particularly taking into account the statement in 617 the following paragraph. 619 As this capability is defined to interwork with the ISDN, if the ISDN 620 forms part of the route, any usage needs to be aware that the 621 security level of the ISDN service may be lower than the security of 622 the SIP service. The ISDN security is itself not definable on an 623 end-to-end basis, and exists on a hop-by-hop basis. This can be high 624 in some places (e.g. it can require physical access to a secure 625 building) and in other places it can be low (e.g. the point where an 626 ISDN access enters a building). If this level of security is not 627 sufficient, then either a different User to User package, or indeed, 628 a different method of data transfer, needs to be selected by the 629 application user. 631 15. Acknowledgments 633 Joanne McMillen was a major contributor and co-author of earlier 634 versions of this document. 636 Thanks to Spencer Dawkins, Vijay Gurbani, Laura Liess, and Roland 637 Jesske for their reviews of this document. The authors wish to thank 638 Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, 639 Mahalingam Mani and Celine Serrut-Valette for their 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. References 649 16.1. Normative References 651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 652 Requirement Levels", BCP 14, RFC 2119, March 1997. 654 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 655 A., Peterson, J., Sparks, R., Handley, M., and E. 656 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 657 June 2002. 659 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 660 for Telephones (SIP-T): Context and Architectures", 661 BCP 63, RFC 3372, September 2002. 663 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 664 "Indicating User Agent Capabilities in the Session 665 Initiation Protocol (SIP)", RFC 3840, August 2004. 667 [I-D.ietf-cuss-sip-uui] 668 Johnston, A. and J. Rafferty, "A Mechanism for 669 Transporting User to User Call Control Information in 670 SIP", draft-ietf-cuss-sip-uui-17 (work in progress), 671 June 2014. 673 [Q931] "ITU-T Recommendation Q.931: Digital subscriber Signalling 674 System No. 1 - Network layer; ISDN user-network interface 675 layer 3 specification for basic call control", 676 ITU-T http://www.itu.int/rec/T-REC-Q.931-199805-I/en. 678 [RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, 679 "Integrated Services Digital Network (ISDN) User Part 680 (ISUP) to Session Initiation Protocol (SIP) Mapping", 681 RFC 3398, December 2002. 683 16.2. Informative References 685 [Q957.1] "ITU-T Recommendation Q.957.1: Digital subscriber 686 Signalling System No. 1 - Stage 3 description for 687 supplementary services using DSS 1; Stage 3 description 688 for additional information transfer supplementary services 689 using DSS 1: User-to-User Signalling (UUS)", 690 ITU-T http://www.itu.int/rec/T-REC-Q.957.1-199607-I. 692 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part 693 formats and codes", 694 ITU-T http://www.itu.int/rec/T-REC-Q.931-199805-I/en. 696 [RFC6567] Johnston, A. and L. Liess, "Problem Statement and 697 Requirements for Transporting User-to-User Call Control 698 Information in SIP", RFC 6567, April 2012. 700 [ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services 701 Digital Network (ISDN)-Explicit Call Transfer 702 Supplementary Service", ANSI T1.643-1995 . 704 [ETSI] ""ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services 705 Digital Network (ISDN); Diversion supplementary 706 services"", ETSI ETF 300 207-1 . 708 Authors' Addresses 710 Keith Drage (editor) 711 Alcatel-Lucent 712 Quadrant, Stonehill Green, Westlea 713 Swindon 714 UK 716 Email: keith.drage@alcatel-lucent.com 718 Alan Johnston 719 Avaya 720 St. Loius, MO 721 US 723 Email: alan.b.johnston@gmail.com