Internet Engineering Task Force                              J. Elwell
     Internet Draft                                                 Siemens
                                                                   F. Derks
                                                                    Philips
                                                      P. Mourot/O. Rousseau
     draft-elwell-sipping-qsig2sip-00.txt                           Alcatel
     Expires: October 2002                                       April 2002
     
     
                          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 RFC2026 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 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 - October 2002                [Page 1]


                       Interworking between SIP and QSIG        April 2002
     
     
        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.ch) on interoperability of QSIG with IP networks.
     
     
     
        1 Introduction....................................................3
        2 Terminology.....................................................4
        3 Definitions.....................................................4
        3.1 External definitions..........................................4
        3.2 Other definitions.............................................5
        3.2.1 Gateway.....................................................5
        3.2.2 IP network..................................................5
        3.2.3 Media stream................................................5
        4 Acronyms........................................................5
        5 Architecture....................................................5
        6 Overview........................................................7
        7 General requirements............................................7
        8 Message mapping requirements....................................8
        8.1 Message validation and handling of protocol errors............8
        8.2 Call establishment from QSIG to SIP...........................9
        8.2.1 Call establishment from QSIG to SIP using enbloc procedures.9
        8.2.1.1 Receipt of QSIG SETUP message............................10
        8.2.1.2 Receipt of SIP 100 (Trying) response.....................10
        8.2.1.3 Receipt of SIP 18x provisional response..................10
        8.2.1.4 Receipt of SIP 2xx response..............................11
        8.2.1.5 Receipt of SIP 3xx response..............................12
        8.2.2 Call establishment from QSIG to SIP using overlap procedures12
        8.2.2.1 Enbloc signalling in SIP network.........................12
        8.2.2.1.1 Receipt of QSIG SETUP message..........................12
        8.2.2.1.2 Receipt of QSIG INFORMATION message....................13
        8.2.2.1.3 Receipt of SIP responses...............................13
        8.2.2.2 Overlap signalling in SIP network........................13
        8.2.2.2.1 Receipt of QSIG SETUP message..........................13
        8.2.2.2.2 Receipt of QSIG INFORMATION message....................13
        8.2.2.2.3 Receipt of SIP 100 (Trying) response...................14
        8.2.2.2.4 Receipt of SIP 18x provisional response................14
        8.2.2.2.5 Receipt of SIP 2xx response............................14
        8.2.2.2.6 Receipt of SIP 3xx response............................14
        8.2.2.2.7 Receipt of a SIP 484 (Address Incomplete) response.....14
        8.2.2.2.8 Receipt of a SIP 4xx (except 484), 5xx or 6xx response.14
        8.2.2.2.9 Receipt of multiple SIP responses......................15
        8.2.2.2.10 Cancelling pending SIP INVITE transactions............15
        8.2.2.2.11 SIP INVITE requests reaching multiple gateways........15
        8.3 Call Establishment from SIP to QSIG..........................16
        8.3.1 Receipt of SIP INVITE request for a new call...............16
        8.3.2 Receipt of QSIG CALL PROCEEDING message....................16
        8.3.3 Receipt of QSIG PROGRESS message...........................17
     
     
     Elwell et alia          Expires - October 2002                [Page 2]


                       Interworking between SIP and QSIG        April 2002
     
     
        8.3.4 Receipt of QSIG ALERTING message...........................17
        8.3.5 Inclusion of SDP information in a SIP 18x provisional response
        .................................................................18
        8.3.6 Receipt of QSIG CONNECT message............................18
        8.3.7 Receipt of SIP PRACK request...............................19
        8.3.8 Receipt of SIP ACK request.................................19
        8.3.9 Receipt of a SIP INVITE request for a call already being
        established......................................................20
        8.4 Call clearing................................................20
        8.4.1 Receipt of a QSIG DISCONNECT, RELEASE or RELEASE COMPLETE
        message..........................................................20
        8.4.2 Receipt of a SIP BYE request...............................23
        8.4.3 Receipt of a SIP CANCEL request............................24
        8.4.4 Receipt of a SIP 4xx - 6xx response........................24
        8.4.5 Timer expiry...............................................25
        8.5 Request to change media characteristics......................25
        9 Number mapping.................................................25
        9.1 Mapping from SIP to QSIG.....................................25
        9.2 Mapping from QSIG to SIP.....................................26
        10 Requirements for support of basic services....................26
        10.1 Derivation of QSIG Bearer capability information element....26
        10.2 Derivation of media type in SDP.............................27
        11 Security considerations.......................................27
        12 Author's Addresses............................................27
        13 Normative References..........................................28
        Annex A û Example message sequences..............................29
     
     
     
     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).
     
        "QSIG" is a signalling protocol that operates at the Q reference
        point between Private Integrated Services eXchanges (PINX) within a
        Private Integrated Services Network (PISN). The Q reference point is
        defined in ECMA-133. A PISN provides circuit-switched basic services
        and supplementary services to its users. QSIG is specified in ECMA
        Standards, in particular ECMA-143 (call control in support of basic
        services), ECMA-165 (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.
        Telephone calls are considered as a type of multimedia session where
        just audio is exchanged. SIP is defined in IETF RFC 3261.
     
     
     
     Elwell et alia          Expires - October 2002                [Page 3]


                       Interworking between SIP and QSIG        April 2002
     
     
        This document specifies 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. Call-related and call-independent
        signalling in support of supplementary services is outside the scope
        of this specification.
     
        Interworking between QSIG and SIP permits a call originating at a
        user of a PISN to terminate at a user of a corporate IP network, or a
        call originating at a user of a corporate IP network to terminate at
        a user of a PISN.
     
        Interworking between a PISN employing QSIG and a public IP network
        employing SIP is outside the scope of this specification. However,
        the functionality specified in this specification is in principle
        applicable to such a scenario when deployed in conjunction with other
        relevant functionality (e.g., number translation, security functions,
        etc.).
     
        This specification is applicable to any interworking unit that can
        act as a gateway between a PISN employing QSIG and a corporate IP
        network employing SIP.
     
     
     2 Terminology
     
        In this document, the key words "MUST", "MUST NOT", "REQUIRED",
        "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
        and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
        indicate requirement levels for compliant SIP implementations.
     
     3 Definitions
     
        For the purposes of this specification, the following definitions
        apply.
     
     3.1 External definitions
     
        This specification uses the following terms defined in other
        documents:
     
        -Call (ECMA-307)
        -Corporate telecommunication network (CN) (ECMA-307)
        -Private Integrated Services Network (PISN) (ECMA-307)
        -Private Integrated services Network eXchange (PINX) (ECMA-133)
     
        Additionally the definitions in ECMA-143 and IETF RFC 3261 apply as
        appropriate.
     
     
     
     Elwell et alia          Expires - October 2002                [Page 4]


                       Interworking between SIP and QSIG        April 2002
     
     
     3.2 Other definitions
     
     3.2.1 Gateway
     
        An entity that performs interworking between a PISN using QSIG and an
        IP network using SIP.
     
     3.2.2 IP network
     
        A network, unless otherwise stated a corporate network, offering
        connectionless packet-mode services based on the Internet Protocol
        (IP) as the network layer protocol.
     
     3.2.3 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.
     
     4 Acronyms
     
        DNS   Domain Name Service
        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 Architecture
     
        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.
     
     
     
     
     
     Elwell et alia          Expires - October 2002                [Page 5]


                       Interworking between SIP and QSIG        April 2002
     
     
             +------+   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
        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 (RFC 768) and TCP (RFC 761) 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 (RFC 2246) and/or SCTP (RFC 2960) as
        additional transport layer protocols on the IP network side, these
        being used for the transport of SIP signalling messages; and
     
        -a means of transferring media 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. RFC 3261 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.
     
     
     Elwell et alia          Expires - October 2002                [Page 6]


                       Interworking between SIP and QSIG        April 2002
     
     
     
        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. 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 ECMA-143 as a gateway and SHALL support SIP
        in accordance with IETF RFC 3261 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 RFC 3261. In addition,
        the gateway SHALL support SIP TU behaviour for a UA in accordance
        with RFC 3261 except where stated otherwise in this specification.
     
     
     
     
     
     Elwell et alia          Expires - October 2002                [Page 7]


                       Interworking between SIP and QSIG        April 2002
     
     
        NOTE 1. RFC 3261 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 IETF RFC BBBB as a UA.
     
        NOTE 2. RFC BBBB 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 RFC 2327 and its use
        in accordance with the offer / answer model in RFC CCCC.
     
        The gateway SHALL support calls from QSIG to SIP and calls from SIP
        to QSIG.
     
        SIP methods not defined in RFC 3261 or RFC BBBB 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 final
        response SHOULD apply only when a final response is received and
        there are no more candidate destinations to try.
     
     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 ECMA-143 and SHALL act in accordance with
        ECMA-143 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
     
     
     
     
     
     
     Elwell et alia          Expires - October 2002                [Page 8]


                       Interworking between SIP and QSIG        April 2002
     
     
        -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.
     
        The gateway SHALL validate received SIP messages (requests and
        responses) in accordance with the requirements of IETF RFC 3261 and
        SHALL act in accordance with IETF RFC 3261 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 RFC 3261) 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.
     
     
     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.
     
     
     Elwell et alia          Expires - October 2002                [Page 9]


                       Interworking between SIP and QSIG        April 2002
     
     
     
        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 RFC BBBB.
     
        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 ECMA-143.
     
     
     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.
     
     
     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
        QSIG ALERTING message SHALL contain a Progress indicator information
     
     
     Elwell et alia          Expires - October 2002               [Page 10]


                       Interworking between SIP and QSIG        April 2002
     
     
        element containing progress description number 8. If the SDP answer
        has been received, the gateway SHALL connect the media streams to the
        corresponding user information channel of the inter-PINX link. If the
        SDP answer has not been received, the gateway SHALL supply ring-back
        tone on the user information channel of the inter-PINX link. If the
        SDP answer is subsequently received, the gateway SHALL stop ring-back
        tone and 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 8 has been sent and the SDP answer has been
        received, 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 the SDP answer has not
        been received, 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. This will ensure that QSIG timer T310 is stopped if running at
        the Originating PINX.
     
        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.
     
     
     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 RFC 3261 and SHALL NOT generate any further QSIG
        messages.
     
        The SDP answer will now have been received. 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.
     
     
     
     Elwell et alia          Expires - October 2002               [Page 11]


                       Interworking between SIP and QSIG        April 2002
     
     
        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.
     
        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 RFC 3261.
     
        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;
     
        -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
     
     
     
     
     
     Elwell et alia          Expires - October 2002               [Page 12]


                       Interworking between SIP and QSIG        April 2002
     
     
        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 T302 timer 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, timer T302 SHALL be restarted. When
        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
     
     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 restart
        the QSIG T302 timer. 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 than it SHALL wait for
        more QSIG INFORMATION messages to arrive.
     
     
     
     Elwell et alia          Expires - October 2002               [Page 13]


                       Interworking between SIP and QSIG        April 2002
     
     
        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 with the new digits. The new
        SIP INVITE request SHALL have the same Call-ID as the first SIP
        INVITE request sent but SHALL have updated Request-URI and To fields.
        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. The first SIP INVITE request and all subsequent SIP INVITE
        requests sent in this way belong to the same call but to different
        dialogs.
     
     
     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.
     
     
     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 484 (Address Incomplete) response
     
     
        The SIP 484 response indicates that more digits are required to
        complete the call. On receipt of a SIP 484 response the gateway SHALL
        send back a SIP ACK request. The gateway SHALL also send a QSIG
        DISCONNECT message if either of the following conditions apply:
     
        -T302 expires and all the SIP INVITE requests sent have been answered
        with a final response other than 200 OK; or
     
        -a QSIG INFORMATION message containing a Sending complete information
        element has been received and all the SIP INVITE requests sent have
        been answered with a final response (other than 200 OK).
     
        In all other cases the receipt of a SIP 484 response SHALL NOT
        trigger the sending of any QSIG message.
     
     
     8.2.2.2.8 Receipt of a SIP 4xx (except 484), 5xx or 6xx response
     
     
     
     
     Elwell et alia          Expires - October 2002               [Page 14]


                       Interworking between SIP and QSIG        April 2002
     
     
        If a SIP 4xx (except 484), 5xx or 6xx final response arrives for a
        pending SIP INVITE transaction, the gateway SHALL send a SIP ACK
        request. If this occurs before T302 has expired, the gateway shall
        either send a QSIG DISCONNECT message (8.4.4) or behave as for a SIP
        484 response (8.2.2.2.7).
     
     
     8.2.2.2.9 Receipt of multiple SIP responses
     
     
        The responses to all the SIP INVITE requests sent except for the last
        one are typically SIP 4xx responses (e.g. 484 (Address Incomplete))
        that terminate the SIP INVITE transaction.
     
        However, the gateway can receive a SIP 183 (Session Progress)
        response with a media description. The media stream will typically
        contain a message such as "àWe are trying to connect youà ". The
        issue of receiving different SIP 183 (Session Progress) responses
        with media descriptions for different SIP INVITE transactions is a
        gateway concern. The gateway SHOULD decide which media stream (if
        any) are to be played to the user.
     
     
     8.2.2.2.10 Cancelling pending SIP INVITE transactions
     
     
        When a gateway sends a new SIP INVITE request containing new digits,
        it SHOULD NOT send a SIP CANCEL request to cancel the previous SIP
        INVITE transaction. 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.
     
     
     8.2.2.2.11 SIP INVITE requests reaching multiple gateways
     
     
        Each SIP INVITE request sent by a gateway represents a new
        transaction and hence can be routed differently. For instance, the
        first SIP INVITE request might be routed to a particular egress
        gateway and a subsequent SIP INVITE request to another gateway. The
        result is that both gateways initiate call establishment in the
        remote network. Since one of the call establishments has an
        incomplete destination number, it can be expected to fail, having
        already consumed resources in the remote network.
     
        To avoid this problem it is RECOMMENDED that all the SIP INVITE
        requests should follow the same path as the first one. This would
        however restrict the number of services the SIP network can provide.
        It would not be possible to route a subsequent SIP INVITE request to
        an application server just because the previous one was routed in a
        different way.
     
     
     
     Elwell et alia          Expires - October 2002               [Page 15]


                       Interworking between SIP and QSIG        April 2002
     
     
        This issue should be taken into consideration before using overlap
        signalling in SIP. If initiating multiple call establishments in the
        remote network is not acceptable in a particular application, overlap
        signalling SHOULD NOT be used.
     
     
     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, 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), the gateway SHALL NOT issue a
        QSIG SETUP message and SHALL send a SIP 4xx, 5xx or 6xx response.
     
        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 SHALL NOT issue a QSIG SETUP message
        and SHALL send a SIP 488 (Not Acceptable Here) response.
     
        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 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 the SDP answer would need to be returned in a SIP PRACK
        request.
     
        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
     
     
     
     
     Elwell et alia          Expires - October 2002               [Page 16]


                       Interworking between SIP and QSIG        April 2002
     
     
        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
        at the egress from the PISN or if the PISN is usable 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.
     
        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 the SDP answer 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.
     
        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 the SDP answer is included in the transmitted SIP
        response or has already been sent or received. Inclusion of SDP offer
     
     
     
     Elwell et alia          Expires - October 2002               [Page 17]


                       Interworking between SIP and QSIG        April 2002
     
     
        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
     
     
        When sending a SIP 18x provisional response, the gateway SHALL
        include SDP information 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 have already been
        exchanged, no SDP 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 was received in the SIP
        INVITE request but no SDP answer has been sent, SDP answer 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 was received in the SIP
        INVITE request and no SDP offer has already been sent, SDP offer
        SHALL be included in the SIP 18x provisional response.
     
        NOTE 1. In this case, SDP answer 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 SHALL be included
        in the SIP 18x provisional response.
     
        NOTE 2. Because the provisional response is unreliable, SDP answer
        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 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 have already been
        exchanged, no SDP 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 SDP offer was received in the SIP
     
     
     Elwell et alia          Expires - October 2002               [Page 18]


                       Interworking between SIP and QSIG        April 2002
     
     
        INVITE request but no SDP answer has been sent, SDP answer 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 was received in the SIP
        INVITE request and no SDP offer has already been sent, SDP offer
        SHALL be included in the SIP 200 response.
     
        NOTE 1. In this case, SDP answer 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 SHALL be included
        in the SIP 200 response.
     
        NOTE 2. Because the provisional response is unreliable, SDP answer
        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 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 the SDP answer 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 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 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.
     
        If the SIP ACK contains SDP answer, 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.
     
     
     
     
     
     Elwell et alia          Expires - October 2002               [Page 19]


                       Interworking between SIP and QSIG        April 2002
     
     
     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.
     
        If a gateway receives a SIP INVITE request with the same Call-ID as
        an existing call for which the QSIG state is overlap sending and with
        updated Request-URI and To fields from which a called party number
        with a superset of digits can be derived, it SHALL generate a QSIG
        INFORMATION message using the call reference of the existing QSIG
        call instead of a new QSIG SETUP message. 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 with the same Call-ID as
        an existing call but failing to meet the other conditions above, the
        gateway SHALL clear the call by sending back a SIP 485 (Ambiguous)
        response and a QSIG DISCONNECT message with Cause Value 16 (Normal
        call clearing).
     
     
     8.4 Call clearing
     
     
     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.
     
     
        1)If the gateway has sent or received a SIP 200 (OK) response
        (indicating that call establishment is complete) and received 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 (indicating that
        call establishment is complete) but 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. In accordance with RFC 3261, 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.
     
     
     
     
     Elwell et alia          Expires - October 2002               [Page 20]


                       Interworking between SIP and QSIG        April 2002
     
     
        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.
     
        In all cases the gateway SHALL also disconnect media streams, if
        established, and allow QSIG and SIP signalling to complete in
        accordance with ECMA-143 and RFC-3261 respectively.
     
     
        Table 1 û Mapping of QSIG Cause Value to SIP 4xx-6xx responses
     
         QSIG Cause value               SIP response
         1 Unallocated number           410 Gone
         2 No route to specified        404 Not found
         transit network
         3 No route to destination      404 Not found
         4 Send special information     502 Bad Gateway or NA
         tone
         5 Misdialled trunk prefix      410 Gone
         6 Channel unacceptable         502 Bad gateway
         7 Call awarded and being       502 Bad gateway
         delivered in an established
         channel
         8 Preemption                   502 Bad gateway
         9 Preemption- circuit          502 Bad gateway
         reserved for reuse
         16 Normal call clearing        502 Bad gateway or BYE
         17 User busy                   486 Busy here
         18 No user responding          480 Temporarily unavailable
         19 No answer from the user     480 Temporarily unavailable
         20 Subscriber absent           480 Temporarily unavailable
         21 Call rejected               603 Decline
         22 Number changed              410 Gone
         23 Redirection to new          410 Gone
         destination
         25 Exchange routing error      502 Bad gateway
         26 Non selected user clearing  502 Bad gateway or NA
         27 Destination out of order    480 Temporarily unavailable
         28 Address incomplete          484 Address incomplete
         29 Facility rejected           488 Not Acceptable Here
         30 Response to STATUS ENQUIRY  502 Bad gateway (if received in
                                        call clearing message)
         31 Normal unspecified          502 Bad gateway
     
     
     Elwell et alia          Expires - October 2002               [Page 21]


                       Interworking between SIP and QSIG        April 2002
     
     
         34 No circuit/channel          503 Service unavailable
         available
         38 Network out of order        502 Bad gateway
         39 Permanent frame mode        502 Bad gateway or NA
         connection out of service
         40 Permanent frame mode        502 Bad gateway or NA
         connection operational
         41 Temporary failure           503 Service unavailable
         42 Switching equipment         502 Bad gateway
         congestion
         43 Access information          502 Bad gateway or NA
         discarded
         44 Requested circuit/channel   503 Service unavailable
         not available
         46 Precedence call blocked     502 Bad gateway
         47 Resource unavailable,       502 Bad gateway
         unspecified
         49 Quality of service not      503 Service unavailable
         available
         50 Requested facility not      503 Service unavailable
         subscribed
         53 Outgoing calls barred       488 Not Acceptable Here
         within CUG
         55 Incoming calls barred       488 Not Acceptable Here
         within CUG
         57 Bearer capability not       488 Not Acceptable Here
         authorized
         58 Bearer capability not       503 Service unavailable
         presently available
         62 Inconsistency in            502 Bad gateway
         designated outgoing access
         information and subscriber
         class
         63 Service or option not       503 Service unavailable
         available, unspecified
         65 Bearer capability not       501 Not implemented
         implemented
         66 Channel type not            502 Bad gateway
         implemented
         69 Requested facility not      503 Service unavailable
         implemented
         70 Only restricted digital     503 Service unavailable
         information bearer capability
         is available
         79 Service or option not       503 Service unavailable
         implemented, unspecified
         81 Invalid call reference      502 Bad gateway
         value
         82 Identified channel does     502 Bad gateway
     
     
     Elwell et alia          Expires - October 2002               [Page 22]


                       Interworking between SIP and QSIG        April 2002
     
     
         not exist
         83 A suspended call exists,    502 Bad gateway
         but this call identity does
         not
         84 Call identity in use        502 Bad gateway
         85 No call suspended           502 Bad gateway
         86 Call having the requested   502 Bad gateway
         call identity has been
         cleared
         87 User not member of CUG      488 Not Acceptable Here
         88 Incompatible destination    488 Not Acceptable Here
         90 Non-existant CUG            502 Bad gateway
         91 Invalid transit network     502 Bad gateway
         selection
         95 Invalid message,            500 Server internal error
         unspecified
         96 Mandatory information       500 Server internal error
         element is missing
         97 Message type non-existent   500 Server internal error
         or not implemented
         98 Message not compatible      500 Server internal error
         with call state or message
         non-existent or not
         implemented
         99 Information element non-    500 Server internal error
         existent or not implemented
         98 Invalid information         500 Server internal error
         element contents
         101 Message not compatible     500 Server internal error
         with call state
         102 Recovery on timer expiry   500 Server internal error
         103 Parameter non-existent or  500 Server internal error
         not implemented, passed on
         110 Message with unrecognized  500 Server internal error
         parameter, discarded
         111 Protocol error             500 Server internal error
         127 Interworking, unspecified  500 Server internal error
     
     
     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 ECMA-143
        and RFC-3261 respectively.
     
        NOTE. When responding to a SIP BYE request, in accordance with
        RFC 3261 the gateway is also required to respond to any other
     
     
     Elwell et alia          Expires - October 2002               [Page 23]


                       Interworking between SIP and QSIG        April 2002
     
     
        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 ECMA-143 and RFC-3261 respectively.
     
     
     8.4.4 Receipt of a SIP 4xx - 6xx response
     
     
        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. The gateway SHALL also disconnect
        media streams, if established, and allow QSIG and SIP signalling to
        complete in accordance with ECMA-143 and RFC-3261 respectively.
     
        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                    88 Incompatible destination
     402 Payment required                88 Incompatible destination
     403 Forbidden                       88 Incompatible destination
     404 Not found                       3  No route to destination
     405 Method not allowed              41 Temporary Failure
     406 Not acceptable                  41 Temporary Failure
     407 Proxy Authentication required   41 Temporary Failure
     408 Request timeout                 41 Temporary Failure
     409 Conflict                        41 Temporary Failure
     410 Gone                            1  Unallocated number
     411 Length required                 41 Temporary Failure
     413 Request Entity too long         41 Temporary Failure
     414 Request-URI too long            41 Temporary Failure
     415 Unsupported media type          65 Bearer Capability Not
                                         implemented
     420 Bad extension                   41 Temporary Failure
     480 Temporarily unavailable         18 No user responding
     481 Call/transaction doesn't exist  41 Temporary Failure
     482 Loop detected                   41 Temporary Failure
     483 Too many hops                   41 Temporary Failure
     484 Address incomplete              28 Invalid number format
     485 Ambiguous                       1  Unallocated Number
     486 Busy here                       17 User busy
     
     
     Elwell et alia          Expires - October 2002               [Page 24]


                       Interworking between SIP and QSIG        April 2002
     
     
     487 Requested Terminated            41 Temporary Failure
     488 Not Acceptable Here             65 Bearer Capability Not
                                         implemented
     500 Server internal error           41 Temporary Failure
     501 Not implemented                 41 Temporary Failure
     502 Bad gateway                     41 Temporary Failure
     503 Service unavailable             41 Temporary Failure
     504 Gateway time-out                41 Temporary Failure
     505 Version not supported           41 Temporary Failure
     600 Busy everywhere                 17 User busy
     603 Decline                         21 Call rejected
     604 Does not exist anywhere         1  Unallocated number
     606 Not acceptable                  21 Call Rejected
     
     8.4.5 Timer expiry
     
     
        The gateway SHALL run protocol timers as specified for QSIG in
        ECMA-143 and for SIP in RFC 3261. On expiry of these timers the
        actions SHALL be as specified by the respective protocol
        specifications.
     
        If the call is to be cleared due to expiry of a QSIG timer, clearing
        of the SIP call SHALL be in accordance with 8.4.1, except that if a
        final response to a SIP INVITE request needs to be sent, a SIP 408
        (Request Timeout) response SHALL be used. If the call is to be
        cleared due to expiry of a SIP timer, the gateway SHALL send a QSIG
        DISCONNECT message with Cause Value 41 (Temporary Failure) to clear
        the call in the PISN.
     
     
     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, 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
     
     
        The SIP æToÆ, æRequest-URIÆ and æFromÆ are in the form of Universal
        Resource Identifiers (URIs).
     
     
     9.1 Mapping from SIP to QSIG
     
     
        The gateway SHALL map the SIP Request-URI and From header to the QSIG
        Called and Calling party number information elements respectively.
        The way in which this is achieved is outside the scope of this
        specification.
     
     
     
     Elwell et alia          Expires - October 2002               [Page 25]


                       Interworking between SIP and QSIG        April 2002
     
     
        The gateway SHALL set the Numbering Plan Identification (NPI) and
        Type of Number (TON) fields in the QSIG Called and Calling party
        number information elements in accordance with ECMA-155.
     
        In the QSIG Calling party number information element, unless the
        gateway performs screening, the screening indicator SHALL be set to
        "user provided, not screened" (0). Unless the gateway performs
        presentation restriction, the presentation indicator SHALL be set to
        "presentation allowed" (0). Support of screening and/or presentation
        restriction is outside the scope of this specification.
     
        Unless the gateway has a means of determining the identity of the
        user that answers a call from QSIG to SIP, the QSIG Connected number
        information SHALL NOT be generated.
     
     
     9.2 Mapping from QSIG to SIP
     
     
        The gateway SHALL map the QSIG Called party number information
        element to the SIP Request-URI and the SIP To header, both of which
        SHOULD contain the same value. The gateway SHALL map the QSIG Calling
        party number information element to the SIP From header. The way in
        which this is achieved is outside the scope of this specification.
     
        If the Calling party number information element is not received in
        the QSIG SETUP message or if it does not contain a number or if the
        presentation indicator has the value "Presentation restricted", the
        gateway SHALL use its own address to generate the From header.
     
     
     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 the SDP information received along
        with the SIP INVITE request. If the SIP INVITE request does not
        contain SDP information or the media type in the SDP 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.
     
        Table 3 û Bearer capability encoding for æaudioÆ transfer
     
     
     Field                          Value
     Coding Standard                "CCITT standardized coding" (00)
     
     
     Elwell et alia          Expires - October 2002               [Page 26]


                       Interworking between SIP and QSIG        April 2002
     
     
     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 @-law"
                                    (00010)
                                    "CCITT recommendation G.711 A-law"
                                    (00011)
     
     
     
     10.2 Derivation of media type in SDP
     
     
        The gateway SHALL generate the SDP information to include in the SIP
        INVITE request based on the Bearer capability information element
        received in the QSIG SETUP message. The media type included in the
        SDP SHALL be 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 security considerations of RFC 3261 apply.
     
     
     12 Author's Addresses
     
     
        John Elwell
        Siemens Communications Limited
        Technology Drive
        Beeston
        Nottingham, UK, NG9 1LA
        email: john.elwell@siemenscomms.co.uk
     
        Frank Derks
        Philips Business Communications
        P.O. Box 32
        1200 JD, Hilversum
     
     
     Elwell et alia          Expires - October 2002               [Page 27]


                       Interworking between SIP and QSIG        April 2002
     
     
        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
     
        Patrick Mourot
        Alcatel Business Systems
        1,Rue Dr A. Schweitzer
        67400 Illkirch
        France
        email: patrick.mourot@sxb.bsf.alcatel.fr
     
     
     13 Normative References
     
     
        [1] ECMA-133 "Private Integrated Services Network (PISN û Reference
        configuration for PISN exchanges (PINX)" (International Standard
        ISO/IEC 11579-1)
     
        [2] ECMA-143 "Private Integrated Services Network - Circuit-mode
        Bearer Services - Inter-Exchange Signalling Procedures and Protocol"
        (International Standard ISO/IEC 11572)
     
        [3] ECMA-165 "Private Integrated Services Network - Generic
        Functional Protocol for the Support of Supplementary Services -
        Inter-Exchange Signalling Procedures and Protocol" (International
        Standard ISO/IEC 11582)
     
        [4] ECMA-307 "Corporate Telecommunication Networks - Signalling
        Interworking between QSIG and H.323 - Generic Functional Protocol for
        the Support of Supplementary Services" (International Standard
        ISO/IEC 21409)
     
        [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.
     
     
     
     Elwell et alia          Expires - October 2002               [Page 28]


                       Interworking between SIP and QSIG        April 2002
     
     
        [10] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation
        protocol", RFC 3261, April 2002.
     
        [11] J. Rosenberg, H. Schulzrinne, "Reliability of Provisional
        Responses in SIP", RFC BBBB.
     
        [12] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with SDP",
        Work in progress, RFC CCCC.
     
     
     
     
     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. 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. 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.
     
     
     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 - October 2002               [Page 29]


                       Interworking between SIP and QSIG        April 2002
     
     
                                   .-------------------.
                                   |                   |
                                   |     GATEWAY       |
               PISN                |                   |         IP NETWORK
                |                  `-----+------+------'                 |
                |                        |      |                        |
                |                        |      |                        |
                |   QSIG SETUP           |      |        1-INVITE        |
               1|----------------------->|......|----------------------->| 2
                |                        |      |                        |
                |                        |      |                        |
                | QSIG CALL PROCCEEDING  |      |        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 - October 2002               [Page 30]


                       Interworking between SIP and QSIG        April 2002
     
     
        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 - October 2002               [Page 31]


                       Interworking between SIP and QSIG        April 2002
     
     
        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 - October 2002               [Page 32]


                       Interworking between SIP and QSIG        April 2002
     
     
                              +----------------------+
          PISN                |        GATEWAY       |           IP NETORK
                              |                      |
          |  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
          |         AUIO              |       |         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 - October 2002               [Page 33]


                       Interworking between SIP and QSIG        April 2002
     
     
        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 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 - October 2002               [Page 34]


                       Interworking between SIP and QSIG        April 2002
     
     
                              +----------------------+
          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 - October 2002               [Page 35]


                       Interworking between SIP and QSIG        April 2002
     
     
        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|-------------------------->|       |                          |
          |     5-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 - October 2002               [Page 36]


                       Interworking between SIP and QSIG        April 2002
     
     
        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 - October 2002               [Page 37]


                       Interworking between SIP and QSIG        April 2002
     
     
                              +----------------------+
          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 - October 2002               [Page 38]


                       Interworking between SIP and QSIG        April 2002
     
     
        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 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 - October 2002               [Page 39]


                       Interworking between SIP and QSIG        April 2002
     
     
                                   .-------------------.
                                   |                   |
                                   |     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 - October 2002               [Page 40]


                       Interworking between SIP and QSIG        April 2002
     
     
        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- 200 OK            |
                |                        |      |<-----------------------|6
                |                        |      |                        |
                |                        |      |                        |
     
     
        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 IP network sends back a SIP 200 (OK) response to the SIP
        CANCEL request. All IP resources are now released
     
     
     A.5 Message sequence for call clearing from SIP to QSIG
     
     
        Below are typical message sequences for Call Clearing from SIP to
        QSIG
     
     
     Elwell et alia          Expires - October 2002               [Page 41]


                       Interworking between SIP and QSIG        April 2002
     
     
     
                                   .-------------------.
                                   |                   |
                                   |     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.
     
                                   .-------------------.
                                   |                   |
                                   |     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)
     
     
     Elwell et alia          Expires - October 2002               [Page 42]


                       Interworking between SIP and QSIG        April 2002
     
     
     
        1  The IP network sends a SIP 4xx-6xx response to the gateway
        2  The gateway sends back a SIPACK 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.
     
                                   .-------------------.
                                   |                   |
                                   |     GATEWAY       |
               IP NETWORK          |                   |              PISN
                |                  `-----+------+------'                 |
                |                        |      |                        |
                |                        |      |                        |
                |   1- CANCEL            |      |     QSIG DISCONNECT    |
               1|----------------------->|......|----------------------->|4
                |                        |      |     QSIG RELEASE       |
                |                        |      |<-----------------------|5
                |1-487 Request Terminated|      |     QSIG RELEASE COMP  |
               2|<-----------------------|      |----------------------->|6
                |                        |      |                        |
                |   1- 200 OK            |      |                        |
               3|<-----------------------|      |                        |
     
     
        Figure 14 û Typical message sequence for call clearing from SIP to
        QSIG 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 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 gateway sends back a SIP 200 (OK) response to the SIP CANCEL
        request. All IP resources are now released
        4  The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT
        message
        5  The PISN sends back a QSIG RELEASE message to the gateway in
        response to the QSIG DISCONNECT message
        6  The gateway sends a QSIG RELEASE COMPLETE message in response. All
        PISN resources are now released.
     
     
     
     
     
     
     
     Elwell et alia          Expires - October 2002               [Page 43]