Network Working Group K. Drage, Ed. Internet-Draft Alcatel-Lucent Intended status: Standards Track A. Johnston Expires: March 23, 2012 Avaya September 20, 2011 Interworking ISDN Call Control User Information with SIP draft-drage-cuss-sip-uui-isdn-01 Abstract The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to- end transparency. This document defines a usage of the User-to-User header field to enable interworking with this ISDN service. This document is covers the interworking with both public ISDN and private ISDN capabilities, so the interworking with QSIG will also be addressed. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 23, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Drage & Johnston Expires March 23, 2012 [Page 1] Internet-Draft SIP UUI for CC September 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Summary of the ISDN User-to-User Service . . . . . . . . . . . 3 3.1. The service . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Impacts of the ISDN service on SIP operation . . . . . . . 5 4. Relation to SIP-T . . . . . . . . . . . . . . . . . . . . . . 6 5. Transition away from ISDN . . . . . . . . . . . . . . . . . . 6 6. ISDN Usage of the User-to-User Header Field . . . . . . . . . 7 7. UAC requirements . . . . . . . . . . . . . . . . . . . . . . . 7 8. UAS requirements . . . . . . . . . . . . . . . . . . . . . . . 9 9. UUI contents . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Considerations for ISDN interworking gateways . . . . . . . . 10 11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 11 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 15. Changes since previous versions . . . . . . . . . . . . . . . 12 16. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Drage & Johnston Expires March 23, 2012 [Page 2] Internet-Draft SIP UUI for CC September 2011 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. Overview This document describes a usage of the User-to-User header field defined in [johnston-cuss-sip-uui] to enable the transport of User to User Information (UUI) in ISDN interworking scenarios using SIP [RFC3261]. Specifically, this document discuss the interworking of call control related ITU-T DSS1 User-user information element [Q931], [Q957.1] and ITU-T Q.763 User-to-user information parameter [Q763] data in SIP. UUI is widely used in the PSTN today in contact centers and call centers which are transitioning away from ISDN to SIP. This usage is not limited to scenarios where interworking will occur. Rather it describes a usage where interworking is possible if interworking is met. That does not preclude its usage directly between two SIP terminals. 3. Summary of the ISDN User-to-User Service 3.1. The service ISDN defines a number of related services. Firstly there is a user signalling bearer service, which uses the information elements / parameters in the signalling channel to carry the data, and does not establish a related circuit-switched connection. For DSS1, this is specified in ITU-T Recommendation Q.931 section 3.3 and section 7 [Q931]. It also defines a user-to-user signalling supplementary service, which uses the information elements / parameters in the signalling channel to carry additional data, but which is used in conjunction with the establishment of a related circuit-switched connection. This reuses the same information elements / parameters as the user signalling bearer service, with the addition of other signalling information, and for DSS1 this is specified in ITU-T Recommendation Q.957.1 [Q957.1]. ISDN defines three variants of the user-to-user signalling supplementary service as follows: Drage & Johnston Expires March 23, 2012 [Page 3] Internet-Draft SIP UUI for CC September 2011 UUS1: User-to-user information exchanged during the setup and clearing phases of a call, by transporting User-to-user information element within call control messages. This in itself has two subvariants, UUS1 implicit and UUS1 explicit. UUS1 explicit uses additional supplementary service control information to control the request and granting of the service, as in USS2 and UUS3. In UUS1 implicit, it is the presence of the user signalling data itself that constitutes the request for the service. UUS1 explicit as a result also allows the requester to additionally specify whether the parallel circuit-switched connection should proceed if the UUS1 service cannot be provided (preferred or required). UUS2: User-to-user information exchanged from the sender's point of view during call establishment, between the DSS1 ALERTING and DSS1 CONNECT messages, within DSS1 USER INFORMATION messages; and UUS3: User-to-user information exchanged while a call is in the Active state, within DSS1 USER INFORMATION messages. The service is always requested by the calling user. This document defines only the application of the ISDN UUS1 implicit supplementary service to interworking scenarios, this being the most widely deployed and used of the various ISDN user-to-user services, and indeed the one that matches the requirements specified in draft-johnston-cuss-sip-uui-reqs. The ISDN UUS1 service has the following additional characteristics as to the data that can be transported: The maximum number of octets of user information that can be transported in 128 octets. It is noted that some early ISDN implementations had a limitation of 32 octets, but it is understood that these are not currently deployed. While this application does not prohibit longer data fields, the mechanism at any interworking point is to discard data elements that are too long to handle. The handled length can normally be assumed to be 128 octets. The content of the user information octets is described by a single octet protocol discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931]. That protocol descriminator may describe the protocol used within the user data, the structure of the user data, or leave it entirely open. Note that not all values within the protocol discriminator necessarily make sense for use in the user to user service, as the content is aligned with the protocol discriminator that appears at the start of all Drage & Johnston Expires March 23, 2012 [Page 4] Internet-Draft SIP UUI for CC September 2011 DSS1 messages (see table 4-1 of ITU-T Recommendation Q.931) [Q931]. The protocol discriminator value has no impact on the interworking capability. Only a single user information package can be transported in each message. The ISDN service works without encryption or integrity protection. The user trusts the intermediate network elements, and therefore the operator of those elements, not to modify the data, and to deliver all the data to the remote user. On a link by link basis, message contents are protected at layer 2 by standard CRC mechanisms - this allows loss on a link level basis to be detected, but does not guard against fraudulent attacks on the link itself. This does not prevent the use of additional encryption or integrity protection within the payload itself, although the limit on the size of the payload (128 octets) will restrict this. 3.2. Impacts of the ISDN service on SIP operation The ISDN service has the following impacts that need to be understood within the SIP environment. Call transfer ISDN call transfer cancels all user-to-user supplementary services. In the ISDN, if user-to-user data is required after call transfer, then UUS3 has to be renegotiated, which is not provided by this SIP extension. The impact of this restriction on the SIP environment is that UUI header fields cannot be exchanged in transactions clearing down the SIP dialog after call transfer has occurred. Conference ISDN conferencing allows the user to still exchange user- to-user data after the conference is created. As far as UUS1 is concerned, this means that when an individual party clears, those clearing messages can still contain user-to-user data. As a conferee this is sent to the conference controller. As the conference controller, as this effectively clears the conference, it can be broadcast to all conferees, or sent to individual conferees [OPEN ISSUE - CHECK THIS IN THE PROTOCOL - DOES IT REQUIRE EXPLICIT]. The ISDN three-party supplementary service is similar in many ways to conferencing, but is signalled using a different mechanism. This means that on clearing, the controller using UUS1 implicit does have the choice of sending data to either or both remote users. Drage & Johnston Expires March 23, 2012 [Page 5] Internet-Draft SIP UUI for CC September 2011 Diversion When ISDN diversion occurs, any UUS1 user-to-user data is sent to the forwarded-to-user (assuming that the call meets requirements for providing the service - this is impacted by the explicit service only). If the type of diversion is such that the call is also delivered to the forwarding user, they will also receive any UUS1 user-to-user data. Contributors note: The above list needs to be studied further in regard to private ISDN service definitions, e.g. for the interworking of SIP and QSIG. 4. Relation to SIP-T A method of transport of ISDN UUI is to use SIP-T [RFC3372] and transport the UUI information end-to-end, as part of an ISUP message or QSIG message) as a MIME body. If the SIP-T method of encapsulation of ISDN instead of interworking is used, this is a reasonable mechanism and does not require any extensions to existing SIP-T. However, if true ISDN interworking is being done, this approach is not reasonable. Instead, the better approach is to interwork the ISDN UUI using the native SIP UUI transport mechanism, the User-to-User header field. The rest of this document describes this approach. 5. Transition away from ISDN This interworking usage of the SIP UUI mechanism will likely begin with one User Agent being an ISDN gateway while the other User Agent is a native SIP endpoint. As networks transition away from ISDN, it is possible that both User Agents could become native SIP endpoints. In this case, there is an opportunity to transition away from this ISDN usage to a more general usage of [johnston-cuss-sip-uui]. This will be possible when both endpoints are aware of the actual application using the UUI. The SIP UUI mechanism provides a way to achieve this transition. As an endpoint moves from being an ISDN gateway to a native SIP endpoint, and a usage application for the UUI has been standardized, the endpoint can carry the UUI both as ISDN and application encoding. This will permit the other endpoint to utlize the UUI if it is an ISDN gateway or a native SIP endpoint. When all the endpoints have moved away from ISDN, the ISDN encoding usage can be discontinued. Drage & Johnston Expires March 23, 2012 [Page 6] Internet-Draft SIP UUI for CC September 2011 6. ISDN Usage of the User-to-User Header Field This document defines the purpose usage of the ISDN interworking application of UUI which is to interoperate with ISDN User to User Signaling (UUS), a supplementary service in which the user is able to send/receive a limited amount of information to/from another ISDN user over the signalling channel in association with a call to the other ISDN user.. Two examples of ISDN UUI with redirection (transfer and diversion) are defined in [ANSII] and [ETSI]. The general principals of this application of the UUI mechanism are as follows: That the sending application is expected limit their sending requirements to the subset provided by the ISDN UUI service. That the SIP UA will not allow the reception of more that one User-to-User header field of the "isdn-uui" application in the same SIP request or response, and will only allow it in a request or response of the appropriate method (INVITE or BYE). What happens to User-to-User header fields relating to different application is outside the scope of this document. That an interworking point trying to interwork application data that is too long will discard the application data, but proceed with the interworking. There is no notification of such discard back to the sending user. If the SIP user knows that it is interworking with the ISDN, then the UUI application at the SIP endpoint should limit its communication to 128 octet packets, in the knowledge that discard will occur if it does not. The UUI application at the SIP endpoint has complete control over what occurs. It should be noted that this was exactly the envisaged operation when early ISDN implementations that only supported 32 octets interworked with those supporting 128 octets. It also corresponds to the interworking with ISDNs that do not support the supplementary service at all, as discard will occur in these circumstances as well. Note that failure to include the user-user data into the ISDN SETUP message (when discard occurs) will result in the service being unavailable for the remainder of the call when UUS1 implicit operation is used. 7. UAC requirements The UAC MUST meet the requirements of [johnston-cuss-sip-uui] in addition to the requirements defined in this document. Drage & Johnston Expires March 23, 2012 [Page 7] Internet-Draft SIP UUI for CC September 2011 The UAC MUST only use this application of the UUI mechanism extension in association with the initial INVITE method and BYE method relating to an INVITE dialog. Usage on transactions associated with any other type of dialog, or on methods not associated with a dialog is precluded. If the UAC wishes to user or permit the sending of UUI data at any point in the dialog, the UAC MUST include in the INVITE request for that dialog a User-to-User header field with an "app" header field parameter set to "isdn-uui". This initial header field constitutes the implicit request to use the UUI service, and is therefore included even when there is no data to send at that point in time. The UAC MUST NOT include the User-to-User header field with an "app" header field parameter set to "isdn-uui" in any message of an INVITE dialog if the original INVITE request did not include the User-to- User header field with an "app" header field parameter set to "isdn- uui" When sending UUI for the ISDN application, the UAC MUST set the User- to-User "app" header field parameter to "isdn-uui". The UAC MUST NOT include more than one User-to-User header field for this application in any SIP request or response. When sending UUI, the sending application MUST include a protocol discriminator octet, conforming to table 4-26 of ITU-T Recommendation Q.931 [Q931] as the first octet of the payload information. When receiving UUI, when multiple User-to-User header fields are received in the same response with the "app" header field parameter to "isdn-uui", the UAS MUST discard all these header fields. There are no mechanisms for determining which was the intended data packet so all are discarded. The application designer will need to take into account the ISDN service restrictions; failure to do so can result in information being discarded at any interworking point with the ISDN. This document makes no further normative requirements based on those constraints, because those constraints may vary from one ISDN to another. It is reasonable to expect that a limitation of 128 octets can be imposed by the ISDN, and therefore payloads longer than this will never reach the destination if such interworking occurs. [johnston-cuss-sip-uui] defines a "uui" option tag for use with the UUI mechanism extension. Because for the ISDN UUI service, the service is service 1 implicit, the inclusion of the "uui" option tag in a Supported header field conveys no additional information over and above the presence of the User-to-User header field with the Drage & Johnston Expires March 23, 2012 [Page 8] Internet-Draft SIP UUI for CC September 2011 "app" header field parameter to "isdn-uui" in the INVITE request. While there is no harm in including the "uui" option tag, and strictly it should be included if the extension is supported, it performs no function. The presence of the "uui" option tag in the Require header field of an INVITE request will cause the request to fail if it reaches a UAS or ISDN interworking gateway that does not support this extension; such a usage is not precluded although it does not form part of the application. 8. UAS requirements The UAS MUST meet the requirements of [johnston-cuss-sip-uui] in addition to the requirements defined in this document. The UAS MUST only use this application of the UUI mechanism extension in association with the initial INVITE method and BYE method relating to an INVITE dialog. Usage on transactions associated with any other type of dialog, or on methods not associated with a dialog is precluded. The UAS MUST NOT include the User-to-User header field with an "app" header field parameter set to "isdn-uui" in any message of an INVITE dialog if the original INVITE request did not include the User-to- User header field with an "app" header field parameter set to "isdn- uui" The UAS MAY include the User-to-User header field in responses to the INVITE request, or subsequent BYE requests or responses within the dialog, only where the original INVITE request included a User-to- User header field with the "app" header field parameter to "isdn- uui". When sending UUI for the ISDN application, the UAS MUST set the User-to-User "app" header field parameter to "isdn-uui". The UAS MUST NOT include more than one User-to-User header field for this application in any SIP request or response. Where the UAS is acting as a redirect server, the UAS MUST NOT include the User-to-User header field in the header URI parameter in a 3xx response to an incoming request. When receiving UUI, when a User-to-User header field is received in a request that is not from the originating user with the "content" header field parameter to "isdn-uui", the UAC MUST discard this header fields. When receiving UUI, when multiple User-to-User header fields are received from the originating user in the same request with the "content" header field parameter to "isdn-uui", the UAC MUST discard Drage & Johnston Expires March 23, 2012 [Page 9] Internet-Draft SIP UUI for CC September 2011 all these header fields. There are no mechanisms for determining which was the intended data packet so all are discarded. 9. UUI contents These requirements apply when the "app" header field parameter is set to "isdn-uui". Processing for User-to-User header fields sent or received with values other than this value are outside the scope of this document, and the appropriate application document for that value applies. When sending UUI, the sending application MAY, but need not, include a "content" header field with a value set to "isdn-uui". A receiving application MUST ignore a received User-to-User header field if the "content" header field parameter is present and the value is some other value that "isdn-uui". When sending UUI, the sending application MAY, but need not, include an "encoding" header field with a value set to "hex". A receiving application MUST ignore a received User-to-User header field if the "encoding" header field parameter is present and the value is some other value that "hex". When sending UUI, the sending application MUST include a protocol discriminator octet, conforming to table 4-26 of ITU-T Recommendation Q.931 [Q931] as the first octet of the payload information. It is up to the receiving application what it does with this value. 10. Considerations for ISDN interworking gateways ISDN interworking gateways MUST support the requirements defined for UAS and UAC operation. ISDN interworking gateways MUST support only the "isdn-uui" application on dialogs that are interworked. When mapping data content from the ISDN to the SIP signalling, or from SIP signalling to the ISDN, the gateway needs to assume that all content is octet structured binary, irrespective of the value of the received protocol discriminator. There are no requirements in the ISDN to ensure that the content matches the value of the protocol discriminator, and it is for the application usage to sort out any discrepancy. The same applies to the ISDN protocol discrimination defined table 4-26 of ITU-T Recommendation Q.931 [Q931] as the first octet of the payload information; the interworking gateway will not perform any additional checking of this value. Drage & Johnston Expires March 23, 2012 [Page 10] Internet-Draft SIP UUI for CC September 2011 [johnston-cuss-sip-uui] defines a "uui" option tag for use with the UUI mechanism extension. The option tag is not interworked at an ISDN interworking gateway. The ISDN interworking gateways MUST NOT take the omission of the "uui" option tag in a received INVITE request to indicate that interworking of a received header field is not to be performed. 11. Coding requirements This document defines "isdn-uui" as a new value of the User-to-User "app" header field parameter. This document defines "isdn-uui" as a new value of the User-to-User "content" header field parameter. 12. IANA Considerations This document adds the following row to the "UUI application values" section of the SIP parameter registry: Value: isdn-uui Meaning: The associated application is being used with constraints suitable for interworking with the ISDN user-to-user service, and therefore can be interworked at ISDN gateways. Reference: RFCXXXX Contact: This document adds the following row to the "UUI content values" section of the SIP parameter registry: Value: isdn-uui Meaning: The associated contents conforms to the content associated with the ISDN user-to-user service. In the presence of the "app" header field parameter set to "isdn-uui" this is the default meaning and therefore need not be included in this case. Reference: RFCXXXX Contact: Editor's Note: [RFCXXXX] should be replaced with the designation of this document. Drage & Johnston Expires March 23, 2012 [Page 11] Internet-Draft SIP UUI for CC September 2011 13. Security Considerations This document contains no specific requirements in regard to security. The overlying use case will define the security measures required. The underlying user-to-user extension provides a number of tools that can meet certain security requirements. As a level of guidance, data that is used to assist in selecting which SIP UA should respond to the call would not be expected to carry any higher level of security than a media feature tag. Information that might otherwise reveal private information about an individual, or where a level of authenticity needs to be guaranteed, may need a higher level of protection, and may indeed not be suitable for this application, particularly taking into account the statement in the following paragraph. As this capability to is defined to interwork with the ISDN, if the ISDN forms part of the route, any usage needs to assume that the security level of the ISDN is the highest level of security available. As the ISDN security is itself not definable on an end- to-end basis, this can be an unknown quantity. This is because ISDN security exists on a hop-by-hop basis, and is only as secure as the least secure component. This can be high in some places (e.g. it can require physical access to a secure building) and in other places it can be low (e.g. the point where an ISDN access enters a building). If this level of security is not sufficient, then either a different user-to-user application, or indeed, a different method of data transfer, needs to be selected by the application user. 14. Acknowledgements Joanne McMillen was a major contributor and co-author of earlier versions of this document. Thanks to Spencer Dawkins, Vijay Gurbani, and Laura Liess for their review of earlier versions of this document. The authors wish to thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, and Mahalingam Mani for their comments. 15. Changes since previous versions Note to RFC editor: This section is to be deleted before final publication. Changes since made in the creation of the -01 version from the -00 version. Drage & Johnston Expires March 23, 2012 [Page 12] Internet-Draft SIP UUI for CC September 2011 Closure of a number of open issues identified in the -00 version and the creation of appropriate procedures for the UAC, the UAS, and the ISDN interworking gateway. 16. Normative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [Q931] "ITU-T Recommendation Q.931: Digital subscriber Signalling System No. 1 - Network layer; ISDN user-network interface layer 3 specification for basic call control", http://www.itu.int/rec/T-REC-Q.931-199805-I/en . [Q957.1] "ITU-T Recommendation Q.957.1: Digital subscriber Signalling System No. 1 - Stage 3 description for supplementary services using DSS 1; Stage 3 description for additional information transfer supplementary services using DSS 1: User-to-User Signalling (UUS)", http://www.itu.int/rec/T-REC-Q.957.1-199607-I . [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part formats and codes", http://www.itu.int/rec/T-REC-Q.931-199805-I/en . [ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services Digital Network (ISDN)-Explicit Call Transfer Supplementary Service". [ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services Digital Network (ISDN); Diversion supplementary services". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002. [johnston-cuss-sip-uui-reqs] Johnston, A., McMillen, J., and L. Liess, "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP", draft-johnston-cuss-sip-uui-reqs-00 . Drage & Johnston Expires March 23, 2012 [Page 13] Internet-Draft SIP UUI for CC September 2011 [johnston-cuss-sip-uui] Johnston, A. and J. Rafferty, "A Mechanism for Transporting User to User Call Control Information in SIP", draft-johnston-cuss-sip-uui-00 . Authors' Addresses Keith Drage (editor) Alcatel-Lucent Quadrant, Stonehill Green, Westlea Swindon UK Email: keith.drage@alcatel-lucent.com Alan Johnston Avaya St. Louis, MO 63124 United States Email: alan.b.johnston@gmail.com Drage & Johnston Expires March 23, 2012 [Page 14]