Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4497

Interworking between the Session Initiation Protocol (SIP) and QSIG

Pages: 65
Best Current Practice: 117
Updated by:  8996
Part 1 of 4 – Pages 1 to 12
None   None   Next

Top   ToC   RFC4497 - Page 1
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.
Top   ToC   RFC4497 - Page 2

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
Top   ToC   RFC4497 - Page 3
   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
Top   ToC   RFC4497 - Page 4

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.
Top   ToC   RFC4497 - Page 5
   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.
Top   ToC   RFC4497 - Page 6

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
Top   ToC   RFC4497 - Page 7

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
Top   ToC   RFC4497 - Page 8
   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
Top   ToC   RFC4497 - Page 9
   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.
Top   ToC   RFC4497 - Page 10
   +---------------------------------------------------------+
   |                   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.
Top   ToC   RFC4497 - Page 11
   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.
Top   ToC   RFC4497 - Page 12
   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)

Next Section