[RFCs/IDs] [Plain Text] [From draft-ietf-sipping-qsig2sip]
BEST CURRENT PRACTICE
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 Practic