Internet Engineering Task Force J. Elwell Internet Draft Siemens J. McMillen Avaya Inc. JF. Rey/O. Rousseau draft-elwell-sipping-qsig-tunnel-00.txt Alcatel Expires: December 2003 June 2003 Tunnelling of QSIG over SIP Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC 2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies tunnelling of "QSIG" over the Session Initiation Protocol (SIP). This enables calls between "islands" of circuit switched networks that use QSIG signalling to be interconnected by an IP network that uses SIP signalling without loss of QSIG functionality. This document is a product of the authors' activities in ECMA (www.ecma.ch) on interoperability of QSIG with IP networks. 1 Introduction....................................................2 2 Terminology.....................................................3 3 Definitions.....................................................3 3.1 External definitions..........................................3 3.2 Other definitions.............................................3 3.2.1 Corporate telecommunication Network (CN)....................3 3.2.2 Egress gateway..............................................4 Elwell et alia Expires - December 2003 [Page 1] Interworking between SIP and QSIG June 2003 3.2.3 Gateway.....................................................4 3.2.4 Ingress gateway.............................................4 3.2.5 IP network..................................................4 3.2.6 Media stream................................................4 3.2.7 Private Integrated Services Network (PISN)..................4 3.2.8 Private Integrated services Network eXchange (PINX).........4 4 Acronyms........................................................4 5 Background and architecture.....................................5 6 Procedures......................................................7 6.1 General.......................................................7 6.2 Encapsulation of QSIG messages in SIP messages................8 6.3 QSIG SETUP message handling at an ingress gateway.............8 6.3.1 Sending a SIP INVITE request................................8 6.3.2 Receipt of responses to the INVITE request..................9 6.4 QSIG SETUP message handling at an egress gateway..............9 6.4.1 Receiving a SIP INVITE request..............................9 6.5 Subsequent QSIG messages.....................................10 6.6 Terminating the SIP dialog...................................10 7 Example message sequences......................................10 7.1 Call establishment...........................................10 7.2 Call clearing................................................11 8 Security considerations........................................12 9 IANA considerations............................................12 10 Author's Addresses............................................12 11 Normative References..........................................13 Annex A - Change log.............................................14 1 Introduction This document specifies tunnelling of "QSIG" over the Session Initiation Protocol (SIP) within a corporate telecommunication network (CN). "QSIG" is a signalling protocol that operates between Private Integrated Services eXchanges (PINX) within a Private Integrated Services Network (PISN). A PISN provides circuit-switched basic services and supplementary services to its users. QSIG is specified in ECMA Standards, in particular [2] (call control in support of basic services), [3] (generic functional protocol for the support of supplementary services) and a number of Standards specifying individual supplementary services. SIP is an application layer protocol for establishing, terminating and modifying multimedia sessions. It is typically carried over IP [6], [7]. Telephone calls are considered as a type of multimedia session where just audio is exchanged. SIP is defined in [1]. Elwell et alia Expires - December 2003 [Page 2] Interworking between SIP and QSIG June 2003 Often a CN comprises both PISNs employing QSIG and IP networks employing SIP. A call can originate at a user connected to a PISN and terminate at a user connected to an IP network or vice versa. In either case, a gateway provides interworking between QSIG and SIP at the boundary between the PISN and the IP network. Basic call interworking at a gateway is specified in [5]. Another case is where a call originates at a user connected to a PISN, traverses an IP network using SIP, and terminates at a user connected to another (or another part of the same) PISN. This document addresses this last case in a way that preserves all QSIG capabilities across the IP network. It achieves this by tunnelling QSIG messages within SIP requests and responses in the context of a SIP dialog. The tunnelling of QSIG through a public IP network employing SIP is outside the scope of this specification. However, the functionality specified in this specification is in principle applicable to such a scenario when deployed in conjunction with other relevant functionality (e.g., address translation, security functions, etc.). This specification is applicable to any interworking unit that can act as a gateway between a PISN employing QSIG and a corporate IP network employing SIP, with QSIG tunnelled within SIP requests and responses. 2 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for compliant SIP implementations. 3 Definitions For the purposes of this specification, the following definitions apply. 3.1 External definitions The definitions in [2] and [1] apply as appropriate. 3.2 Other definitions 3.2.1 Corporate telecommunication Network (CN) Sets of privately-owned or carrier-provided equipment that are located at geographically dispersed locations and are interconnected to provide telecommunication services to a defined group of users. Elwell et alia Expires - December 2003 [Page 3] Interworking between SIP and QSIG June 2003 NOTE. A CN can comprise a PISN, a private IP network (intranet) or a combination of the two. 3.2.2 Egress gateway A gateway handling a QSIG call established in the direction IP network to PISN. 3.2.3 Gateway An entity that behaves as a QSIG Transit PINX with QSIG carried over a circuit-switch link within a PISN on one side and QSIG tunnelled over SIP within an IP network on the other side. 3.2.4 Ingress gateway A gateway handling a QSIG call established in the direction PISN to IP network. 3.2.5 IP network A network, unless otherwise stated a corporate network, offering connectionless packet-mode services based on the Internet Protocol (IP) as the network layer protocol. 3.2.6 Media stream Audio or other user information transmitted in UDP packets, typically containing RTP, in a single direction between the gateway and a peer entity participating in a session established using SIP. NOTE. Normally a SIP session establishes a pair of media streams, one in each direction. 3.2.7 Private Integrated Services Network (PISN) A CN or part of a CN that employs circuit-switched technology and QSIG signalling. 3.2.8 Private Integrated services Network eXchange (PINX) A PISN nodal entity comprising switching and call handling functions and supporting QSIG signalling in accordance with [2]. 4 Acronyms IP Internet Protocol PINX Private Integrated services Network eXchange PISN Private Integrated Services Network Elwell et alia Expires - December 2003 [Page 4] Interworking between SIP and QSIG June 2003 RTP Real-time Transport Protocol SDP Session Description Protocol SIP Session Initiation Protocol TCP Transmission Control Protocol UA User Agent UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol 5 Background and architecture This document concerns the case of a call that originates at a user connected to a PISN employing QSIG, traverses an IP network employing SIP, and terminates at a user connected to another (or another part of the same) PISN. This can be achieved by employing a gateway at each boundary between a PISN employing QSIG and an IP network employing SIP, as shown in Figure 1. PISN IP network (SIP) PISN (QSIG) <-----------------------> (QSIG) +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ |PINX | |Gate-| |SIP | |SIP | |Gate-| |PINX | | |---|way |---|proxy|---|proxy|---|way |---| | | | | | | | | | | | | | +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ Figure 1 û Call from QSIG via SIP to QSIG EDITOR'S NOTE. Further consideration needs to be given to tunnelling call-unrelated signalling information (both connection-oriented and connectionless). Each gateway can provide interworking as specified in [5]. This provides a basic call capability. However, [5] only specifies interworking for QSIG basic call, as specified in [2]. Many of the other capabilities of QSIG (support for supplementary services and additional network features) as specified in other standards and in vendor-specific specifications are not covered. Some of these additional capabilities of QSIG are suitable for interworking with SIP and might be the subject of future informational RFCs or other specifications. Other capabilities of QSIG are unsuitable for interworking with SIP because corresponding capabilities do not exist in SIP or are achieved in ways that are incompatible with QSIG. Therefore interworking at a gateway between QSIG and SIP will be limited to those QSIG capabilities that have sufficiently compatible equivalents in SIP. Each capability requires special implementation in the gateway, and therefore a typical gateway might provide interworking for only a subset of capabilities for which interworking is feasible. Elwell et alia Expires - December 2003 [Page 5] Interworking between SIP and QSIG June 2003 The result of this is that there will be a loss of capability on a call from QSIG to SIP or vice versa. For a call similar to that shown in figure 1 there will likewise be a loss of capability. This can be compounded if the two gateways are of different types, since only those capabilities common to both gateways will survive end-to-end. The solution is to tunnel QSIG messages through the IP network within SIP messages so that no end-to-end QSIG capabilities are lost. One of the two gateways originates a SIP dialog to the other gateway. SIP messages within the dialog are used to tunnel QSIG messages. Through the use of SDP, the dialog also establishes a session in which media streams carry user information (e.g., speech) between the two QSIG gateways. The two gateways act as QSIG Transit PINXs, which relay QSIG messages with little or no modification. In a conventional PISN employing QSIG, two PINXs are connected by means of an inter-PINX link, which comprises a signalling channel (carrying QSIG messages) and one or more user information channels carrying speech, modem information or data. With the tunnelling solution, the IP network provides the inter-PINX link between the two gateways acting as Transit PINXs. The tunnel provided by SIP for QSIG messages acts as the signalling channel and the media streams act as the user information channels. This document restricts itself to the case where a single dialog between two gateways is used for a single QSIG call. This means that the dialog is established when the QSIG call is established and cleared down when the QSIG call is cleared down. An enhanced scenario in which a single SIP dialog is maintained long term and used to tunnel a multiplicity of QSIG calls, with the possibility of multiple QSIG calls being in progress at any one time, is outside the scope of this document. When a gateway (the ingress gateway) receives a QSIG call establishment request (QSIG SETUP message) from the PISN, it needs to generate a SIP INVITE request using a Request-URI that will route the request to an appropriate egress gateway. The Request-URI must be derived in some way from the required destination of the QSIG call (as indicated in the Called party number information element of the QSIG SETUP message). The Request-URI can explicitly identify the egress gateway or it can simply identify the required destination. The first case is likely to require some sort of look-up capability in the gateway, the configuration of which is outside the scope of this document. For the latter case algorithmic mapping of the called party number to a Request-URI might be sufficient, but this delegates the task of selecting an appropriate egress gateway to SIP proxies. Elwell et alia Expires - December 2003 [Page 6] Interworking between SIP and QSIG June 2003 An ingress gateway may determine from the required destination of a call that the destination is not reachable via QSIG tunnelling. In this case the QSIG gateway can either route the call onwards within the PISN or can route the call into the IP network using interworking as specified in [5]. How an ingress gateway determines that the destination is not reachable via QSIG tunnelling is outside the scope of this document. If an ingress gateway maps the QSIG called party number to a Request URI that does not explicitly identify a particular egress gateway, routing of the INVITE request is left to SIP proxies. A proxy might route the request to a UAS that is not an egress gateway to QSIG, in which case QSIG tunnelling will not be possible. Allowing the call to proceed in this situation is likely to be undesirable, since the ingress gateway expects to carry out QSIG tunnelling whereas interworking with SIP, as specified in [5], would be more appropriate. To cater for this situation, this document proposes a new option tag for QSIG tunnelling. This option tag is included in a Require header in the SIP INVITE request so that the request will be rejected by a UAS that does not support this feature. This allows the ingress gateway to take alternative action, as described above for the case where the ingress gateway determines by local means that QSIG tunnelling is not possible. NOTE. Allowing the INVITE request to be routed by proxies either to an egress gateway to QSIG or to some other UAS without the ability for the ingress gateway to determine this in advance is undesirable. It implies that the ingress gateway maps the QSIG SETUP message to a SIP INVITE request in accordance with both this document and [5] simultaneously. Although this may seem feasible superficially, architecturally it is dangerous because with QSIG tunnelling the ingress gateway should act as a QSIG Transit PINX whereas with interworking in accordance with [5] it should act as a QSIG Outgoing Gateway PINX. The ingress gateway will not know for certain which behaviour to adopt until a 200 OK arrives, and therefore in the meantime it will not know how to handle information relating to certain QSIG capabilities (supplementary services and additional network features) in the QSIG SETUP message. It is not clear whether this can be handled safely for all possible QSIG capabilities (including vendor-specific capabilities). 6 Procedures 6.1 General A gateway SHALL behave as a QSIG Transit PINX as specified in [2] and modified as specified below. Elwell et alia Expires - December 2003 [Page 7] Interworking between SIP and QSIG June 2003 6.2 Encapsulation of QSIG messages in SIP messages When encapsulating a QSIG message inside a SIP message, a gateway SHALL include the QSIG message in the body of the SIP request or response in accordance with [8] using media type application/QSIG. QSIG segmentation SHALL NOT apply. 6.3 QSIG SETUP message handling at an ingress gateway 6.3.1 Sending a SIP INVITE request The ingress gateway, on receipt of a QSIG SETUP message eligible for tunnelling over SIP to an egress gateway, SHALL build a SIP INVITE request message containing a Request-URI suitable for routing towards a suitable egress. NOTE. The Request-URI should be derived in some way from the Called party number information in the QSIG SETUP message. The Request-URI can explicitly identify a particular egress gateway. Alternatively it can identify the final destination in a way that leaves selection of a suitable egress gateway to SIP proxies. The From header should contain a URI identifying either the ingress gateway or the calling party (derived from the QSIG Calling party number information element). The ingress gateway SHALL include a Require header containing option tag qsigTunnelling. The ingress gateway SHALL encapsulate the QSIG SETUP message in the SIP INVITE request. EDITOR'S NOTE. Should we relax this to allow the QSIG SETUP message to be sent later after receipt of 200 OK? This might be more in line with the proposed multiple calls / 1 dialog scenario. The encapsulated QSIG SETUP message MAY differ from the received SETUP message in accordance with acceptable modification at a QSIG Transit PINX. For example, the Channel identification information element MAY change. Because in the encapsulated QSIG SETUP message the contents of the Channel identification information element have no significance, the channel number field SHOULD contain value 1 and the preferred/exclusive field SHOULD contain value 1 (exclusive). The INVITE request SHALL contain an SDP offer proposing a pair of media streams, one in each direction, that the gateway can map to the user information channel indicated in the Channel identification information element in the received QSIG message. The media streams Elwell et alia Expires - December 2003 [Page 8] Interworking between SIP and QSIG June 2003 SHALL be suitable for use in accordance with the Bearer capability information element in the received QSIG SETUP message. After sending the SIP INVITE request, the ingress gateway SHALL NOT encapsulate any further message from QSIG until a SIP 200 OK response has been received. 6.3.2 Receipt of responses to the INVITE request The action specified below is in addition to normal UA handling of a SIP response. On receipt of a SIP 4xx, 5xx or 6xx final response, the ingress gateway SHALL either take alternative action to route the call (outside the scope of this document) or clear the call using an appropriate cause value in the QSIG Cause information element of the QSIG call clearing message concerned (DISCONNECT, RELEASE or RELEASE COMPLETE). If the SIP response contains an encapsulated QSIG RELEASE COMPLETE message, the ingress gateway MAY use the cause value in that message to determine the cause value when clearing the call. EDITOR'S NOTE. Cause mapping may need to be specified. On receipt of a SIP 200 OK response containing a Supported header with option tag qsigTunnelling, the ingress gateway SHALL carry out normal SIP processing, including transmission of an ACK request, and SHALL act upon any encapsulated QSIG message. The ingress gateway SHALL also connect the QSIG user information channel to the media streams indicated in the SDP answer. EDITOR'S NOTE. Is the Supported header necessary? 6.4 QSIG SETUP message handling at an egress gateway 6.4.1 Receiving a SIP INVITE request On receipt of a SIP INVITE request containing a QSIG message in the body of the request, the egress gateway shall behave as follows. If the QSIG message is a SETUP message acceptable for routing onwards into the PISN, the egress gateway SHALL select a user information channel on the PISN side and shall forward the QSIG SETUP message. The forwarded QSIG SETUP message MAY differ from the received SETUP message in accordance with acceptable modification at a QSIG Transit PINX. In particular, the Channel identification information element SHALL reflect the selected user information channel. The egress gateway SHALL also send a SIP 200 response containing an SDP answer confirming a pair of media streams (one in each direction) that the gateway can map to the selected user information channel used in Elwell et alia Expires - December 2003 [Page 9] Interworking between SIP and QSIG June 2003 accordance with the Bearer capability information element in the forwarded QSIG SETUP message. The egress gateway SHALL also connect the QSIG user information channel to the media streams indicated in the SDP answer. The egress gateway SHALL include in the SIP 200 response a Supported header containing option tag qsigTunnelling. The egress gateway MAY include in the SIP 200 response an encapsulated QSIG SETUP ACKNOWLEDGE message or CALL PROCEEDING message. Otherwise the gateway SHALL transmit this first responding QSIG message later in a SIP INFO message in accordance with 6.5. If the egress gateway contains an INVITE request containing a QSIG message that is not a SETUP message suitable for routing onwards, the egress gateway SHALL send back a ???? response containing a responding QSIG message in accordance with ECMA-143, e.g, a RELEASE COMPLETE message containing an appropriate value in the QSIG Cause information element. EDITORÆS NOTE. Appropriate SIP response code to be identified. 6.5 Subsequent QSIG messages After receipt transmitting a 200 OK response (egress gateway) or transmitting an ACK following receipt of a 200 OK response (ingress gateway), a gateway SHALL encapsulate any further QSIG messages for transmission to the peer gateway in the body of a SIP INFO request [9] and SHALL be able to receive further QSIG messages from the peer gateway encapsulated in the body of SIP INFO request. The exception is a QSIG RELEASE COMPLETE message, which MAY be encapsulated in a SIP BYE request in accordance with 6.6. 6.6 Terminating the SIP dialog When a gateway determines that a QSIG call has terminated, it SHALL terminate the SIP session by transmitting a BYE request. If a gateway transmits the final QSIG message of the call (RELEASE COMPLETE), the gateway MAY encapsulate that QSIG message in the BYE request. Otherwise the gateway SHALL transmit the BYE request after the final QSIG message has been sent or received and SHALL NOT encapsulate a QSIG message in the BYE request. 7 Example message sequences 7.1 Call establishment IP network +-----------+ (SIP with +-----------+ Elwell et alia Expires - December 2003 [Page 10] Interworking between SIP and QSIG June 2003 PISN |Ingress | tunnelled |Egress | PISN (QSIG) |gateway | QSIG) |gateway | (QSIG) +-----------+ +-----------+ QSIG SETUP || SIP INVITE request || ----------------->|| Required=qsigTunnelling|| || QSIG SETUP || QSIG CALL ||----------------------->|| QSIG SETUP PROCEEDING || ||-----------------> <-----------------|| SIP 200 OK || || QSIG CALL PROCEEDING || QSIG CALL ||<-----------------------|| PROCEEDING || ||<----------------- || SIP ACK || ||----------------------->|| || || QSIG ALERTING || SIP INFO ||<----------------- || QSIG ALERTING || ||<-----------------------|| QSIG ALERTING || || <-----------------|| SIP 200 OK || ||----------------------->|| || || QSIG CONNECT || SIP INFO ||<----------------- || QSIG CONNECT || ||<-----------------------|| QSIG CONNECT ACK QSIG CONNECT || ||-----------------> <-----------------|| SIP 200 OK || ||----------------------->|| || || || SIP INFO || || QSIG CONNECT ACK || ||----------------------->|| QSIG CONNECT ACK || || ----------------->|| SIP 200 OK || ||<-----------------------|| || || Figure 2 û Call establishment QSIG-SIP-QSIG 7.2 Call clearing IP network +-----------+ (SIP with +-----------+ PISN |Ingress | tunnelled |Egress | PISN (QSIG) |gateway | QSIG) |gateway | (QSIG) +-----------+ +-----------+ QSIG DISCONNECT || SIP INFO || ----------------->|| QSIG DISCONNECT || ||----------------------->|| QSIG DISCONNECT Elwell et alia Expires - December 2003 [Page 11] Interworking between SIP and QSIG June 2003 QSIG RELEASE || ||-----------------> <-----------------|| SIP 200 OK || ||<-----------------------|| QSIG RELEASE || || COMPLETE || SIP INFO || ----------------->|| QSIG RELEASE || ||<-----------------------|| QSIG RELEASE || ||<----------------- || || || || QSIG RELEASE || || COMPLETE || SIP 200 OK ||-----------------> ||----------------------->|| || || || SIP BYE || || QSIG RELEASE COMPLETE || ||----------------------->|| || || || SIP 200 OK || ||<-----------------------|| || || Figure 3 û Call clearing QSIG-SIP-QSIG 8 Security considerations EDITOR'S NOTE. To be added 9 IANA considerations This document registers a new option tag, based on the IANA registration process of RFC 3261. This specification registers a single option tag, qsigTunnelling. The required information for this registration, as specified in [1], is: Name: qsigTunnelling Description: This option tag is for encapsulation of QSIG messages within bodies of SIP requests and responses. When present in a Supported header, it indicates that the UA can send or receive QSIG messages encapsulated in bodies of SIP requests and responses. When present in a Required header in an INVITE request, it indicates that the UAS MUST support encapsulation of QSIG messages in bodies of SIP requests and responses if it accepts the INVITE request. 10 Author's Addresses John Elwell Siemens Communications Elwell et alia Expires - December 2003 [Page 12] Interworking between SIP and QSIG June 2003 Technology Drive Beeston Nottingham, UK, NG9 1LA email: john.elwell@siemens.com Joanne McMillen Avaya Inc. 1300 W. 120th Ave. Westminster, CO 80234-2726 email: joanne@avaya.com Olivier Rousseau Alcatel Business Systems 32,Avenue Kleber 92700 Colombes France email: olivier.rousseau@col.bsf.alcatel.fr Jean-Francois Rey Alcatel Business Systems 8,Rue de Kervezennec, BP 82 802 29228 Brest Cedex 2 France email: jean-francois.rey@bst.bsf.alcatel.fr 11 Normative References [1] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation protocol", RFC 3261. [2] International Standard ISO/IEC 11572 "Private Integrated Services Network - Circuit-mode Bearer Services - Inter-Exchange Signalling Procedures and Protocol" (also published by ECMA as Standard ECMA-143) [3] International Standard ISO/IEC 11582 "Private Integrated Services Network - Generic Functional Protocol for the Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol" (also published by ECMA as Standard ECMA-165) [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] F. Derks, J. Elwell, P. Mourot, O. Rousseau, "Interworking between SIP and QSIG", draft-ietf-sipping-qsig2sip-02 [6] J. Postel, "Internet Protocol", RFC 791. Elwell et alia Expires - December 2003 [Page 13] Interworking between SIP and QSIG June 2003 [7] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)", RFC 2460. [8] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG objects", RFC 3204, December 2001. [9] Donovan, S., "The SIP INFO Method", RFC2976, October 2000. Annex A (temporary) - Change log Elwell et alia Expires - December 2003 [Page 14]