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