[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-elwell-sipping-qsig2sip) 00 01 02 03 04 RFC 4497

     Internet Engineering Task Force                              J. Elwell
     Internet Draft                                                 Siemens
                                                                   F. Derks
                                                                    Philips
                                                      P. Mourot/O. Rousseau
     draft-ietf-sipping-qsig2sip-02.txt                             Alcatel
     Expires: February 2004                                     August 2003
     
     
                          Interworking between SIP and QSIG
     
     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 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.
     
        As the support of telephony within corporate networks evolves from
        circuit-switched technology to Internet technology, the two
        technologies will co-exist 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
     
     
     Elwell et alia         Expires - February 2004               [Page 1]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        network and a participant in the QSIG network. Such calls are
        supported by gateways that perform interworking between SIP and QSIG.
     
        This document is a product of the authors' activities in ECMA
        (www.ecma-international.org) on interoperability of QSIG with IP
        networks. An earlier version is published as Standard ECMA-339. ECMA
        has made this work available to the IETF as the basis for publishing
        an RFC.
     
        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) (also known as
        enterprise network)...............................................5
        3.2.2 Gateway.....................................................5
        3.2.3 IP network..................................................5
        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.....................................6
        6 Overview........................................................9
        7 General requirements...........................................10
        8 Message mapping requirements...................................11
        8.1 Message validation and handling of protocol errors...........11
        8.2 Call establishment from QSIG to SIP..........................13
        8.2.1 Call establishment from QSIG to SIP using enbloc procedures13
        8.2.1.1 Receipt of QSIG SETUP message............................13
        8.2.1.2 Receipt of SIP 100 (Trying) response.....................13
        8.2.1.3 Receipt of SIP 18x provisional response..................14
        8.2.1.4 Receipt of SIP 2xx response..............................15
        8.2.1.5 Receipt of SIP 3xx response..............................15
        8.2.2 Call establishment from QSIG to SIP using overlap procedures15
        8.2.2.1 Enbloc signalling in SIP network.........................16
        8.2.2.1.1 Receipt of QSIG SETUP message..........................16
        8.2.2.1.2 Receipt of QSIG INFORMATION message....................16
        8.2.2.1.3 Receipt of SIP responses...............................16
        8.2.2.2 Overlap signalling in SIP network........................16
        8.2.2.2.1 Receipt of QSIG SETUP message..........................17
        8.2.2.2.2 Receipt of QSIG INFORMATION message....................17
        8.2.2.2.3 Receipt of SIP 100 (Trying) response...................18
        8.2.2.2.4 Receipt of SIP 18x provisional response................18
        8.2.2.2.5 Receipt of SIP 2xx response............................18
        8.2.2.2.6 Receipt of SIP 3xx response............................18
        8.2.2.2.7 Receipt of a SIP 4xx, 5xx or 6xx final response........18
        8.2.2.2.8 Receipt of multiple SIP responses......................18
        8.2.2.2.9 Cancelling pending SIP INVITE transactions.............18
     
     
     Elwell et alia         Expires - February 2004               [Page 2]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        8.2.2.2.10 QSIG timer T302 expiry................................19
        8.3 Call Establishment from SIP to QSIG..........................19
        8.3.1 Receipt of SIP INVITE request for a new call...............19
        8.3.2 Receipt of QSIG CALL PROCEEDING message....................20
        8.3.3 Receipt of QSIG PROGRESS message...........................20
        8.3.4 Receipt of QSIG ALERTING message...........................21
        8.3.5 Inclusion of SDP information in a SIP 18x provisional response
        .................................................................21
        8.3.6 Receipt of QSIG CONNECT message............................22
        8.3.7 Receipt of SIP PRACK request...............................23
        8.3.8 Receipt of SIP ACK request.................................23
        8.3.9 Receipt of a SIP INVITE request for a call already being
        established......................................................24
        8.4 Call clearing and call failure...............................24
        8.4.1 Receipt of a QSIG DISCONNECT, RELEASE or RELEASE COMPLETE
        message..........................................................24
        8.4.2 Receipt of a SIP BYE request...............................27
        8.4.3 Receipt of a SIP CANCEL request............................27
        8.4.4 Receipt of a SIP 4xx - 6xx response........................27
        8.4.5 Gateway-initiated call clearing............................29
        8.5 Request to change media characteristics......................30
        9 Number mapping.................................................30
        9.1 Mapping from QSIG to SIP.....................................30
        9.1.1 Using information from the QSIG Called party number information
        element..........................................................31
        9.1.2 Using information from the QSIG Calling party number
        information element..............................................31
        9.1.2.1 No URI derived and presentation indicator does not have value
        "presentation restricted"........................................31
        9.1.2.2 No URI derived and presentation indicator has value
        "presentation restricted"........................................31
        9.1.2.3 URI derived and presentation indicator has value
        "presentation restricted"........................................31
        9.1.2.4 URI derived and presentation indicator does not have value
        "presentation restricted"........................................32
        9.1.3 Using information from the QSIG Connected number information
        element..........................................................32
        9.1.3.1 No URI derived and presentation indicator does not have value
        "presentation restricted"........................................32
        9.1.3.2 No URI derived and presentation indicator has value
        "presentation restricted"........................................32
        9.1.3.3 URI derived and presentation indicator has value
        "presentation restricted"........................................33
        9.1.3.4 URI derived and presentation indicator does not have value
        "presentation restricted"........................................33
        9.2 Mapping from SIP to QSIG.....................................33
        9.2.1 Generating the QSIG Called party number information element33
        9.2.2 Generating the QSIG Calling party number information element34
        9.2.3 Generating the QSIG Connected number information element...34
     
     
     Elwell et alia         Expires - February 2004               [Page 3]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        10 Requirements for support of basic services....................35
        10.1 Derivation of QSIG Bearer capability information element....35
        10.2 Derivation of media type in SDP.............................36
        11 Security considerations.......................................36
        12 Acknowledgements..............................................39
        13 Author's Addresses............................................39
        14 Normative References..........................................40
        Annex A - Example message sequences..............................41
        Annex B - Change log.............................................56
     
     
     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.
     
        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 as a type of multimedia
        session where just audio is exchanged. SIP is defined in [10].
     
        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.
     
     
     Elwell et alia         Expires - February 2004               [Page 4]
     

                       Interworking between SIP and QSIG       August 2003
     
     
     
        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) (also known as enterprise
          network)
     
        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
     
     
     
     
     Elwell et alia         Expires - February 2004               [Page 5]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        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
     
     
     Elwell et alia         Expires - February 2004               [Page 6]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        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 24 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.
     
        Another way of migrating is to use a SIP network to interconnect two
        parts of a PISN and encapsulate QSIG signalling in SIP messages for
        calls between the two parts of the PISN. This is outside the scope of
        this specification but could be the subject of future work.
     
     
     Elwell et alia         Expires - February 2004               [Page 7]
     

                       Interworking between SIP and QSIG       August 2003
     
     
     
        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 information 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 information;
     
        -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
     
     
     
     Elwell et alia         Expires - February 2004               [Page 8]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        -a means of transferring media information in each direction between
        the PISN and the IP network, including as a minimum packetization of
        media information sent to the IP network and de-packetization of
        media information 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.
     
              +---------------------------------------------------------+
              |                  Inter-working 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 completes negotiation
        of the bearer channel to be used for that call. The gateway then
     
     
     Elwell et alia         Expires - February 2004               [Page 9]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        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 200 OK
        response 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.
     
        Annex 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 1. [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 2. [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].
     
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 10]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        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 look-up 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 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).
     
     8 Message mapping requirements
     
     8.1 Message validation and handling of protocol errors
     
        The gateway SHALL validate received QSIG messages in accordance with
        the requirements of [2] and SHALL act in accordance with [2] on
        detection of a QSIG protocol error. The requirements of this section
        for acting on a received QSIG message apply only to a received QSIG
        message that has been successfully validated and that satisfies one
        of the following conditions:
     
        -the QSIG message is a SETUP message and indicates a destination in
        the IP network and a bearer capability for which the gateway is able
        to provide interworking; or
     
        -the QSIG message is a message other than SETUP and contains a call
        reference that identifies an existing call for which the gateway is
        providing interworking between QSIG and SIP.
     
        The processing of any valid QSIG message that does not satisfy any of
        these conditions is outside the scope of this specification. Also the
        processing of any QSIG message relating to call-independent
        signalling connections or connectionless transport, as specified in
        [3], is outside the scope of this specification.
     
        If segmented QSIG messages are received, the gateway SHALL await
        receipt of all segments of a message and SHALL validate and act on
        the complete reassembled message.
     
     
     Elwell et alia         Expires - February 2004              [Page 11]
     

                       Interworking between SIP and QSIG       August 2003
     
     
     
        The gateway SHALL validate received SIP messages (requests and
        responses) in accordance with the requirements of [10] and SHALL act
        in accordance with [10] on detection of a SIP protocol error.
        Requirements of this section for acting on a received SIP message
        apply only to a received message that has been successfully validated
        and that satisfies one of the following conditions:
     
        -the SIP message is an INVITE request that contains no tag parameter
        in the To header field, does not match an ongoing transaction (i.e.,
        is not a merged request, see 8.2.2.2 of [10]) and indicates a
        destination in the PISN for which the gateway is able to provide
        interworking; or
     
        -the SIP message is a request that relates to an existing dialog
        representing a call for which the gateway is providing interworking
        between QSIG and SIP; or
     
        -the SIP message is a CANCEL request that relates to a received
        INVITE request for which the gateway is providing interworking with
        QSIG but for which the only response sent is informational (1xx), no
        dialog having been confirmed; or
     
        -the SIP message is a response to a request sent by the gateway in
        accordance with this section.
     
        The processing of any valid SIP message that does not satisfy any of
        these conditions is outside the scope of this specification.
     
        NOTE. These rules mean that an error detected in a received message
        will not be propagated to the other side of the gateway. However,
        there can be an indirect impact on the other side of the gateway,
        e.g., the initiation of call clearing procedures.
     
        The gateway SHALL run QSIG protocol timers as specified in [2] and
        SHALL act in accordance with [2] if a QSIG protocol timer expires.
        Any other action on expiry of a QSIG protocol timer is outside the
        scope of this specification, except that if it results in the
        clearing of the QSIG call, the gateway SHALL also clear the SIP call
        in accordance with 8.4.5.
     
        The gateway SHALL run SIP protocol timers as specified in [10] and
        SHALL act in accordance with [10] if a SIP protocol timer expires.
        Any other action on expiry of a SIP protocol timer is outside the
        scope of this specification, except that if it results in the
        clearing of the SIP call, the gateway SHALL also clear the QSIG call
        in accordance with 8.4.5.
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 12]
     

                       Interworking between SIP and QSIG       August 2003
     
     
     8.2 Call establishment from QSIG to SIP
     8.2.1 Call establishment from QSIG to SIP using enbloc procedures
     
        The following procedures apply when the gateway receives a QSIG SETUP
        message containing a Sending Complete information element or the
        gateway receives a QSIG SETUP message and is able to determine that
        the number in the Called party number information element is
        complete.
     
        NOTE. The means by which the gateway determines the number to be
        complete is an implementation matter. It can involve knowledge of the
        numbering plan and/or use of inter-digit timer expiry.
     
     8.2.1.1 Receipt of QSIG SETUP message
     
        On receipt of a QSIG SETUP message containing a number that the
        gateway determines to be complete in the Called party number
        information element, or containing a Sending complete information
        element and a number that the gateway cannot determine to be
        complete, the gateway SHALL map the QSIG SETUP message to a SIP
        INVITE request. The gateway SHALL also send a QSIG CALL PROCEEDING
        message.
     
        The gateway SHALL generate the SIP Request-URI, To and From fields in
        the SIP INVITE request in accordance with section 9. The gateway
        SHALL include in the INVITE request a Supported header containing
        option tag 100rel, to indicate support for [11].
     
        The gateway SHALL include SDP information in the SIP INVITE request
        as described in section 10.
     
        On receipt of a QSIG SETUP message containing a Sending complete
        information element and a number that the gateway determines to be
        incomplete in the Called party number information element, the
        gateway SHALL initiate QSIG call clearing procedures using cause
        value 28 "invalid number format (address incomplete)".
     
        If information in the QSIG SETUP message is unsuitable for generating
        any of the mandatory fields in a SIP INVITE request (e.g., if a
        Request-URI cannot be derived from the QSIG Called party number
        information element) or for generating SDP information, the gateway
        SHALL NOT issue a SIP INVITE request and SHALL initiate QSIG call
        clearing procedures in accordance with [2].
     
     8.2.1.2 Receipt of SIP 100 (Trying) response
     
        A SIP 100 response SHALL NOT trigger any QSIG messages. It only
        serves the purpose of suppressing INVITE request retransmissions.
     
     
     
     Elwell et alia         Expires - February 2004              [Page 13]
     

                       Interworking between SIP and QSIG       August 2003
     
     
     8.2.1.3 Receipt of SIP 18x provisional response
     
        The gateway SHALL map a received SIP 18x response to a QSIG PROGRESS
        or ALERTING message based on the following conditions.
     
        - If a SIP 180 response is received and no QSIG ALERTING message has
        been sent, the gateway SHALL generate a QSIG ALERTING message. The
        gateway MAY supply ring-back tone on the user information channel of
        the inter-PINX link, in which case the gateway SHALL include progress
        description number 8 in the QSIG ALERTING message. Otherwise the
        gateway SHALL NOT include progress description number 8 in the QSIG
        ALERTING message unless a media stream has been established towards
        the gateway and the gateway is aware that in-band information (e.g.,
        ring-back tone) is being transmitted.
     
        -If a SIP 181/182/183 response is received, no QSIG ALERTING message
        has been sent, no QSIG PROGRESS message containing progress
        description number 8 has been sent and a media stream has been
        established towards the gateway, the gateway SHALL generate a QSIG
        PROGRESS message. The QSIG PROGRESS message SHALL contain progress
        description number 8 in a Progress indicator information element. The
        gateway SHALL also connect the media streams to the corresponding
        user information channel of the inter-PINX link.
     
        -If a SIP 181/182/183 response is received, no QSIG ALERTING message
        has been sent, no QSIG PROGRESS message containing progress
        description number 1 or 8 has been sent and no media stream has been
        established towards the gateway, the gateway SHALL generate a QSIG
        PROGRESS message. The QSIG PROGRESS message SHALL contain progress
        description number 1 in a Progress indicator information element.
     
        NOTE 1. This will ensure that QSIG timer T310 is stopped if running
        at the Originating PINX.
     
        NOTE 2. Media streams are established as a result of receiving SDP
        answer information in a provisional response or receiving SDP offer
        information in a reliable provisional response and sending SDP answer
        information in a PRACK request. If a media stream is established
        towards the gateway, connecting the media stream  to the
        corresponding user information channel on the inter-PINX link will
        allow the caller to hear in-band tones or announcements.
     
        In all other scenarios the gateway SHALL NOT map the SIP 18x response
        to a QSIG message.
     
        If the SIP 18x response contains a Require header with option tag
        100rel, the gateway SHALL send back a SIP PRACK request in accordance
        with [11].
     
     
     
     Elwell et alia         Expires - February 2004              [Page 14]
     

                       Interworking between SIP and QSIG       August 2003
     
     
     8.2.1.4 Receipt of SIP 2xx response
     
        If the gateway receives a SIP 200 (OK) response as the first SIP 200
        response to a SIP INVITE request, the gateway SHALL map the SIP 200
        (OK) response to a QSIG CONNECT message. The gateway SHALL also send
        a SIP ACK request to acknowledge the 200 (OK) response. The gateway
        SHALL NOT include any SDP information in the SIP ACK request. If the
        gateway receives further 200 (OK) responses, it SHALL respond to each
        in accordance with [10] and SHALL NOT generate any further QSIG
        messages.
     
        Media streams will normally have been established in the IP network
        in each direction. If so, the gateway SHALL connect the media streams
        to the corresponding user-information channel on the inter-PINX link
        if it has not already done so and stop any local ring-back tone.
     
        If the SIP 200 (OK) response is received in response to the SIP PRACK
        request, the gateway SHALL NOT map this message to any QSIG message.
     
        If the gateway receives a SIP 2xx response other than 200 (OK), the
        gateway SHALL send a SIP ACK request but SHALL NOT take action on the
        QSIG side.
     
        NOTE. A SIP 200 (OK) response can be received later as a result of a
        forking proxy.
     
     8.2.1.5 Receipt of SIP 3xx response
     
        On receipt of a SIP 3xx response, the gateway SHALL act in accordance
        with [10].
     
        NOTE. This will normally result in sending a new SIP INVITE request.
     
        Unless the gateway supports the QSIG Call Diversion Supplementary
        Service, no QSIG message SHALL be sent. The definition of Call
        Diversion Supplementary Service for QSIG to SIP interworking is
        beyond the scope of this specification.
     
     8.2.2 Call establishment from QSIG to SIP using overlap procedures
     
        SIP uses en-bloc signalling and it is strongly RECOMMENDED to avoid
        using overlap signalling in a SIP network. A SIP/QSIG gateway dealing
        with overlap signalling, SHOULD perform a conversion from overlap to
        en-bloc signalling method using one or more of the following
        mechanisms:
     
        -timers;
     
        -numbering plan information;
     
     
     Elwell et alia         Expires - February 2004              [Page 15]
     

                       Interworking between SIP and QSIG       August 2003
     
     
     
        -the presence of a Sending complete information element in a received
        QSIG INFORMATION message.
     
        If the gateway performs a conversion from overlap to en-bloc
        signalling in the SIP network then the procedures defined in 8.2.2.1
        SHALL apply.
     
        However, for some applications it might be impossible to avoid using
        overlap signalling in the SIP network. In this case the procedures
        defined in 8.2.2.2 SHALL apply.
     
     8.2.2.1 Enbloc signalling in SIP network
     
     8.2.2.1.1 Receipt of QSIG SETUP message
     
        On receipt of a QSIG SETUP message containing no Sending complete
        information element and a number in the Called party number
        information element that the gateway cannot determine to be complete,
        the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message, start
        QSIG timer T302 and await further number digits.
     
     8.2.2.1.2 Receipt of QSIG INFORMATION message
     
        On receipt of each QSIG INFORMATION message containing no Sending
        complete information element and containing a number that the gateway
        cannot determine to be complete, QSIG timer T302 SHALL be restarted.
        When QSIG timer T302 expires or a QSIG INFORMATION message containing
        a Sending complete information element is received the gateway SHALL
        send a SIP INVITE request as described in 8.2.1.1. The Request-URI
        and To fields (see section 9) SHALL be generated from the
        concatenation of information in the Called party number information
        element in the received QSIG SETUP and INFORMATION messages. The
        gateway SHALL also send a QSIG CALL PROCEEDING message.
     
     8.2.2.1.3 Receipt of SIP responses
     
        SIP responses SHALL be mapped as described in 8.2.1.
     
     8.2.2.2 Overlap signalling in SIP network
     
        The procedures below for using overlap signalling in the SIP network
        are in accordance with the principles described in [18] for using
        overlap sending when interworking with ISUP. In [18] there is
        discussion of some potential problems arising from the use of overlap
        sending in the SIP network. These potential problems are applicable
        also in the context of QSIG-SIP interworking and can be avoided if
        overlap sending in the QSIG network is terminated at the gateway, in
     
     
     
     Elwell et alia         Expires - February 2004              [Page 16]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        accordance with 8.2.2.1. The procedures below should be used only
        where it is not feasible to use the procedures of 8.2.2.1.
     
     8.2.2.2.1 Receipt of QSIG SETUP message
     
        On receipt of a QSIG SETUP message containing no Sending complete
        information element and a number in the Called party number
        information element that the gateway cannot determine to be complete,
        the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message and
        start QSIG timer T302. If the QSIG SETUP message contains the minimum
        number of digits required to route the call in the IP network, the
        gateway SHALL send a SIP INVITE request as specified in 8.2.1.1.
        Otherwise the gateway SHALL wait for more digits to arrive in QSIG
        INFORMATION messages.
     
     8.2.2.2.2 Receipt of QSIG INFORMATION message
     
        On receipt of a QSIG INFORMATION message the gateway SHALL handle the
        QSIG timer T302 in accordance with [2].
     
        NOTE 1. [2] requires the QSIG timer to be stopped if the INFORMATION
        message contains a Sending complete information element or to be
        restarted otherwise.
     
        Further behaviour of the gateway SHALL depend on whether or not it
        has already sent a SIP INVITE request. If the gateway has not sent a
        SIP INVITE request and it now has the minimum number of digits
        required to route the call, it SHALL send a SIP INVITE request as
        specified in 8.2.2.1.2. If the gateway still does not have the
        minimum number of digits required it SHALL wait for more QSIG
        INFORMATION messages to arrive.
     
        If the gateway has already sent one or more SIP INVITE requests, and
        whether or not final responses to those requests have been received,
        it SHALL send a new SIP INVITE request in accordance with 3.2 of
        [18].The updated Request-URI and To fields (see section 9) SHALL be
        generated from the concatenation of information in the Called party
        number information element in the received QSIG SETUP and INFORMATION
        messages.
     
        NOTE 2. [18] requires the new request to have the same Call-ID and
        the same From header (including tag) as in the previous INVITE
        request. [18] recommends that the CSeq header should contain a value
        higher than that in the previous INVITE request.
     
        NOTE 3. The first SIP INVITE request and all subsequent SIP INVITE
        requests sent in this way belong to the same call but to different
        dialogs.
     
     
     
     Elwell et alia         Expires - February 2004              [Page 17]
     

                       Interworking between SIP and QSIG       August 2003
     
     
     8.2.2.2.3 Receipt of SIP 100 (Trying) response
     
        The requirements of 8.2.1.2 SHALL apply.
     
     8.2.2.2.4 Receipt of SIP 18x provisional response
     
        The requirements of 8.2.1.3 SHALL apply.
     
     8.2.2.2.5 Receipt of SIP 2xx response
     
        The requirements of 8.2.1.4 SHALL apply. In addition the gateway
        SHALL send a SIP CANCEL request in accordance with 3.4 of [18] to
        cancel any SIP INVITE transactions for which no final response has
        been received.
     
     8.2.2.2.6 Receipt of SIP 3xx response
     
        The requirements of 8.2.1.5 SHALL apply.
     
     8.2.2.2.7 Receipt of a SIP 4xx, 5xx or 6xx final response
     
        On receipt of a SIP 4xx, 5xx or 6xx final response the gateway SHALL
        send back a SIP ACK request. The gateway SHALL also send a QSIG
        DISCONNECT message (8.4.4) if no further QSIG INFORMATION messages
        are expected and final responses have been received to all
        transmitted SIP INVITE requests.
     
        NOTE 1. Further QSIG INFORMATION messages will not be expected after
        QSIG timer T302 has expired or after a Sending complete information
        element has been received.
     
        In all other cases the receipt of a SIP 484 response SHALL NOT
        trigger the sending of any QSIG message.
     
        NOTE 2. If further QSIG INFORMATION messages arrive, these will
        result in further SIP INVITE requests being sent, one of which might
        result in successful call establishment. For example, initial INVITE
        requests might produce 484 (Address Incomplete) or 404 (Not Found)
        responses because the Request-URIs derived from incomplete numbers
        cannot be routed, yet a subsequent INVITE request with a routable
        Request-URI might produce a 2xx final response or a more meaningful
        4xx, 5xx or 6xx final response.
     
     8.2.2.2.8 Receipt of multiple SIP responses
     
        3.3 of [18] applies.
     
     8.2.2.2.9 Cancelling pending SIP INVITE transactions
     
     
     
     Elwell et alia         Expires - February 2004              [Page 18]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        As stated in 3.4 of [18], when a gateway sends a new SIP INVITE
        request containing new digits, it SHOULD NOT send a SIP CANCEL
        request to cancel a previous SIP INVITE transaction that has not had
        a final response. This SIP CANCEL request could arrive at an egress
        gateway before the new SIP INVITE request and trigger premature call
        clearing.
     
        NOTE. Previous SIP INVITE transactions can be expected to result in
        SIP 4xx class responses, which terminate the transaction. In
        8.2.2.2.5 there is provision for cancelling any transactions still in
        progress after a SIP 2xx response has been received.
     
     8.2.2.2.10 QSIG timer T302 expiry
     
        If QSIG timer T302 expires and the gateway has received 4xx, 5xx or
        6xx responses to all transmitted SIP INVITE requests, the gateway
        SHALL send a QSIG DISCONNECT message. If T302 expires and the gateway
        has not received 4xx, 5xx or 6xx responses to all transmitted SIP
        INVITE requests, the gateway SHALL ignore any further QSIG
        INFORMATION messages but SHALL NOT send a QSIG DISCONNECT message at
        this stage.
     
        NOTE. A QSIG DISCONNECT request will be sent when all outstanding SIP
        INVITE requests have received 4xx, 5xx or 6xx responses.
     
     8.3 Call Establishment from SIP to QSIG
     
     8.3.1 Receipt of SIP INVITE request for a new call
     
        On receipt of a SIP INVITE request for a new call, and if a suitable
        channel is available on the inter-PINX link, the gateway SHALL
        generate a QSIG SETUP message from the received SIP INVITE request.
        The gateway SHALL generate the Called party number and Calling party
        number information elements in accordance with section 9 and SHALL
        generate the Bearer capability information element in accordance with
        section 10. If the gateway can determine that the number placed in
        the Called party number information element is complete, the gateway
        MAY include the Sending complete information element.
     
        NOTE 1. The means by which the gateway determines the number to be
        complete is an implementation matter. It can involve knowledge of the
        numbering plan and/or use of the inter-digit timer.
     
        The gateway SHOULD send a SIP 100 (Trying) response.
     
        If information in the SIP INVITE request is unsuitable for generating
        any of the mandatory information elements in a QSIG SETUP message
        (e.g., if a QSIG Called party number information element cannot be
        derived from SIP Request-URI field) or if no suitable channel is
     
     
     Elwell et alia         Expires - February 2004              [Page 19]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        available on the inter-PINX link, the gateway SHALL NOT issue a QSIG
        SETUP message and SHALL send a SIP 4xx, 5xx or 6xx response. If no
        suitable channel is available the gateway should use response code
        503 (Service Unavailable).
     
        If the SIP INVITE request does not contain SDP information and does
        not contain either a Required header or a Supported header with
        option tag 100rel, the gateway SHOULD send a SIP 488 (Not Acceptable
        Here) response, in which case it SHALL NOT issue a QSIG SETUP
        message.
     
        NOTE 2. The absence of SDP offer information in the SIP INVITE
        request means that the gateway might need to send SDP offer
        information in a provisional response and receive SDP answer
        information in a SIP PRACK request (in accordance with [11]) in order
        to ensure that tones and announcements from the PISN are transmitted.
        SDP offer information cannot be sent in an unreliable provisional
        response because SDP answer information would need to be returned in
        a SIP PRACK request. A gateway that has a priori knowledge that
        essential in-band information will not need to be sent before answer
        can choose to proceed with the call in these circumstances.
     
        NOTE 3. If SDP offer information is present in the INVITE request,
        the issuing of a QSIG SETUP message is not dependent on the presence
        of a Required header or a Supported header with option tag 100rel.
     
        On receipt of a SIP INVITE request relating to a call that has
        already been established from SIP to QSIG, the procedures of 8.3.9
        SHALL apply.
     
     8.3.2 Receipt of QSIG CALL PROCEEDING message
     
        The receipt of a QSIG CALL PROCEEDING message SHALL NOT result in any
        SIP message being sent.
     
     8.3.3 Receipt of QSIG PROGRESS message
     
        A QSIG PROGRESS message can be received in the event of interworking
        on the remote side of the PISN or if the PISN is unable to complete
        the call and generates an in-band tone or announcement. In the latter
        case a Cause information element is included in the QSIG PROGRESS
        message.
     
        The gateway SHALL map a received QSIG PROGRESS message to a SIP 183
        (Session Progress) response. If the SIP INVITE request contained
        either a Require header or a Supported header with option tag 100rel,
        the gateway SHALL include in the SIP 183 response a Require header
        with option tag 100rel.
     
     
     
     Elwell et alia         Expires - February 2004              [Page 20]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        NOTE. In accordance with [11], inclusion of option tag 100rel in a
        provisional response instructs the UAC to acknowledge the provisional
        response by sending a PRACK request. [11] also specifies procedures
        for repeating a provisional response with option tag 100rel if no
        PRACK is received.
     
        If the QSIG PROGRESS message contained a Progress indicator
        information element with Progress description number 1 or 8, the
        gateway SHALL connect the media streams to the corresponding user
        information channel of the inter-PINX link if it has not already done
        so, provided SDP answer information is included in the transmitted
        SIP response or has already been sent or received. Inclusion of SDP
        offer or answer information in the 183 provisional response SHALL be
        in accordance with 8.3.5.
     
        If the QSIG PROGRESS message is received with a Cause information
        element, the gateway SHALL either wait until the tone/announcement is
        complete or has been applied for sufficient time before initiating
        call clearing, or wait for a SIP CANCEL request. If call clearing is
        initiated, the cause value in the QSIG PROGRESS message SHALL be used
        to derive the response to the SIP INVITE request in accordance with
        table 1.
     
     8.3.4 Receipt of QSIG ALERTING message
     
        The gateway SHALL map a QSIG ALERTING message to a SIP 180 (Ringing)
        response. If the SIP INVITE request contained either a Require header
        or a Supported header with option tag 100rel, the gateway SHALL
        include in the SIP 180 response a Require header with option tag
        100rel.
     
        NOTE. In accordance with [11], inclusion of option tag 100rel in a
        provisional response instructs the UAC to acknowledge the provisional
        response by sending a PRACK request. [11] also specifies procedures
        for repeating a provisional response with option tag 100rel if no
        PRACK is received.
     
        If the QSIG ALERTING message contained a Progress indicator
        information element with Progress description number 1 or 8, the
        gateway SHALL connect the media streams to the corresponding user
        information channel of the inter-PINX link if it has not already done
        so, provided SDP answer information is included in the transmitted
        SIP response or has already been sent or received. Inclusion of SDP
        offer or answer information in the 180 provisional response SHALL be
        in accordance with 8.3.5.
     
     8.3.5 Inclusion of SDP information in a SIP 18x provisional response
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 21]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        When sending a SIP 18x provisional response, if a QSIG message
        containing a Progress indicator information element with progress
        description number 1 or 8 has been received the gateway SHALL include
        SDP information. Otherwise the gateway MAY include SDP information.
        If SDP information is included it shall be in accordance with the
        following rules.
     
        If the SIP INVITE request contained a Required or Supported header
        with option tag 100rel, and if SDP offer and answer information has
        already been exchanged, no SDP information SHALL be included in the
        SIP 18x provisional response.
     
        If the SIP INVITE request contained a Required or Supported header
        with option tag 100rel, and if SDP offer information was received in
        the SIP INVITE request but no SDP answer information has been sent,
        SDP answer information SHALL be included in the SIP 18x provisional
        response.
     
        If the SIP INVITE request contained a Required or Supported header
        with option tag 100rel, and if no SDP offer information was received
        in the SIP INVITE request and no SDP offer information has already
        been sent, SDP offer information SHALL be included in the SIP 18x
        provisional response.
     
        NOTE 1. In this case, SDP answer information can be expected in the
        SIP PRACK.
     
        If the SIP INVITE request contained neither a Required nor a
        Supported header with option tag 100rel, SDP answer information SHALL
        be included in the SIP 18x provisional response.
     
        NOTE 2. Because the provisional response is unreliable, SDP answer
        information needs to be repeated in each provisional response and in
        the final SIP 2xx response.
     
        NOTE 3. If the SIP INVITE request contained no SDP offer information
        and neither a Required nor a Supported header with option tag 100rel,
        it should have been rejected in accordance with 8.3.1.
     
     8.3.6 Receipt of QSIG CONNECT message
     
        The gateway SHALL map a QSIG CONNECT message to a SIP 200 (OK) final
        response for the SIP INVITE request. The gateway SHALL also send a
        QSIG CONNECT ACKNOWLEDGE message.
     
        If the SIP INVITE request contained a Required or Supported header
        with option tag 100rel, and if SDP offer and answer information has
        already been exchanged, no SDP information SHALL be included in the
        SIP 200 response.
     
     
     Elwell et alia         Expires - February 2004              [Page 22]
     

                       Interworking between SIP and QSIG       August 2003
     
     
     
        If the SIP INVITE request contained a Required or Supported header
        with option tag 100rel, and if SDP offer information was received in
        the SIP INVITE request but no SDP answer information has been sent,
        SDP answer information SHALL be included in the SIP 200 response.
     
        If the SIP INVITE request contained a Required or Supported header
        with option tag 100rel, and if no SDP offer information was received
        in the SIP INVITE request and no SDP offer information has already
        been sent, SDP offer information SHALL be included in the SIP 200
        response.
     
        NOTE 1. In this case, SDP answer information can be expected in the
        SIP ACK.
     
        If the SIP INVITE request contained neither a Required nor a
        Supported header with option tag 100rel, SDP answer information SHALL
        be included in the SIP 200 response.
     
        NOTE 2. Because the provisional response is unreliable, SDP answer
        information needs to be repeated in each provisional response and in
        the final 2xx response.
     
        NOTE 3. If the SIP INVITE request contained no SDP offer information
        and neither a Required nor a Supported header with option tag 100rel,
        it should have been rejected in accordance with 8.3.1.
     
        The gateway SHALL connect the media streams to the corresponding user
        information channel of the inter-PINX link if it has not already done
        so, provided SDP answer information is included in the transmitted
        SIP response or has already been sent or received.
     
     8.3.7 Receipt of SIP PRACK request
     
        The receipt of a SIP PRACK request acknowledging a reliable
        provisional response SHALL NOT result in any QSIG message being sent.
        The gateway SHALL send back a SIP 200 (OK) response to the SIP PRACK
        request.
     
        If the SIP PRACK contains SDP answer information and a QSIG message
        containing a Progress indicator information element with progress
        description number 1 or 8 has been received, the gateway SHALL
        connect the media streams to the corresponding user information
        channel of the inter-PINX link.
     
     8.3.8 Receipt of SIP ACK request
     
        The receipt of a SIP ACK request SHALL NOT result in any QSIG message
        being sent.
     
     
     Elwell et alia         Expires - February 2004              [Page 23]
     

                       Interworking between SIP and QSIG       August 2003
     
     
     
        If the SIP ACK contains SDP answer information, the gateway SHALL
        connect the media streams to the corresponding user information
        channel of the inter-PINX link if it has not already done so.
     
     8.3.9 Receipt of a SIP INVITE request for a call already being
          established
     
        For a call from SIP using overlap procedures, the gateway will
        receive multiple SIP INVITE requests that belong to the same call but
        have different Request-URI and To fields. Each SIP INVITE request
        belongs to a different dialog.
     
        A SIP INVITE request is considered to be for the purpose of overlap
        sending if, compared to a previously received SIP INVITE request, it
        has:
     
        - the same Call-ID header;
        - the same From header (including the tag);
        - no tag in the To header;
        - an updated Request-URI from which can be derived a called party
        number with a superset of the digits derived from the previously
        received SIP INVITE request;
        - the gateway has not yet sent a final response other than 484 to the
        previously received SIP INVITE request.
     
        If a gateway receives a SIP INVITE request for the purpose of overlap
        sending, it SHALL generate a QSIG INFORMATION message using the call
        reference of the existing QSIG call instead of a new QSIG SETUP
        message and containing only the additional digits in the Called party
        number information element. It SHALL also respond to the SIP INVITE
        request received previously with a SIP 484 Address Incomplete
        response.
     
        If a gateway receives a SIP INVITE request that meets all of the
        conditions for a SIP INVITE request for the purpose of overlap
        sending except the condition concerning the Request-URI, , the
        gateway SHALL respond to the new request with a SIP 485 (Ambiguous)
        response.
     
     8.4 Call clearing and call failure
     
     8.4.1 Receipt of a QSIG DISCONNECT, RELEASE or RELEASE COMPLETE message
     
        On receipt of QSIG DISCONNECT, RELEASE or RELEASE COMPLETE message as
        the first QSIG call clearing message, gateway behaviour SHALL depend
        on the state of call establishment.
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 24]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        1)If the gateway has sent a SIP 200 (OK) response to a SIP INVITE
        request and received a SIP ACK request or has received a SIP 200 (OK)
        response to a SIP INVITE request and sent a SIP ACK request, the
        gateway SHALL send a SIP BYE request to clear the call.
     
        2)If the gateway has sent a SIP 200 (OK) response to a SIP INVITE
        request (indicating that call establishment is complete) but has not
        received a SIP ACK request, the gateway SHALL wait until a SIP ACK is
        received and then send a SIP BYE request to clear the call.
     
        3)If the gateway has sent a SIP INVITE request and received a SIP
        provisional response but not a SIP final response, the gateway SHALL
        send a SIP CANCEL request to clear the call.
     
        NOTE 1. In accordance with [10], if after sending a SIP CANCEL
        request a SIP 2xx response is received to the SIP INVITE request, the
        gateway will need to send a SIP BYE request.
     
        4)If the gateway has sent a SIP INVITE request but received no SIP
        response, the gateway SHALL NOT send a SIP message. If a SIP final or
        provisional response is subsequently received, the gateway SHALL then
        act in accordance with 1, 2 or 3 above respectively.
     
        5)If the gateway has received a SIP INVITE request but not sent a SIP
        final response, the gateway SHALL send a SIP final response chosen
        according to the cause value in the received QSIG message as
        specified in table 1. SIP response 500 (Server internal error) SHALL
        be used as the default for cause values not shown in table 1.
     
        NOTE 2. It is not necessarily appropriate to map some QSIG cause
        values to SIP messages because these cause values are meaningful only
        at the gateway.  A good example of this is cause value 44 "Requested
        circuit or channel not available", which signifies that the channel
        number in the transmitted QSIG SETUP message was not acceptable to
        the peer PINX. The appropriate behavior in this case is for the
        gateway to send another SETUP message indicating a different channel
        number. If this is not possible, the gateway should treat it either
        as a congestion situation (no channels available, see 8.3.1) or as a
        gateway failure situation (in which case the default SIP response
        code applies).
     
        In all cases the gateway SHALL also disconnect media streams, if
        established, and allow QSIG and SIP signalling to complete in
        accordance with [2] and [10] respectively.
     
     
        Table 1 - Mapping of QSIG Cause Value to SIP 4xx-6xx responses
     
         QSIG Cause value               SIP response
     
     
     Elwell et alia         Expires - February 2004              [Page 25]
     

                       Interworking between SIP and QSIG       August 2003
     
     
         1 Unallocated number           404 Not found
         2 No route to specified        404 Not found
         transit network
         3 No route to destination      404 Not found
         16 Normal call clearing        (NOTE 3)
         17 User busy                   486 Busy here
         18 No user responding          408 Request timeout
         19 No answer from the user     480 Temporarily unavailable
         20 Subscriber absent           480 Temporarily unavailable
         21 Call rejected               603 Decline, if location field
                                        in Cause information element
                                        indicates user. Otherwise:
                                        403 Forbidden
         22 Number changed              301 Moved permanently, if
                                        information in diagnostic field
                                        of Cause information element is
                                        suitable for generating a SIP
                                        Contact header. Otherwise:
                                        410 Gone
         23 Redirection to new          410 Gone
         destination
         27 Destination out of order    502 Bad gateway
         28 Address incomplete          484 Address incomplete
         29 Facility rejected           501 Not implemented
         31 Normal, unspecified         480 Temporarily unavailable
         34 No circuit/channel          503 Service unavailable
         available
         38 Network out of order        503 Service unavailable
         41 Temporary failure           503 Service unavailable
         42 Switching equipment         503 Service unavailable
         congestion
         47 Resource unavailable,       503 Service unavailable
         unspecified
         55 Incoming calls barred       403 Forbidden
         within CUG
         57 Bearer capability not       403 Forbidden
         authorized
         58 Bearer capability not       503 Service unavailable
         presently available
         65 Bearer capability not       488 Not acceptable here (NOTE
         implemented                    4)
         69 Requested facility not      501 Not implemented
         implemented
         70 Only restricted digital     488 Not acceptable here (NOTE
         information available          4)
         79 Service or option not       501 Not implemented
         implemented, unspecified
         87 User not member of CUG      403 Forbidden
         88 Incompatible destination    503 Service unavailable
     
     
     Elwell et alia         Expires - February 2004              [Page 26]
     

                       Interworking between SIP and QSIG       August 2003
     
     
         102 Recovery on timer expiry   504 Server time-out
     
        NOTE 3. A QSIG call clearing message containing cause value 16 will
        normally result in the sending of a SIP BYE or CANCEL request.
        However, if a SIP response is to be sent, the default response code
        should be used.
     
        NOTE 4. The gateway may include a SIP Warning header if diagnostic
        information in the QSIG Cause information element allows a suitable
        warning code to be selected.
     
     8.4.2 Receipt of a SIP BYE request
     
        On receipt of a SIP BYE request, the gateway SHALL send a QSIG
        DISCONNECT message with cause value 16 (normal call clearing). The
        gateway SHALL also disconnect media streams, if established, and
        allow QSIG and SIP signalling to complete in accordance with [2] and
        [10] respectively.
     
        NOTE. When responding to a SIP BYE request, in accordance with [10]
        the gateway is also required to respond to any other outstanding
        transactions, e.g., with a SIP 487 (Request Terminated) response.
        This applies in particular if the gateway has not yet returned a
        final response to the SIP INVITE request.
     
     8.4.3 Receipt of a SIP CANCEL request
     
        On receipt of a SIP CANCEL request to clear a call for which the
        gateway has not sent a SIP final response to the received SIP INVITE
        request, the gateway SHALL send a QSIG DISCONNECT message with cause
        value 16 (normal call clearing). The gateway SHALL also disconnect
        media streams, if established, and allow QSIG and SIP signalling to
        complete in accordance with [2] and [10] respectively.
     
     8.4.4 Receipt of a SIP 4xx - 6xx response
     
        Except where otherwise specified in the context of overlap sending
        (8.2.2.2), on receipt of a SIP final response (4xx-6xx) to a SIP
        INVITE request, the gateway SHALL transmit a QSIG DISCONNECT message.
        The cause value in the QSIG DISCONNECT message SHALL be derived from
        the SIP 4xx-6xx response according to table 2. Cause value 31
        (Normal, unspecified) SHALL be used as the default for SIP responses
        not shown in table 2. The gateway SHALL also disconnect media
        streams, if established, and allow QSIG and SIP signalling to
        complete in accordance with [2] and [10] respectively.
     
        When generating a QSIG Cause information element, the location field
        SHOULD contain the value "user" if generated as a result of a SIP
     
     
     
     Elwell et alia         Expires - February 2004              [Page 27]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        response code 6xx or the value "Private network serving the remote
        user" in other circumstances.
     
        Table 2 - Mapping of SIP 4xx-6xx responses to QSIG Cause values
     
     SIP response                        QSIG Cause value
     400 Bad request                     41 Temporary failure
     401 Unauthorized                    21 Call rejected (NOTE 1)
     402 Payment required                21 Call rejected
     403 Forbidden                       21 Call rejected
     404 Not found                       1 Unallocated number
     405 Method not allowed              63 Service or option
                                         unavailable, unspecified
     406 Not acceptable                  79 Service or option not
                                         implemented, unspecified
     407 Proxy Authentication required   21 Call rejected (NOTE 1)
     408 Request timeout                 102 Recovery on timer expiry
     410 Gone                            22 Number changed
     413 Request entity too large        127 Interworking, unspecified
                                         (NOTE 2)
     414 Request-URI too long            127 Interworking, unspecified
                                         (NOTE 2)
     415 Unsupported media type          79 Service or option not
                                         implemented, unspecified (NOTE
                                         2)
     416 Unsupported URI scheme          127 Interworking, unspecified
                                         (NOTE 2)
     420 Bad extension                   127 Interworking, unspecified
                                         (NOTE 2)
     421 Extension required              127 Interworking, unspecified
                                         (NOTE 2)
     423 Interval too brief              127 Interworking, unspecified
                                         (NOTE 2)
     480 Temporarily unavailable         18 No user responding
     481 Call/transaction does not exist 41 Temporary failure
     482 Loop detected                   25 Exchange routing error
     483 Too many hops                   25 Exchange routing error
     484 Address incomplete              28 Invalid number format (NOTE
                                         2)
     485 Ambiguous                       1  Unallocated Number
     486 Busy here                       17 User busy
     487 Request terminated              (NOTE 3)
     488 Not Acceptable Here             65 Bearer capability not
                                         implemented or 31 Normal,
                                         unspecified(NOTE 4)
     500 Server internal error           41 Temporary failure
     501 Not implemented                 79 Service or option not
                                         implemented, unspecified
     502 Bad gateway                     38 Network out of order
     
     
     Elwell et alia         Expires - February 2004              [Page 28]
     

                       Interworking between SIP and QSIG       August 2003
     
     
     503 Service unavailable             41 Temporary failure
     504 Gateway time-out                102 Recovery on timer expiry
     505 Version not supported           127 Interworking, unspecified
                                         (NOTE 2)
     513 Message too large               127 Interworking, unspecified
                                         (NOTE 2)
     600 Busy everywhere                 17 User busy
     603 Decline                         21 Call rejected
     604 Does not exist anywhere         1  Unallocated number
     606 Not acceptable                  65 Bearer capability not
                                         implemented or
                                         31 Normal, unspecified(NOTE 4)
     
        NOTE 1. In some cases, it may be possible for the gateway to provide
        credentials to the SIP UAS that is rejecting an INVITE due to
        authorization failure.  If the gateway can authenticate itself, then
        obviously it should do so and proceed with the call. Only if the
        gateway cannot authorize itself should the gateway clear the call in
        the QSIG network with this cause value.
     
        NOTE 2. If at all possible, the gateway should respond to these
        protocol errors by remedying unacceptable behavior and attempting to
        re-originate the session.  Only if this proves impossible should the
        gateway clear the call in the QSIG network with this cause value.
     
        NOTE 3. The circumstances in which SIP response code 487 can be
        expected to arise do not require it to be mapped to a QSIG cause
        code, since the QSIG call will normally already be cleared or in the
        process of clearing. If QSIG call clearing does, however, need to be
        initiated, the default cause value should be used.
     
        NOTE 4. When the Warning header is present in a SIP 606 or 488
        message, the warning code should be examined to determine whether it
        is reasonable to generate cause value 65. This cause value should be
        generated only if there is a chance that a new call attempt with
        different content in the Bearer capability information element will
        avoid the problem. In other circumstances the default cause value
        should be used.
     
     8.4.5 Gateway-initiated call clearing
     
        If the gateway initiates clearing of the QSIG call owing to QSIG
        timer expiry, QSIG protocol error or use of the QSIG RESTART message
        in accordance with [2], the gateway SHALL also initiate clearing of
        the SIP call in accordance with 8.4.1. If this involves the sending
        of a final response to a SIP INVITE request, the gateway SHALL use
        response code 480 (Temporarily Unavailable) if optional QSIG timer
        T301 has expired or otherwise response code 408 (Request timeout) or
        500 (Server internal error) as appropriate.
     
     
     Elwell et alia         Expires - February 2004              [Page 29]
     

                       Interworking between SIP and QSIG       August 2003
     
     
     
        If the gateway initiates clearing of the SIP call owing to SIP timer
        expiry or SIP protocol error in accordance with [10], the gateway
        SHALL also initiate clearing of the QSIG call in accordance with [2]
        using cause value 102 (Recovery on timer expiry) or 41 (Temporary
        failure) as appropriate.
     
     8.5 Request to change media characteristics
     
        If after a call has been successfully established the gateway
        receives a SIP INVITE request to change the media characteristics of
        the call in a way that would be incompatible with the bearer
        capability in use within the PISN, the gateway SHALL send back a SIP
        503 (Service unavailable) response and SHALL NOT change the media
        characteristics of the existing call.
     
     9 Number mapping
     
        In QSIG, users are identified by numbers, as defined in [1]. Numbers
        are conveyed within the Called party number, Calling party number and
        Connected number information elements. The Calling party number and
        Connected number information elements also contain a presentation
        indicator, which can indicate that privacy is required (presentation
        restricted) and a screening indicator that indicates the source and
        authentication status of the number.
     
        In SIP, users are identified by Universal Resource Identifiers (URIs)
        conveyed within the Request-URI and various headers, including the
        From and To headers specified in [10] and the P-Asserted-Identity
        header specified in [14]. In addition, privacy is indicated by the
        Privacy header specified in [13].
     
        This clause specifies the mapping between QSIG Called party number,
        Calling party number and Connected number information elements and
        corresponding elements in SIP.
     
        A gateway MAY implement the P-Asserted-Identity header in accordance
        with [14]. If a gateway implements the P-Asserted-Identity header it
        SHALL also implement the Privacy header in accordance with [13]. If a
        gateway does not implement the P-Asserted-Identity header it MAY
        implement the Privacy header.
     
     9.1 Mapping from QSIG to SIP
     
        The method used to convert a number to a URI is outside the scope of
        this specification. However, the gateway SHOULD take account of the
        Numbering Plan (NPI) and Type Of Number (TON) fields in the QSIG
        information element concerned when interpreting a number.
     
     
     
     Elwell et alia         Expires - February 2004              [Page 30]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        Some aspects of mapping depend on whether the gateway trusts the
        adjacent proxy (i.e., the proxy to which the INVITE request is sent
        or from which INVITE request is received) to honour requests for
        identity privacy in the Privacy header. This will be network-
        dependent and it is RECOMMENDED that gateways supporting the
        P-Asserted-Identity header be configurable to either trust or not
        trust the proxy in this respect.
     
     9.1.1 Using information from the QSIG Called party number information
          element
     
        When mapping a QSIG SETUP message to a SIP INVITE request, the
        gateway SHALL convert the number in the QSIG Called party number
        information to a URI and include that URI in the SIP Request-URI and
        in the To header.
     
     9.1.2 Using information from the QSIG Calling party number information
          element
     
        When mapping a QSIG SETUP message to a SIP INVITE request, the
        gateway SHALL use the Calling party number information element, if
        present, as follows.
     
        If the information element contains a number, the gateway SHALL
        attempt to derive a URI from that number. Further behaviour depends
        on whether a URI has been derived and the value of the presentation
        indication.
     
     9.1.2.1 No URI derived and presentation indicator does not have value
           "presentation restricted"
     
        In this case (including the case where the Calling party number
        information element is absent) the gateway SHALL NOT generate a
        P-Asserted-Identity header, SHALL NOT generate a Privacy header and
        SHALL include a URI identifying the gateway in the From header.
     
     9.1.2.2 No URI derived and presentation indicator has value
           "presentation restricted"
     
        In this case the gateway SHALL NOT generate a P-Asserted-Identity
        header, SHALL generate a Privacy header with parameter priv-value =
        "id" if the gateway supports this header, and SHALL generate an
        anonymous From header. The inclusion of additional values of the
        priv-value parameter in the Privacy header is outside the scope of
        this specification.
     
     9.1.2.3 URI derived and presentation indicator has value "presentation
           restricted"
     
     
     
     Elwell et alia         Expires - February 2004              [Page 31]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        If the gateway supports the P-Asserted-Identity header and trusts the
        proxy to honour the Privacy header, the gateway SHALL generate a
        P-Asserted-Identity header containing the derived URI, SHALL generate
        a Privacy header with parameter priv-value = "id" and SHALL generate
        an anonymous From header. The inclusion of additional values of the
        priv-value parameter in the Privacy header is outside the scope of
        this specification.
     
        If the gateway does not support the P-Asserted-Identity header or
        does not trust the proxy to honour the Privacy header, the gateway
        SHALL behave as in 9.1.2.2.
     
     9.1.2.4 URI derived and presentation indicator does not have value
           "presentation restricted"
     
        In this case the gateway SHALL generate a P-Asserted-Identity header
        containing the derived URI if the gateway supports this header, SHALL
        NOT generate a Privacy header and SHALL include the derived URI in
        the From header.
     
     9.1.3 Using information from the QSIG Connected number information
          element
     
        When mapping a QSIG CONNECT message to a SIP 200 (OK) response to an
        INVITE request, the gateway SHALL use the Connected number
        information element, if present, as follows.
     
        If the information element contains a number, the gateway SHALL
        attempt to derive a URI from that number. Further behaviour depends
        on whether a URI has been derived and the value of the presentation
        indication.
     
     9.1.3.1 No URI derived and presentation indicator does not have value
           "presentation restricted"
     
        In this case (including the case where the Connected number
        information element is absent) the gateway SHALL NOT generate a
        P-Asserted-Identity header and SHALL NOT generate a Privacy header.
     
     9.1.3.2 No URI derived and presentation indicator has value
           "presentation restricted"
     
        In this case the gateway SHALL NOT generate a P-Asserted-Identity
        header and SHALL generate a Privacy header with parameter priv-value
        = "id" if the gateway supports this header. The inclusion of
        additional values of the priv-value parameter in the Privacy header
        is outside the scope of this specification.
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 32]
     

                       Interworking between SIP and QSIG       August 2003
     
     
     9.1.3.3 URI derived and presentation indicator has value "presentation
           restricted"
     
        If the gateway supports the P-Asserted-Identity header and trusts the
        proxy to honour the Privacy header, the gateway SHALL generate a
        P-Asserted-Identity header containing the derived URI and SHALL
        generate a Privacy header with parameter priv-value = "id". The
        inclusion of additional values of the priv-value parameter in the
        Privacy header is outside the scope of this specification.
     
        If the gateway does not support the P-Asserted-Identity header or
        does not trust the proxy to honour the Privacy header, the gateway
        SHALL behave as in 9.1.3.2.
     
     9.1.3.4 URI derived and presentation indicator does not have value
           "presentation restricted"
     
        In this case the gateway SHALL generate a P-Asserted-Identity header
        containing the derived URI if the gateway supports this header and
        SHALL NOT generate a Privacy header.
     
     9.2 Mapping from SIP to QSIG
     
        The method used to convert a URI to a number is outside the scope of
        this specification. However, NPI and TON fields in the QSIG
        information element concerned SHALL be set to appropriate values in
        accordance with [1].
     
        Some aspects of mapping depend on whether the gateway trusts the
        adjacent proxy (i.e., the proxy to which the INVITE request is sent
        or from which INVITE request is received) to provide accurate
        information in the P-Asserted-Identity header. This will be network-
        dependent and it is RECOMMENDED that gateways be configurable to
        either trust or not trust the proxy in this respect.
     
        Some aspects of mapping depend on whether the gateway is prepared to
        use a URI in the From header to derive a number for the Calling party
        number information element. The default behaviour SHOULD be not to
        use the From header for this purpose, since in principle the
        information comes from an untrusted source (the remote UA). However,
        it is recognised that some network administrations may consider that
        the benefits to be derived from supplying a calling party number
        outweigh any risks of supplying false information. Therefore a
        gateway MAY be configurable to use the From header for this purpose.
     
     9.2.1 Generating the QSIG Called party number information element
     
        When mapping a SIP INVITE request to a QSIG SETUP message, the
        gateway SHALL convert the URI in the SIP Request-URI to a number and
     
     
     Elwell et alia         Expires - February 2004              [Page 33]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        include that number in the QSIG Called party number information
        element.
     
        NOTE. The To header should not be used for this purpose. This is
        because re-targeting of the request in the SIP network can change the
        Request-URI but leave the To header unchanged. It is important that
        routing in the QSIG network be based on the final target from the SIP
        network.
     
     9.2.2 Generating the QSIG Calling party number information element
     
        When mapping a SIP INVITE request to a QSIG SETUP message, the
        gateway SHALL generate a Calling party number information element as
        follows.
     
        If the SIP INVITE request contains a P-Asserted-Identity header and
        the gateway supports that header and trusts the information therein,
        the gateway SHALL attempt to derive a number from the URI in that
        header. If a number is derived from the P-Asserted-Identity header,
        the gateway SHALL include it in the Calling party number information
        element and include value "network provided" in the screening
        indicator.
     
        If no number is derivable from a P-Asserted-Identity header
        (including the case where there is no P-Asserted-Identity header) and
        if the gateway is prepared to use the From header, the gateway SHALL
        attempt to derive a number from the URI in the From header. If a
        number is derived from the From header, the gateway SHALL include it
        in the Calling party number information element and include value
        "user provided, not screened" in the screening indicator.
     
        If no number is derivable, the gateway SHALL NOT include a number in
        the Calling party number information element.
     
        If the SIP INVITE request contains a Privacy header with value "id"
        in parameter priv-value and the gateway supports this header, the
        gateway SHALL include value "presentation restricted" in the
        presentation indicator. Otherwise the gateway SHALL include value
        "presentation allowed" if a number is present or "not available due
        to interworking" if no number is present.
     
        If the resulting Calling party number information element contains no
        number and value "not available due to interworking" in the
        presentation indicator, the gateway MAY omit the information element
        from the QSIG SETUP message.
     
     9.2.3 Generating the QSIG Connected number information element
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 34]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        When mapping a SIP 200 (OK) response to an INVITE request to a QSIG
        CONNECT message, the gateway SHALL generate a Connected number
        information element as follows.
     
        If the SIP 200 (OK) response contains a P-Asserted-Identity header
        and the gateway supports that header and trusts the information
        therein, the gateway SHALL attempt to derive a number from the URI in
        that header. If a number is derived from the P-Asserted-Identity
        header, the gateway SHALL include it in the Connected number
        information element and include value "network provided" in the
        screening indicator.
     
        If no number is derivable (including the case where there is no
        P-Asserted-Identity header), the gateway SHALL NOT include a number
        in the Connected number information element.
     
        If the SIP 200 (OK) response contains a Privacy header with value
        "id" in parameter priv-value and the gateway supports this header,
        the gateway SHALL include value "presentation restricted" in the
        presentation indicator. Otherwise the gateway SHALL include value
        "presentation allowed" if a number is present or "not available due
        to interworking" if no number is present.
     
        If the resulting Connected number information element contains no
        number and value "not available due to interworking" in the
        presentation indicator, the gateway MAY omit the information element
        from the QSIG CONNECT message.
     
     10 Requirements for support of basic services
     
        This document specifies signalling interworking for basic services
        that provide a bi-directional transfer capability for speech,
        facsimile and modem media between the two networks.
     
     10.1 Derivation of QSIG Bearer capability information element
     
        The gateway SHALL generate the Bearer Capability Information Element
        in the QSIG SETUP message based on SDP offer information received
        along with the SIP INVITE request. If the SIP INVITE request does not
        contain SDP offer information or the media type in the SDP offer
        information is only 'audio' then the Bearer capability information
        element SHALL BE generated according to table 3. Coding of the Bearer
        capability information element for other media types is outside the
        scope of this specification.
     
        In addition, the gateway MAY include a Low layer compatibility
        information element and/or High layer compatibility information in
        the QSIG SETUP message if the gateway is able to derive relevant
     
     
     
     Elwell et alia         Expires - February 2004              [Page 35]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        information from the SDP offer information. Specific mappings are
        outside the scope of this specification.
     
        Table 3 - Bearer capability encoding for 'audio' transfer
     
     Field                          Value
     Coding Standard                "CCITT standardized coding" (00)
     Information transfer           "3,1 kHz audio" (10000)
     capability
     Transfer mode                  "circuit mode" (00)
     Information transfer rate      "64 Kbits/s" (10000)
     Multiplier                     Octet omitted
     User information layer 1       Generated by gateway based on
     protocol                       Information of the PISN. Supported
                                    values are
                                    "CCITT recommendation G.711 mu-law"
                                    (00010)
                                    "CCITT recommendation G.711 A-law"
                                    (00011)
     
     
     10.2 Derivation of media type in SDP
     
        The gateway SHALL generate SDP offer information to include in the
        SIP INVITE request based on information in the QSIG SETUP message.
        The gateway MAY take account of QSIG Low layer compatibility and/or
        High layer compatibility information elements, if present in the QSIG
        SETUP message, when deriving SDP offer information, in which case
        specific mappings are outside the scope of this specification.
        Otherwise the gateway shall generate SDP offer information based only
        on the Bearer capability information element in the QSIG SETUP
        message, in which case the media type SHALL be derived according to
        table 4.
     
        Table 4 - Media type setting in SDP based on Bearer capability
        information element
     
     Information transfer capability in          Media type in SDP
     Bearer capability information element
     
     "speech" (00000)                            audio
     "3,1 kHz audio" (10000)                     audio
     "unrestricted digital information" (01000)  data
     
     
     11 Security considerations
     
        The translation of QSIG information elements into SIP headers can
        introduce some privacy and security concerns. For example, care needs
     
     
     Elwell et alia         Expires - February 2004              [Page 36]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        to be taken to provide adequate privacy for a user requesting
        presentation restriction if the Calling party number information
        element is openly mapped to the From header. Procedures for dealing
        with this particular situation are specified in 9.1.2.  However,
        since the mapping specified in this document is mainly concerned with
        translating information elements into the headers and fields used to
        route SIP requests, gateways consequently reveal (through this
        translation process) the minimum possible amount of information.
     
        In most respects, the information that is translated from QSIG to SIP
        has no special security requirements.  In order for translated
        information elements to be used to route requests, they should be
        legible to intermediaries; end-to-end confidentiality of this data
        would be unnecessary and most likely detrimental.  There are also
        numerous circumstances under which intermediaries can legitimately
        overwrite the values that have been provided by translation, and
        hence integrity over these headers is similarly not desirable.
     
        There are some concerns, however, that arise from the other direction
        of mapping, the mapping of SIP headers to QSIG information elements,
        which are enumerated in the following paragraphs.  When end users
        dial numbers in a PISN, their selections populate the Called party
        number information element in the QSIG SETUP message.  Similarly, the
        SIP URI or tel URL and its optional parameters in the Request-URI of
        a SIP INVITE request, which can be created directly by end users of a
        SIP device, map to that information element at a gateway.  However,
        in a PISN, policy can prevent the user from dialing certain (invalid
        or restricted) numbers. Thus, gateway implementers may wish to
        provide a means for gateway administrators to apply policies
        restricting the use of certain SIP URIs or tel URLs, or SIP URI or
        tel URL parameters, when authorizing a call from SIP to QSIG.
     
        Some additional risks may result from the SIP response code to QSIG
        cause value mapping.  SIP user agents could conceivably respond to an
        INVITE request from a gateway with any arbitrary SIP response code,
        and thus they can dictate (within the boundaries of the mappings
        supported by the gateway) the Q.850 cause code that will be sent by
        the gateway in the resulting QSIG call clearing message. Generally
        speaking, the manner in which a call is rejected is unlikely to
        provide any avenue for fraud or denial of service (e.g., by
        signalling that a call should not be billed, or that the network
        should take critical resources off-line).  However, gateway
        implementers may wish to make provision for gateway administrators to
        modify the response code to cause value mappings to avoid any
        undesirable network-specific behaviour resulting from the mappings
        recommended in 8.4.4.
     
        This specification requires the gateway to map the Request-URI rather
        than the To header in a SIP INVITE request to the Called party number
     
     
     Elwell et alia         Expires - February 2004              [Page 37]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        information element in a QSIG SETUP message. Although a SIP UA is
        expected to put the same URI in the To header and in the Request-URI,
        this is not policed by other SIP entities. Therefore a To header URI
        that differs from the Request-URI received at the gateway cannot be
        used as a reliable indication that the call has been retargeted in
        the SIP network or as a reliable indication of the original target.
        Gateway implementers making use of the To header for mapping to QSIG
        elements (e.g., as part of QSIG call diversion signalling) may wish
        to make provision for disabling this mapping when deployed in
        situations where the reliability of the QSIG elements concerned is
        important.
     
        The arbitrary population of the From header of requests by SIP user
        agents has some well-understood security implications for devices
        that rely on the From header as an accurate representation of the
        identity of the originator.  Any gateway that intends to use the From
        header to populate the Calling party number information element of a
        QSIG SETUP message should authenticate the originator of the request
        and make sure that it is authorized to assert that calling number (or
        make use of some more secure method to ascertain the identity of the
        caller).  Note that gateways, like all other SIP user agents, MUST
        support Digest authentication as described in [10]. Similar
        considerations apply to the use of the SIP P-Asserted-Identity header
        for mapping to the QSIG Calling party number or Connected number
        information element.
     
        There is another class of potential risk that is related to the cut-
        through of the backwards media path before the call is answered.
        Several practices described in this document involve the connection
        of media streams to user information channels on inter-PINX links and
        the sending of progress description number 1 or 8 in a backward QSIG
        message. This can result in media being cut through end-to-end, and
        it is possible for the called user agent then to play arbitrary audio
        to the caller for an indefinite period of time before transmitting a
        final response (in the form of a 2xx or higher response code).  This
        is useful since it also permits network entities (particularly legacy
        networks that are incapable of transmitting Q.850 cause values) to
        play tones and announcements to indicate call failure or call
        progress, without triggering charging by transmitting a 2xx response.
        Also early cut-through can help to prevent clipping of the initial
        media when the call is answered. There are conceivable respects in
        which this capability could be used fraudulently by the called user
        agent for transmitting arbitrary information without answering the
        call or before answering the call. However, in corporate networks
        charging is often not an issue, and for calls arriving at a corporate
        network from a carrier network the carrier network normally takes
        steps to prevent fraud.
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 38]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        The usefulness of this capability appears to outweigh any risks
        involved, which may in practice be no greater than in existing
        PISN/ISDN environments. However, gateway implementers may wish to
        make provision for gateway administrators to turn off cut-through or
        minimise its impact (e.g., by imposing a time limit) when deployed in
        situations where problems can arise.
     
        Unlike a traditional PISN phone, a SIP user agent can launch multiple
        simultaneous requests in order to reach a particular resource.  It
        would be trivial for a SIP user agent to launch 100 SIP INVITE
        requests at a 100 port gateway, thereby tying up all of its ports.  A
        malicious user could choose to launch requests to telephone numbers
        that are known never to answer, or, where overlap signalling is used,
        to incomplete addresses. This could saturate resources at the gateway
        indefinitely, potentially without incurring any charges.  Gateways
        implementers may therefore wish to provide means of restricting
        according to policy the number of simultaneous requests originating
        from the same authenticated source, or similar mechanisms to address
        this possible denial-of-service attack.
     
     12 Acknowledgements
     
        The authors wish to acknowledge the assistance of Francois Audet,
        Jean-Francois Rey, Thomas Stach and members of ECMA TC32-TG17 in
        preparing and commenting on this draft.
     
     13 Author's Addresses
     
        John Elwell
        Siemens Communications
        Technology Drive
        Beeston
        Nottingham, UK, NG9 1LA
        email: john.elwell@siemens.com
     
        Frank Derks
        Philips Business Communications
        P.O. Box 32
        1200 JD, Hilversum
        The Netherlands
        email: frank.derks@philips.com
     
        Olivier Rousseau
        Alcatel Business Systems
        32,Avenue Kleber
        92700 Colombes
        France
        email: olivier.rousseau@col.bsf.alcatel.fr
     
     
     
     Elwell et alia         Expires - February 2004              [Page 39]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        Patrick Mourot
        Alcatel Business Systems
        1,Rue Dr A. Schweitzer
        67400 Illkirch
        France
        email: patrick.mourot@sxb.bsf.alcatel.fr
     
     14 Normative References
     
        [1] International Standard ISO/IEC 11571 "Private Integrated Services
        Networks (PISN) - Addressing" (also published by ECMA as Standard
        ECMA-155)
     
        [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] J. Postel, "Transmission Control Protocol", RFC 793.
     
        [6] J. Postel, "User Datagram Protocol", RFC 768.
     
        [7] T. Dierks, C.Allen, "The TLS protocol version 1.0", RFC 2246.
     
        [8] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC
        2327.
     
        [9] R. Stewart et al., "Stream Control Transmission Protocol" RFC
        2960.
     
        [10] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation
        protocol", RFC 3261.
     
        [11] J. Rosenberg, H. Schulzrinne, "Reliability of Provisional
        Responses in SIP", RFC 3262.
     
        [12] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with SDP",
        RFC 3264.
     
        [13] J. Peterson, "A Privacy Mechanism for the Session Initiation
        Protocol (SIP) ", RFC 3323
     
     
     Elwell et alia         Expires - February 2004              [Page 40]
     

                       Interworking between SIP and QSIG       August 2003
     
     
     
        [14] C. Jennings, J. Peterson, M. Watson, "Private Extensions to the
        Session Initiation Protocol (SIP) for Asserted Identity within
        Trusted Networks", RFC 3325
     
        [15] J. Postel, "Internet Protocol", RFC 791.
     
        [16] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) ",
        RFC 2460.
     
        [17] ITU-T Recommendation E.164, "The International Public
        Telecommunication Numbering Plan", (1997-05).
     
        [18] G. Camarillo, A. Roach, J. Peterson, L. Ong, "Mapping of
        Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap
        Signalling to the Session Initiation Protocol", draft-ietf-sipping-
        overlap-04 (work in progress)
     
     Annex A (informative) - Example message sequences
     
     A.1 Introduction
     
        This annex shows some typical message sequences that can occur for an
        interworking between QSIG and SIP.
     
        NOTE 1. For all message sequence diagrams, there is no message
        mapping between QSIG and SIP unless explicitly indicated by dotted
        lines. Also, if there are no dotted lines connecting two messages,
        this means that these are independent of each other in terms of the
        time when they occur.
     
        NOTE 2. Numbers prefixing SIP method names and response codes in the
        diagrams represent sequence numbers.  Messages bearing the same
        number will have the same value in the CSeq header.
     
        NOTE 3. In these examples SIP provisional responses (other than 100)
        are shown as being sent reliably, using the PRACK method for
        acknowledgement.
     
     A.2 Message sequences for call establishment from QSIG to SIP
     
        Below are typical message sequences for successful call establishment
        from QSIG to SIP
     
     
     
     
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 41]
     

                       Interworking between SIP and QSIG       August 2003
     
     
                                +-------------------+
                                |                   |
                                |     GATEWAY       |
             PISN               |                   |        IP NETWORK
             |                  +-----+------+------+                 |
             |                        |      |                        |
             |                        |      |                        |
             |   QSIG SETUP           |      |        1-INVITE        |
            1|----------------------->|......|----------------------->| 2
             |                        |      |                        |
             |                        |      |                        |
             | QSIG CALL PROCEEDING   |      |        1-100 TRYING    |
            3|<-----------------------|      |<-----------------------+ 4
             |                        |      |                        |
             |                        |      |                        |
             |   QSIG ALERTING        |      |        1-180 RINGING   |
            8|<-----------------------|......|<-----------------------+ 5
             |                        |      |                        |
             |                        |      |        2-PRACK         |
             |                        |      |----------------------->| 6
             |                        |      |        2-200 OK        |
             |                        |      |<-----------------------+ 7
             |                        |      |                        |
             |   QSIG CONNECT         |      |        1-200 OK        |
           11|<-----------------------|......|<-----------------------+ 9
             |                        |      |                        |
             |   QSIG CONNECT ACK     |      |        1-ACK           |
           12|----------------------->|      |----------------------->| 10
             |                        |      |                        |
             |<======================>|      |<======================>|
             |        AUDIO           |      |         AUDIO          |
     
        Figure 3 - Typical message sequence for successful call establishment
        from QSIG to SIP using enbloc procedures on both QSIG and SIP
     
        1 The PISN sends a QSIG SETUP message to the gateway to begin a
        session with a SIP UA
        2  On receipt of the QSIG SETUP message, the gateway generates a SIP
        INVITE request and sends it to an appropriate SIP entity in the IP
        network based on the called number
        3  The gateway sends a QSIG CALL PROCEEDING message to the PISN - no
        more QSIG INFORMATION messages will be accepted
        4  The IP network sends a SIP 100 (Trying) response to the gateway
        5  The IP network sends a SIP 180 (Ringing) response.
        6  The gateway may send back a SIP PRACK request to the IP network
        based on the inclusion of a Require header or a Supported header with
        option tag 100rel in the initial SIP INVITE request
        7  The IP network sends a SIP 200 (OK) response to the gateway to
        acknowledge the SIP PRACK request
     
     
     Elwell et alia         Expires - February 2004              [Page 42]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        8  The gateway maps this SIP 180 (Ringing) response to a QSIG
        ALERTING message and sends it to the PISN.
        9  The IP network sends a SIP 200 (OK) response when the call is
        answered.
        10 The gateway sends a SIP ACK request to acknowledge the SIP 200
        (OK)response.
        11 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT
        message and sends it to the PISN.
        12 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to
        the QSIG CONNECT message.
     
                             +------------------------+
          PISN               |         GATEWAY        |      IP NETWORK
                             |                        |
          |  QSIG SETUP      +--------+-------+-------+                |
         1|-------------------------->|       |                        |
          |                           |       |                        |
          |  QSIG SETUP ACK           |       |                        |
         2|<--------------------------|       |                        |
          |                           |       |                        |
          | QSIG INFORMATION          |       |                        |
         3|-------------------------->|       |                        |
          |                           |       |                        |
          | QSIG INFORMATION          |       |  1-INVITE              |
        3a|-------------------------->|.......|----------------------->|4
          | QSIG CALL PROCEEDING      |       |  1-100 TRYING          |
         5|<--------------------------|       |<-----------------------|6
          |                           |       |                        |
          | QSIG ALERTING             |       |  1-180 RINGING         |
        10|<--------------------------|.......|<-----------------------|7
          |                           |       |  2-PRACK               |
          |                           |       |----------------------->|8
          |                           |       |  2-200 OK              |
          |                           |       |<-----------------------|9
          | QSIG CONNECT              |       |  1-200 OK              |
        13|<--------------------------|.......|<-----------------------|11
          |                           |       |                        |
          | QSIG CONNECT ACK          |       |  1-ACK                 |
        14|-------------------------->|       |----------------------->|12
          |          AUDIO            |       |           AUDIO        |
          |<=========================>|       |<======================>|
     
        Figure 4 - Typical message sequence for successful call establishment
        from QSIG to SIP using overlap receiving on QSIG and enbloc sending
        on SIP
     
        1  The PISN sends a QSIG SETUP message to the gateway to begin a
        session with a SIP UA. The QSIG SETUP message does not contain a
        Sending Complete information element.
     
     
     Elwell et alia         Expires - February 2004              [Page 43]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        2  The gateway sends a QSIG SETUP ACKNOWLEDGE message to the PISN.
        More digits are expected.
        3  More digits are sent from the PISN within a QSIG INFORMATION
        message.
        3a More digits are sent from the PISN within a QSIG INFORMATION
        message. The QSIG INFORMATION message contains a Sending Complete
        information element
        4  The Gateway generates a SIP INVITE request and sends it to an
        appropriate SIP entity in the IP network, based on the called number
        5  The gateway sends a QSIG CALL PROCEEDING message to the PISN - no
        more QSIG INFORMATION messages will be accepted
        6  The IP network sends a SIP 100 (Trying) response to the gateway
        7  The IP network sends a SIP 180 (Ringing) response.
        8  The gateway may send back a SIP PRACK request to the IP network
        based on the inclusion of a Require header or a Supported header with
        option tag 100rel in the initial SIP INVITE request
        9  The IP network sends a SIP 200 (OK) response to the gateway to
        acknowledge the SIP PRACK request
        10 The gateway maps this SIP 180 (Ringing) response to a QSIG
        ALERTING message and sends it to the PINX.
        11 The IP network sends a SIP 200 (OK) response when the call is
        answered.
        12 The gateway sends an SIP ACK request to acknowledge the SIP 200
        (OK) response.
        13 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT
        message and sends it to the PINX.
        14 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to
        the QSIG CONNECT message.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 44]
     

                       Interworking between SIP and QSIG       August 2003
     
     
                             +----------------------+
          PISN               |        GATEWAY       |         IP NETWORK
                             |                      |
          |  QSIG SETUP      +-------+-------+------+                  |
        1 |------------------------->|       |                         |
          |                          |       |                         |
          |  QSIG SETUP ACK          |       |                         |
        2 |<-------------------------|       |                         |
          |                          |       |                         |
          | QSIG INFORMATION         |       |                         |
        3 |------------------------->|       |                         |
          | QSIG INFORMATION         |       | 1-INVITE                |
        3 |------------------------->|.......|------------------------>|4
          |                          |       | 1-484                   |
          |                          |       |<------------------------|5
          |                          |       | 1-ACK                   |
          |                          |       |------------------------>|6
          | QSIG INFORMATION         |       | 2-INVITE                |
        7 |------------------------->|.......|------------------------>|4
          |                          |       | 2-484                   |
          |                          |       |<------------------------|5
          |                          |       | 2-ACK                   |
          |                          |       |------------------------>|6
          |                          |       |                         |
          | QSIG INFORMATION         |       |                         |
          | Sending Complete IE      |       | 3-INVITE                |
        8 |------------------------->|.......|------------------------>|10
          | QSIG CALL PROCEEDING     |       | 3-100 TRYING            |
        9 |<-------------------------|       |<------------------------|11
          |                          |       |                         |
          | QSIG ALERTING            |       | 3-180 RINGING           |
        15|<-------------------------|.......|<------------------------|12
          |                          |       | 4-PRACK                 |
          |                          |       |------------------------>|13
          |                          |       | 4-200 OK                |
          |                          |       |<------------------------|14
          | QSIG CONNECT             |       | 3-200 OK                |
        18|<-------------------------|.......|<------------------------|16
          |                          |       |                         |
          | QSIG CONNECT ACK         |       | 3-ACK                   |
        19|------------------------->|       |------------------------>|17
          |         AUDIO            |       |         AUDIO           |
          |<========================>|       |<=======================>|
          |                          |       |                         |
     
        Figure 5 - Typical message sequence for successful call establishment
        from QSIG to SIP using overlap procedures on both QSIG and SIP
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 45]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        1  The PISN sends a QSIG SETUP message to the gateway to begin a
        session with a SIP UA. The QSIG SETUP message does not contain a
        Sending complete information element.
        2  The gateway sends a QSIG SETUP ACKNOWLEDGE message to the PISN.
        More digits are expected.
        3  More digits are sent from the PISN within a QSIG INFORMATION
        message.
        4  When the gateway receives the minimum number of digits required to
        route the call it generates a SIP INVITE request and sends it to an
        appropriate SIP entity in the IP network based on the called number
        5  Due to an insufficient number of digits the IP network will return
        a SIP 484 (Address Incomplete) response.
        6  The SIP 484 (Address Incomplete) response is acknowledged.
        7  More digits are received from the PISN in a QSIG INFORMATION
        message. A new INVITE is sent with the same Call-ID and From values
        but an updated Request-URI.
        8  More digits are received from the PISN in a QSIG INFORMATION
        message. The QSIG INFORMATION message contains a Sending Complete
        information element
        9  The gateway sends a QSIG CALL PROCEEDING message to the PISN - no
        more information will be accepted
        10 The gateway sends a new SIP INVITE request with an updated
        Request-URI field.
        11 The IP network sends a SIP 100 (Trying) response to the gateway
        12 The IP network sends a SIP 180 (Ringing) response.
        13 The gateway may send back a SIP PRACK request to the IP network
        based on the inclusion of a Require header or a Supported header with
        option tag 100rel in the initial SIP INVITE request
        14 The IP network sends a SIP 200 (OK) response to the gateway to
        acknowledge the SIP PRACK request
        15 The gateway maps this SIP 180 (Ringing) response to a QSIG
        ALERTING message and sends it to the PISN.
        16 The IP network sends a SIP 200 (OK) response when the call is
        answered.
        17 The gateway sends a SIP ACK request to acknowledge the SIP 200
        (OK) response.
        18 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT
        message.
        19 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to
        the QSIG CONNECT message.
     
     A.3 Message sequences for call establishment from SIP to QSIG
     
        Below are typical message sequences for successful call establishment
        from SIP to QSIG
     
     
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 46]
     

                       Interworking between SIP and QSIG       August 2003
     
     
                             +----------------------+
          IP NETWORK         |        GATEWAY       |              PISN
                             |                      |
          |                  +-------+-------+------+                  |
          |                          |       |                         |
          |                          |       |                         |
          |     1-INVITE             |       | QSIG SETUP              |
        1 |------------------------->|.......|------------------------>|3
          |     1-100 TRYING         |       | QSIG CALL PROCEEDING    |
        2 |<-------------------------|       |<------------------------|4
          |     1-180 RINGING        |       | QSIG ALERTING           |
        6 |<-------------------------|.......|<------------------------|5
          |                          |       |                         |
          |                          |       |                         |
          |     2-PRACK              |       |                         |
        7 |------------------------->|       |                         |
          |     2-200 OK             |       |                         |
        8 |<-------------------------|       |                         |
          |     1-200 OK             |       | QSIG CONNECT            |
        11|<-------------------------|.......|<------------------------|9
          |                          |       |                         |
          |     1-ACK                |       | QSIG CONNECT ACK        |
        12|------------------------->|       |------------------------>|10
          |         AUDIO            |       |         AUDIO           |
          |<========================>|       |<=======================>|
          |                          |       |                         |
     
        Figure 6 - Typical message sequence for successful call establishment
        from SIP to QSIG using enbloc procedures
     
        1  The IP network sends a SIP INVITE request to the gateway
        2  The gateway sends a SIP 100 (Trying) response to the IP network
        3  On receipt of the SIP INVITE request, the gateway sends a QSIG
        SETUP message
        4  The PISN sends a QSIG CALL PROCEEDING message to the gateway
        5  A QSIG ALERTING message is returned to indicate that the end user
        in the PISN is being alerted
        6  The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing)
        response
        7  The IP network can send back a SIP PRACK request to the IP network
        based on the inclusion of a Require header or a Supported header with
        option tag 100rel in the initial SIP INVITE request
        8  The gateway sends a SIP 200 (OK) response to acknowledge the SIP
        PRACK request
        9  The PISN sends a QSIG CONNECT message to the gateway when the call
        is answered
        10 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to
        acknowledge the QSIG CONNECT message
        11 The QSIG CONNECT message is mapped to a SIP 200 (OK) response.
     
     
     Elwell et alia         Expires - February 2004              [Page 47]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        12 The IP network, upon receiving a SIP INVITE final response (200),
        will send a SIP ACK request to acknowledge receipt
     
                             +----------------------+
          IP NETWORK         |        GATEWAY       |               PISN
                             |                      |
          | 1-INVITE         +-------+-------+------+                  |
        1 |------------------------->|       |                         |
          |     1-484                |       |                         |
        2 |<-------------------------|       |                         |
          |     1-ACK                |       |                         |
        3 |------------------------->|       |                         |
          |     2-INVITE             |       |                         |
        1 |------------------------->|       |                         |
          |     2-484                |       |                         |
        2 |<-------------------------|       |                         |
          |     2- ACK               |       |                         |
        3 |------------------------->|       |                         |
          |     3-INVITE             |       | QSIG SETUP              |
        4 |------------------------->|.......|------------------------>|6
          |     3-100 TRYING         |       | QSIG CALL PROCEEDING    |
        5 |<-------------------------|       |<------------------------|7
          |     3-180 RINGING        |       | QSIG ALERTING           |
        9 |<-------------------------|.......|<------------------------|8
          |                          |       |                         |
          |                          |       |                         |
          |     4-PRACK              |       |                         |
        10|------------------------->|       |                         |
          |     4-200 OK             |       |                         |
        11|<-------------------------|       |                         |
          |     3-200 OK             |       | QSIG CONNECT            |
        14|<-------------------------|.......|<------------------------|12
          |                          |       |                         |
          |     3-ACK                |       | QSIG CONNECT ACK        |
        15|------------------------->|       |------------------------>|13
          |         AUDIO            |       |         AUDIO           |
          |<========================>|       |<=======================>|
          |                          |       |                         |
     
        Figure 7 - Typical message sequence for successful call establishment
        from SIP to QSIG using overlap receiving on SIP and enbloc sending on
        QSIG
     
        1  The IP network sends a SIP INVITE request to the gateway
        2  Due to an insufficient number of digits the gateway returns a SIP
        484(Address Incomplete) response.
        3  The IP network acknowledge the SIP 484 (Address Incomplete)
        response.
     
     
     
     Elwell et alia         Expires - February 2004              [Page 48]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        4  The IP network sends a new SIP INVITE request with the same Call-
        ID and updated Request-URI.
        5  The gateway now has all the digits required to route the call to
        the PISN. The gateway sends back a SIP 100 (Trying) response
        6  The gateway sends a QSIG SETUP message
        7  The PISN sends a QSIG CALL PROCEEDING message to the gateway
        8  A QSIG ALERTING message is returned to indicate that the end user
        in the PISN is being alerted
        9  The gateway maps the QSIG ALERTING message to a SIP 180
        (Ringing)response
        10 The IP network can send back a SIP PRACK request to the IP network
        based on the inclusion of a Require header or a Supported header with
        option tag 100rel in the initial SIP INVITE request
        11 The gateway sends a SIP 200 (OK) response to acknowledge the SIP
        PRACK request
        12 The PISN sends a QSIG CONNECT message to the gateway when the call
        is answered
        13 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to
        acknowledge the CONNECT message
        14 The QSIG CONNECT message is mapped to a SIP 200 (OK) response.
        15 The IP network, upon receiving a SIP INVITE final response (200),
        will send a SIP ACK request to acknowledge receipt
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 49]
     

                       Interworking between SIP and QSIG       August 2003
     
     
                             +----------------------+
          IP NETWORK         |        GATEWAY       |               PISN
                             |                      |
          | 1-INVITE         +-------+-------+------+                  |
        1 |------------------------->|       |                         |
          |     1-484                |       |                         |
        2 |<-------------------------|       |                         |
          |     1-ACK                |       |                         |
        3 |------------------------->|       |                         |
          |     2-INVITE             |       | QSIG SETUP              |
        4 |------------------------->|.......|------------------------>|6
          |     2-100 TRYING         |       | QSIG SETUP ACK          |
        5 |<-------------------------|       |<------------------------|7
          |     3- INVITE            |       | QSIG INFORMATION        |
        8 |------------------------->|.......|------------------------>|10
          |     3-100 TRYING         |       |                         |
        9 |<-------------------------|       | QSIG CALL PROCEEDING    |
          |                          |       |<------------------------|11
        13|     3-180 RINGING        |       | QSIG ALERTING           |
          |<-------------------------|.......|<------------------------|12
          |     2-484                |       |                         |
        14|<-------------------------|       |                         |
          |     2-ACK                |       |                         |
        15|------------------------->|       |                         |
          |     4-PRACK              |       |                         |
        16|------------------------->|       |                         |
          |     4-200 OK             |       |                         |
        17|<-------------------------|       |                         |
          |     3-200 OK             |       | QSIG CONNECT            |
        20|<-------------------------|.......|<------------------------|18
          |                          |       |                         |
          |     3-ACK                |       | QSIG CONNECT ACK        |
        21|------------------------->|       |------------------------>|19
          |         AUDIO            |       |         AUDIO           |
          |<========================>|       |<=======================>|
          |                          |       |                         |
     
        Figure 8 - Typical message sequence for successful call establishment
        from SIP to QSIG using overlap procedures on both SIP and QSIG
     
        1  The IP network sends a SIP INVITE request to the gateway
        2  Due to an insufficient number of digits the gateway returns a SIP
        484(Address Incomplete) response.
        3  The IP network acknowledge the SIP 484 (Address Incomplete)
        response.
        4  The IP network sends a new SIP INVITE request with the same Call-
        ID and updated Request-URI.
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 50]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        5  The gateway now has all the digits required to route the call to
        the PISN. The gateway sends back a SIP 100 (Trying) response to the
        IP network
        6  The gateway sends a QSIG SETUP message
        7  The PISN needs more digits to route the call and sends a QSIG
        SETUP ACKNOWLEDGE message to the gateway
        8  The IP network sends a new SIP INVITE request with the same Call-
        ID and From values and updated Request-URI.
        9  The gateway sends back a SIP 100 (Trying) response to the IP
        network
        10 The gateway maps the new SIP INVITE request to a QSIG INFORMATION
        message
        11 The PISN has all the digits required and sends back a QSIG CALL
        PROCEEDING message to the gateway
        12 A QSIG ALERTING message is returned to indicate that the end user
        in the PISN is being alerted
        13 The gateway maps the QSIG ALERTING message to a SIP 180
        (Ringing)response
        14 The gateway sends a SIP 484 (Address Incomplete) response for the
        previous SIP INVITE request
        15 The IP network acknowledges the SIP 484 (Address Incomplete)
        response
        16 The IP network can send back a SIP PRACK request to the IP network
        based on the inclusion of a Require header or a Supported header with
        option tag 100rel in the initial SIP INVITE request
        17 The gateway sends a SIP 200 (OK) response to acknowledge the SIP
        PRACK request
        18 The PISN sends a QSIG CONNECT message to the gateway when the call
        is answered
        19 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to
        acknowledge the QSIG CONNECT message
        20 The QSIG CONNECT message is mapped to a SIP 200 (OK) response.
        21 The IP network, upon receiving a SIP INVITE final response (200),
        will send a SIP ACK request to acknowledge receipt
     
     A.4 Message sequence for call clearing from QSIG to SIP
     
        Below are typical message sequences for Call Clearing from QSIG to
        SIP
     
     
     
     
     
     
     
     
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 51]
     

                       Interworking between SIP and QSIG       August 2003
     
     
                                    +-------------------+
                                    |                   |
                                    |     GATEWAY       |
                PISN                |                   |         IP NETWORK
                 |                  +-----+------+------+                 |
                 |                        |      |                        |
                 |                        |      |                        |
                 |     QSIG DISCONNECT    |      |   2- BYE               |
                1|----------------------->|......|----------------------->|4
                 |     QSIG RELEASE       |      |        2-200 OK        |
                2|<-----------------------|      |<-----------------------|5
                 |     QSIG RELEASE COMP  |      |                        |
                3|----------------------->|      |                        |
                 |                        |      |                        |
                 |                        |      |                        |
                 |                        |      |                        |
     
        Figure 9 - Typical message sequence for call clearing from QSIG to
        SIP subsequent to call establishment
     
        1  The PISN sends a QSIG DISCONNECT message to the gateway
        2  The gateway sends back a QSIG RELEASE message to the PISN in
        response to the QSIG DISCONNECT message
        3  The PISN sends a QSIG RELEASE COMPLETE message in response. All
        PISN resources are now released.
        4  The gateway maps the QSIG DISCONNECT message to a SIP BYE request
        5  The IP network sends back a SIP 200 (OK) response to the SIP BYE
        request. All IP resources are now released
     
                                   +-------------------+
                                   |                   |
                                   |     GATEWAY       |
                PISN               |                   |       IP NETWORK
                |                  +-----+------+------+                |
                |                        |      |                       |
                |                        |      |                       |
                |     QSIG DISCONNECT    |      |   1- 4XX / 6XX        |
               1|----------------------->|......|---------------------->|4
                |     QSIG RELEASE       |      |        1- ACK         |
               2|<-----------------------|      |<----------------------|5
                |     QSIG RELEASE COMP  |      |                       |
               3|----------------------->|      |                       |
                |                        |      |                       |
                |                        |      |                       |
     
        Figure 10 - Typical message sequence for call clearing from QSIG to
        SIP during establishment of a call from SIP to QSIG (gateway has not
        sent a final response to the SIP INVITE request)
     
     
     
     Elwell et alia         Expires - February 2004              [Page 52]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        1  The PISN sends a QSIG DISCONNECT message to the gateway
        2  The gateway sends back a QSIG RELEASE message to the PISN in
        response to the QSIG DISCONNECT message
        3  The PISN sends a QSIG RELEASE COMPLETE message in response. All
        PISN resources are now released.
        4  The gateway maps the QSIG DISCONNECT message to a SIP 4xx-6xx
        response
        5  The IP network sends back a SIP ACK request in response to the SIP
        4xx-6xx response. All IP resources are now released
     
                                  +-------------------+
                                  |                   |
                                  |     GATEWAY       |
              PISN                |                   |         IP NETWORK
               |                  +-----+------+------+                 |
               |                        |      |                        |
               |                        |      |                        |
               |     QSIG DISCONNECT    |      |   1- CANCEL            |
              1|----------------------->|......|----------------------->|4
               |     QSIG RELEASE       |      |1-487 Request Terminated|
              2|<-----------------------|      |<-----------------------|5
               |     QSIG RELEASE COMP  |      |                        |
              3|----------------------->|      |   1- ACK               |
               |                        |      |----------------------->|6
               |                        |      |                        |
               |                        |      |   1- 200 OK            |
               |                        |      |<-----------------------|7
               |                        |      |                        |
     
        Figure 11 - Typical message sequence for call clearing from QSIG to
        SIP during establishment of a call from QSIG to SIP (gateway has
        received a provisional response to the SIP INVITE request but not a
        final response)
     
        1  The PISN sends a QSIG DISCONNECT message to the gateway
        2  The gateway sends back a QSIG RELEASE message to the PISN in
        response to the QSIG DISCONNECT message
        3  The PISN sends a QSIG RELEASE COMPLETE message in response. All
        PISN resources are now released.
        4  The gateway maps the QSIG DISCONNECT message to a SIP CANCEL
        request(subject to a provisional response but no final response
        having been received)
        5  The IP network sends back a SIP 487 (Request Terminated) response
        to the SIP INVITE request.
        6  The gateway, on receiving a SIP final response (487) to the SIP
        INVITE request, sends back a SIP ACK request to acknowledge receipt
        7  The IP network sends back a SIP 200 (OK) response to the SIP
        CANCEL request. All IP resources are now released
     
     
     
     Elwell et alia         Expires - February 2004              [Page 53]
     

                       Interworking between SIP and QSIG       August 2003
     
     
     A.5 Message sequence for call clearing from SIP to QSIG
     
        Below are typical message sequences for Call Clearing from SIP to
        QSIG
     
                                  +-------------------+
                                  |                   |
                                  |     GATEWAY       |
               IP NETWORK         |                   |              PISN
               |                  +-----+------+------+                 |
               |                        |      |                        |
               |                        |      |                        |
               |   2- BYE               |      |     QSIG DISCONNECT    |
              1|----------------------->|......|----------------------->|3
               |                        |      |     QSIG RELEASE       |
               |                        |      |<-----------------------|4
               |        2-200 OK        |      |     QSIG RELEASE COMP  |
              2|<-----------------------|      |----------------------->|5
               |                        |      |                        |
               |                        |      |                        |
     
        Figure 12 - Typical message sequence for call clearing from SIP to
        QSIG subsequent to call establishment
     
        1  The IP network sends a SIP BYE request to the gateway
        2  The gateway sends back a SIP 200 (OK) response to the SIP BYE
        request. All IP resources are now released
        3  The gateway maps the SIP BYE request to a QSIG DISCONNECT message
        4  The PISN sends back a QSIG RELEASE message to the gateway in
        response to the QSIG DISCONNECT message
        5  The gateway sends a QSIG RELEASE COMPLETE message in response. All
        PISN resources are now released.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 54]
     

                       Interworking between SIP and QSIG       August 2003
     
     
                                  +-------------------+
                                  |                   |
                                  |     GATEWAY       |
               IP NETWORK         |                   |              PISN
               |                  +-----+------+------+                 |
               |                        |      |                        |
               |                        |      |                        |
               |   1- 4XX / 6XX         |      |     QSIG DISCONNECT    |
              1|----------------------->|......|----------------------->|3
               |                        |      |     QSIG RELEASE       |
               |                        |      |<-----------------------|4
               |        1- ACK          |      |     QSIG RELEASE COMP  |
              2|<-----------------------|      |----------------------->|5
               |                        |      |                        |
               |                        |      |                        |
               |                        |      |                        |
     
        Figure 13 - Typical message sequence for call clearing from SIP to
        QSIG during establishment of a call from QSIG to SIP (gateway has not
        previously received a final response to the SIP INVITE request)
     
        1  The IP network sends a SIP 4xx-6xx response to the gateway
        2  The gateway sends back a SIP ACK request in response to the SIP
        4xx-6xx response. All IP resources are now released
        3  The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT
        message
        4  The PISN sends back a QSIG RELEASE message to the gateway in
        response to the QSIG DISCONNECT message
        5  The gateway sends a QSIG RELEASE COMPLETE message in response. All
        PISN resources are now released.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 55]
     

                       Interworking between SIP and QSIG       August 2003
     
     
                                  +-------------------+
                                  |                   |
                                  |     GATEWAY       |
              IP NETWORK          |                   |              PISN
               |                  +-----+------+------+                 |
               |                        |      |                        |
               |                        |      |                        |
               |   1- CANCEL            |      |     QSIG DISCONNECT    |
              1|----------------------->|......|----------------------->|4
               |                        |      |     QSIG RELEASE       |
               |                        |      |<-----------------------|5
               |1-487 Request Terminated|      |     QSIG RELEASE COMP  |
              2|<-----------------------|      |----------------------->|6
               |                        |      |                        |
               |   1- ACK               |      |                        |
              3|----------------------->|      |                        |
               |                        |      |                        |
               |   1- 200 OK            |      |                        |
              4|<-----------------------|      |                        |
     
        Figure 14 - Typical message sequence for call clearing from SIP to
        QSIG during establishment of a call from SIP to QSIG (gateway has
        sent a provisional response to the SIP INVITE request but not a final
        response)
     
        1  The IP network sends a SIP CANCEL request to the gateway
        2  The gateway sends back a SIP 487 (Request Terminated) response to
        the SIP INVITE request
        3  The IP network, on receiving a SIP final response (487) to the SIP
        INVITE request, sends back a SIP ACK request to acknowledge receipt
        4  The gateway sends back a SIP 200 (OK) response to the SIP CANCEL
        request. All IP resources are now released
        5  The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT
        message
        6  The PISN sends back a QSIG RELEASE message to the gateway in
        response to the QSIG DISCONNECT message
        7  The gateway sends a QSIG RELEASE COMPLETE message in response. All
        PISN resources are now released.
     
     
        Annex B (temporary) - Change log
     
        Compared with draft-ietf-sipping-qsig2sip-01 the following changes
        have been made:
     
        - editorial changes and minor clarifications resulting from comments
          received during WGLC;
        - relaxation of the rule concerning sending 488 response if no SDP
          offer in INVITE request and 100rel not supported;
     
     
     Elwell et alia         Expires - February 2004              [Page 56]
     

                       Interworking between SIP and QSIG       August 2003
     
     
        - additional text on use of QSIG Low layer compatibility and High
          layer compatibility information elements.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Elwell et alia         Expires - February 2004              [Page 57]
     

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/