idnits 2.17.1 draft-drage-cuss-sip-uui-isdn-01.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 571 has weird spacing: '...ats and codes...' -- The document date (September 20, 2011) is 4599 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 498, 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: March 23, 2012 Avaya 6 September 20, 2011 8 Interworking ISDN Call Control User Information with SIP 9 draft-drage-cuss-sip-uui-isdn-01 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 March 23, 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 . . . . . . . . . 7 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 77 15. Changes since previous versions . . . . . . . . . . . . . . . 12 78 16. Normative References . . . . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in BCP 14, RFC 2119 86 [RFC2119]. 88 2. Overview 90 This document describes a usage of the User-to-User header field 91 defined in [johnston-cuss-sip-uui] to enable the transport of User to 92 User Information (UUI) in ISDN interworking scenarios using SIP 93 [RFC3261]. Specifically, this document discuss the interworking of 94 call control related ITU-T DSS1 User-user information element [Q931], 95 [Q957.1] and ITU-T Q.763 User-to-user information parameter [Q763] 96 data in SIP. UUI is widely used in the PSTN today in contact centers 97 and call centers which are transitioning away from ISDN to SIP. 99 This usage is not limited to scenarios where interworking will occur. 100 Rather it describes a usage where interworking is possible if 101 interworking is met. That does not preclude its usage directly 102 between two SIP terminals. 104 3. Summary of the ISDN User-to-User Service 106 3.1. The service 108 ISDN defines a number of related services. Firstly there is a user 109 signalling bearer service, which uses the information elements / 110 parameters in the signalling channel to carry the data, and does not 111 establish a related circuit-switched connection. For DSS1, this is 112 specified in ITU-T Recommendation Q.931 section 3.3 and section 7 113 [Q931]. It also defines a user-to-user signalling supplementary 114 service, which uses the information elements / parameters in the 115 signalling channel to carry additional data, but which is used in 116 conjunction with the establishment of a related circuit-switched 117 connection. This reuses the same information elements / parameters 118 as the user signalling bearer service, with the addition of other 119 signalling information, and for DSS1 this is specified in ITU-T 120 Recommendation Q.957.1 [Q957.1]. 122 ISDN defines three variants of the user-to-user signalling 123 supplementary service as follows: 125 UUS1: User-to-user information exchanged during the setup and 126 clearing phases of a call, by transporting User-to-user 127 information element within call control messages. This in itself 128 has two subvariants, UUS1 implicit and UUS1 explicit. UUS1 129 explicit uses additional supplementary service control information 130 to control the request and granting of the service, as in USS2 and 131 UUS3. In UUS1 implicit, it is the presence of the user signalling 132 data itself that constitutes the request for the service. UUS1 133 explicit as a result also allows the requester to additionally 134 specify whether the parallel circuit-switched connection should 135 proceed if the UUS1 service cannot be provided (preferred or 136 required). 138 UUS2: User-to-user information exchanged from the sender's point of 139 view during call establishment, between the DSS1 ALERTING and DSS1 140 CONNECT messages, within DSS1 USER INFORMATION messages; and 142 UUS3: User-to-user information exchanged while a call is in the 143 Active state, within DSS1 USER INFORMATION messages. 145 The service is always requested by the calling user. 147 This document defines only the application of the ISDN UUS1 implicit 148 supplementary service to interworking scenarios, this being the most 149 widely deployed and used of the various ISDN user-to-user services, 150 and indeed the one that matches the requirements specified in 151 draft-johnston-cuss-sip-uui-reqs. 153 The ISDN UUS1 service has the following additional characteristics as 154 to the data that can be transported: 156 The maximum number of octets of user information that can be 157 transported in 128 octets. It is noted that some early ISDN 158 implementations had a limitation of 32 octets, but it is 159 understood that these are not currently deployed. While this 160 application does not prohibit longer data fields, the mechanism at 161 any interworking point is to discard data elements that are too 162 long to handle. The handled length can normally be assumed to be 163 128 octets. 165 The content of the user information octets is described by a 166 single octet protocol discriminator (see table 4-26 of ITU-T 167 Recommendation Q.931) [Q931]. That protocol descriminator may 168 describe the protocol used within the user data, the structure of 169 the user data, or leave it entirely open. Note that not all 170 values within the protocol discriminator necessarily make sense 171 for use in the user to user service, as the content is aligned 172 with the protocol discriminator that appears at the start of all 173 DSS1 messages (see table 4-1 of ITU-T Recommendation Q.931) 174 [Q931]. The protocol discriminator value has no impact on the 175 interworking capability. 177 Only a single user information package can be transported in each 178 message. 180 The ISDN service works without encryption or integrity protection. 181 The user trusts the intermediate network elements, and therefore 182 the operator of those elements, not to modify the data, and to 183 deliver all the data to the remote user. On a link by link basis, 184 message contents are protected at layer 2 by standard CRC 185 mechanisms - this allows loss on a link level basis to be 186 detected, but does not guard against fraudulent attacks on the 187 link itself. This does not prevent the use of additional 188 encryption or integrity protection within the payload itself, 189 although the limit on the size of the payload (128 octets) will 190 restrict this. 192 3.2. Impacts of the ISDN service on SIP operation 194 The ISDN service has the following impacts that need to be understood 195 within the SIP environment. 197 Call transfer ISDN call transfer cancels all user-to-user 198 supplementary services. In the ISDN, if user-to-user data is 199 required after call transfer, then UUS3 has to be renegotiated, 200 which is not provided by this SIP extension. The impact of this 201 restriction on the SIP environment is that UUI header fields 202 cannot be exchanged in transactions clearing down the SIP dialog 203 after call transfer has occurred. 205 Conference ISDN conferencing allows the user to still exchange user- 206 to-user data after the conference is created. As far as UUS1 is 207 concerned, this means that when an individual party clears, those 208 clearing messages can still contain user-to-user data. As a 209 conferee this is sent to the conference controller. As the 210 conference controller, as this effectively clears the conference, 211 it can be broadcast to all conferees, or sent to individual 212 conferees [OPEN ISSUE - CHECK THIS IN THE PROTOCOL - DOES IT 213 REQUIRE EXPLICIT]. 215 The ISDN three-party supplementary service is similar in many ways 216 to conferencing, but is signalled using a different mechanism. 217 This means that on clearing, the controller using UUS1 implicit 218 does have the choice of sending data to either or both remote 219 users. 221 Diversion When ISDN diversion occurs, any UUS1 user-to-user data is 222 sent to the forwarded-to-user (assuming that the call meets 223 requirements for providing the service - this is impacted by the 224 explicit service only). If the type of diversion is such that the 225 call is also delivered to the forwarding user, they will also 226 receive any UUS1 user-to-user data. 228 Contributors note: The above list needs to be studied further in 229 regard to private ISDN service definitions, e.g. for the interworking 230 of SIP and QSIG. 232 4. Relation to SIP-T 234 A method of transport of ISDN UUI is to use SIP-T [RFC3372] and 235 transport the UUI information end-to-end, as part of an ISUP message 236 or QSIG message) as a MIME body. If the SIP-T method of 237 encapsulation of ISDN instead of interworking is used, this is a 238 reasonable mechanism and does not require any extensions to existing 239 SIP-T. However, if true ISDN interworking is being done, this 240 approach is not reasonable. Instead, the better approach is to 241 interwork the ISDN UUI using the native SIP UUI transport mechanism, 242 the User-to-User header field. The rest of this document describes 243 this approach. 245 5. Transition away from ISDN 247 This interworking usage of the SIP UUI mechanism will likely begin 248 with one User Agent being an ISDN gateway while the other User Agent 249 is a native SIP endpoint. As networks transition away from ISDN, it 250 is possible that both User Agents could become native SIP endpoints. 251 In this case, there is an opportunity to transition away from this 252 ISDN usage to a more general usage of [johnston-cuss-sip-uui]. This 253 will be possible when both endpoints are aware of the actual 254 application using the UUI. 256 The SIP UUI mechanism provides a way to achieve this transition. As 257 an endpoint moves from being an ISDN gateway to a native SIP 258 endpoint, and a usage application for the UUI has been standardized, 259 the endpoint can carry the UUI both as ISDN and application encoding. 260 This will permit the other endpoint to utlize the UUI if it is an 261 ISDN gateway or a native SIP endpoint. When all the endpoints have 262 moved away from ISDN, the ISDN encoding usage can be discontinued. 264 6. ISDN Usage of the User-to-User Header Field 266 This document defines the purpose usage of the ISDN interworking 267 application of UUI which is to interoperate with ISDN User to User 268 Signaling (UUS), a supplementary service in which the user is able to 269 send/receive a limited amount of information to/from another ISDN 270 user over the signalling channel in association with a call to the 271 other ISDN user.. 273 Two examples of ISDN UUI with redirection (transfer and diversion) 274 are defined in [ANSII] and [ETSI]. 276 The general principals of this application of the UUI mechanism are 277 as follows: 279 That the sending application is expected limit their sending 280 requirements to the subset provided by the ISDN UUI service. 282 That the SIP UA will not allow the reception of more that one 283 User-to-User header field of the "isdn-uui" application in the 284 same SIP request or response, and will only allow it in a request 285 or response of the appropriate method (INVITE or BYE). What 286 happens to User-to-User header fields relating to different 287 application is outside the scope of this document. 289 That an interworking point trying to interwork application data 290 that is too long will discard the application data, but proceed 291 with the interworking. There is no notification of such discard 292 back to the sending user. If the SIP user knows that it is 293 interworking with the ISDN, then the UUI application at the SIP 294 endpoint should limit its communication to 128 octet packets, in 295 the knowledge that discard will occur if it does not. The UUI 296 application at the SIP endpoint has complete control over what 297 occurs. It should be noted that this was exactly the envisaged 298 operation when early ISDN implementations that only supported 32 299 octets interworked with those supporting 128 octets. It also 300 corresponds to the interworking with ISDNs that do not support the 301 supplementary service at all, as discard will occur in these 302 circumstances as well. Note that failure to include the user-user 303 data into the ISDN SETUP message (when discard occurs) will result 304 in the service being unavailable for the remainder of the call 305 when UUS1 implicit operation is used. 307 7. UAC requirements 309 The UAC MUST meet the requirements of [johnston-cuss-sip-uui] in 310 addition to the requirements defined in this document. 312 The UAC MUST only use this application of the UUI mechanism extension 313 in association with the initial INVITE method and BYE method relating 314 to an INVITE dialog. Usage on transactions associated with any other 315 type of dialog, or on methods not associated with a dialog is 316 precluded. 318 If the UAC wishes to user or permit the sending of UUI data at any 319 point in the dialog, the UAC MUST include in the INVITE request for 320 that dialog a User-to-User header field with an "app" header field 321 parameter set to "isdn-uui". This initial header field constitutes 322 the implicit request to use the UUI service, and is therefore 323 included even when there is no data to send at that point in time. 325 The UAC MUST NOT include the User-to-User header field with an "app" 326 header field parameter set to "isdn-uui" in any message of an INVITE 327 dialog if the original INVITE request did not include the User-to- 328 User header field with an "app" header field parameter set to "isdn- 329 uui" 331 When sending UUI for the ISDN application, the UAC MUST set the User- 332 to-User "app" header field parameter to "isdn-uui". The UAC MUST NOT 333 include more than one User-to-User header field for this application 334 in any SIP request or response. 336 When sending UUI, the sending application MUST include a protocol 337 discriminator octet, conforming to table 4-26 of ITU-T Recommendation 338 Q.931 [Q931] as the first octet of the payload information. 340 When receiving UUI, when multiple User-to-User header fields are 341 received in the same response with the "app" header field parameter 342 to "isdn-uui", the UAS MUST discard all these header fields. There 343 are no mechanisms for determining which was the intended data packet 344 so all are discarded. 346 The application designer will need to take into account the ISDN 347 service restrictions; failure to do so can result in information 348 being discarded at any interworking point with the ISDN. This 349 document makes no further normative requirements based on those 350 constraints, because those constraints may vary from one ISDN to 351 another. It is reasonable to expect that a limitation of 128 octets 352 can be imposed by the ISDN, and therefore payloads longer than this 353 will never reach the destination if such interworking occurs. 355 [johnston-cuss-sip-uui] defines a "uui" option tag for use with the 356 UUI mechanism extension. Because for the ISDN UUI service, the 357 service is service 1 implicit, the inclusion of the "uui" option tag 358 in a Supported header field conveys no additional information over 359 and above the presence of the User-to-User header field with the 360 "app" header field parameter to "isdn-uui" in the INVITE request. 361 While there is no harm in including the "uui" option tag, and 362 strictly it should be included if the extension is supported, it 363 performs no function. The presence of the "uui" option tag in the 364 Require header field of an INVITE request will cause the request to 365 fail if it reaches a UAS or ISDN interworking gateway that does not 366 support this extension; such a usage is not precluded although it 367 does not form part of the application. 369 8. UAS requirements 371 The UAS MUST meet the requirements of [johnston-cuss-sip-uui] in 372 addition to the requirements defined in this document. 374 The UAS MUST only use this application of the UUI mechanism extension 375 in association with the initial INVITE method and BYE method relating 376 to an INVITE dialog. Usage on transactions associated with any other 377 type of dialog, or on methods not associated with a dialog is 378 precluded. 380 The UAS MUST NOT include the User-to-User header field with an "app" 381 header field parameter set to "isdn-uui" in any message of an INVITE 382 dialog if the original INVITE request did not include the User-to- 383 User header field with an "app" header field parameter set to "isdn- 384 uui" 386 The UAS MAY include the User-to-User header field in responses to the 387 INVITE request, or subsequent BYE requests or responses within the 388 dialog, only where the original INVITE request included a User-to- 389 User header field with the "app" header field parameter to "isdn- 390 uui". When sending UUI for the ISDN application, the UAS MUST set 391 the User-to-User "app" header field parameter to "isdn-uui". The UAS 392 MUST NOT include more than one User-to-User header field for this 393 application in any SIP request or response. 395 Where the UAS is acting as a redirect server, the UAS MUST NOT 396 include the User-to-User header field in the header URI parameter in 397 a 3xx response to an incoming request. 399 When receiving UUI, when a User-to-User header field is received in a 400 request that is not from the originating user with the "content" 401 header field parameter to "isdn-uui", the UAC MUST discard this 402 header fields. 404 When receiving UUI, when multiple User-to-User header fields are 405 received from the originating user in the same request with the 406 "content" header field parameter to "isdn-uui", the UAC MUST discard 407 all these header fields. There are no mechanisms for determining 408 which was the intended data packet so all are discarded. 410 9. UUI contents 412 These requirements apply when the "app" header field parameter is set 413 to "isdn-uui". Processing for User-to-User header fields sent or 414 received with values other than this value are outside the scope of 415 this document, and the appropriate application document for that 416 value applies. 418 When sending UUI, the sending application MAY, but need not, include 419 a "content" header field with a value set to "isdn-uui". A receiving 420 application MUST ignore a received User-to-User header field if the 421 "content" header field parameter is present and the value is some 422 other value that "isdn-uui". 424 When sending UUI, the sending application MAY, but need not, include 425 an "encoding" header field with a value set to "hex". A receiving 426 application MUST ignore a received User-to-User header field if the 427 "encoding" header field parameter is present and the value is some 428 other value that "hex". 430 When sending UUI, the sending application MUST include a protocol 431 discriminator octet, conforming to table 4-26 of ITU-T Recommendation 432 Q.931 [Q931] as the first octet of the payload information. It is up 433 to the receiving application what it does with this value. 435 10. Considerations for ISDN interworking gateways 437 ISDN interworking gateways MUST support the requirements defined for 438 UAS and UAC operation. 440 ISDN interworking gateways MUST support only the "isdn-uui" 441 application on dialogs that are interworked. 443 When mapping data content from the ISDN to the SIP signalling, or 444 from SIP signalling to the ISDN, the gateway needs to assume that all 445 content is octet structured binary, irrespective of the value of the 446 received protocol discriminator. There are no requirements in the 447 ISDN to ensure that the content matches the value of the protocol 448 discriminator, and it is for the application usage to sort out any 449 discrepancy. The same applies to the ISDN protocol discrimination 450 defined table 4-26 of ITU-T Recommendation Q.931 [Q931] as the first 451 octet of the payload information; the interworking gateway will not 452 perform any additional checking of this value. 454 [johnston-cuss-sip-uui] defines a "uui" option tag for use with the 455 UUI mechanism extension. The option tag is not interworked at an 456 ISDN interworking gateway. The ISDN interworking gateways MUST NOT 457 take the omission of the "uui" option tag in a received INVITE 458 request to indicate that interworking of a received header field is 459 not to be performed. 461 11. Coding requirements 463 This document defines "isdn-uui" as a new value of the User-to-User 464 "app" header field parameter. 466 This document defines "isdn-uui" as a new value of the User-to-User 467 "content" header field parameter. 469 12. IANA Considerations 471 This document adds the following row to the "UUI application values" 472 section of the SIP parameter registry: 474 Value: isdn-uui 476 Meaning: The associated application is being used with constraints 477 suitable for interworking with the ISDN user-to-user service, and 478 therefore can be interworked at ISDN gateways. 480 Reference: RFCXXXX 482 Contact: 484 This document adds the following row to the "UUI content values" 485 section of the SIP parameter registry: 487 Value: isdn-uui 489 Meaning: The associated contents conforms to the content 490 associated with the ISDN user-to-user service. In the presence of 491 the "app" header field parameter set to "isdn-uui" this is the 492 default meaning and therefore need not be included in this case. 494 Reference: RFCXXXX 496 Contact: 498 Editor's Note: [RFCXXXX] should be replaced with the designation of 499 this document. 501 13. Security Considerations 503 This document contains no specific requirements in regard to 504 security. The overlying use case will define the security measures 505 required. The underlying user-to-user extension provides a number of 506 tools that can meet certain security requirements. As a level of 507 guidance, data that is used to assist in selecting which SIP UA 508 should respond to the call would not be expected to carry any higher 509 level of security than a media feature tag. Information that might 510 otherwise reveal private information about an individual, or where a 511 level of authenticity needs to be guaranteed, may need a higher level 512 of protection, and may indeed not be suitable for this application, 513 particularly taking into account the statement in the following 514 paragraph. 516 As this capability to is defined to interwork with the ISDN, if the 517 ISDN forms part of the route, any usage needs to assume that the 518 security level of the ISDN is the highest level of security 519 available. As the ISDN security is itself not definable on an end- 520 to-end basis, this can be an unknown quantity. This is because ISDN 521 security exists on a hop-by-hop basis, and is only as secure as the 522 least secure component. This can be high in some places (e.g. it can 523 require physical access to a secure building) and in other places it 524 can be low (e.g. the point where an ISDN access enters a building). 525 If this level of security is not sufficient, then either a different 526 user-to-user application, or indeed, a different method of data 527 transfer, needs to be selected by the application user. 529 14. Acknowledgements 531 Joanne McMillen was a major contributor and co-author of earlier 532 versions of this document. 534 Thanks to Spencer Dawkins, Vijay Gurbani, and Laura Liess for their 535 review of earlier versions of this document. The authors wish to 536 thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen 537 Jennings, and Mahalingam Mani for their comments. 539 15. Changes since previous versions 541 Note to RFC editor: This section is to be deleted before final 542 publication. 544 Changes since made in the creation of the -01 version from the -00 545 version. 547 Closure of a number of open issues identified in the -00 version 548 and the creation of appropriate procedures for the UAC, the UAS, 549 and the ISDN interworking gateway. 551 16. Normative References 553 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 554 A., Peterson, J., Sparks, R., Handley, M., and E. 555 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 556 June 2002. 558 [Q931] "ITU-T Recommendation Q.931: Digital subscriber Signalling 559 System No. 1 - Network layer; ISDN user-network interface 560 layer 3 specification for basic call control", 561 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 563 [Q957.1] "ITU-T Recommendation Q.957.1: Digital subscriber 564 Signalling System No. 1 - Stage 3 description for 565 supplementary services using DSS 1; Stage 3 description 566 for additional information transfer supplementary services 567 using DSS 1: User-to-User Signalling (UUS)", 568 http://www.itu.int/rec/T-REC-Q.957.1-199607-I . 570 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part 571 formats and codes", 572 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 574 [ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services 575 Digital Network (ISDN)-Explicit Call Transfer 576 Supplementary Service". 578 [ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services 579 Digital Network (ISDN); Diversion supplementary 580 services". 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, March 1997. 585 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 586 for Telephones (SIP-T): Context and Architectures", 587 BCP 63, RFC 3372, September 2002. 589 [johnston-cuss-sip-uui-reqs] 590 Johnston, A., McMillen, J., and L. Liess, "Problem 591 Statement and Requirements for Transporting User to User 592 Call Control Information in SIP", 593 draft-johnston-cuss-sip-uui-reqs-00 . 595 [johnston-cuss-sip-uui] 596 Johnston, A. and J. Rafferty, "A Mechanism for 597 Transporting User to User Call Control Information in 598 SIP", draft-johnston-cuss-sip-uui-00 . 600 Authors' Addresses 602 Keith Drage (editor) 603 Alcatel-Lucent 604 Quadrant, Stonehill Green, Westlea 605 Swindon 606 UK 608 Email: keith.drage@alcatel-lucent.com 610 Alan Johnston 611 Avaya 612 St. Louis, MO 63124 613 United States 615 Email: alan.b.johnston@gmail.com