diff options
Diffstat (limited to 'doc/rfc/rfc4497.txt')
| -rw-r--r-- | doc/rfc/rfc4497.txt | 3643 |
1 files changed, 3643 insertions, 0 deletions
diff --git a/doc/rfc/rfc4497.txt b/doc/rfc/rfc4497.txt new file mode 100644 index 0000000..2db71cb --- /dev/null +++ b/doc/rfc/rfc4497.txt @@ -0,0 +1,3643 @@ + + + + + + +Network Working Group J. Elwell +Request for Comments: 4497 Siemens +BCP: 117 F. Derks +Category: Best Current Practice NEC Philips + P. Mourot + O. Rousseau + Alcatel + May 2006 + + + Interworking between the Session Initiation Protocol (SIP) and QSIG + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document specifies interworking between the Session Initiation + Protocol (SIP) and QSIG within corporate telecommunication networks + (also known as enterprise networks). SIP is an Internet + application-layer control (signalling) protocol for creating, + modifying, and terminating sessions with one or more participants. + These sessions include, in particular, telephone calls. QSIG is a + signalling protocol for creating, modifying, and terminating + circuit-switched calls (in particular, telephone calls) within + Private Integrated Services Networks (PISNs). QSIG is specified in a + number of Ecma Standards and published also as ISO/IEC standards. + + + + + + + + + + + + + + + + + +Elwell, et al. Best Current Practice [Page 1] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +Table of Contents + + 1. Introduction ....................................................4 + 2. Terminology .....................................................5 + 3. Definitions .....................................................5 + 3.1. External Definitions .......................................5 + 3.2. Other definitions ..........................................5 + 3.2.1. Corporate Telecommunication Network (CN) ............5 + 3.2.2. Gateway .............................................6 + 3.2.3. IP Network ..........................................6 + 3.2.4. Media Stream ........................................6 + 3.2.5. Private Integrated Services Network (PISN) ..........6 + 3.2.6. Private Integrated Services Network Exchange + (PINX) ..............................................6 + 4. Acronyms ........................................................6 + 5. Background and Architecture .....................................7 + 6. Overview .......................................................10 + 7. General Requirements ...........................................11 + 8. Message Mapping Requirements ...................................12 + 8.1. Message Validation and Handling of Protocol Errors ........12 + 8.2. Call Establishment from QSIG to SIP .......................14 + 8.2.1. Call Establishment from QSIG to SIP Using + En Bloc Procedures .................................14 + 8.2.2. Call Establishment from QSIG to SIP Using + Overlap Procedures .................................16 + 8.3. Call Establishment from SIP to QSIG .......................20 + 8.3.1. Receipt of SIP INVITE Request for a New Call .......20 + 8.3.2. Receipt of QSIG CALL PROCEEDING Message ............21 + 8.3.3. Receipt of QSIG PROGRESS Message ...................22 + 8.3.4. Receipt of QSIG ALERTING Message ...................22 + 8.3.5. Inclusion of SDP Information in a SIP 18x + Provisional Response ...............................23 + 8.3.6. Receipt of QSIG CONNECT Message ....................24 + 8.3.7. Receipt of SIP PRACK Request .......................25 + 8.3.8. Receipt of SIP ACK Request .........................25 + 8.3.9. Receipt of a SIP INVITE Request for a Call + Already Being ......................................25 + 8.4. Call Clearing and Call Failure ............................26 + 8.4.1. Receipt of a QSIG DISCONNECT, RELEASE, or + RELEASE COMPLETE ...................................26 + 8.4.2. Receipt of a SIP BYE Request .......................29 + 8.4.3. Receipt of a SIP CANCEL Request ....................29 + 8.4.4. Receipt of a SIP 4xx-6xx Response to an + INVITE Request .....................................29 + 8.4.5. Gateway-Initiated Call Clearing ....................32 + 8.5. Request to Change Media Characteristics ...................32 + + + + + +Elwell, et al. Best Current Practice [Page 2] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + 9. Number Mapping .................................................32 + 9.1. Mapping from QSIG to SIP ..................................33 + 9.1.1. Using Information from the QSIG Called + Party Number Information Element ...................33 + 9.1.2. Using Information from the QSIG Calling + Party Number Information Element ...................33 + 9.1.3. Using Information from the QSIG Connected + Number Information Element .........................35 + 9.2. Mapping from SIP to QSIG ..................................36 + 9.2.1. Generating the QSIG Called Party Number + Information Element ................................36 + 9.2.2. Generating the QSIG Calling Party Number + Information Element ................................37 + 9.2.3. Generating the QSIG Connected Number + Information Element ................................38 + 10. Requirements for Support of Basic Services ....................39 + 10.1. Derivation of QSIG Bearer Capability Information + Element ..................................................39 + 10.2. Derivation of Media Type in SDP ..........................39 + 11. Security Considerations .......................................40 + 11.1. General ..................................................40 + 11.2. Calls from QSIG to Invalid or Restricted Numbers .........40 + 11.3. Abuse of SIP Response Code ...............................41 + 11.4. Use of the To Header URI .................................41 + 11.5. Use of the From Header URI ...............................41 + 11.6. Abuse of Early Media .....................................42 + 11.7. Protection from Denial-of-Service Attacks ................42 + 12. Acknowledgements ..............................................43 + 13. Normative References ..........................................43 + Appendix A. Example Message Sequences .............................45 + + + + + + + + + + + + + + + + + + + + + +Elwell, et al. Best Current Practice [Page 3] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +1. Introduction + + This document specifies signalling interworking between QSIG and the + Session Initiation Protocol (SIP) in support of basic services within + a corporate telecommunication network (CN) (also known as enterprise + network). + + QSIG is a signalling protocol that operates between Private + Integrated Services eXchanges (PINX) within a Private Integrated + Services Network (PISN). A PISN provides circuit-switched basic + services and supplementary services to its users. QSIG is specified + in Ecma Standards; in particular, [2] (call control in support of + basic services), [3] (generic functional protocol for the support of + supplementary services), and a number of standards specifying + individual supplementary services. + + NOTE: The name QSIG was derived from the fact that it is used for + signalling at the Q reference point. The Q reference point is a + point of demarcation between two PINXs. + + SIP is an application-layer protocol for establishing, terminating, + and modifying multimedia sessions. It is typically carried over IP + [15], [16]. Telephone calls are considered a type of multimedia + session where just audio is exchanged. SIP is defined in [10]. + + As the support of telephony within corporate networks evolves from + circuit-switched technology to Internet technology, the two + technologies will coexist in many networks for a period, perhaps + several years. Therefore, there is a need to be able to establish, + modify, and terminate sessions involving a participant in the SIP + network and a participant in the QSIG network. Such calls are + supported by gateways that perform interworking between SIP and QSIG. + + This document specifies SIP-QSIG signalling interworking for basic + services that provide a bi-directional transfer capability for + speech, DTMF, facsimile, and modem media between a PISN employing + QSIG and a corporate IP network employing SIP. Other aspects of + interworking, e.g., the use of RTP and SDP, will differ according to + the type of media concerned and are outside the scope of this + specification. + + Call-related and call-independent signalling in support of + supplementary services is outside the scope of this specification, + but support for certain supplementary services (e.g., call transfer, + call diversion) could be the subject of future work. + + + + + + +Elwell, et al. Best Current Practice [Page 4] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + Interworking between QSIG and SIP permits a call originating at a + user of a PISN to terminate at a user of a corporate IP network, or a + call originating at a user of a corporate IP network to terminate at + a user of a PISN. + + Interworking between a PISN employing QSIG and a public IP network + employing SIP is outside the scope of this specification. However, + the functionality specified in this specification is in principle + applicable to such a scenario when deployed in conjunction with other + relevant functionality (e.g., number translation, security functions, + etc.). + + This specification is applicable to any interworking unit that can + act as a gateway between a PISN employing QSIG and a corporate IP + network employing SIP. + +2. Terminology + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and + indicate requirement levels for compliant SIP implementations. + +3. Definitions + + For the purposes of this specification, the following definitions + apply. + +3.1. External Definitions + + The definitions in [2] and [10] apply as appropriate. + +3.2. Other definitions + +3.2.1. Corporate Telecommunication Network (CN) + + Sets of privately-owned or carrier-provided equipment that are + located at geographically dispersed locations and are interconnected + to provide telecommunication services to a defined group of users. + + NOTE: A CN can comprise a PISN, a private IP network (intranet), or a + combination of the two. + + + + + + + + + +Elwell, et al. Best Current Practice [Page 5] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +3.2.2. Gateway + + An entity that performs interworking between a PISN using QSIG and an + IP network using SIP. + +3.2.3. IP Network + + A network (unless otherwise stated, a corporate network) offering + connectionless packet-mode services based on the Internet Protocol + (IP) as the network-layer protocol. + +3.2.4. Media Stream + + Audio or other user information transmitted in UDP packets, typically + containing RTP, in a single direction between the gateway and a peer + entity participating in a session established using SIP. + + NOTE: Normally a SIP session establishes a pair of media streams, one + in each direction. + +3.2.5. Private Integrated Services Network (PISN) + + A CN or part of a CN that employs circuit-switched technology. + +3.2.6. Private Integrated Services Network Exchange (PINX) + + A PISN nodal entity comprising switching and call handling functions + and supporting QSIG signalling in accordance with [2]. + +4. Acronyms + + DNS Domain Name Service + IP Internet Protocol + PINX Private Integrated services Network eXchange + PISN Private Integrated Services Network + RTP Real-time Transport Protocol + SCTP Stream Control Transmission Protocol + SDP Session Description Protocol + SIP Session Initiation Protocol + TCP Transmission Control Protocol + TLS Transport Layer Security + TU Transaction User + UA User Agent + UAC User Agent Client + UAS User Agent Server + UDP User Datagram Protocol + + + + + +Elwell, et al. Best Current Practice [Page 6] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +5. Background and Architecture + + During the 1980s, corporate voice telecommunications adopted + technology similar in principle to Integrated Services Digital + Networks (ISDN). Digital circuit switches, commonly known as Private + Branch eXchanges (PBX) or more formally as Private Integrated + services Network eXchanges (PINX) have been interconnected by digital + transmission systems to form Private Integrated Services Networks + (PISN). These digital transmission systems carry voice or other + payload in fixed-rate channels, typically 64 Kbit/s, and signalling + in a separate channel. A technique known as common channel + signalling is employed, whereby a single signalling channel + potentially controls a number of payload channels or bearer channels. + A typical arrangement is a point-to-point transmission facility at T1 + or E1 rate providing a 64 Kbit/s signalling channel and 23 or 30 + bearer channels, respectively. Other arrangements are possible and + have been deployed, including the use of multiple transmission + facilities for a signalling channel and its logically associated + bearer channels. Also, arrangements involving bearer channels at + sub-64 Kbit/s have been deployed, where voice payload requires the + use of codecs that perform compression. + + QSIG is the internationally-standardized message-based signalling + protocol for use in networks as described above. It runs in a + signalling channel between two PINXs and controls calls on a number + of logically associated bearer channels between the same two PINXs. + The signalling channel and its logically associated bearer channels + are collectively known as an inter-PINX link. QSIG is independent of + the type of transmission capabilities over which the signalling + channel and bearer channels are provided. QSIG is also independent + of the transport protocol used to transport QSIG messages reliably + over the signalling channel. + + QSIG provides a means for establishing and clearing calls that + originate and terminate on different PINXs. A call can be routed + over a single inter-PINX link connecting the originating and + terminating PINX, or over several inter-PINX links in series with + switching at intermediate PINXs known as transit PINXs. A call can + originate or terminate in another network, in which case it enters or + leaves the PISN environment through a gateway PINX. Parties are + identified by numbers, in accordance with either [17] or a private + numbering plan. This basic call capability is specified in [2]. In + addition to basic call capability, QSIG specifies a number of further + capabilities supporting the use of supplementary services in PISNs. + + More recently, corporate telecommunications networks have started to + exploit IP in various ways. One way is to migrate part of the + network to IP using SIP. This might, for example, be a new branch + + + +Elwell, et al. Best Current Practice [Page 7] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + office with a SIP proxy and SIP endpoints instead of a PINX. + Alternatively, SIP equipment might be used to replace an existing + PINX or PINXs. The new SIP environment needs to interwork with the + QSIG-based PISN in order to support calls originating in one + environment and terminating in the other. Interworking is achieved + through a gateway. + + Interworking between QSIG and SIP at gateways can also be used where + a SIP network interconnects different parts of a PISN, thereby + allowing calls between the different parts. A call can enter the SIP + network at one gateway and leave at another. Each gateway would + behave in accordance with this specification. + + Another way of connecting two parts of a PISN would be to encapsulate + QSIG signalling in SIP messages for calls between the two parts. + This is outside the scope of this specification but could be the + subject of future work. + + This document specifies signalling protocol interworking aspects of a + gateway between a PISN employing QSIG signalling and an IP network + employing SIP signalling. The gateway appears as a PINX to other + PINXs in the PISN. The gateway appears as a SIP endpoint to other + SIP entities in the IP network. The environment is shown in Figure + 1. + + +------+ IP network PISN + | | + |SIP | +------+ + |Proxy | /| | + | | / |PINX | + +---+--+ *-----------+ / | | + | | | +-----+/ +------+ + | | | | | + | | | |PINX | + ---+-----+-------+--------+ Gateway +--------| | + | | | | | |\ + | | | | +-----+ \ + | | | | \ +------+ + | | | | \| | + +--+---+ +--+---+ *-----------+ |PINX | + |SIP | |SIP | | | + |End- | |End- | +------+ + |point | |point | + +------+ +------+ + + Figure 1: Environment + + + + + +Elwell, et al. Best Current Practice [Page 8] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + In addition to the signalling interworking functionality specified in + this specification, it is assumed that the gateway also includes the + following functionality: + + - one or more physical interfaces on the PISN side supporting one or + more inter-PINX links, each link providing one or more constant bit + rate channels for media streams and a reliable layer 2 connection + (e.g., over a fixed rate physical channel) for transporting QSIG + signalling messages; and + + - one or more physical interfaces on the IP network side supporting, + through layer 1 and layer 2 protocols, IP as the network layer + protocol and UDP [6] and TCP [5] as transport layer protocols, + these being used for the transport of SIP signalling messages and, + in the case of UDP, also for media streams; + + - optionally the support of TLS [7] and/or SCTP [9] as additional + transport layer protocols on the IP network side, these being used + for the transport of SIP signalling messages; and + + - a means of transferring media streams in each direction between the + PISN and the IP network, including as a minimum packetization of + media streams sent to the IP network and de-packetization of media + streams received from the IP network. + + NOTE: [10] mandates support for both UDP and TCP for the transport of + SIP messages and allows optional support for TLS and/or SCTP for this + same purpose. + + The protocol model relevant to signalling interworking functionality + of a gateway is shown in Figure 2. + + + + + + + + + + + + + + + + + + + + +Elwell, et al. Best Current Practice [Page 9] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + +---------------------------------------------------------+ + | Interworking function | + | | + +-----------------------+---------+-----------------------+ + | | | | + | SIP | | | + | | | | + +-----------------------+ | | + | | | | + | UDP/TCP/TLS/SCTP | | QSIG | + | | | | + +-----------------------+ | | + | | | | + | IP | | | + | | | | + +-----------------------+ +-----------------------+ + | IP network | | PISN | + | lower layers | | lower layers | + | | | | + +-----------------------+ +-----------------------+ + + Figure 2: Protocol model + + In Figure 2, the SIP box represents SIP syntax and encoding, the SIP + transport layer, and the SIP transaction layer. The Interworking + function includes SIP Transaction User (TU) functionality. + +6. Overview + + The gateway maps received QSIG messages, where appropriate, to SIP + messages and vice versa and maintains an association between a QSIG + call and a SIP dialog. + + A call from QSIG to SIP is initiated when a QSIG SETUP message + arrives at the gateway. The QSIG SETUP message initiates QSIG call + establishment, and an initial response message (e.g., CALL + PROCEEDING) completes negotiation of the bearer channel to be used + for that call. The gateway then sends a SIP INVITE request, having + translated the QSIG called party number to a URI suitable for + inclusion in the Request-URI. The SIP INVITE request and the + resulting SIP dialog, if successfully established, are associated + with the QSIG call. The SIP 2xx response to the INVITE request is + mapped to a QSIG CONNECT message, signifying answer of the call. + During establishment, media streams established by SIP and SDP are + connected to the bearer channel. + + + + + + +Elwell, et al. Best Current Practice [Page 10] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + A call from SIP to QSIG is initiated when a SIP INVITE request + arrives at the gateway. The gateway sends a QSIG SETUP message to + initiate QSIG call establishment, having translated the SIP Request- + URI to a number suitable for use as the QSIG called party number. + The resulting QSIG call is associated with the SIP INVITE request and + with the eventual SIP dialog. Receipt of an initial QSIG response + message completes negotiation of the bearer channel to be used, + allowing media streams established by SIP and SDP to be connected to + that bearer channel. The QSIG CONNECT message is mapped to a SIP 200 + OK response to the INVITE request. + + Appendix A gives examples of typical message sequences that can + arise. + +7. General Requirements + + In order to conform to this specification, a gateway SHALL support + QSIG in accordance with [2] as a gateway and SHALL support SIP in + accordance with [10] as a UA. In particular, the gateway SHALL + support SIP syntax and encoding, the SIP transport layer, and the SIP + transaction layer in accordance with [10]. In addition, the gateway + SHALL support SIP TU behaviour for a UA in accordance with [10] + except where stated otherwise in Sections 8, 9, and 10 of this + specification. + + NOTE: [10] mandates that a SIP entity support both UDP and TCP as + transport layer protocols for SIP messages. Other transport layer + protocols can also be supported. + + The gateway SHALL also support SIP reliable provisional responses in + accordance with [11] as a UA. + + NOTE: [11] makes provision for recovering from loss of provisional + responses (other than 100) to INVITE requests when using unreliable + transport services in the IP network. This is important for ensuring + delivery of responses that map to essential QSIG messages. + + The gateway SHALL support SDP in accordance with [8] and its use in + accordance with the offer/answer model in [12]. + + Section 9 also specifies optional use of the Privacy header in + accordance with [13] and the P-Asserted-Identity header in accordance + with [14]. + + The gateway SHALL support calls from QSIG to SIP and calls from SIP + to QSIG. + + + + + +Elwell, et al. Best Current Practice [Page 11] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + SIP methods not defined in [10] or [11] are outside the scope of this + specification but could be the subject of other specifications for + interworking with QSIG, e.g., for interworking in support of + supplementary services. + + As a result of DNS lookup by the gateway in order to determine where + to send a SIP INVITE request, a number of candidate destinations can + be attempted in sequence. The way in which this is handled by the + gateway is outside the scope of this specification. However, any + behaviour specified in this document on receipt of a SIP 4xx or 5xx + final response to an INVITE request SHOULD apply only when there are + no more candidate destinations to try or when overlap signalling + applies in the SIP network (see 8.2.2.2). + +8. Message Mapping Requirements + +8.1. Message Validation and Handling of Protocol Errors + + The gateway SHALL validate received QSIG messages in accordance with + the requirements of [2] and SHALL act in accordance with [2] on + detection of a QSIG protocol error. The requirements of this section + for acting on a received QSIG message apply only to a received QSIG + message that has been successfully validated and that satisfies one + of the following conditions: + + -the QSIG message is a SETUP message and indicates a destination in + the IP network and a bearer capability for which the gateway is able + to provide interworking; or + + -the QSIG message is a message other than SETUP and contains a call + reference that identifies an existing call for which the gateway is + providing interworking between QSIG and SIP. + + The processing of any valid QSIG message that does not satisfy any of + these conditions is outside the scope of this specification. Also, + the processing of any QSIG message relating to call-independent + signalling connections or connectionless transport, as specified in + [3], is outside the scope of this specification. + + If segmented QSIG messages are received, the gateway SHALL await + receipt of all segments of a message and SHALL validate and act on + the complete reassembled message. + + The gateway SHALL validate received SIP messages (requests and + responses) in accordance with the requirements of [10] and SHALL act + in accordance with [10] on detection of a SIP protocol error. + + + + + +Elwell, et al. Best Current Practice [Page 12] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + 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 Section 8.2.2.2 of [10]), and + indicates a destination in the PISN for which the gateway is able + to provide interworking; or + + - the SIP message is a request that relates to an existing dialog + representing a call for which the gateway is providing interworking + between QSIG and SIP; or + + - the SIP message is a CANCEL request that relates to a received + INVITE request for which the gateway is providing interworking with + QSIG but for which the only response sent is informational (1xx), + no dialog having been confirmed; or + + - the SIP message is a response to a request sent by the gateway in + accordance with this section. + + The processing of any valid SIP message that does not satisfy any of + these conditions is outside the scope of this specification. + + NOTE: These rules mean that an error detected in a received message + will not be propagated to the other side of the gateway. However, + there can be an indirect impact on the other side of the gateway, + e.g., the initiation of call clearing procedures. + + The gateway SHALL run QSIG protocol timers as specified in [2] and + SHALL act in accordance with [2] if a QSIG protocol timer expires. + Any other action on expiry of a QSIG protocol timer is outside the + scope of this specification, except that if it results in the + clearing of the QSIG call, the gateway SHALL also clear the SIP call + in accordance with Section 8.4.5. + + The gateway SHALL run SIP protocol timers as specified in [10] and + SHALL act in accordance with [10] if a SIP protocol timer expires. + Any other action on expiry of a SIP protocol timer is outside the + scope of this specification, except that if it results in the + clearing of the SIP call, the gateway SHALL also clear the QSIG call + in accordance with Section 8.4.5. + + + + + + + + +Elwell, et al. Best Current Practice [Page 13] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +8.2. Call Establishment from QSIG to SIP + +8.2.1. Call Establishment from QSIG to SIP Using En Bloc Procedures + + The following procedures apply when the gateway receives a QSIG SETUP + message containing a Sending Complete information element or the + gateway receives a QSIG SETUP message and is able to determine that + the number in the Called party number information element is + complete. + + NOTE: In the absence of a Sending Complete information element, 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 could potentially be complete, the gateway + SHALL map the QSIG SETUP message to a SIP INVITE request. The + gateway SHALL also send a QSIG CALL PROCEEDING message. + + The gateway SHALL generate the SIP Request-URI, To, and From fields + in the SIP INVITE request in accordance with Section 9. The gateway + SHALL include in the INVITE request a Supported header containing + option tag 100rel, to indicate support for [11]. + + The gateway SHALL include SDP offer information in the SIP INVITE + request as described in Section 10. It SHOULD also connect the + incoming media stream to the user information channel of the inter- + PINX link, to allow the caller to hear in-band tones or announcements + and prevent speech clipping on answer. Because of forking, the + gateway may receive more than one media stream, in which case it + SHOULD select one (e.g., the first received). If the gateway is able + to correlate an unselected media stream with a particular early + dialog established using a reliable provisional response, it MAY use + the UPDATE method [19] to stop that stream and then use the UPDATE + method to start that stream again if a 2xx response is received on + that dialog. + + 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)". + + + + +Elwell, et al. Best Current Practice [Page 14] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + If information in the QSIG SETUP message is unsuitable for generating + any of the mandatory fields in a SIP INVITE request (e.g., if a + Request-URI cannot be derived from the QSIG Called party number + information element) or for generating SDP information, the gateway + SHALL NOT issue a SIP INVITE request and SHALL initiate QSIG call + clearing procedures in accordance with [2]. + +8.2.1.2. Receipt of SIP 100 (Trying) Response to an INVITE Request + + 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 to an INVITE request + + The gateway SHALL map a received SIP 18x response to an INVITE + request to a QSIG PROGRESS or ALERTING message based on the following + conditions. + + - If a SIP 180 response is received and no QSIG ALERTING message has + been sent, the gateway SHALL generate a QSIG ALERTING message. The + gateway MAY supply ring-back tone on the user information channel of + the inter-PINX link, in which case the gateway SHALL include progress + description number 8 in the QSIG ALERTING message. Otherwise the + gateway SHALL NOT include progress description number 8 in the QSIG + ALERTING message unless the gateway is aware that in-band information + (e.g., ring-back tone) is being transmitted. + + - If a SIP 181/182/183 response is received, no QSIG ALERTING message + has been sent, and no message containing progress description number + 1 has been sent, the gateway SHALL generate a QSIG PROGRESS message + containing progress description number 1. + + 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 in accordance + with [11]. + +8.2.1.4. Receipt of SIP 2xx Response to an INVITE Request + + If the gateway receives a SIP 2xx response as the first SIP 2xx + response to a SIP INVITE request, the gateway SHALL map the SIP 2xx + response to a QSIG CONNECT message. The gateway SHALL also send a + SIP ACK request to acknowledge the 2xx response. The gateway SHALL + + + +Elwell, et al. Best Current Practice [Page 15] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + NOT include any SDP information in the SIP ACK request. If the + gateway receives further 2xx responses, it SHALL respond to each in + accordance with [10], SHOULD issue a BYE request for each, and SHALL + NOT generate any further QSIG messages. + + Media streams will normally have been established in the IP network + in each direction. If so, the gateway SHALL connect the media + streams to the corresponding user-information channel on the inter- + PINX link if it has not already done so and stop any local ring-back + tone. + + If the SIP 2xx response is received in response to the SIP PRACK + request, the gateway SHALL NOT map this message to any QSIG message. + + NOTE: A SIP 2xx response to the INVITE request can be received later + on a different dialog as a result of a forking proxy. + +8.2.1.5. Receipt of SIP 3xx Response to an INVITE Request + + On receipt of a SIP 3xx response to an INVITE request, the gateway + SHALL act in accordance with [10]. + + NOTE: This will normally result in sending a new SIP INVITE request. + + Unless the gateway supports the QSIG Call Diversion Supplementary + Service, no QSIG message SHALL be sent. The definition of Call + Diversion Supplementary Service for QSIG to SIP interworking is + beyond the scope of this specification. + +8.2.2. Call Establishment from QSIG to SIP Using Overlap Procedures + + SIP uses en bloc signalling, and it is strongly RECOMMENDED to avoid + using overlap signalling in a SIP network. A SIP/QSIG gateway + dealing with overlap signalling SHOULD perform a conversion from + overlap to en bloc signalling method using one or more of the + following mechanisms: + + - timers; + + - numbering plan information; + + - 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 Section + 8.2.2.1 SHALL apply. + + + + +Elwell, et al. Best Current Practice [Page 16] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + However, for some applications it might be impossible to avoid using + overlap signalling in the SIP network. In this case, the procedures + defined in Section 8.2.2.2 SHALL apply. + +8.2.2.1. En Bloc Signalling in SIP Network + +8.2.2.1.1. Receipt of QSIG SETUP Message + + On receipt of a QSIG SETUP message containing no Sending complete + information element and a number in the Called party number + information element that the gateway cannot determine to be complete, + the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message, start + QSIG timer T302, and await further number digits. + +8.2.2.1.2. Receipt of QSIG INFORMATION Message + + On receipt of each QSIG INFORMATION message containing no Sending + complete information element and containing a number that the gateway + cannot determine to be complete, QSIG timer T302 SHALL be restarted. + When QSIG timer T302 expires or a QSIG INFORMATION message containing + a Sending complete information element is received, the gateway SHALL + send a SIP INVITE request as described in Section 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 to INVITE Requests + + SIP responses to INVITE requests SHALL be mapped as described in + 8.2.1. + +8.2.2.2. Overlap Signalling in SIP Network + + The procedures below for using overlap signalling in the SIP network + are in accordance with the principles described in [18] for using + overlap sending when interworking with ISDN User Part (ISUP). In + [18], there is discussion of some potential problems arising from the + use of overlap sending in the SIP network. These potential problems + are applicable also in the context of QSIG-SIP interworking and can + be avoided if overlap sending in the QSIG network is terminated at + the gateway, in accordance with Section 8.2.2.1. The procedures + below should be used only where it is not feasible to use the + procedures of Section 8.2.2.1. + + + + + + + +Elwell, et al. Best Current Practice [Page 17] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +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 + Section 8.2.1.1. Otherwise, the gateway SHALL wait for more digits + to arrive in QSIG INFORMATION messages. + +8.2.2.2.2. Receipt of QSIG INFORMATION Message + + On receipt of a QSIG INFORMATION message, the gateway SHALL handle + the QSIG timer T302 in accordance with [2]. + + NOTE: [2] requires the QSIG timer to be stopped if the INFORMATION + message contains a Sending complete information element or to be + restarted otherwise. + + Further behaviour of the gateway SHALL depend on whether or not it + has already sent a SIP INVITE request. If the gateway has not sent a + SIP INVITE request and it now has the minimum number of digits + required to route the call, it SHALL send a SIP INVITE request as + specified in Section 8.2.2.1.2. If the gateway still does not have + the minimum number of digits required, it SHALL wait for more QSIG + INFORMATION messages to arrive. + + If the gateway has already sent one or more SIP INVITE requests, + whether or not final responses to those requests have been received, + it SHALL send a new SIP INVITE request in accordance with Section 3.2 + of [18]. The updated Request-URI and To fields (see Section 9) SHALL + be generated from the concatenation of information in the Called + party number information element in the received QSIG SETUP and + INFORMATION messages. + + NOTE: [18] requires the new request to have the same Call-ID and the + same From header (including tag) as in the previous INVITE request. + [18] recommends that the CSeq header should contain a value higher + than that in the previous INVITE request. + +8.2.2.2.3. Receipt of SIP 100 (Trying) Response to an INVITE Request + + The requirements of Section 8.2.1.2 SHALL apply. + + + + + + +Elwell, et al. Best Current Practice [Page 18] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +8.2.2.2.4. Receipt of SIP 18x Provisional Response to an INVITE Request + + The requirements of Section 8.2.1.3 SHALL apply. + +8.2.2.2.5. Receipt of SIP 2xx Response to an INVITE Request + + The requirements of Section 8.2.1.4 SHALL apply. In addition, the + gateway SHALL send a SIP CANCEL request in accordance with Section + 3.4 of [18] to cancel any SIP INVITE transactions for which no final + response has been received. + +8.2.2.2.6. Receipt of SIP 3xx Response to an INVITE Request + + The requirements of Section 8.2.1.5 SHALL apply. + +8.2.2.2.7. Receipt of a SIP 4xx, 5xx, or 6xx Final Response to an + INVITE Request + + On receipt of a SIP 4xx, 5xx, or 6xx final response to an INVITE + request, the gateway SHALL send back a SIP ACK request. Unless the + gateway is able to retry the INVITE request to avoid the problem + (e.g., by supplying authentication in the case of a 401 or 407 + response), the gateway SHALL also send a QSIG DISCONNECT message + (8.4.4) if no further QSIG INFORMATION messages are expected and + final responses have been received to all transmitted SIP INVITE + requests. + + NOTE: Further QSIG INFORMATION messages will not be expected after + QSIG timer T302 has expired or after a Sending complete information + element has been received. + + In all other cases, the receipt of a SIP 4xx, 5xx, or 6xx final + response to an INVITE request SHALL NOT trigger the sending of any + QSIG message. + + NOTE: If further QSIG INFORMATION messages arrive, these will result + in further SIP INVITE requests being sent, one of which might result + in successful call establishment. For example, initial INVITE + requests might produce 484 (Address Incomplete) or 404 (Not Found) + responses because the Request-URIs derived from incomplete numbers + cannot be routed, yet a subsequent INVITE request with a routable + Request-URI might produce a 2xx final response or a more meaningful + 4xx, 5xx, or 6xx final response. + + + + + + + + +Elwell, et al. Best Current Practice [Page 19] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +8.2.2.2.8. Receipt of Multiple SIP Responses to an INVITE Request + + Section 3.3 of [18] applies. + +8.2.2.2.9. Cancelling Pending SIP INVITE Transactions + + As stated in Section 3.4 of [18], when a gateway sends a new SIP + INVITE request containing new digits, it SHOULD NOT send a SIP CANCEL + request to cancel a previous SIP INVITE transaction that has not had + a final response. This SIP CANCEL request could arrive at an egress + gateway before the new SIP INVITE request and trigger premature call + clearing. + + NOTE: Previous SIP INVITE transactions can be expected to result in + SIP 4xx class responses, which terminate the transaction. In Section + 8.2.2.2.5, there is provision for cancelling any transactions still + in progress after a SIP 2xx response has been received. + +8.2.2.2.10. QSIG Timer T302 Expiry + + If QSIG timer T302 expires and the gateway has received 4xx, 5xx, or + 6xx responses to all transmitted SIP INVITE requests, the gateway + SHALL send a QSIG DISCONNECT message. If T302 expires and the + gateway has not received 4xx, 5xx, or 6xx responses to all + transmitted SIP INVITE requests, the gateway SHALL ignore any further + QSIG INFORMATION messages but SHALL NOT send a QSIG DISCONNECT + message at this stage. + + NOTE: A QSIG DISCONNECT request will be sent when all outstanding SIP + INVITE requests have received 4xx, 5xx, or 6xx responses. + +8.3. Call Establishment from SIP to QSIG + +8.3.1. Receipt of SIP INVITE Request for a New Call + + On receipt of a SIP INVITE request for a new call, if a suitable + channel is available on the inter-PINX link, the gateway SHALL + generate a QSIG SETUP message from the received SIP INVITE request. + The gateway SHALL generate the Called party number and Calling party + number information elements in accordance with Section 9 and SHALL + generate the Bearer capability information element in accordance with + Section 10. If the gateway can determine that the number placed in + the Called party number information element is complete, the gateway + MAY include the Sending complete information element. + + NOTE: 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. + + + +Elwell, et al. Best Current Practice [Page 20] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + The gateway SHOULD send a SIP 100 (Trying) response. + + If information in the SIP INVITE request is unsuitable for generating + any of the mandatory information elements in a QSIG SETUP message + (e.g., if a QSIG Called party number information element cannot be + derived from SIP Request-URI field) or if no suitable channel is + available on the inter-PINX link, the gateway SHALL NOT issue a QSIG + SETUP message and SHALL send a SIP 4xx, 5xx, or 6xx response. If no + suitable channel is available, the gateway should use response code + 503 (Service Unavailable). + + If the SIP INVITE request does not contain SDP information and does + not contain either a Required header or a Supported header with + option tag 100rel, the gateway SHOULD still proceed as above, + although an implementation can instead send a SIP 488 (Not Acceptable + Here) response, in which case it SHALL NOT issue a QSIG SETUP + message. + + NOTE: The absence of SDP offer information in the SIP INVITE request + means that the gateway might need to send SDP offer information in a + provisional response and receive SDP answer information in a SIP + PRACK request (in accordance with [11]) in order to ensure that tones + and announcements from the PISN are transmitted. SDP offer + information cannot be sent in an unreliable provisional response + because SDP answer information would need to be returned in a SIP + PRACK request. The recommendation above still to proceed with call + establishment in this situation reflects the desire to maximise the + chances of a successful call. However, if important in-band + information is likely to be denied in this situation, a gateway can + choose not to proceed. + + NOTE: If SDP offer information is present in the INVITE request, the + issuing of a QSIG SETUP message is not dependent on the presence of a + Required header or a Supported header with option tag 100rel. + + On receipt of a SIP INVITE request relating to a call that has + already been established from SIP to QSIG, the procedures of 8.3.9 + SHALL apply. + +8.3.2. Receipt of QSIG CALL PROCEEDING Message + + The receipt of a QSIG CALL PROCEEDING message SHALL NOT result in any + SIP message being sent. + + + + + + + + +Elwell, et al. Best Current Practice [Page 21] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +8.3.3. Receipt of QSIG PROGRESS Message + + A QSIG PROGRESS message can be received in the event of interworking + on the remote side of the PISN or if the PISN is unable to complete + the call and generates an in-band tone or announcement. In the + latter case, a Cause information element is included in the QSIG + PROGRESS message. + + The gateway SHALL map a received QSIG PROGRESS message to a SIP 183 + (Session Progress) response to the INVITE request. 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. + + NOTE: In accordance with [11], inclusion of option tag 100rel in a + provisional response instructs the UAC to acknowledge the provisional + response by sending a PRACK request. [11] also specifies procedures + for repeating a provisional response with option tag 100rel if no + PRACK is received. + + If the QSIG PROGRESS message contained a Progress indicator + information element with Progress description number 1 or 8, the + gateway SHALL connect the media streams to the corresponding user + information channel of the inter-PINX link if it has not already done + so, provided that SDP answer information is included in the + transmitted SIP response to the INVITE request or has already been + sent or received. Inclusion of SDP offer or answer information in + the 183 provisional response SHALL be in accordance with Section + 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 to the INVITE request. 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. + + + + + + +Elwell, et al. Best Current Practice [Page 22] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + NOTE: In accordance with [11], inclusion of option tag 100rel in a + provisional response instructs the UAC to acknowledge the provisional + response by sending a PRACK request. [11] also specifies procedures + for repeating a provisional response with option tag 100rel if no + PRACK is received. + + If the QSIG ALERTING message contained a Progress indicator + information element with Progress description number 1 or 8, the + gateway SHALL connect the media streams to the corresponding user + information channel of the inter-PINX link if it has not already done + so, provided that SDP answer information is included in the + transmitted SIP response or has already been sent or received. + Inclusion of SDP offer or answer information in the 180 provisional + response SHALL be in accordance with Section 8.3.5. + +8.3.5. Inclusion of SDP Information in a SIP 18x Provisional Response + + When sending a SIP 18x provisional response to the INVITE request, if + a QSIG message containing a Progress indicator information element + with progress description number 1 or 8 has been received the gateway + SHALL include SDP information. Otherwise, the gateway MAY include + SDP information. If SDP information is included, it shall be in + accordance with the following rules. + + If the SIP INVITE request contained a Required or Supported header + with option tag 100rel, and if SDP offer and answer information has + already been exchanged, no SDP information SHALL be included in the + SIP 18x provisional response. + + If the SIP INVITE request contained a Required or Supported header + with option tag 100rel, and if SDP offer information was received in + the SIP INVITE request but no SDP answer information has been sent, + SDP answer information SHALL be included in the SIP 18x provisional + response. + + If the SIP INVITE request contained a Required or Supported header + with option tag 100rel, and if no SDP offer information was received + in the SIP INVITE request and no SDP offer information has already + been sent, SDP offer information SHALL be included in the SIP 18x + provisional response. + + NOTE: In this case, SDP answer information can be expected in the SIP + PRACK. + + If the SIP INVITE request contained neither a Required nor a + Supported header with option tag 100rel, SDP answer information SHALL + be included in the SIP 18x provisional response. + + + + +Elwell, et al. Best Current Practice [Page 23] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + NOTE: Because the provisional response is unreliable, SDP answer + information needs to be repeated in each provisional response and in + the final SIP 2xx response. + + NOTE: If the SIP INVITE request contained no SDP offer information + and neither a Required nor a Supported header with option tag 100rel, + it should have been rejected in accordance with Section 8.3.1. + +8.3.6. Receipt of QSIG CONNECT Message + + The gateway SHALL map a QSIG CONNECT message to a SIP 200 (OK) final + response for the SIP INVITE request. The gateway SHALL also send a + QSIG CONNECT ACKNOWLEDGE message. + + If the SIP INVITE request contained a Required or Supported header + with option tag 100rel, and if SDP offer and answer information has + already been exchanged, no SDP information SHALL be included in the + SIP 200 response. + + If the SIP INVITE request contained a Required or Supported header + with option tag 100rel, and if SDP offer information was received in + the SIP INVITE request but no SDP answer information has been sent, + SDP answer information SHALL be included in the SIP 200 response. + + If the SIP INVITE request contained a Required or Supported header + with option tag 100rel, and if no SDP offer information was received + in the SIP INVITE request and no SDP offer information has already + been sent, SDP offer information SHALL be included in the SIP 200 + response. + + NOTE: In this case, SDP answer information can be expected in the SIP + ACK. + + If the SIP INVITE request contained neither a Required nor a + Supported header with option tag 100rel, SDP answer information SHALL + be included in the SIP 200 response. + + NOTE: Because the provisional response is unreliable, SDP answer + information needs to be repeated in each provisional response and in + the final 2xx response. + + NOTE: If the SIP INVITE request contained no SDP offer information + and neither a Required nor a Supported header with option tag 100rel, + it may have been rejected in accordance with Section 8.3.1. + + + + + + + +Elwell, et al. Best Current Practice [Page 24] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + 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 that SDP answer information is included in the + transmitted SIP response or has already been sent or received. + +8.3.7. Receipt of SIP PRACK Request + + The receipt of a SIP PRACK request acknowledging a reliable + provisional response SHALL NOT result in any QSIG message being sent. + The gateway SHALL send back a SIP 200 (OK) response to the SIP PRACK + request. + + If the SIP PRACK contains SDP answer information and a QSIG message + containing a Progress indicator information element with progress + description number 1 or 8 has been received, the gateway SHALL + connect the media streams to the corresponding user information + channel of the inter-PINX link. + +8.3.8. Receipt of SIP ACK Request + + The receipt of a SIP ACK request SHALL NOT result in any QSIG message + being sent. + + If the SIP ACK contains SDP answer information, the gateway SHALL + connect the media streams to the corresponding user information + channel of the inter-PINX link if it has not already done so. + +8.3.9. Receipt of a SIP INVITE Request for a Call Already Being + Established + + A gateway can receive a call from SIP using overlap procedures. This + should occur when the UAC for the INVITE request is a gateway from a + network that employs overlap procedures (e.g., an ISUP gateway or + another QSIG gateway) and the gateway has not absorbed overlap. + + For a call from SIP using overlap procedures, the gateway will + receive multiple SIP INVITE requests that belong to the same call but + have different Request-URI and To fields. Each SIP INVITE request + belongs to a different dialog. + + A SIP INVITE request is considered to be for the purpose of overlap + sending if, compared to a previously received SIP INVITE request, it + has: + + - the same Call-ID header; + - the same From header (including the tag); + - no tag in the To header; + + + + +Elwell, et al. Best Current Practice [Page 25] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + - an updated Request-URI from which can be derived a called party + number with a superset of the digits derived from the previously + received SIP INVITE request; + + and if + + - the gateway has not yet sent a final response other than 484 to + the previously received SIP INVITE request. + + If a gateway receives a SIP INVITE request for the purpose of overlap + sending, it SHALL generate a QSIG INFORMATION message using the call + reference of the existing QSIG call instead of a new QSIG SETUP + message and containing only the additional digits in the Called party + number information element. It SHALL also respond to the SIP INVITE + request received previously with a SIP 484 Address Incomplete + response. + + If a gateway receives a SIP INVITE request that meets all of the + conditions for a SIP INVITE request for the purpose of overlap + sending except the condition concerning the Request-URI, the gateway + SHALL respond to the new request with a SIP 485 (Ambiguous) response. + +8.4. Call Clearing and Call Failure + +8.4.1. Receipt of a QSIG DISCONNECT, RELEASE, or RELEASE COMPLETE + Message + + On receipt of QSIG DISCONNECT, RELEASE, or RELEASE COMPLETE message + as the first QSIG call clearing message, gateway behaviour SHALL + depend on the state of call establishment. + + 1) If the gateway has sent a SIP 200 (OK) response to a SIP INVITE + request and received a SIP ACK request, or if it has received a + SIP 200 (OK) response to a SIP INVITE request and sent a SIP ACK + request, the gateway SHALL send a SIP BYE request to clear the + call. + + 2) If the gateway has sent a SIP 200 (OK) response to a SIP INVITE + request (indicating that call establishment is complete) but has + not received a SIP ACK request, the gateway SHALL wait until a SIP + ACK is received and then send a SIP BYE request to clear the call. + + 3) If the gateway has sent a SIP INVITE request and received a SIP + provisional response but not a SIP final response, the gateway + SHALL send a SIP CANCEL request to clear the call. + + + + + + +Elwell, et al. Best Current Practice [Page 26] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + NOTE 1: In accordance with [10], if after sending a SIP CANCEL + request a SIP 2xx response is received to the SIP INVITE request, + the gateway will need to send a SIP BYE request. + + 4) If the gateway has sent a SIP INVITE request but received no SIP + response, the gateway SHALL NOT send a SIP message. If a SIP + final or provisional response is subsequently received, the + gateway SHALL then act in accordance with 1, 2, or 3 above, + respectively. + + 5) If the gateway has received a SIP INVITE request but not sent a + SIP final response, the gateway SHALL send a SIP final response + chosen according to the cause value in the received QSIG message + as specified in Table 1. SIP response 500 (Server internal error) + SHALL be used as the default for cause values not shown in + Table 1. + + NOTE 2: It is not necessarily appropriate to map some QSIG cause + values to SIP messages because these cause values are meaningful only + at the gateway. A good example of this is cause value 44, "Requested + circuit or channel not available", which signifies that the channel + number in the transmitted QSIG SETUP message was not acceptable to + the peer PINX. The appropriate behavior in this case is for the + gateway to send another SETUP message indicating a different channel + number. If this is not possible, the gateway should treat it either + as a congestion situation (no channels available; see Section 8.3.1) + or as a gateway failure situation (in which case the default SIP + response code applies). + + In all cases, the gateway SHALL also disconnect media streams, if + established, and allow QSIG and SIP signalling to complete in + accordance with [2] and [10], respectively. + + + + + + + + + + + + + + + + + + + +Elwell, et al. Best Current Practice [Page 27] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + Table 1: Mapping of QSIG Cause Value to SIP 4xx-6xx responses to an + INVITE request + + QSIG Cause value SIP response + ---------------------------------------------------------------- + 1 Unallocated number 404 Not found + 2 No route to specified 404 Not found + transit network + 3 No route to destination 404 Not found + 16 Normal call clearing (NOTE 3) + 17 User busy 486 Busy here + 18 No user responding 408 Request timeout + 19 No answer from the user 480 Temporarily unavailable + 20 Subscriber absent 480 Temporarily unavailable + 21 Call rejected 603 Decline, if location field + in Cause information element + indicates user. Otherwise: + 403 Forbidden + 22 Number changed 301 Moved permanently, if + information in diagnostic field + of Cause information element is + suitable for generating a SIP + Contact header. Otherwise: + 410 Gone + 23 Redirection to new 410 Gone + destination + 27 Destination out of order 502 Bad gateway + 28 Address incomplete 484 Address incomplete + 29 Facility rejected 501 Not implemented + 31 Normal, unspecified 480 Temporarily unavailable + 34 No circuit/channel 503 Service unavailable + available + 38 Network out of order 503 Service unavailable + 41 Temporary failure 503 Service unavailable + 42 Switching equipment 503 Service unavailable + congestion + 47 Resource unavailable, 503 Service unavailable + unspecified + 55 Incoming calls barred 403 Forbidden + within CUG + 57 Bearer capability not 403 Forbidden + authorized + 58 Bearer capability not 503 Service unavailable + presently available + 65 Bearer capability not 488 Not acceptable here (NOTE 4) + implemented + 69 Requested facility not 501 Not implemented + implemented + + + +Elwell, et al. Best Current Practice [Page 28] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + 70 Only restricted digital 488 Not acceptable here (NOTE 4) + information available + 79 Service or option not 501 Not implemented + implemented, unspecified + 87 User not member of CUG 403 Forbidden + 88 Incompatible destination 503 Service unavailable + 102 Recovery on timer expiry 504 Server time-out + + NOTE 3: A QSIG call clearing message containing cause value 16 will + normally result in the sending of a SIP BYE or CANCEL request. + However, if a SIP response is to be sent to the INVITE request, the + default response code should be used. + + NOTE 4: The gateway may include a SIP Warning header if diagnostic + information in the QSIG Cause information element allows a suitable + warning code to be selected. + +8.4.2. Receipt of a SIP BYE Request + + On receipt of a SIP BYE request, the gateway SHALL send a QSIG + DISCONNECT message with cause value 16 (normal call clearing). The + gateway SHALL also disconnect media streams, if established, and + allow QSIG and SIP signalling to complete in accordance with [2] and + [10], respectively. + + NOTE: When responding to a SIP BYE request, in accordance with [10], + the gateway is also required to respond to any other outstanding + transactions, e.g., with a SIP 487 (Request Terminated) response. + This applies in particular if the gateway has not yet returned a + final response to the SIP INVITE request. + +8.4.3. Receipt of a SIP CANCEL Request + + On receipt of a SIP CANCEL request to clear a call for which the + gateway has not sent a SIP final response to the received SIP INVITE + request, the gateway SHALL send a QSIG DISCONNECT message with cause + value 16 (normal call clearing). The gateway SHALL also disconnect + media streams, if established, and allow QSIG and SIP signalling to + complete in accordance with [2] and [10], respectively. + +8.4.4. Receipt of a SIP 4xx-6xx Response to an INVITE Request + + Except where otherwise specified in the context of overlap sending + (8.2.2.2), on receipt of a SIP final response (4xx-6xx) to a SIP + INVITE request, unless the gateway is able to retry the INVITE + request to avoid the problem (e.g., by supplying authentication in + the case of a 401 or 407 response), the gateway SHALL transmit a QSIG + DISCONNECT message. The cause value in the QSIG DISCONNECT message + + + +Elwell, et al. Best Current Practice [Page 29] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + SHALL be derived from the SIP 4xx-6xx response according to Table 2. + Cause value 31 (Normal, unspecified) SHALL be used as the default for + SIP responses not shown in Table 2. The gateway SHALL also + disconnect media streams, if established, and allow QSIG and SIP + signalling to complete in accordance with [2] and [10], respectively. + + When generating a QSIG Cause information element, the location field + SHOULD contain the value "user", if generated as a result of a SIP + response code 6xx, or the value "Private network serving the remote + user" in other circumstances. + + Table 2: Mapping of SIP 4xx-6xx responses to an INVITE request to + QSIG Cause values + + SIP response QSIG Cause value (NOTE 6) + ------------------------------------------------------------------ + 400 Bad request 41 Temporary failure + 401 Unauthorized 21 Call rejected (NOTE 5) + 402 Payment required 21 Call rejected + 403 Forbidden 21 Call rejected + 404 Not found 1 Unallocated number + 405 Method not allowed 63 Service or option + unavailable, unspecified + 406 Not acceptable 79 Service or option not + implemented, unspecified + 407 Proxy Authentication required 21 Call rejected (NOTE 5) + 408 Request timeout 102 Recovery on timer expiry + 410 Gone 22 Number changed + 413 Request entity too large 127 Interworking, unspecified + (NOTE 6) + 414 Request-URI too long 127 Interworking, unspecified + (NOTE 6) + 415 Unsupported media type 79 Service or option not + implemented, unspecified + (NOTE 6) + 416 Unsupported URI scheme 127 Interworking, unspecified + (NOTE 6) + 420 Bad extension 127 Interworking, unspecified + (NOTE 6) + 421 Extension required 127 Interworking, unspecified + (NOTE 6) + 423 Interval too brief 127 Interworking, unspecified + (NOTE 6) + 480 Temporarily unavailable 18 No user responding + 481 Call/transaction does not exist 41 Temporary failure + 482 Loop detected 25 Exchange routing error + 483 Too many hops 25 Exchange routing error + + + + +Elwell, et al. Best Current Practice [Page 30] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + 484 Address incomplete 28 Invalid number format + (NOTE 6) + 485 Ambiguous 1 Unallocated Number + 486 Busy here 17 User busy + 487 Request terminated (NOTE 7) + 488 Not Acceptable Here 65 Bearer capability not + implemented or 31 Normal, + unspecified (NOTE 8) + 500 Server internal error 41 Temporary failure + 501 Not implemented 79 Service or option not + implemented, unspecified + 502 Bad gateway 38 Network out of order + 503 Service unavailable 41 Temporary failure + 504 Gateway time-out 102 Recovery on timer expiry + 505 Version not supported 127 Interworking, unspecified + (NOTE 6) + 513 Message too large 127 Interworking, unspecified + (NOTE 6) + 600 Busy everywhere 17 User busy + 603 Decline 21 Call rejected + 604 Does not exist anywhere 1 Unallocated number + 606 Not acceptable 65 Bearer capability not + implemented or + 31 Normal, unspecified (NOTE 8) + + NOTE 5: In some cases, it may be possible for the gateway to provide + credentials to the SIP UAS that is rejecting an INVITE due to + authorization failure. If the gateway can authenticate itself, then + obviously it should do so and proceed with the call. Only if the + gateway cannot authorize itself should the gateway clear the call in + the QSIG network with this cause value. + + NOTE 6: For some response codes, the gateway may be able to retry the + INVITE request in order to work around the problem. In particular, + this may be the case with response codes indicating a protocol error. + The gateway SHOULD clear the call in the QSIG network with the + indicated cause value only if retry is not possible or fails. + + NOTE 7: The circumstances in which SIP response code 487 can be + expected to arise do not require it to be mapped to a QSIG cause + code, since the QSIG call will normally already be cleared or in the + process of clearing. If QSIG call clearing does, however, need to be + initiated, the default cause value should be used. + + NOTE 8: When the Warning header is present in a SIP 606 or 488 + message, the warning code should be examined to determine whether it + is reasonable to generate cause value 65. This cause value should be + generated only if there is a chance that a new call attempt with + + + +Elwell, et al. Best Current Practice [Page 31] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + different content in the Bearer capability information element will + avoid the problem. In other circumstances, the default cause value + should be used. + +8.4.5 Gateway-Initiated Call Clearing + + If the gateway initiates clearing of the QSIG call owing to QSIG + timer expiry, QSIG protocol error, or use of the QSIG RESTART message + in accordance with [2], the gateway SHALL also initiate clearing of + the SIP call in accordance with Section 8.4.1. If this involves the + sending of a final response to a SIP INVITE request, the gateway + SHALL use response code 480 (Temporarily Unavailable) if optional + QSIG timer T301 has expired or, otherwise, response code 408 (Request + timeout) or 500 (Server internal error), as appropriate. + + If the gateway initiates clearing of the SIP call owing to SIP timer + expiry or SIP protocol error in accordance with [10], the gateway + SHALL also initiate clearing of the QSIG call in accordance with [2] + using cause value 102 (Recovery on timer expiry) or 41 (Temporary + failure), as appropriate. + +8.5. Request to Change Media Characteristics + + If after a call has been successfully established the gateway + receives a SIP INVITE request to change the media characteristics of + the call in a way that would be incompatible with the bearer + capability in use within the PISN, the gateway SHALL send back a SIP + 488 (Not Acceptable Here) response and SHALL NOT change the media + characteristics of the existing call. + +9. Number Mapping + + In QSIG, users are identified by numbers, as defined in [1]. Numbers + are conveyed within the Called party number, Calling party number, + and Connected number information elements. The Calling party number + and Connected number information elements also contain a presentation + indicator, which can indicate that privacy is required (presentation + restricted), and a screening indicator, which indicates the source + and authentication status of the number. + + In SIP, users are identified by Universal Resource Identifiers (URIs) + conveyed within the Request-URI and various headers, including the + From and To headers specified in [10] and optionally the P-Asserted- + Identity header specified in [14]. In addition, privacy is indicated + by the Privacy header specified in [13]. + + + + + + +Elwell, et al. Best Current Practice [Page 32] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + This clause specifies the mapping between QSIG Called party number, + Calling party number, and Connected number information elements and + corresponding elements in SIP. + + A gateway MAY implement the P-Asserted-Identity header in accordance + with [14]. If a gateway implements the P-Asserted-Identity header, + it SHALL also implement the Privacy header in accordance with [13]. + If a gateway does not implement the P-Asserted-Identity header, it + MAY implement the Privacy header. + +9.1. Mapping from QSIG to SIP + + The method used to convert a number to a URI is outside the scope of + this specification. However, the gateway SHOULD take account of the + Numbering Plan (NPI) and Type Of Number (TON) fields in the QSIG + information element concerned when interpreting a number. + + Some aspects of mapping depend on whether the gateway is in the same + trust domain (as defined in [14]) as the next hop SIP node (i.e., the + proxy or UA to which the INVITE request is sent or from which INVITE + request is received) to honour requests for identity privacy in the + Privacy header. This will be network-dependent, and it is + RECOMMENDED that gateways supporting the P-Asserted-Identity header + hold a configurable list of next hop nodes that are to be trusted in + this respect. + +9.1.1. Using Information from the QSIG Called Party Number Information + Element + + When mapping a QSIG SETUP message to a SIP INVITE request, the + gateway SHALL convert the number in the QSIG Called party number + information to a URI and include that URI in the SIP Request-URI and + in the To header. + +9.1.2. Using Information from the QSIG Calling Party Number Information + Element + + When mapping a QSIG SETUP message to a SIP INVITE request, the + gateway SHALL use the Calling party number information element, if + present, as follows. + + If the information element contains a number, the gateway SHALL + attempt to derive a URI from that number. Further behaviour depends + on whether a URI has been derived and the value of the presentation + indication. + + + + + + +Elwell, et al. Best Current Practice [Page 33] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +9.1.2.1. No URI derived, and presentation indicator does not have value + "presentation restricted" + + In this case (including the case where the Calling party number + information element is absent), the gateway SHALL include a URI + identifying the gateway in the From header. Also, if the gateway + supports the mechanism defined in [14], the gateway SHALL NOT + generate a P-Asserted-Identity header. + +9.1.2.2. No URI derived, and presentation indicator has value + "presentation restricted" + + In this case, the gateway SHALL generate an anonymous From header. + Also, if the gateway supports the mechanism defined in [14], the + gateway SHALL generate a Privacy header field with parameter + priv-value = "id" and SHALL NOT generate a P-Asserted-Identity + header. The inclusion of additional values of the priv-value + parameter in the Privacy header is outside the scope of this + specification. + +9.1.2.3. URI derived, and presentation indicator has value + "presentation restricted" + + If the gateway supports the P-Asserted-Identity header and trusts the + next hop proxy to honour the Privacy header, the gateway SHALL + generate a P-Asserted-Identity header containing the derived URI, + SHALL generate a Privacy header with parameter priv-value = "id", and + SHALL generate an anonymous From header. The inclusion of additional + values of the priv-value parameter in the Privacy header is outside + the scope of this specification. + + If the gateway does not support the P-Asserted-Identity header or + does not trust the proxy to honour the Privacy header, the gateway + SHALL behave as in Section 9.1.2.2. + +9.1.2.4. URI derived, and presentation indicator does not have value + "presentation restricted" + + In this case, the gateway SHALL generate a P-Asserted-Identity header + containing the derived URI if the gateway supports this header, SHALL + NOT generate a Privacy header, and SHALL include the derived URI in + the From header. In addition, the gateway MAY use S/MIME, as + described in Section 23 of [10], to sign a copy of the From header + included in a message/sipfrag body of the INVITE request as described + in [20]. + + + + + + +Elwell, et al. Best Current Practice [Page 34] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +9.1.3. Using Information from the QSIG Connected Number Information + Element + + When mapping a QSIG CONNECT message to a SIP 200 (OK) response to an + INVITE request, the gateway SHALL use the Connected number + information element, if present, as follows. + + If the information element contains a number, the gateway SHALL + attempt to derive a URI from that number. Further behaviour depends + on whether a URI has been derived and the value of the presentation + indication. + +9.1.3.1. No URI derived, and presentation indicator does not have value + "presentation restricted" + + In this case (including the case where the Connected number + information element is absent), the gateway SHALL NOT generate a + P-Asserted-Identity header and SHALL NOT generate a Privacy header. + +9.1.3.2. No URI derived, and presentation indicator has value + "presentation restricted" + + In this case, if the gateway supports the mechanism defined in [14], + the gateway SHALL generate a Privacy header field with parameter + priv-value = "id" and SHALL NOT generate a P-Asserted-Identity + header. The inclusion of additional values of the priv-value + parameter in the Privacy header is outside the scope of this + specification. + +9.1.3.3. URI derived, and presentation indicator has value + "presentation restricted" + + If the gateway supports the P-Asserted-Identity header and trusts the + next hop proxy to honour the Privacy header, the gateway SHALL + generate a P-Asserted-Identity header containing the derived URI and + SHALL generate a Privacy header with parameter priv-value = "id". + The inclusion of additional values of the priv-value parameter in the + Privacy header is outside the scope of this specification. + + If the gateway does not support the P-Asserted-Identity header or + does not trust the proxy to honour the Privacy header, the gateway + SHALL behave as in Section 9.1.3.2. + + + + + + + + + +Elwell, et al. Best Current Practice [Page 35] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +9.1.3.4. URI derived, and presentation indicator does not have value + "presentation restricted" + + In this case, the gateway SHALL generate a P-Asserted-Identity header + containing the derived URI if the gateway supports this header and + SHALL NOT generate a Privacy header. In addition, the gateway MAY + use S/MIME, as described in Section 23 of [10], to sign a To header + containing the derived URI, the To header being included in a + message/sipfrag body of the INVITE response as described in [20]. + + NOTE: The To header in the message/sipfrag body may differ from the + to header in the response's headers. + +9.2. Mapping from SIP to QSIG + + The method used to convert a URI to a number is outside the scope of + this specification. However, NPI and TON fields in the QSIG + information element concerned SHALL be set to appropriate values in + accordance with [1]. + + Some aspects of mapping depend on whether the gateway trusts the next + hop SIP node (i.e., the proxy or UA to which the INVITE request is + sent or from which INVITE request is received) to provide accurate + information in the P-Asserted-Identity header. This will be + network-dependent, and it is RECOMMENDED that gateways hold a + configurable list of next hop nodes that are to be trusted in this + respect. + + Some aspects of mapping depend on whether the gateway is prepared to + use a URI in the From header to derive a number for the Calling party + number information element. The default behaviour SHOULD be not to + use an unsigned or unvalidated From header for this purpose, since in + principle the information comes from an untrusted source (the remote + UA). However, it is recognised that some network administrations may + believe that the benefits to be derived from supplying a calling + party number outweigh any risks of supplying false information. + Therefore, a gateway MAY be configurable to use an unsigned or + unvalidated From header for this purpose. + +9.2.1. Generating the QSIG Called Party Number Information Element + + When mapping a SIP INVITE request to a QSIG SETUP message, the + gateway SHALL convert the URI in the SIP Request-URI to a number and + include that number in the QSIG Called party number information + element. + + + + + + +Elwell, et al. Best Current Practice [Page 36] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + NOTE: The To header should not be used for this purpose. This is + because re-targeting of the request in the SIP network can change the + Request-URI but leave the To header unchanged. It is important that + routing in the QSIG network be based on the final target from the SIP + network. + +9.2.2. Generating the QSIG Calling Party Number Information Element + + When mapping a SIP INVITE request to a QSIG SETUP message, the + gateway SHALL generate a Calling party number information element as + follows. + + If the SIP INVITE request contains an S/MIME signed message/sipfrag + body [20] containing a From header, and if the gateway supports this + capability and can verify the authenticity and trustworthiness of + this information, the gateway SHALL attempt to derive a number from + the URI in that header. If no number is derived from a + message/sipfrag body, if the SIP INVITE request contains a P- + Asserted-Identity header, and if the gateway supports that header and + trusts the information therein, the gateway SHALL attempt to derive a + number from the URI in that header. If a number is derived from one + of these headers, the gateway SHALL include it in the Calling party + number information element and include value "network provided" in + the screening indicator. + + If no number is derivable as described above and if the gateway is + prepared to use the unsigned or unvalidated From header, the gateway + SHALL attempt to derive a number from the URI in the From header. If + a number is derived from the From header, the gateway SHALL include + it in the Calling party number information element and include value + "user provided, not screened" in the screening indicator. + + If no number is derivable, the gateway SHALL NOT include a number in + the Calling party number information element. + + If the SIP INVITE request contains a Privacy header with value "id" + in parameter priv-value and the gateway supports this header, or if + the value in the From header indicates anonymous, the gateway SHALL + include value "presentation restricted" in the presentation + indicator. Based on local policy, the gateway MAY use the presence + of other priv-values to set the presentation indicator to + "presentation restricted". Otherwise the gateway SHALL include value + "presentation allowed" if a number is present or "not available due + to interworking" if no number is present. + + + + + + + +Elwell, et al. Best Current Practice [Page 37] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + If the resulting Calling party number information element contains no + number and contains value "not available due to interworking" in the + presentation indicator, the gateway MAY omit the information element + from the QSIG SETUP message. + +9.2.3. Generating the QSIG Connected Number Information Element + + When mapping a SIP 2xx response to an INVITE request to a QSIG + CONNECT message, the gateway SHALL generate a Connected number + information element as follows. + + If the SIP 2xx response contains an S/MIME signed message/sipfrag + [20] body containing a To header and the gateway supports this + capability and can verify the authenticity and trustworthiness of + this information, the gateway SHALL attempt to derive a number from + the URI in that header. If no number is derived from a + message/sipfrag body, if the SIP 2xx response contains a + P-Asserted-Identity header, and if the gateway supports that header + and trusts the information therein, the gateway SHALL attempt to + derive a number from the URI in that header. If a number is derived + from one of these headers, the gateway SHALL include it in the + Connected number information element and include value "network + provided" in the screening indicator. + + If no number is derivable as described above, the gateway SHOULD NOT + include a number in the Connected number information element. + + If the SIP 2xx response contains a Privacy header with value "id" in + parameter priv-value and the gateway supports this header, the + gateway SHALL include value "presentation restricted" in the + presentation indicator. Based on local policy, the gateway MAY use + the presence of other priv-values to set the presentation indicator + to "presentation restricted". Otherwise, the gateway SHALL include + value "presentation allowed" if a number is present or "not available + due to interworking" if no number is present. + + If the resulting Connected number information element contains no + number and value "not available due to interworking" in the + presentation indicator, the gateway MAY omit the information element + from the QSIG CONNECT message. + + + + + + + + + + + +Elwell, et al. Best Current Practice [Page 38] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +10. Requirements for Support of Basic Services + + This document specifies signalling interworking for basic services + that provide a bi-directional transfer capability for speech, + facsimile, and modem media between the two networks. + +10.1. Derivation of QSIG Bearer Capability Information Element + + The gateway SHALL generate the Bearer Capability Information Element + in the QSIG SETUP message based on SDP offer information received + along with the SIP INVITE request. If the SIP INVITE request does + not contain SDP offer information or the media type in the SDP offer + information is only 'audio', then the Bearer capability information + element SHALL BE generated according to Table 3. Coding of the + Bearer capability information element for other media types is + outside the scope of this specification. + + In addition, the gateway MAY include a Low layer compatibility + information element and/or High layer compatibility information in + the QSIG SETUP message if the gateway is able to derive relevant + information from the SDP offer information. Specific mappings are + outside the scope of this specification. + + Table 3: Bearer capability encoding for 'audio' transfer + + Field Value + ----------------------------------------------------------------- + Coding Standard "CCITT standardized coding" (00) + Information transfer "3,1 kHz audio" (10000) + capability + Transfer mode "circuit mode" (00) + Information transfer rate "64 Kbits/s" (10000) + Multiplier Octet omitted + User information layer 1 Generated by gateway based on + protocol Information of the PISN. Supported + values are + "CCITT recommendation G.711 mu-law" + (00010) + "CCITT recommendation G.711 A-law" + (00011) + +10.2. Derivation of Media Type in SDP + + The gateway SHALL generate SDP offer information to include in the + SIP INVITE request based on information in the QSIG SETUP message. + The gateway MAY take account of QSIG Low layer compatibility and/or + High layer compatibility information elements, if present in the QSIG + SETUP message, when deriving SDP offer information, in which case + + + +Elwell, et al. Best Current Practice [Page 39] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + specific mappings are outside the scope of this specification. + Otherwise, the gateway shall generate SDP offer information based + only on the Bearer capability information element in the QSIG SETUP + message, in which case the media type SHALL be derived according to + Table 4. + + Table 4: Media type setting in SDP based on Bearer capability + information element + + Information transfer capability in Media type in SDP + Bearer capability information element + --------------------------------------------------------------- + "speech" (00000) audio + "3,1 kHz audio" (10000) audio + +11. Security Considerations + +11.1. General + + Normal considerations apply for UA use of SIP security measures, + including digest authentication, TLS, and S/MIME as described in + [10]. + + The translation of QSIG information elements into SIP headers can + introduce some privacy and security concerns. For example, care + needs to be taken to provide adequate privacy for a user requesting + presentation restriction if the Calling party number information + element is openly mapped to the From header. Procedures for dealing + with this particular situation are specified in Section 9.1.2. + However, since the mapping specified in this document is mainly + concerned with translating information elements into the headers and + fields used to route SIP requests, gateways consequently reveal + (through this translation process) the minimum possible amount of + information. + + There are some concerns, however, that arise from the other direction + of mapping, the mapping of SIP headers to QSIG information elements, + which are enumerated in the following paragraphs. + +11.2. Calls from QSIG to Invalid or Restricted Numbers + + When end users dial numbers in a PISN, their selections populate the + Called party number information element in the QSIG SETUP message. + Similarly, the SIP URI or tel URL and its optional parameters in the + Request-URI of a SIP INVITE request, which can be created directly by + end users of a SIP device, map to that information element at a + gateway. However, in a PISN, policy can prevent the user from + dialing certain (invalid or restricted) numbers. Thus, gateway + + + +Elwell, et al. Best Current Practice [Page 40] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + implementers may wish to provide a means for gateway administrators + to apply policies restricting the use of certain SIP URIs or tel + URLs, or SIP URI or tel URL parameters, when authorizing a call from + SIP to QSIG. + +11.3. Abuse of SIP Response Code + + Some additional risks may result from the mapping of SIP response + codes to QSIG cause values. SIP user agents could conceivably + respond to an INVITE request from a gateway with any arbitrary SIP + response code, and thus they can dictate (within the boundaries of + the mappings supported by the gateway) the Q.850 cause code that will + be sent by the gateway in the resulting QSIG call clearing message. + Generally speaking, the manner in which a call is rejected is + unlikely to provide any avenue for fraud or denial of service (e.g., + by signalling that a call should not be billed, or that the network + should take critical resources off-line). However, gateway + implementers may wish to make provision for gateway administrators to + modify the response code to cause value mappings to avoid any + undesirable network-specific behaviour resulting from the mappings + recommended in Section 8.4.4. + +11.4. Use of the To Header URI + + This specification requires the gateway to map the Request-URI rather + than the To header in a SIP INVITE request to the Called party number + information element in a QSIG SETUP message. Although a SIP UA is + expected to put the same URI in the To header and in the Request-URI, + this is not policed by other SIP entities. Therefore, a To header + URI that differs from the Request-URI received at the gateway cannot + be used as a reliable indication that the call has been re-targeted + in the SIP network or as a reliable indication of the original + target. Gateway implementers making use of the To header for mapping + to QSIG elements (e.g., as part of QSIG call diversion signalling) + may wish to make provision for disabling this mapping when deployed + in situations where the reliability of the QSIG elements concerned is + important. + +11.5. Use of the From Header URI + + The arbitrary population of the From header of requests by SIP user + agents has some well-understood security implications for devices + that rely on the From header as an accurate representation of the + identity of the originator. Any gateway that intends to use an + unsigned or unverified From header to populate the Calling party + number information element of a QSIG SETUP message should + authenticate the originator of the request and make sure that it is + authorized to assert that calling number (or make use of some more + + + +Elwell, et al. Best Current Practice [Page 41] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + secure method to ascertain the identity of the caller). Note that + gateways, like all other SIP user agents, MUST support Digest + authentication as described in [10]. Similar considerations apply to + the use of the SIP P-Asserted-Identity header for mapping to the QSIG + Calling party number or Connected number information element, i.e., + the source of this information should be authenticated. Use of a + signed message/sipfrag body to derive a QSIG Calling party number or + Connected number information element is another secure alternative. + +11.6. Abuse of Early Media + + There is another class of potential risk that is related to the cut- + through of the backwards media path before the call is answered. + Several practices described in this document involve the connection + of media streams to user information channels on inter-PINX links and + the sending of progress description number 1 or 8 in a backward QSIG + message. This can result in media being cut through end-to-end, and + it is possible for the called user agent then to play arbitrary audio + to the caller for an indefinite period of time before transmitting a + final response (in the form of a 2xx or higher response code) to an + INVITE request. This is useful since it also permits network + entities (particularly legacy networks that are incapable of + transmitting Q.850 cause values) to play tones and announcements to + indicate call failure or call progress, without triggering charging + by transmitting a 2xx response. Also, early cut-through can help + prevent clipping of the initial media when the call is answered. + There are conceivable respects in which this capability could be used + fraudulently by the called user agent for transmitting arbitrary + information without answering the call or before answering the call. + However, in corporate networks, charging is often not an issue, and + for calls arriving at a corporate network from a carrier network, the + carrier network normally takes steps to prevent fraud. + + The usefulness of this capability appears to outweigh any risks + involved, which may in practice be no greater than in existing + PISN/ISDN environments. However, gateway implementers may wish to + make provision for gateway administrators to turn off cut-through or + minimise its impact (e.g., by imposing a time limit) when deployed in + situations where problems can arise. + +11.7. Protection from Denial-of-Service Attacks + + Unlike a traditional PISN phone, a SIP user agent can launch multiple + simultaneous requests in order to reach a particular resource. It + would be trivial for a SIP user agent to launch 100 SIP INVITE + requests at a 100 port gateway, thereby tying up all of its ports. A + malicious user could choose to launch requests to telephone numbers + that are known never to answer, or, where overlap signalling is used, + + + +Elwell, et al. Best Current Practice [Page 42] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + to incomplete addresses. This could saturate resources at the + gateway indefinitely, potentially without incurring any charges. + Gateway implementers may therefore wish to provide means of + restricting according to policy the number of simultaneous requests + originating from the same authenticated source, or similar mechanisms + to address this possible denial-of-service attack. + +12. Acknowledgements + + This document is a product of the authors' activities in Ecma + (www.ecma-international.org) on interoperability of QSIG with IP + networks. An earlier version is published as Standard ECMA-339. + Ecma has made this work available to the IETF as the basis for + publishing an RFC. + + The authors wish to acknowledge the assistance of Francois Audet, + Adam Roach, Jean-Francois Rey, Thomas Stach, and members of Ecma + TC32-TG17 in preparing and commenting on this document. + +13. Normative References + + [1] International Standard ISO/IEC 11571 "Private Integrated + Services Networks (PISN) - Addressing" (also published by Ecma + as Standard ECMA-155). + + [2] International Standard ISO/IEC 11572 "Private Integrated + Services Network - Circuit-mode Bearer Services - Inter-Exchange + Signalling Procedures and Protocol" (also published by Ecma as + Standard ECMA-143). + + [3] International Standard ISO/IEC 11582 "Private Integrated + Services Network - Generic Functional Protocol for the Support + of Supplementary Services - Inter-Exchange Signalling Procedures + and Protocol" (also published by Ecma as Standard ECMA-165). + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [5] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, + September 1981. + + [6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August + 1980. + + [7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC + 2246, January 1999. + + + + + +Elwell, et al. Best Current Practice [Page 43] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + [8] Handley, M. and V. Jacobson, "SDP: Session Description + Protocol", RFC 2327, April 1998. + + [9] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, + H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, + "Stream Control Transmission Protocol", RFC 2960, October 2000. + + [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [11] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional + Responses in Session Initiation Protocol (SIP)", RFC 3262, June + 2002. + + [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with + Session Description Protocol (SDP)", RFC 3264, June 2002. + + [13] Peterson, J., "A Privacy Mechanism for the Session Initiation + Protocol (SIP)", RFC 3323, November 2002. + + [14] Jennings, C., Peterson, J., and M. Watson, "Private Extensions + to the Session Initiation Protocol (SIP) for Asserted Identity + within Trusted Networks", RFC 3325, November 2002. + + [15] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. + + [16] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460, December 1998. + + [17] ITU-T Recommendation E.164, "The International Public + Telecommunication Numbering Plan", (1997-05). + + [18] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Mapping of + Integrated Services Digital Network (ISDN) User Part (ISUP) + Overlap Signalling to the Session Initiation Protocol (SIP)", + RFC 3578, August 2003. + + [19] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE + Method", RFC 3311, October 2002. + + [20] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, + November 2002. + + + + + + + + +Elwell, et al. Best Current Practice [Page 44] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +Appendix A. Example Message Sequences + +A.1. Introduction + + This appendix shows some typical message sequences that can occur for + an interworking between QSIG and SIP. It is informative. + + 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. + + NOTE: In these examples, SIP provisional responses (other than 100) + are shown as being sent reliably, using the PRACK method for + acknowledgement. + +A.2. Message Sequences for Call Establishment from QSIG to SIP + + Below are typical message sequences for successful call establishment + from QSIG to SIP + + + + + + + + + + + + + + + + + + + + + + + + + + +Elwell, et al. Best Current Practice [Page 45] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +A.2.1. QSIG to SIP, using en bloc procedures on both QSIG and SIP + + +-------------------+ + | | + | GATEWAY | + PISN | | IP NETWORK + | +-----+------+------+ | + | | | | + | | | | + | QSIG SETUP | | 1-INVITE | + 1|----------------------->|......|----------------------->| 2 + | | | | + | | | | + | QSIG CALL PROCEEDING | | 1-100 TRYING | + 3|<-----------------------| |<-----------------------+ 4 + | | | | + | | | | + | QSIG ALERTING | | 1-180 RINGING | + 8|<-----------------------|......|<-----------------------+ 5 + | | | | + | | | 2-PRACK | + | | |----------------------->| 6 + | | | 2-200 OK | + | | |<-----------------------+ 7 + | | | | + | QSIG CONNECT | | 1-200 OK | + 11|<-----------------------|......|<-----------------------+ 9 + | | | | + | QSIG CONNECT ACK | | 1-ACK | + 12|----------------------->| |----------------------->| 10 + | | | | + |<======================>| |<======================>| + | AUDIO | | AUDIO | + + Figure 3: Typical message sequence for successful call establishment + from QSIG to SIP, using en bloc 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. + + + + + +Elwell, et al. Best Current Practice [Page 46] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + 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 + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Elwell, et al. Best Current Practice [Page 47] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +A.2.2. QSIG to SIP, using overlap receiving on QSIG and en bloc sending + on SIP + + +------------------------+ + 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 en bloc 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. + 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. + + + +Elwell, et al. Best Current Practice [Page 48] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + 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 al. Best Current Practice [Page 49] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +A.2.3. QSIG to SIP, using overlap procedures on both QSIG and SIP + + +----------------------+ + PISN | GATEWAY | IP NETWORK + | | + | QSIG SETUP +-------+-------+------+ | + 1 |------------------------->| | | + | | | | + | QSIG SETUP ACK | | | + 2 |<-------------------------| | | + | | | | + | QSIG INFORMATION | | | + 3 |------------------------->| | | + | QSIG INFORMATION | | 1-INVITE | + 3 |------------------------->|.......|------------------------>|4 + | | | 1-484 | + | | |<------------------------|5 + | | | 1-ACK | + | | |------------------------>|6 + | QSIG INFORMATION | | 2-INVITE | + 7 |------------------------->|.......|------------------------>|4 + | | | 2-484 | + | | |<------------------------|5 + | | | 2-ACK | + | | |------------------------>|6 + | | | | + | QSIG INFORMATION | | | + | Sending Complete IE | | 3-INVITE | + 8 |------------------------->|.......|------------------------>|10 + | QSIG CALL PROCEEDING | | 3-100 TRYING | + 9 |<-------------------------| |<------------------------|11 + | | | | + | QSIG ALERTING | | 3-180 RINGING | + 15|<-------------------------|.......|<------------------------|12 + | | | 4-PRACK | + | | |------------------------>|13 + | | | 4-200 OK | + | | |<------------------------|14 + | QSIG CONNECT | | 3-200 OK | + 18|<-------------------------|.......|<------------------------|16 + | | | | + | QSIG CONNECT ACK | | 3-ACK | + 19|------------------------->| |------------------------>|17 + | AUDIO | | AUDIO | + |<========================>| |<=======================>| + | | | | + + + + + +Elwell, et al. Best Current Practice [Page 50] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + Figure 5: Typical message sequence for successful call establishment + from QSIG to SIP, using overlap 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. The QSIG SETUP message does not contain a + Sending complete information element. + 2 The gateway sends a QSIG SETUP ACKNOWLEDGE message to the PISN. + More digits are expected. + 3 More digits are sent from the PISN within a QSIG INFORMATION + message. + 4 When the gateway receives the minimum number of digits required to + route the call, it generates a SIP INVITE request and sends it to + an appropriate SIP entity in the IP network based on the called + number + 5 Due to an insufficient number of digits, the IP network will + return a SIP 484 (Address Incomplete) response. + 6 The SIP 484 (Address Incomplete) response is acknowledged. + 7 More digits are received from the PISN in a QSIG INFORMATION + message. A new INVITE is sent with the same Call-ID and From + values but an updated Request-URI. + 8 More digits are received from the PISN in a QSIG INFORMATION + message. The QSIG INFORMATION message contains a Sending Complete + information element. + 9 The gateway sends a QSIG CALL PROCEEDING message to the PISN; no + more information will be accepted. + 10 The gateway sends a new SIP INVITE request with an updated + Request-URI field. + 11 The IP network sends a SIP 100 (Trying) response to the gateway. + 12 The IP network sends a SIP 180 (Ringing) response. + 13 The gateway may send back a SIP PRACK request to the IP network + based on the inclusion of a Require header or a Supported header + with option tag 100rel in the initial SIP INVITE request. + 14 The IP network sends a SIP 200 (OK) response to the gateway to + acknowledge the SIP PRACK request. + 15 The gateway maps this SIP 180 (Ringing) response to a QSIG + ALERTING message and sends it to the PISN. + 16 The IP network sends a SIP 200 (OK) response when the call is + answered. + 17 The gateway sends a SIP ACK request to acknowledge the SIP 200 + (OK) response. + 18 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT + message. + 19 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to + the QSIG CONNECT message. + + + + + + + +Elwell, et al. Best Current Practice [Page 51] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +A.3. Message sequences for call establishment from SIP to QSIG + + Below are typical message sequences for successful call establishment + from SIP to QSIG + +A.3.1. SIP to QSIG, using en bloc procedures + + +----------------------+ + 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 en bloc 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. + + + + + +Elwell, et al. Best Current Practice [Page 52] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + 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. + 12 The IP network, upon receiving a SIP INVITE final response (200), + will send a SIP ACK request to acknowledge receipt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Elwell, et al. Best Current Practice [Page 53] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +A.3.2. SIP to QSIG, using overlap receiving on SIP and en bloc sending + on QSIG + + +----------------------+ + IP NETWORK | GATEWAY | PISN + | | + | 1-INVITE +-------+-------+------+ | + 1 |------------------------->| | | + | 1-484 | | | + 2 |<-------------------------| | | + | 1-ACK | | | + 3 |------------------------->| | | + | 2-INVITE | | | + 1 |------------------------->| | | + | 2-484 | | | + 2 |<-------------------------| | | + | 2- ACK | | | + 3 |------------------------->| | | + | 3-INVITE | | QSIG SETUP | + 4 |------------------------->|.......|------------------------>|6 + | 3-100 TRYING | | QSIG CALL PROCEEDING | + 5 |<-------------------------| |<------------------------|7 + | 3-180 RINGING | | QSIG ALERTING | + 9 |<-------------------------|.......|<------------------------|8 + | | | | + | | | | + | 4-PRACK | | | + 10|------------------------->| | | + | 4-200 OK | | | + 11|<-------------------------| | | + | 3-200 OK | | QSIG CONNECT | + 14|<-------------------------|.......|<------------------------|12 + | | | | + | 3-ACK | | QSIG CONNECT ACK | + 15|------------------------->| |------------------------>|13 + | AUDIO | | AUDIO | + |<========================>| |<=======================>| + | | | | + + Figure 7: Typical message sequence for successful call establishment + from SIP to QSIG, using overlap receiving on SIP and en bloc 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 acknowledges the SIP 484 (Address Incomplete) + response. + + + +Elwell, et al. Best Current Practice [Page 54] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + 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 al. Best Current Practice [Page 55] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +A.3.3. SIP to QSIG, using overlap procedures on both SIP and QSIG + + +----------------------+ + 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 acknowledges the SIP 484 (Address Incomplete) + response. + + + + +Elwell, et al. Best Current Practice [Page 56] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + + 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 to + the IP network. + 6 The gateway sends a QSIG SETUP message. + 7 The PISN needs more digits to route the call and sends a QSIG + SETUP ACKNOWLEDGE message to the gateway. + 8 The IP network sends a new SIP INVITE request with the same + Call-ID and From values and updated Request-URI. + 9 The gateway sends back a SIP 100 (Trying) response to the IP + network. + 10 The gateway maps the new SIP INVITE request to a QSIG INFORMATION + message. + 11 The PISN has all the digits required and sends back a QSIG CALL + PROCEEDING message to the gateway. + 12 A QSIG ALERTING message is returned to indicate that the end user + in the PISN is being alerted. + 13 The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing) + response. + 14 The gateway sends a SIP 484 (Address Incomplete) response for the + previous SIP INVITE request. + 15 The IP network acknowledges the SIP 484 (Address Incomplete) + response. + 16 The IP network can send back a SIP PRACK request to the IP network + based on the inclusion of a Require header or a Supported header + with option tag 100rel in the initial SIP INVITE request. + 17 The gateway sends a SIP 200 (OK) response to acknowledge the SIP + PRACK request. + 18 The PISN sends a QSIG CONNECT message to the gateway when the call + is answered. + 19 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to + acknowledge the QSIG CONNECT message. + 20 The QSIG CONNECT message is mapped to a SIP 200 (OK) response. + 21 The IP network, upon receiving a SIP INVITE final response (200), + will send a SIP ACK request to acknowledge receipt. + + + + + + + + + + + + + + + +Elwell, et al. Best Current Practice [Page 57] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +A.4. Message Sequence for Call Clearing from QSIG to SIP + + Below are typical message sequences for Call Clearing from QSIG to + SIP + +A.4.1. QSIG to SIP, subsequent to call establishment + + +-------------------+ + | | + | 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. + + + + + + + + + + + + + + + + +Elwell, et al. Best Current Practice [Page 58] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +A.4.2. QSIG to SIP, during establishment of a call from SIP to QSIG + + +-------------------+ + | | + | 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) + + 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 + + + + + + + + + + + + + + + + + + + + +Elwell, et al. Best Current Practice [Page 59] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +A.4.3. QSIG to SIP, during establishment of a call from QSIG to SIP + + +-------------------+ + | | + | GATEWAY | + PISN | | IP NETWORK + | +-----+------+------+ | + | | | | + | | | | + | QSIG DISCONNECT | | 1- CANCEL | + 1|----------------------->|......|----------------------->|4 + | QSIG RELEASE | |1-487 Request Terminated| + 2|<-----------------------| |<-----------------------|5 + | QSIG RELEASE COMP | | | + 3|----------------------->| | 1- ACK | + | | |----------------------->|6 + | | | | + | | | 1- 200 OK | + | | |<-----------------------|7 + | | | | + + Figure 11: Typical message sequence for call clearing from QSIG to + SIP, during establishment of a call from QSIG to SIP (gateway has + received a provisional response to the SIP INVITE request but not a + final response) + + 1 The PISN sends a QSIG DISCONNECT message to the gateway. + 2 The gateway sends back a QSIG RELEASE message to the PISN in + response to the QSIG DISCONNECT message. + 3 The PISN sends a QSIG RELEASE COMPLETE message in response. All + PISN resources are now released. + 4 The gateway maps the QSIG DISCONNECT message to a SIP CANCEL + request (subject to receipt of a provisional response, but not of + a final response). + 5 The IP network sends back a SIP 487 (Request Terminated) response + to the SIP INVITE request. + 6 The gateway, on receiving a SIP final response (487) to the SIP + INVITE request, sends back a SIP ACK request to acknowledge + receipt. + 7 The IP network sends back a SIP 200 (OK) response to the SIP + CANCEL request. All IP resources are now released. + + + + + + + + + + +Elwell, et al. Best Current Practice [Page 60] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +A.5. Message Sequence for Call Clearing from SIP to QSIG + + Below are typical message sequences for Call Clearing from SIP to + QSIG + +A.5.1. SIP to QSIG, subsequent to call establishment + + +-------------------+ + | | + | GATEWAY | + IP NETWORK | | PISN + | +-----+------+------+ | + | | | | + | | | | + | 2- BYE | | QSIG DISCONNECT | + 1|----------------------->|......|----------------------->|3 + | | | QSIG RELEASE | + | | |<-----------------------|4 + | 2-200 OK | | QSIG RELEASE COMP | + 2|<-----------------------| |----------------------->|5 + | | | | + | | | | + + Figure 12: Typical message sequence for call clearing from SIP to + QSIG, subsequent to call establishment + + 1 The IP network sends a SIP BYE request to the gateway. + 2 The gateway sends back a SIP 200 (OK) response to the SIP BYE + request. All IP resources are now released. + 3 The gateway maps the SIP BYE request to a QSIG DISCONNECT message. + 4 The PISN sends back a QSIG RELEASE message to the gateway in + response to the QSIG DISCONNECT message. + 5 The gateway sends a QSIG RELEASE COMPLETE message in response. + All PISN resources are now released. + + + + + + + + + + + + + + + + + +Elwell, et al. Best Current Practice [Page 61] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +A.5.2. SIP to QSIG, during establishment of a call from QSIG to SIP + + +-------------------+ + | | + | GATEWAY | + IP NETWORK | | PISN + | +-----+------+------+ | + | | | | + | | | | + | 1- 4XX / 6XX | | QSIG DISCONNECT | + 1|----------------------->|......|----------------------->|3 + | | | QSIG RELEASE | + | | |<-----------------------|4 + | 1- ACK | | QSIG RELEASE COMP | + 2|<-----------------------| |----------------------->|5 + | | | | + | | | | + | | | | + + Figure 13: Typical message sequence for call clearing from SIP to + QSIG, during establishment of a call from QSIG to SIP (gateway has + not previously received a final response to the SIP INVITE request) + + 1 The IP network sends a SIP 4xx-6xx response to the gateway. + 2 The gateway sends back a SIP ACK request in response to the SIP + 4xx-6xx response. All IP resources are now released. + 3 The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT + message. + 4 The PISN sends back a QSIG RELEASE message to the gateway in + response to the QSIG DISCONNECT message. + 5 The gateway sends a QSIG RELEASE COMPLETE message in response. + All PISN resources are now released. + + + + + + + + + + + + + + + + + + + +Elwell, et al. Best Current Practice [Page 62] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +A.5.3. SIP to QSIG, during establishment of a call from SIP to QSIG + + +-------------------+ + | | + | GATEWAY | + IP NETWORK | | PISN + | +-----+------+------+ | + | | | | + | | | | + | 1- CANCEL | | QSIG DISCONNECT | + 1|----------------------->|......|----------------------->|4 + | | | QSIG RELEASE | + | | |<-----------------------|5 + |1-487 Request Terminated| | QSIG RELEASE COMP | + 2|<-----------------------| |----------------------->|6 + | | | | + | 1- ACK | | | + 3|----------------------->| | | + | | | | + | 1- 200 OK | | | + 4|<-----------------------| | | + + Figure 14: Typical message sequence for call clearing from SIP to + QSIG, during establishment of a call from SIP to QSIG (gateway has + sent a provisional response to the SIP INVITE request but not a final + response) + + 1 The IP network sends a SIP CANCEL request to the gateway. + 2 The gateway sends back a SIP 487 (Request Terminated) response to + the SIP INVITE request. + 3 The IP network, on receiving a SIP final response (487) to the SIP + INVITE request, sends back a SIP ACK request to acknowledge + receipt. + 4 The gateway sends back a SIP 200 (OK) response to the SIP CANCEL + request. All IP resources are now released. + 5 The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT + message. + 6 The PISN sends back a QSIG RELEASE message to the gateway in + response to the QSIG DISCONNECT message. + 7 The gateway sends a QSIG RELEASE COMPLETE message in response. + All PISN resources are now released. + + + + + + + + + + +Elwell, et al. Best Current Practice [Page 63] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +Authors' Addresses + + John Elwell + Siemens plc + Technology Drive + Beeston + Nottingham, UK, NG9 1LA + + EMail: john.elwell@siemens.com + + + Frank Derks + NEC Philips Unified Solutions + Anton Philipsweg 1 + 1223 KZ Hilversum + The Netherlands + + EMail: frank.derks@nec-philips.com + + + Olivier Rousseau + Alcatel Business Systems + 32,Avenue Kleber + 92700 Colombes + France + + EMail: Olivier.Rousseau@alcatel.fr + + + Patrick Mourot + Alcatel Business Systems + 1,Rue Dr A. Schweitzer + 67400 Illkirch + France + + EMail: Patrick.Mourot@alcatel.fr + + + + + + + + + + + + + + + +Elwell, et al. Best Current Practice [Page 64] + +RFC 4497 Interworking between SIP and QSIG May 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Elwell, et al. Best Current Practice [Page 65] + |