idnits 2.17.1 draft-ietf-cuss-sip-uui-isdn-11.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 696 has weird spacing: '...ats and codes...' -- The document date (November 11, 2014) is 3453 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: May 15, 2015 Avaya 6 November 11, 2014 8 Interworking ISDN Call Control User Information with SIP 9 draft-ietf-cuss-sip-uui-isdn-11 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 called 19 the ISDN UUI package) of the User-to-User header field to enable 20 interworking with this ISDN 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 May 15, 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- 95 to-User Information (UUI) in ISDN interworking scenarios using SIP 96 [RFC3261]. Specifically, this document discusses the interworking of 97 call control related ITU-T DSS1 User-user information element Q931 98 [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 DSS1 User-user 131 information elements 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: DSS1 User-user information elements exchanged from the 143 sender's point of view during call establishment, between the DSS1 144 ALERTING and DSS1 CONNECT messages, within DSS1 USER INFORMATION 145 messages; and 147 UUS3: DSS1 User-user information elements exchanged while a call is 148 in the 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 RFC6567 156 [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 ISDN User-to-User service, as the content is 189 aligned with the protocol discriminator that appears at the start 190 of all 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 ISDN 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. The ISDN three-party 224 supplementary service is similar in many ways to conferencing, but 225 is signalled using a different mechanism. This means that on 226 clearing, the controller using UUS1 implicit does have the choice 227 of sending data to either or both remote users. Because SIP 228 conferencing cannot completely emulate the ISDN three-party 229 supplementary service at the served user, UUS1 implicit is not 230 possible. 232 Diversion: When ISDN diversion occurs, any UUS1 User-to-User data is 233 sent to the forwarded-to-user (assuming that the call meets 234 requirements for providing the service - this is impacted by the 235 explicit service only). If the type of diversion is such that the 236 call is also delivered to the forwarding user, they will also 237 receive any UUS1 User-to-User data. 239 4. Relation to SIP-T 241 A method of transport of ISDN User-to-User data is to use SIP-T 242 [RFC3372] and transport the UUI information end-to-end, as part of an 243 ISUP message or QSIG message) as a MIME body. If the SIP-T method of 244 encapsulation of ISDN instead of interworking is used, this is a 245 reasonable mechanism and does not require any extensions to existing 246 SIP-T. However, if true ISDN interworking is being done, and 247 therefore SIP-T would not otherwise be used, this approach is not 248 reasonable, because then implementation of the many elements of ISUP 249 syntax would be required to understand one element of data. Instead, 250 the better approach is to interwork the ISDN User-to-User data using 251 the native SIP UUI transport mechanism, the User-to-User header 252 field. The rest of this document describes this approach. 254 5. Transition away from ISDN 256 This interworking usage of the SIP UUI mechanism will likely begin 257 with one User Agent being an ISDN gateway while the other User Agent 258 is a native SIP endpoint. As networks transition away from ISDN, it 259 is possible that both User Agents could become native SIP endpoints. 260 In this case, there is an opportunity to transition away from this 261 ISDN usage to a more general usage of [I-D.ietf-cuss-sip-uui]. 263 The SIP UUI mechanism provides a way to achieve this transition. As 264 an endpoint moves from being an ISDN gateway to a native SIP 265 endpoint, and a future package for some form of enhanced UUI has been 266 standardized, the endpoint can carry the UUI data both as ISDN and as 267 the future package in parallel, and in the same messages or in 268 different messages depending on the needs of the application. This 269 will permit the other endpoint to use the UUI according to the ISDN 270 UUI package if it is an ISDN gateway or the future package if it is a 271 native SIP endpoint. 273 6. ISDN Usage of the User-to-User Header Field 275 This document defines the package for the ISDN interworking of UUI 276 which is to interoperate with ISDN User-to-User Signaling (UUS), a 277 supplementary service in which the user is able to send/receive a 278 limited amount of information to/from another ISDN user over the 279 signalling channel in association with a call to the other ISDN user. 281 Two examples of ISDN UUI with redirection (transfer and diversion) 282 are defined in [ANSII] and [ETSI]. 284 One objective of the design of this package has been to keep the 285 functionality at the interworking point as simple as possible. As a 286 result there is also only one encoding value specified. 287 Responsibility for respecting the limits has been transferred to the 288 end UA. If an interworking point is reached, and the limitations of 289 the ISDN (see section 3.1) are not met, then the UUI data will not be 290 transferred, although the SIP request will otherwise be interworked. 291 This is rather than have the interworking point attempt to resolve 292 the non- compliance with the limitations of ISDN. 294 The general principals of this package of the UUI mechanism are 295 therefore as follows: 297 That the sending application is expected to limit their sending 298 requirements to the subset provided by the ISDN User-to-User 299 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-to-User data into the ISDN SETUP message (when discard 323 occurs) will result in the service being unavailable for the 324 remainder of 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 UUI package, if the "purpose" header 356 field is included, the UAC MUST set the User-to-User "purpose" header 357 field parameter to "isdn-uui". The UAC MUST NOT include more than 358 one 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 User-to-User service, 383 the service is UUS1 implicit, the inclusion of the "uui" option tag 384 in a Supported header field conveys no additional information over 385 and above the presence, in the INVITE request, of the User-to-User 386 header field with the "purpose" header field parameter set to "isdn- 387 uui". 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 UUI package, the UAS SHOULD 420 set 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 UUI package, if the "purpose" header 426 field is included, the UAS MUST set the User-to-User "purpose" header 427 field parameter to "isdn-uui". The UAS MUST NOT include more than 428 one User-to-User header field for this package in any SIP request or 429 response. 431 The "isdn-interwork" value for "purpose" header field parameter was 432 used in Internet-Drafts that have led to the publication of the 433 present document. Although these documents had no other status than 434 "work in progress", this value is implemented by some vendors. While 435 not defined by this document, implementations could find it useful 436 for interoperability purposes to support parsing and interpreting 437 "isdn- 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 internetworking 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 ISDN 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 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 [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]. However, 607 since this capability is designed to interwork with the ISDN, the 608 general security considerations of SIP to ISUP (ISDN User Part) 609 interworking defined in [RFC3398] apply. Any SIP/PSTN gateway 610 implementing the ISDN User-to-User service should not blindly trust 611 ISUP from the PSTN. In general, the overlying use case will define 612 the security measures required. The underlying User-to-User header 613 field extension provides a number of tools that can meet certain 614 security requirements. 616 Information that might otherwise reveal private information about an 617 individual, or where a level of authenticity needs to be guaranteed, 618 may need a higher level of protection, and may indeed not be suitable 619 for this package, particularly taking into account the statement in 620 the following paragraph. 622 As this capability is defined to interwork with the ISDN, if the ISDN 623 forms part of the route, any usage needs to be aware that the 624 security level of the ISDN service may be lower than the security of 625 the SIP service. The ISDN security is itself not definable on an 626 end-to-end basis, and exists on a hop-by-hop basis. This can be high 627 in some places (e.g. it can require physical access to a secure 628 building) and in other places it can be low (e.g. the point where an 629 ISDN access enters a building). If this level of security is not 630 sufficient, then either a different package, or indeed, a different 631 method of data transfer, needs to be selected by the application 632 user. 634 15. Acknowledgments 636 Joanne McMillen was a major contributor and co-author of earlier 637 versions of this document. 639 Thanks to Spencer Dawkins, Vijay Gurbani, Laura Liess, and Roland 640 Jesske for their reviews of this document. The authors wish to thank 641 Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, 642 Mahalingam Mani and Celine Serrut-Valette for their comments. 644 The death of Francois Audet occurred before this document was 645 finalised, and the authors would like to identify the significant 646 contribution of Francois to this and a number of important RFCs, and 647 to express their condolences to his family. It was always a pleasure 648 to work with Francois. 650 16. References 652 16.1. Normative References 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, March 1997. 657 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 658 A., Peterson, J., Sparks, R., Handley, M., and E. 659 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 660 June 2002. 662 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 663 for Telephones (SIP-T): Context and Architectures", 664 BCP 63, RFC 3372, September 2002. 666 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 667 "Indicating User Agent Capabilities in the Session 668 Initiation Protocol (SIP)", RFC 3840, August 2004. 670 [I-D.ietf-cuss-sip-uui] 671 Johnston, A. and J. Rafferty, "A Mechanism for 672 Transporting User to User Call Control Information in 673 SIP", draft-ietf-cuss-sip-uui-17 (work in progress), 674 June 2014. 676 [Q931] "ITU-T Recommendation Q.931: Digital subscriber Signalling 677 System No. 1 - Network layer; ISDN user-network interface 678 layer 3 specification for basic call control", 679 ITU-T http://www.itu.int/rec/T-REC-Q.931-199805-I/en. 681 [RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, 682 "Integrated Services Digital Network (ISDN) User Part 683 (ISUP) to Session Initiation Protocol (SIP) Mapping", 684 RFC 3398, December 2002. 686 16.2. Informative References 688 [Q957.1] "ITU-T Recommendation Q.957.1: Digital subscriber 689 Signalling System No. 1 - Stage 3 description for 690 supplementary services using DSS 1; Stage 3 description 691 for additional information transfer supplementary services 692 using DSS 1: User-to-User Signalling (UUS)", 693 ITU-T http://www.itu.int/rec/T-REC-Q.957.1-199607-I. 695 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part 696 formats and codes", 697 ITU-T http://www.itu.int/rec/T-REC-Q.931-199805-I/en. 699 [RFC6567] Johnston, A. and L. Liess, "Problem Statement and 700 Requirements for Transporting User-to-User Call Control 701 Information in SIP", RFC 6567, April 2012. 703 [ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services 704 Digital Network (ISDN)-Explicit Call Transfer 705 Supplementary Service", ANSI T1.643-1995 . 707 [ETSI] ""ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services 708 Digital Network (ISDN); Diversion supplementary 709 services"", ETSI ETF 300 207-1 . 711 Authors' Addresses 713 Keith Drage (editor) 714 Alcatel-Lucent 715 Quadrant, Stonehill Green, Westlea 716 Swindon 717 UK 719 Email: keith.drage@alcatel-lucent.com 721 Alan Johnston 722 Avaya 723 St. Loius, MO 724 US 726 Email: alan.b.johnston@gmail.com