RFC 4497
Interworking between the Session Initiation Protocol (SIP) and QSIG
Network Working Group J. Elwell Request for Comments: 4497 Siemens BCP: 117 F. Derks Category: Best Current Practice NEC Philips P. Mourot O. Rousseau Alcatel May 2006 Interworking between the Session Initiation Protocol (SIP) and QSIG Status of This Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006).Abstract
This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) within Private Integrated Services Networks (PISNs). QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards.
Table of Contents
1. Introduction ....................................................4 2. Terminology .....................................................5 3. Definitions .....................................................5 3.1. External Definitions .......................................5 3.2. Other definitions ..........................................5 3.2.1. Corporate Telecommunication Network (CN) ............5 3.2.2. Gateway .............................................6 3.2.3. IP Network ..........................................6 3.2.4. Media Stream ........................................6 3.2.5. Private Integrated Services Network (PISN) ..........6 3.2.6. Private Integrated Services Network Exchange (PINX) ..............................................6 4. Acronyms ........................................................6 5. Background and Architecture .....................................7 6. Overview .......................................................10 7. General Requirements ...........................................11 8. Message Mapping Requirements ...................................12 8.1. Message Validation and Handling of Protocol Errors ........12 8.2. Call Establishment from QSIG to SIP .......................14 8.2.1. Call Establishment from QSIG to SIP Using En Bloc Procedures .................................14 8.2.2. Call Establishment from QSIG to SIP Using Overlap Procedures .................................16 8.3. Call Establishment from SIP to QSIG .......................20 8.3.1. Receipt of SIP INVITE Request for a New Call .......20 8.3.2. Receipt of QSIG CALL PROCEEDING Message ............21 8.3.3. Receipt of QSIG PROGRESS Message ...................22 8.3.4. Receipt of QSIG ALERTING Message ...................22 8.3.5. Inclusion of SDP Information in a SIP 18x Provisional Response ...............................23 8.3.6. Receipt of QSIG CONNECT Message ....................24 8.3.7. Receipt of SIP PRACK Request .......................25 8.3.8. Receipt of SIP ACK Request .........................25 8.3.9. Receipt of a SIP INVITE Request for a Call Already Being ......................................25 8.4. Call Clearing and Call Failure ............................26 8.4.1. Receipt of a QSIG DISCONNECT, RELEASE, or RELEASE COMPLETE ...................................26 8.4.2. Receipt of a SIP BYE Request .......................29 8.4.3. Receipt of a SIP CANCEL Request ....................29 8.4.4. Receipt of a SIP 4xx-6xx Response to an INVITE Request .....................................29 8.4.5. Gateway-Initiated Call Clearing ....................32 8.5. Request to Change Media Characteristics ...................32
9. Number Mapping .................................................32 9.1. Mapping from QSIG to SIP ..................................33 9.1.1. Using Information from the QSIG Called Party Number Information Element ...................33 9.1.2. Using Information from the QSIG Calling Party Number Information Element ...................33 9.1.3. Using Information from the QSIG Connected Number Information Element .........................35 9.2. Mapping from SIP to QSIG ..................................36 9.2.1. Generating the QSIG Called Party Number Information Element ................................36 9.2.2. Generating the QSIG Calling Party Number Information Element ................................37 9.2.3. Generating the QSIG Connected Number Information Element ................................38 10. Requirements for Support of Basic Services ....................39 10.1. Derivation of QSIG Bearer Capability Information Element ..................................................39 10.2. Derivation of Media Type in SDP ..........................39 11. Security Considerations .......................................40 11.1. General ..................................................40 11.2. Calls from QSIG to Invalid or Restricted Numbers .........40 11.3. Abuse of SIP Response Code ...............................41 11.4. Use of the To Header URI .................................41 11.5. Use of the From Header URI ...............................41 11.6. Abuse of Early Media .....................................42 11.7. Protection from Denial-of-Service Attacks ................42 12. Acknowledgements ..............................................43 13. Normative References ..........................................43 Appendix A. Example Message Sequences .............................45
1. Introduction
This document specifies signalling interworking between QSIG and the Session Initiation Protocol (SIP) in support of basic services within a corporate telecommunication network (CN) (also known as enterprise network). 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. NOTE: The name QSIG was derived from the fact that it is used for signalling at the Q reference point. The Q reference point is a point of demarcation between two PINXs. SIP is an application-layer protocol for establishing, terminating, and modifying multimedia sessions. It is typically carried over IP [15], [16]. Telephone calls are considered a type of multimedia session where just audio is exchanged. SIP is defined in [10]. As the support of telephony within corporate networks evolves from circuit-switched technology to Internet technology, the two technologies will coexist in many networks for a period, perhaps several years. Therefore, there is a need to be able to establish, modify, and terminate sessions involving a participant in the SIP network and a participant in the QSIG network. Such calls are supported by gateways that perform interworking between SIP and QSIG. This document specifies SIP-QSIG signalling interworking for basic services that provide a bi-directional transfer capability for speech, DTMF, facsimile, and modem media between a PISN employing QSIG and a corporate IP network employing SIP. Other aspects of interworking, e.g., the use of RTP and SDP, will differ according to the type of media concerned and are outside the scope of this specification. Call-related and call-independent signalling in support of supplementary services is outside the scope of this specification, but support for certain supplementary services (e.g., call transfer, call diversion) could be the subject of future work.
Interworking between QSIG and SIP permits a call originating at a user of a PISN to terminate at a user of a corporate IP network, or a call originating at a user of a corporate IP network to terminate at a user of a PISN. Interworking between a PISN employing QSIG and 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., number 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.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 [10] 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. NOTE: A CN can comprise a PISN, a private IP network (intranet), or a combination of the two.
3.2.2. Gateway
An entity that performs interworking between a PISN using QSIG and an IP network using SIP.3.2.3. 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.4. 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.5. Private Integrated Services Network (PISN)
A CN or part of a CN that employs circuit-switched technology.3.2.6. 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
DNS Domain Name Service IP Internet Protocol PINX Private Integrated services Network eXchange PISN Private Integrated Services Network RTP Real-time Transport Protocol SCTP Stream Control Transmission Protocol SDP Session Description Protocol SIP Session Initiation Protocol TCP Transmission Control Protocol TLS Transport Layer Security TU Transaction User UA User Agent UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol
5. Background and Architecture
During the 1980s, corporate voice telecommunications adopted technology similar in principle to Integrated Services Digital Networks (ISDN). Digital circuit switches, commonly known as Private Branch eXchanges (PBX) or more formally as Private Integrated services Network eXchanges (PINX) have been interconnected by digital transmission systems to form Private Integrated Services Networks (PISN). These digital transmission systems carry voice or other payload in fixed-rate channels, typically 64 Kbit/s, and signalling in a separate channel. A technique known as common channel signalling is employed, whereby a single signalling channel potentially controls a number of payload channels or bearer channels. A typical arrangement is a point-to-point transmission facility at T1 or E1 rate providing a 64 Kbit/s signalling channel and 23 or 30 bearer channels, respectively. Other arrangements are possible and have been deployed, including the use of multiple transmission facilities for a signalling channel and its logically associated bearer channels. Also, arrangements involving bearer channels at sub-64 Kbit/s have been deployed, where voice payload requires the use of codecs that perform compression. QSIG is the internationally-standardized message-based signalling protocol for use in networks as described above. It runs in a signalling channel between two PINXs and controls calls on a number of logically associated bearer channels between the same two PINXs. The signalling channel and its logically associated bearer channels are collectively known as an inter-PINX link. QSIG is independent of the type of transmission capabilities over which the signalling channel and bearer channels are provided. QSIG is also independent of the transport protocol used to transport QSIG messages reliably over the signalling channel. QSIG provides a means for establishing and clearing calls that originate and terminate on different PINXs. A call can be routed over a single inter-PINX link connecting the originating and terminating PINX, or over several inter-PINX links in series with switching at intermediate PINXs known as transit PINXs. A call can originate or terminate in another network, in which case it enters or leaves the PISN environment through a gateway PINX. Parties are identified by numbers, in accordance with either [17] or a private numbering plan. This basic call capability is specified in [2]. In addition to basic call capability, QSIG specifies a number of further capabilities supporting the use of supplementary services in PISNs. More recently, corporate telecommunications networks have started to exploit IP in various ways. One way is to migrate part of the network to IP using SIP. This might, for example, be a new branch
office with a SIP proxy and SIP endpoints instead of a PINX. Alternatively, SIP equipment might be used to replace an existing PINX or PINXs. The new SIP environment needs to interwork with the QSIG-based PISN in order to support calls originating in one environment and terminating in the other. Interworking is achieved through a gateway. Interworking between QSIG and SIP at gateways can also be used where a SIP network interconnects different parts of a PISN, thereby allowing calls between the different parts. A call can enter the SIP network at one gateway and leave at another. Each gateway would behave in accordance with this specification. Another way of connecting two parts of a PISN would be to encapsulate QSIG signalling in SIP messages for calls between the two parts. This is outside the scope of this specification but could be the subject of future work. This document specifies signalling protocol interworking aspects of a gateway between a PISN employing QSIG signalling and an IP network employing SIP signalling. The gateway appears as a PINX to other PINXs in the PISN. The gateway appears as a SIP endpoint to other SIP entities in the IP network. The environment is shown in Figure 1. +------+ IP network PISN | | |SIP | +------+ |Proxy | /| | | | / |PINX | +---+--+ *-----------+ / | | | | | +-----+/ +------+ | | | | | | | | |PINX | ---+-----+-------+--------+ Gateway +--------| | | | | | | |\ | | | | +-----+ \ | | | | \ +------+ | | | | \| | +--+---+ +--+---+ *-----------+ |PINX | |SIP | |SIP | | | |End- | |End- | +------+ |point | |point | +------+ +------+ Figure 1: Environment
In addition to the signalling interworking functionality specified in
this specification, it is assumed that the gateway also includes the
following functionality:
- one or more physical interfaces on the PISN side supporting one or
more inter-PINX links, each link providing one or more constant bit
rate channels for media streams and a reliable layer 2 connection
(e.g., over a fixed rate physical channel) for transporting QSIG
signalling messages; and
- one or more physical interfaces on the IP network side supporting,
through layer 1 and layer 2 protocols, IP as the network layer
protocol and UDP [6] and TCP [5] as transport layer protocols,
these being used for the transport of SIP signalling messages and,
in the case of UDP, also for media streams;
- optionally the support of TLS [7] and/or SCTP [9] as additional
transport layer protocols on the IP network side, these being used
for the transport of SIP signalling messages; and
- a means of transferring media streams in each direction between the
PISN and the IP network, including as a minimum packetization of
media streams sent to the IP network and de-packetization of media
streams received from the IP network.
NOTE: [10] mandates support for both UDP and TCP for the transport of
SIP messages and allows optional support for TLS and/or SCTP for this
same purpose.
The protocol model relevant to signalling interworking functionality
of a gateway is shown in Figure 2.
+---------------------------------------------------------+ | Interworking function | | | +-----------------------+---------+-----------------------+ | | | | | SIP | | | | | | | +-----------------------+ | | | | | | | UDP/TCP/TLS/SCTP | | QSIG | | | | | +-----------------------+ | | | | | | | IP | | | | | | | +-----------------------+ +-----------------------+ | IP network | | PISN | | lower layers | | lower layers | | | | | +-----------------------+ +-----------------------+ Figure 2: Protocol model In Figure 2, the SIP box represents SIP syntax and encoding, the SIP transport layer, and the SIP transaction layer. The Interworking function includes SIP Transaction User (TU) functionality.6. Overview
The gateway maps received QSIG messages, where appropriate, to SIP messages and vice versa and maintains an association between a QSIG call and a SIP dialog. A call from QSIG to SIP is initiated when a QSIG SETUP message arrives at the gateway. The QSIG SETUP message initiates QSIG call establishment, and an initial response message (e.g., CALL PROCEEDING) completes negotiation of the bearer channel to be used for that call. The gateway then sends a SIP INVITE request, having translated the QSIG called party number to a URI suitable for inclusion in the Request-URI. The SIP INVITE request and the resulting SIP dialog, if successfully established, are associated with the QSIG call. The SIP 2xx response to the INVITE request is mapped to a QSIG CONNECT message, signifying answer of the call. During establishment, media streams established by SIP and SDP are connected to the bearer channel.
A call from SIP to QSIG is initiated when a SIP INVITE request arrives at the gateway. The gateway sends a QSIG SETUP message to initiate QSIG call establishment, having translated the SIP Request- URI to a number suitable for use as the QSIG called party number. The resulting QSIG call is associated with the SIP INVITE request and with the eventual SIP dialog. Receipt of an initial QSIG response message completes negotiation of the bearer channel to be used, allowing media streams established by SIP and SDP to be connected to that bearer channel. The QSIG CONNECT message is mapped to a SIP 200 OK response to the INVITE request. Appendix A gives examples of typical message sequences that can arise.7. General Requirements
In order to conform to this specification, a gateway SHALL support QSIG in accordance with [2] as a gateway and SHALL support SIP in accordance with [10] as a UA. In particular, the gateway SHALL support SIP syntax and encoding, the SIP transport layer, and the SIP transaction layer in accordance with [10]. In addition, the gateway SHALL support SIP TU behaviour for a UA in accordance with [10] except where stated otherwise in Sections 8, 9, and 10 of this specification. NOTE: [10] mandates that a SIP entity support both UDP and TCP as transport layer protocols for SIP messages. Other transport layer protocols can also be supported. The gateway SHALL also support SIP reliable provisional responses in accordance with [11] as a UA. NOTE: [11] makes provision for recovering from loss of provisional responses (other than 100) to INVITE requests when using unreliable transport services in the IP network. This is important for ensuring delivery of responses that map to essential QSIG messages. The gateway SHALL support SDP in accordance with [8] and its use in accordance with the offer/answer model in [12]. Section 9 also specifies optional use of the Privacy header in accordance with [13] and the P-Asserted-Identity header in accordance with [14]. The gateway SHALL support calls from QSIG to SIP and calls from SIP to QSIG.
SIP methods not defined in [10] or [11] are outside the scope of this specification but could be the subject of other specifications for interworking with QSIG, e.g., for interworking in support of supplementary services. As a result of DNS lookup by the gateway in order to determine where to send a SIP INVITE request, a number of candidate destinations can be attempted in sequence. The way in which this is handled by the gateway is outside the scope of this specification. However, any behaviour specified in this document on receipt of a SIP 4xx or 5xx final response to an INVITE request SHOULD apply only when there are no more candidate destinations to try or when overlap signalling applies in the SIP network (see 8.2.2.2).
(page 12 continued on part 2)
