Internet Engineering Task Force J. Elwell
Internet Draft Siemens
F. Derks
Philips
P. Mourot/O. Rousseau
draft-elwell-sipping-qsig2sip-00.txt Alcatel
Expires: October 2002 April 2002
Interworking between SIP and QSIG
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026 except that the right to produce derivative
works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document specifies interworking between the Session Initiation
Protocol (SIP) and QSIG within corporate networks. SIP is an Internet
application-layer control (signalling) protocol for creating,
modifying, and terminating sessions with one or more participants.
These sessions include, in particular, telephone calls. QSIG is a
signalling protocol for creating, modifying and terminating circuit-
switched calls, in particular telephone calls, within Private
Integrated Services Networks (PISNs). QSIG is specified in a number
of ECMA Standards and published also as ISO/IEC standards.
As the support of telephony within corporate networks evolves from
circuit-switched technology to Internet technology, the two
technologies will co-exist in many networks for a period, perhaps
several years. Therefore there is a need to be able to establish,
modify and terminate sessions involving a participant in the SIP
Elwell et alia Expires - October 2002 [Page 1]
Interworking between SIP and QSIG April 2002
network and a participant in the QSIG network. Such calls are
supported by gateways that perform interworking between SIP and QSIG.
This document is a product of the authors' activities in ECMA
(www.ecma.ch) on interoperability of QSIG with IP networks.
1 Introduction....................................................3
2 Terminology.....................................................4
3 Definitions.....................................................4
3.1 External definitions..........................................4
3.2 Other definitions.............................................5
3.2.1 Gateway.....................................................5
3.2.2 IP network..................................................5
3.2.3 Media stream................................................5
4 Acronyms........................................................5
5 Architecture....................................................5
6 Overview........................................................7
7 General requirements............................................7
8 Message mapping requirements....................................8
8.1 Message validation and handling of protocol errors............8
8.2 Call establishment from QSIG to SIP...........................9
8.2.1 Call establishment from QSIG to SIP using enbloc procedures.9
8.2.1.1 Receipt of QSIG SETUP message............................10
8.2.1.2 Receipt of SIP 100 (Trying) response.....................10
8.2.1.3 Receipt of SIP 18x provisional response..................10
8.2.1.4 Receipt of SIP 2xx response..............................11
8.2.1.5 Receipt of SIP 3xx response..............................12
8.2.2 Call establishment from QSIG to SIP using overlap procedures12
8.2.2.1 Enbloc signalling in SIP network.........................12
8.2.2.1.1 Receipt of QSIG SETUP message..........................12
8.2.2.1.2 Receipt of QSIG INFORMATION message....................13
8.2.2.1.3 Receipt of SIP responses...............................13
8.2.2.2 Overlap signalling in SIP network........................13
8.2.2.2.1 Receipt of QSIG SETUP message..........................13
8.2.2.2.2 Receipt of QSIG INFORMATION message....................13
8.2.2.2.3 Receipt of SIP 100 (Trying) response...................14
8.2.2.2.4 Receipt of SIP 18x provisional response................14
8.2.2.2.5 Receipt of SIP 2xx response............................14
8.2.2.2.6 Receipt of SIP 3xx response............................14
8.2.2.2.7 Receipt of a SIP 484 (Address Incomplete) response.....14
8.2.2.2.8 Receipt of a SIP 4xx (except 484), 5xx or 6xx response.14
8.2.2.2.9 Receipt of multiple SIP responses......................15
8.2.2.2.10 Cancelling pending SIP INVITE transactions............15
8.2.2.2.11 SIP INVITE requests reaching multiple gateways........15
8.3 Call Establishment from SIP to QSIG..........................16
8.3.1 Receipt of SIP INVITE request for a new call...............16
8.3.2 Receipt of QSIG CALL PROCEEDING message....................16
8.3.3 Receipt of QSIG PROGRESS message...........................17
Elwell et alia Expires - October 2002 [Page 2]
Interworking between SIP and QSIG April 2002
8.3.4 Receipt of QSIG ALERTING message...........................17
8.3.5 Inclusion of SDP information in a SIP 18x provisional response
.................................................................18
8.3.6 Receipt of QSIG CONNECT message............................18
8.3.7 Receipt of SIP PRACK request...............................19
8.3.8 Receipt of SIP ACK request.................................19
8.3.9 Receipt of a SIP INVITE request for a call already being
established......................................................20
8.4 Call clearing................................................20
8.4.1 Receipt of a QSIG DISCONNECT, RELEASE or RELEASE COMPLETE
message..........................................................20
8.4.2 Receipt of a SIP BYE request...............................23
8.4.3 Receipt of a SIP CANCEL request............................24
8.4.4 Receipt of a SIP 4xx - 6xx response........................24
8.4.5 Timer expiry...............................................25
8.5 Request to change media characteristics......................25
9 Number mapping.................................................25
9.1 Mapping from SIP to QSIG.....................................25
9.2 Mapping from QSIG to SIP.....................................26
10 Requirements for support of basic services....................26
10.1 Derivation of QSIG Bearer capability information element....26
10.2 Derivation of media type in SDP.............................27
11 Security considerations.......................................27
12 Author's Addresses............................................27
13 Normative References..........................................28
Annex A û Example message sequences..............................29
1 Introduction
This document specifies signalling interworking between "QSIG" and
the Session Initiation Protocol (SIP) in support of basic services
within a corporate telecommunication network (CN).
"QSIG" is a signalling protocol that operates at the Q reference
point between Private Integrated Services eXchanges (PINX) within a
Private Integrated Services Network (PISN). The Q reference point is
defined in ECMA-133. A PISN provides circuit-switched basic services
and supplementary services to its users. QSIG is specified in ECMA
Standards, in particular ECMA-143 (call control in support of basic
services), ECMA-165 (generic functional protocol for the support of
supplementary services) and a number of Standards specifying
individual supplementary services.
SIP is an application layer protocol for establishing, terminating
and modifying multimedia sessions. It is typically carried over IP.
Telephone calls are considered as a type of multimedia session where
just audio is exchanged. SIP is defined in IETF RFC 3261.
Elwell et alia Expires - October 2002 [Page 3]
Interworking between SIP and QSIG April 2002
This document specifies signalling interworking for basic services
that provide a bi-directional transfer capability for speech, DTMF,
facsimile and modem media between a PISN employing QSIG and a
corporate IP network employing SIP. Call-related and call-independent
signalling in support of supplementary services is outside the scope
of this specification.
Interworking between QSIG and SIP permits a call originating at a
user of a PISN to terminate at a user of a corporate IP network, or a
call originating at a user of a corporate IP network to terminate at
a user of a PISN.
Interworking between a PISN employing QSIG and a public IP network
employing SIP is outside the scope of this specification. However,
the functionality specified in this specification is in principle
applicable to such a scenario when deployed in conjunction with other
relevant functionality (e.g., number translation, security functions,
etc.).
This specification is applicable to any interworking unit that can
act as a gateway between a PISN employing QSIG and a corporate IP
network employing SIP.
2 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
indicate requirement levels for compliant SIP implementations.
3 Definitions
For the purposes of this specification, the following definitions
apply.
3.1 External definitions
This specification uses the following terms defined in other
documents:
-Call (ECMA-307)
-Corporate telecommunication network (CN) (ECMA-307)
-Private Integrated Services Network (PISN) (ECMA-307)
-Private Integrated services Network eXchange (PINX) (ECMA-133)
Additionally the definitions in ECMA-143 and IETF RFC 3261 apply as
appropriate.
Elwell et alia Expires - October 2002 [Page 4]
Interworking between SIP and QSIG April 2002
3.2 Other definitions
3.2.1 Gateway
An entity that performs interworking between a PISN using QSIG and an
IP network using SIP.
3.2.2 IP network
A network, unless otherwise stated a corporate network, offering
connectionless packet-mode services based on the Internet Protocol
(IP) as the network layer protocol.
3.2.3 Media stream
Audio or other user information transmitted in UDP packets, typically
containing RTP, in a single direction between the gateway and a peer
entity participating in a session established using SIP.
NOTE. Normally a SIP session establishes a pair of media streams, one
in each direction.
4 Acronyms
DNS Domain Name Service
PINX Private Integrated services Network eXchange
PISN Private Integrated Services Network
RTP Real-time Transport Protocol
SCTP Stream Control Transmission Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
TCP Transmission Control Protocol
TLS Transport Layer Security
TU Transaction User
UA User Agent
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
5 Architecture
This document specifies signalling protocol interworking aspects of a
gateway between a PISN employing QSIG signalling and an IP network
employing SIP signalling. The gateway appears as a PINX to other
PINXs in the PISN. The gateway appears as a SIP endpoint to other SIP
entities in the IP network. The environment is shown in figure 1.
Elwell et alia Expires - October 2002 [Page 5]
Interworking between SIP and QSIG April 2002
+------+ IP network PISN
| |
|SIP | +------+
|Proxy | /| |
| | / |PINX |
+---+--+ *-----------+ / | |
| | | +-----+/ +------+
| | | | |
| | | |PINX |
-----+-----+---------+--------+ Gateway +--------| |
| | | | | |\
| | | | +-----+ \
| | | | \ +------+
| | | | \| |
+--+---+ +--+---+ *-----------+ |PINX |
|SIP | |SIP | | |
|End- | |End- | +------+
|point | |point |
+------+ +------+
Figure 1 û Environment
In addition to the signalling interworking functionality specified in
this specification, it is assumed that the gateway also includes the
following functionality:
-one or more physical interfaces on the PISN side supporting one or
more inter-PINX links, each link providing one or more constant bit
rate channels for media information and a reliable layer 2 connection
for transporting QSIG signalling messages; and
-one or more physical interfaces on the IP network side supporting,
through layer 1 and layer 2 protocols, IP as the network layer
protocol and UDP (RFC 768) and TCP (RFC 761) as transport layer
protocols, these being used for the transport of SIP signalling
messages and, in the case of UDP, also for media information;
-optionally the support of TLS (RFC 2246) and/or SCTP (RFC 2960) as
additional transport layer protocols on the IP network side, these
being used for the transport of SIP signalling messages; and
-a means of transferring media information in each direction between
the PISN and the IP network, including as a minimum packetization of
media information sent to the IP network and de-packetization of
media information received from the IP network.
NOTE. RFC 3261 mandates support for both UDP and TCP for the
transport of SIP messages and allows optional support for TLS and/or
SCTP for this same purpose.
Elwell et alia Expires - October 2002 [Page 6]
Interworking between SIP and QSIG April 2002
The protocol model relevant to signalling interworking functionality
of a gateway is shown in figure 2.
+---------------------------------------------------------+
| Inter-working function |
| |
+-----------------------+---------+-----------------------+
| | | |
| SIP | | |
| | | |
+-----------------------+ | |
| | | |
| UDP/TCP/TLS/SCTP | | QSIG |
| | | |
+-----------------------+ | |
| | | |
| IP | | |
| | | |
+-----------------------+ +-----------------------+
| IP network | | PISN |
| lower layers | | lower layers |
| | | |
+-----------------------+ +-----------------------+
Figure 2 û Protocol model
In figure 2, the SIP box represents SIP syntax and encoding, the SIP
transport layer and the SIP transaction layer. The Interworking
function includes SIP Transaction User (TU) functionality.
6 Overview
The gateway maps received QSIG messages, where appropriate, to SIP
messages and vice versa. Annex A gives examples of typical message
sequences that can arise.
7 General requirements
In order to conform to this specification, a gateway SHALL support
QSIG in accordance with ECMA-143 as a gateway and SHALL support SIP
in accordance with IETF RFC 3261 as a UA. In particular the gateway
SHALL support SIP syntax and encoding, the SIP transport layer and
the SIP transaction layer in accordance with RFC 3261. In addition,
the gateway SHALL support SIP TU behaviour for a UA in accordance
with RFC 3261 except where stated otherwise in this specification.
Elwell et alia Expires - October 2002 [Page 7]
Interworking between SIP and QSIG April 2002
NOTE 1. RFC 3261 mandates that a SIP entity support both UDP and TCP
as transport layer protocols for SIP messages. Other transport layer
protocols can also be supported.
The gateway SHALL also support SIP reliable provisional responses in
accordance with IETF RFC BBBB as a UA.
NOTE 2. RFC BBBB makes provision for recovering from loss of
provisional responses (other than 100) to INVITE requests when using
unreliable transport services in the IP network. This is important
for ensuring delivery of responses that map to essential QSIG
messages.
The gateway SHALL support SDP in accordance with RFC 2327 and its use
in accordance with the offer / answer model in RFC CCCC.
The gateway SHALL support calls from QSIG to SIP and calls from SIP
to QSIG.
SIP methods not defined in RFC 3261 or RFC BBBB are outside the scope
of this specification but could be the subject of other
specifications for interworking with QSIG, e.g., for interworking in
support of supplementary services.
As a result of DNS look-up by the gateway in order to determine where
to send a SIP INVITE request, a number of candidate destinations can
be attempted in sequence. The way in which this is handled by the
gateway is outside the scope of this specification. However, any
behaviour specified in this document on receipt of a SIP final
response SHOULD apply only when a final response is received and
there are no more candidate destinations to try.
8 Message mapping requirements
8.1 Message validation and handling of protocol errors
The gateway SHALL validate received QSIG messages in accordance with
the requirements of ECMA-143 and SHALL act in accordance with
ECMA-143 on detection of a QSIG protocol error. The requirements of
this section for acting on a received QSIG message apply only to a
received QSIG message that has been successfully validated and that
satisfies one of the following conditions:
-the QSIG message is a SETUP message and indicates a destination in
the IP network and a bearer capability for which the gateway is able
to provide interworking; or
Elwell et alia Expires - October 2002 [Page 8]
Interworking between SIP and QSIG April 2002
-the QSIG message is a message other than SETUP and contains a call
reference that identifies an existing call for which the gateway is
providing interworking between QSIG and SIP.
The processing of any valid QSIG message that does not satisfy any of
these conditions is outside the scope of this specification.
The gateway SHALL validate received SIP messages (requests and
responses) in accordance with the requirements of IETF RFC 3261 and
SHALL act in accordance with IETF RFC 3261 on detection of a SIP
protocol error. Requirements of this section for acting on a received
SIP message apply only to a received message that has been
successfully validated and that satisfies one of the following
conditions:
-the SIP message is an INVITE request that contains no tag parameter
in the To header field, does not match an ongoing transaction (i.e.,
is not a merged request, see 8.2.2.2 of RFC 3261) and indicates a
destination in the PISN for which the gateway is able to provide
interworking; or
-the SIP message is a request that relates to an existing dialog
representing a call for which the gateway is providing interworking
between QSIG and SIP; or
-the SIP message is a CANCEL request that relates to a received
INVITE request for which the gateway is providing interworking with
QSIG but for which the only response sent is informational (1xx), no
dialog having been confirmed; or
-the SIP message is a response to a request sent by the gateway in
accordance with this section.
The processing of any valid SIP message that does not satisfy any of
these conditions is outside the scope of this specification.
NOTE. These rules mean that an error detected in a received message
will not be propagated to the other side of the gateway. However,
there can be an indirect impact on the other side of the gateway,
e.g., the initiation of call clearing procedures.
8.2 Call establishment from QSIG to SIP
8.2.1 Call establishment from QSIG to SIP using enbloc procedures
The following procedures apply when the gateway receives a QSIG SETUP
message containing a Sending Complete information element or the
gateway receives a QSIG SETUP message and is able to determine that
the number in the Called party number information element is
complete.
Elwell et alia Expires - October 2002 [Page 9]
Interworking between SIP and QSIG April 2002
NOTE. The means by which the gateway determines the number to be
complete is an implementation matter. It can involve knowledge of the
numbering plan and/or use of inter-digit timer expiry.
8.2.1.1 Receipt of QSIG SETUP message
On receipt of a QSIG SETUP message containing a number that the
gateway determines to be complete in the Called party number
information element, or containing a Sending complete information
element and a number that the gateway cannot determine to be
complete, the gateway SHALL map the QSIG SETUP message to a SIP
INVITE request. The gateway SHALL also send a QSIG CALL PROCEEDING
message.
The gateway SHALL generate the SIP Request-URI, To and From fields in
the SIP INVITE request in accordance with section 9. The gateway
SHALL include in the INVITE request a Supported header containing
option tag 100rel, to indicate support for RFC BBBB.
The gateway SHALL include SDP information in the SIP INVITE request
as described in section 10.
On receipt of a QSIG SETUP message containing a Sending complete
information element and a number that the gateway determines to be
incomplete in the Called party number information element, the
gateway SHALL initiate QSIG call clearing procedures using cause
value 28 ôinvalid number format (address incomplete)ö.
If information in the QSIG SETUP message is unsuitable for generating
any of the mandatory fields in a SIP INVITE request (e.g., if a
Request-URI cannot be derived from the QSIG Called party number
information element) or for generating SDP information, the gateway
SHALL NOT issue a SIP INVITE request and SHALL initiate QSIG call
clearing procedures in accordance with ECMA-143.
8.2.1.2 Receipt of SIP 100 (Trying) response
A SIP 100 response SHALL NOT trigger any QSIG messages. It only
serves the purpose of suppressing INVITE request retransmissions.
8.2.1.3 Receipt of SIP 18x provisional response
The gateway SHALL map a received SIP 18x response to a QSIG PROGRESS
or ALERTING message based on the following conditions.
-If a SIP 180 response is received and no QSIG ALERTING message has
been sent, the gateway SHALL generate a QSIG ALERTING message. The
QSIG ALERTING message SHALL contain a Progress indicator information
Elwell et alia Expires - October 2002 [Page 10]
Interworking between SIP and QSIG April 2002
element containing progress description number 8. If the SDP answer
has been received, the gateway SHALL connect the media streams to the
corresponding user information channel of the inter-PINX link. If the
SDP answer has not been received, the gateway SHALL supply ring-back
tone on the user information channel of the inter-PINX link. If the
SDP answer is subsequently received, the gateway SHALL stop ring-back
tone and connect the media streams to the corresponding user
information channel of the inter-PINX link.
-If a SIP 181/182/183 response is received, no QSIG ALERTING message
has been sent, no QSIG PROGRESS message containing progress
description number 8 has been sent and the SDP answer has been
received, the gateway SHALL generate a QSIG PROGRESS message. The
QSIG PROGRESS message SHALL contain progress description number 8 in
a Progress indicator information element. The gateway SHALL also
connect the media streams to the corresponding user information
channel of the inter-PINX link.
-If a SIP 181/182/183 response is received, no QSIG ALERTING message
has been sent, no QSIG PROGRESS message containing progress
description number 1 or 8 has been sent and the SDP answer has not
been received, the gateway SHALL generate a QSIG PROGRESS message.
The QSIG PROGRESS message SHALL contain progress description number 1
in a Progress indicator information element.
NOTE. This will ensure that QSIG timer T310 is stopped if running at
the Originating PINX.
In all other scenarios the gateway SHALL NOT map the SIP 18x response
to a QSIG message.
If the SIP 18x response contains a Require header with option tag
100rel, the gateway SHALL send back a SIP PRACK request.
8.2.1.4 Receipt of SIP 2xx response
If the gateway receives a SIP 200 (OK) response as the first SIP 200
response to a SIP INVITE request, the gateway SHALL map the SIP 200
(OK) response to a QSIG CONNECT message. The gateway SHALL also send
a SIP ACK request to acknowledge the 200 (OK) response. The gateway
SHALL NOT include any SDP information in the SIP ACK request. If the
gateway receives further 200 (OK) responses, it SHALL respond to each
in accordance with RFC 3261 and SHALL NOT generate any further QSIG
messages.
The SDP answer will now have been received. The gateway SHALL connect
the media streams to the corresponding user-information channel on
the inter-PINX link if it has not already done so.
Elwell et alia Expires - October 2002 [Page 11]
Interworking between SIP and QSIG April 2002
If the SIP 200 (OK) response is received in response to the SIP PRACK
request, the gateway SHALL NOT map this message to any QSIG message.
If the gateway receives a SIP 2xx response other than 200 (OK), the
gateway SHALL send a SIP ACK request.
NOTE. A SIP 200 (OK) response can be received later as a result of a
forking proxy.
8.2.1.5 Receipt of SIP 3xx response
On receipt of a SIP 3xx response, the gateway SHALL act in accordance
with RFC 3261.
NOTE. This will normally result in sending a new SIP INVITE request.
Unless the gateway supports the QSIG Call Diversion Supplementary
Service, no QSIG message SHALL be sent. The definition of Call
Diversion Supplementary Service for QSIG to SIP interworking is
beyond the scope of this specification.
8.2.2 Call establishment from QSIG to SIP using overlap procedures
SIP uses en-bloc signalling and it is strongly RECOMMENDED to avoid
using overlap signalling in a SIP network. A SIP/QSIG gateway dealing
with overlap signalling, SHOULD perform a conversion from overlap to
en-bloc signalling method using one or more of the following
mechanisms:
-timers;
-numbering plan information;
-the presence of a Sending complete information element in a received
QSIG INFORMATION message.
If the gateway performs a conversion from overlap to en-bloc
signalling in the SIP network then the procedures defined in 8.2.2.1
SHALL apply.
However, for some applications it might be impossible to avoid using
overlap signalling in the SIP network. In this case the procedures
defined in 8.2.2.2 SHALL apply.
8.2.2.1 Enbloc signalling in SIP network
8.2.2.1.1 Receipt of QSIG SETUP message
Elwell et alia Expires - October 2002 [Page 12]
Interworking between SIP and QSIG April 2002
On receipt of a QSIG SETUP message containing no Sending complete
information element and a number in the Called party number
information element that the gateway cannot determine to be complete,
the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message, start
QSIG T302 timer and await further number digits.
8.2.2.1.2 Receipt of QSIG INFORMATION message
On receipt of each QSIG INFORMATION message containing no Sending
complete information element and containing a number that the gateway
cannot determine to be complete, timer T302 SHALL be restarted. When
T302 expires or a QSIG INFORMATION message containing a Sending
complete information element is received the gateway SHALL send a SIP
INVITE request as described in 8.2.1.1. The Request-URI and To fields
(see section 9) SHALL be generated from the concatenation of
information in the Called party number information element in the
received QSIG SETUP and INFORMATION messages. The gateway SHALL also
send a QSIG CALL PROCEEDING message.
8.2.2.1.3 Receipt of SIP responses
SIP responses SHALL be mapped as described in 8.2.1.
8.2.2.2 Overlap signalling in SIP network
8.2.2.2.1 Receipt of QSIG SETUP message
On receipt of a QSIG SETUP message containing no Sending complete
information element and a number in the Called party number
information element that the gateway cannot determine to be complete,
the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message and
start QSIG timer T302. If the QSIG SETUP message contains the minimum
number of digits required to route the call in the IP network, the
gateway SHALL send a SIP INVITE request as specified in 8.2.1.1.
Otherwise the gateway SHALL wait for more digits to arrive in QSIG
INFORMATION messages.
8.2.2.2.2 Receipt of QSIG INFORMATION message
On receipt of a QSIG INFORMATION message the gateway SHALL restart
the QSIG T302 timer. Further behaviour of the gateway SHALL depend on
whether or not it has already sent a SIP INVITE request. If the
gateway has not sent a SIP INVITE request and it now has the minimum
number of digits required to route the call, it SHALL send a SIP
INVITE request as specified in 8.2.2.1.2. If the gateway still does
not have the minimum number of digits required than it SHALL wait for
more QSIG INFORMATION messages to arrive.
Elwell et alia Expires - October 2002 [Page 13]
Interworking between SIP and QSIG April 2002
If the gateway has already sent one or more SIP INVITE requests, and
whether or not final responses to those requests have been received,
it SHALL send a new SIP INVITE request with the new digits. The new
SIP INVITE request SHALL have the same Call-ID as the first SIP
INVITE request sent but SHALL have updated Request-URI and To fields.
The updated Request-URI and To fields (see section 9) SHALL be
generated from the concatenation of information in the Called party
number information element in the received QSIG SETUP and INFORMATION
messages.
NOTE. The first SIP INVITE request and all subsequent SIP INVITE
requests sent in this way belong to the same call but to different
dialogs.
8.2.2.2.3 Receipt of SIP 100 (Trying) response
The requirements of 8.2.1.2 SHALL apply.
8.2.2.2.4 Receipt of SIP 18x provisional response
The requirements of 8.2.1.3 SHALL apply.
8.2.2.2.5 Receipt of SIP 2xx response
The requirements of 8.2.1.4 SHALL apply.
8.2.2.2.6 Receipt of SIP 3xx response
The requirements of 8.2.1.5 SHALL apply.
8.2.2.2.7 Receipt of a SIP 484 (Address Incomplete) response
The SIP 484 response indicates that more digits are required to
complete the call. On receipt of a SIP 484 response the gateway SHALL
send back a SIP ACK request. The gateway SHALL also send a QSIG
DISCONNECT message if either of the following conditions apply:
-T302 expires and all the SIP INVITE requests sent have been answered
with a final response other than 200 OK; or
-a QSIG INFORMATION message containing a Sending complete information
element has been received and all the SIP INVITE requests sent have
been answered with a final response (other than 200 OK).
In all other cases the receipt of a SIP 484 response SHALL NOT
trigger the sending of any QSIG message.
8.2.2.2.8 Receipt of a SIP 4xx (except 484), 5xx or 6xx response
Elwell et alia Expires - October 2002 [Page 14]
Interworking between SIP and QSIG April 2002
If a SIP 4xx (except 484), 5xx or 6xx final response arrives for a
pending SIP INVITE transaction, the gateway SHALL send a SIP ACK
request. If this occurs before T302 has expired, the gateway shall
either send a QSIG DISCONNECT message (8.4.4) or behave as for a SIP
484 response (8.2.2.2.7).
8.2.2.2.9 Receipt of multiple SIP responses
The responses to all the SIP INVITE requests sent except for the last
one are typically SIP 4xx responses (e.g. 484 (Address Incomplete))
that terminate the SIP INVITE transaction.
However, the gateway can receive a SIP 183 (Session Progress)
response with a media description. The media stream will typically
contain a message such as "àWe are trying to connect youà ". The
issue of receiving different SIP 183 (Session Progress) responses
with media descriptions for different SIP INVITE transactions is a
gateway concern. The gateway SHOULD decide which media stream (if
any) are to be played to the user.
8.2.2.2.10 Cancelling pending SIP INVITE transactions
When a gateway sends a new SIP INVITE request containing new digits,
it SHOULD NOT send a SIP CANCEL request to cancel the previous SIP
INVITE transaction. This SIP CANCEL request could arrive at an egress
gateway before the new SIP INVITE request and trigger premature call
clearing.
NOTE. Previous SIP INVITE transactions can be expected to result in
SIP 4xx class responses, which terminate the transaction.
8.2.2.2.11 SIP INVITE requests reaching multiple gateways
Each SIP INVITE request sent by a gateway represents a new
transaction and hence can be routed differently. For instance, the
first SIP INVITE request might be routed to a particular egress
gateway and a subsequent SIP INVITE request to another gateway. The
result is that both gateways initiate call establishment in the
remote network. Since one of the call establishments has an
incomplete destination number, it can be expected to fail, having
already consumed resources in the remote network.
To avoid this problem it is RECOMMENDED that all the SIP INVITE
requests should follow the same path as the first one. This would
however restrict the number of services the SIP network can provide.
It would not be possible to route a subsequent SIP INVITE request to
an application server just because the previous one was routed in a
different way.
Elwell et alia Expires - October 2002 [Page 15]
Interworking between SIP and QSIG April 2002
This issue should be taken into consideration before using overlap
signalling in SIP. If initiating multiple call establishments in the
remote network is not acceptable in a particular application, overlap
signalling SHOULD NOT be used.
8.3 Call Establishment from SIP to QSIG
8.3.1 Receipt of SIP INVITE request for a new call
On receipt of a SIP INVITE request for a new call, the gateway SHALL
generate a QSIG SETUP message from the received SIP INVITE request.
The gateway SHALL generate the Called party number and Calling party
number information elements in accordance with section 9 and SHALL
generate the Bearer capability information element in accordance with
section 10. If the gateway can determine that the number placed in
the Called party number information element is complete, the gateway
MAY include the Sending complete information element.
NOTE 1. The means by which the gateway determines the number to be
complete is an implementation matter. It can involve knowledge of the
numbering plan and/or use of the inter-digit timer.
The gateway SHOULD send a SIP 100 (Trying) response.
If information in the SIP INVITE request is unsuitable for generating
any of the mandatory information elements in a QSIG SETUP message
(e.g., if a QSIG Called party number information element cannot be
derived from SIP Request-URI field), the gateway SHALL NOT issue a
QSIG SETUP message and SHALL send a SIP 4xx, 5xx or 6xx response.
If the SIP INVITE request does not contain SDP information and does
not contain either a Required header or a Supported header with
option tag 100rel, the gateway SHALL NOT issue a QSIG SETUP message
and SHALL send a SIP 488 (Not Acceptable Here) response.
NOTE 2. The absence of SDP offer information in the SIP INVITE
request means that the gateway might need to send SDP offer
information in a provisional response in order to ensure that tones
and announcements from the PISN are transmitted. SDP offer
information cannot be sent in an unreliable provisional response
because the SDP answer would need to be returned in a SIP PRACK
request.
On receipt of a SIP INVITE request relating to a call that has
already been established from SIP to QSIG, the procedures of 8.3.9
SHALL apply.
8.3.2 Receipt of QSIG CALL PROCEEDING message
Elwell et alia Expires - October 2002 [Page 16]
Interworking between SIP and QSIG April 2002
The receipt of a QSIG CALL PROCEEDING message SHALL NOT result in any
SIP message being sent.
8.3.3 Receipt of QSIG PROGRESS message
A QSIG PROGRESS message can be received in the event of interworking
at the egress from the PISN or if the PISN is usable to complete the
call and generates an in-band tone or announcement. In the latter
case a Cause information element is included in the QSIG PROGRESS
message.
The gateway SHALL map a received QSIG PROGRESS message to a SIP 183
(Session Progress) response. If the SIP INVITE request contained
either a Require header or a Supported header with option tag 100rel,
the gateway SHALL include in the SIP 183 response a Require header
with option tag 100rel.
If the QSIG PROGRESS message contained a Progress indicator
information element with Progress description number 1 or 8, the
gateway SHALL connect the media streams to the corresponding user
information channel of the inter-PINX link if it has not already done
so, provided the SDP answer is included in the transmitted SIP
response or has already been sent or received. Inclusion of SDP offer
or answer information in the 183 provisional response SHALL be in
accordance with 8.3.5
If the QSIG PROGRESS message is received with a Cause information
element, the gateway SHALL either wait until the tone/announcement is
complete or has been applied for sufficient time before initiating
call clearing, or wait for a SIP CANCEL request. If call clearing is
initiated, the cause value in the QSIG PROGRESS message SHALL be used
to derive the response to the SIP INVITE request in accordance with
table 1.
8.3.4 Receipt of QSIG ALERTING message
The gateway SHALL map a QSIG ALERTING message to a SIP 180 (Ringing)
response. If the SIP INVITE request contained either a Require header
or a Supported header with option tag 100rel, the gateway SHALL
include in the SIP 180 response a Require header with option tag
100rel.
If the QSIG ALERTING message contained a Progress indicator
information element with Progress description number 1 or 8, the
gateway SHALL connect the media streams to the corresponding user
information channel of the inter-PINX link if it has not already done
so, provided the SDP answer is included in the transmitted SIP
response or has already been sent or received. Inclusion of SDP offer
Elwell et alia Expires - October 2002 [Page 17]
Interworking between SIP and QSIG April 2002
or answer information in the 180 provisional response SHALL be in
accordance with 8.3.5
8.3.5 Inclusion of SDP information in a SIP 18x provisional response
When sending a SIP 18x provisional response, the gateway SHALL
include SDP information in accordance with the following rules.
If the SIP INVITE request contained a Required or Supported header
with option tag 100rel, and if SDP offer and answer have already been
exchanged, no SDP SHALL be included in the SIP 18x provisional
response.
If the SIP INVITE request contained a Required or Supported header
with option tag 100rel, and if SDP offer was received in the SIP
INVITE request but no SDP answer has been sent, SDP answer SHALL be
included in the SIP 18x provisional response.
If the SIP INVITE request contained a Required or Supported header
with option tag 100rel, and if no SDP offer was received in the SIP
INVITE request and no SDP offer has already been sent, SDP offer
SHALL be included in the SIP 18x provisional response.
NOTE 1. In this case, SDP answer can be expected in the SIP PRACK.
If the SIP INVITE request contained neither a Required nor a
Supported header with option tag 100rel, SDP answer SHALL be included
in the SIP 18x provisional response.
NOTE 2. Because the provisional response is unreliable, SDP answer
needs to be repeated in each provisional response and in the final
SIP 2xx response.
NOTE 3. If the SIP INVITE request contained no SDP offer and neither
a Required nor a Supported header with option tag 100rel, it should
have been rejected in accordance with 8.3.1.
8.3.6 Receipt of QSIG CONNECT message
The gateway SHALL map a QSIG CONNECT message to a SIP 200 (OK) final
response for the SIP INVITE request. The gateway SHALL also send a
QSIG CONNECT ACKNOWLEDGE message.
If the SIP INVITE request contained a Required or Supported header
with option tag 100rel, and if SDP offer and answer have already been
exchanged, no SDP SHALL be included in the SIP 200 response.
If the SIP INVITE request contained a Required or Supported header
with option tag 100rel, and if SDP offer was received in the SIP
Elwell et alia Expires - October 2002 [Page 18]
Interworking between SIP and QSIG April 2002
INVITE request but no SDP answer has been sent, SDP answer SHALL be
included in the SIP 200 response.
If the SIP INVITE request contained a Required or Supported header
with option tag 100rel, and if no SDP offer was received in the SIP
INVITE request and no SDP offer has already been sent, SDP offer
SHALL be included in the SIP 200 response.
NOTE 1. In this case, SDP answer can be expected in the SIP ACK.
If the SIP INVITE request contained neither a Required nor a
Supported header with option tag 100rel, SDP answer SHALL be included
in the SIP 200 response.
NOTE 2. Because the provisional response is unreliable, SDP answer
needs to be repeated in each provisional response and in the final
2xx response.
NOTE 3. If the SIP INVITE request contained no SDP offer and neither
a Required nor a Supported header with option tag 100rel, it should
have been rejected in accordance with 8.3.1.
The gateway SHALL connect the media streams to the corresponding user
information channel of the inter-PINX link if it has not already done
so, provided the SDP answer is included in the transmitted SIP
response or has already been sent or received.
8.3.7 Receipt of SIP PRACK request
The receipt of a SIP PRACK request SHALL NOT result in any QSIG
message being sent. The gateway SHALL send back a SIP 200 (OK)
response to the SIP PRACK request.
If the SIP PRACK contains SDP answer and a QSIG message containing a
Progress indicator information element with progress description
number 1 or 8 has been received, the gateway SHALL connect the media
streams to the corresponding user information channel of the inter-
PINX link.
8.3.8 Receipt of SIP ACK request
The receipt of a SIP ACK request SHALL NOT result in any QSIG message
being sent.
If the SIP ACK contains SDP answer, the gateway SHALL connect the
media streams to the corresponding user information channel of the
inter-PINX link if it has not already done so.
Elwell et alia Expires - October 2002 [Page 19]
Interworking between SIP and QSIG April 2002
8.3.9 Receipt of a SIP INVITE request for a call already being
established
For a call from SIP using overlap procedures, the gateway will
receive multiple SIP INVITE requests that belong to the same call but
have different Request-URI and To fields. Each SIP INVITE request
belongs to a different dialog.
If a gateway receives a SIP INVITE request with the same Call-ID as
an existing call for which the QSIG state is overlap sending and with
updated Request-URI and To fields from which a called party number
with a superset of digits can be derived, it SHALL generate a QSIG
INFORMATION message using the call reference of the existing QSIG
call instead of a new QSIG SETUP message. It SHALL also respond to
the SIP INVITE request received previously with a SIP 484 Address
Incomplete response.
If a gateway receives a SIP INVITE request with the same Call-ID as
an existing call but failing to meet the other conditions above, the
gateway SHALL clear the call by sending back a SIP 485 (Ambiguous)
response and a QSIG DISCONNECT message with Cause Value 16 (Normal
call clearing).
8.4 Call clearing
8.4.1 Receipt of a QSIG DISCONNECT, RELEASE or RELEASE COMPLETE message
On receipt of QSIG DISCONNECT, RELEASE or RELEASE COMPLETE message as
the first QSIG call clearing message, gateway behaviour SHALL depend
on the state of call establishment.
1)If the gateway has sent or received a SIP 200 (OK) response
(indicating that call establishment is complete) and received a SIP
ACK request, the gateway SHALL send a SIP BYE request to clear the
call.
2)If the gateway has sent a SIP 200 (OK) response (indicating that
call establishment is complete) but not received a SIP ACK request,
the gateway SHALL wait until a SIP ACK is received and then send a
SIP BYE request to clear the call.
3)If the gateway has sent a SIP INVITE request and received a SIP
provisional response but not a SIP final response, the gateway SHALL
send a SIP CANCEL request to clear the call.
NOTE. In accordance with RFC 3261, if after sending a SIP CANCEL
request a SIP 2xx response is received to the SIP INVITE request, the
gateway will need to send a SIP BYE request.
Elwell et alia Expires - October 2002 [Page 20]
Interworking between SIP and QSIG April 2002
4)If the gateway has sent a SIP INVITE request but received no SIP
response, the gateway SHALL NOT send a SIP message. If a SIP final or
provisional response is subsequently received, the gateway SHALL then
act in accordance with 1, 2 or 3 above respectively.
5)If the gateway has received a SIP INVITE request but not sent a SIP
final response, the gateway SHALL send a SIP final response chosen
according to the cause value in the received QSIG message as
specified in table 1.
In all cases the gateway SHALL also disconnect media streams, if
established, and allow QSIG and SIP signalling to complete in
accordance with ECMA-143 and RFC-3261 respectively.
Table 1 û Mapping of QSIG Cause Value to SIP 4xx-6xx responses
QSIG Cause value SIP response
1 Unallocated number 410 Gone
2 No route to specified 404 Not found
transit network
3 No route to destination 404 Not found
4 Send special information 502 Bad Gateway or NA
tone
5 Misdialled trunk prefix 410 Gone
6 Channel unacceptable 502 Bad gateway
7 Call awarded and being 502 Bad gateway
delivered in an established
channel
8 Preemption 502 Bad gateway
9 Preemption- circuit 502 Bad gateway
reserved for reuse
16 Normal call clearing 502 Bad gateway or BYE
17 User busy 486 Busy here
18 No user responding 480 Temporarily unavailable
19 No answer from the user 480 Temporarily unavailable
20 Subscriber absent 480 Temporarily unavailable
21 Call rejected 603 Decline
22 Number changed 410 Gone
23 Redirection to new 410 Gone
destination
25 Exchange routing error 502 Bad gateway
26 Non selected user clearing 502 Bad gateway or NA
27 Destination out of order 480 Temporarily unavailable
28 Address incomplete 484 Address incomplete
29 Facility rejected 488 Not Acceptable Here
30 Response to STATUS ENQUIRY 502 Bad gateway (if received in
call clearing message)
31 Normal unspecified 502 Bad gateway
Elwell et alia Expires - October 2002 [Page 21]
Interworking between SIP and QSIG April 2002
34 No circuit/channel 503 Service unavailable
available
38 Network out of order 502 Bad gateway
39 Permanent frame mode 502 Bad gateway or NA
connection out of service
40 Permanent frame mode 502 Bad gateway or NA
connection operational
41 Temporary failure 503 Service unavailable
42 Switching equipment 502 Bad gateway
congestion
43 Access information 502 Bad gateway or NA
discarded
44 Requested circuit/channel 503 Service unavailable
not available
46 Precedence call blocked 502 Bad gateway
47 Resource unavailable, 502 Bad gateway
unspecified
49 Quality of service not 503 Service unavailable
available
50 Requested facility not 503 Service unavailable
subscribed
53 Outgoing calls barred 488 Not Acceptable Here
within CUG
55 Incoming calls barred 488 Not Acceptable Here
within CUG
57 Bearer capability not 488 Not Acceptable Here
authorized
58 Bearer capability not 503 Service unavailable
presently available
62 Inconsistency in 502 Bad gateway
designated outgoing access
information and subscriber
class
63 Service or option not 503 Service unavailable
available, unspecified
65 Bearer capability not 501 Not implemented
implemented
66 Channel type not 502 Bad gateway
implemented
69 Requested facility not 503 Service unavailable
implemented
70 Only restricted digital 503 Service unavailable
information bearer capability
is available
79 Service or option not 503 Service unavailable
implemented, unspecified
81 Invalid call reference 502 Bad gateway
value
82 Identified channel does 502 Bad gateway
Elwell et alia Expires - October 2002 [Page 22]
Interworking between SIP and QSIG April 2002
not exist
83 A suspended call exists, 502 Bad gateway
but this call identity does
not
84 Call identity in use 502 Bad gateway
85 No call suspended 502 Bad gateway
86 Call having the requested 502 Bad gateway
call identity has been
cleared
87 User not member of CUG 488 Not Acceptable Here
88 Incompatible destination 488 Not Acceptable Here
90 Non-existant CUG 502 Bad gateway
91 Invalid transit network 502 Bad gateway
selection
95 Invalid message, 500 Server internal error
unspecified
96 Mandatory information 500 Server internal error
element is missing
97 Message type non-existent 500 Server internal error
or not implemented
98 Message not compatible 500 Server internal error
with call state or message
non-existent or not
implemented
99 Information element non- 500 Server internal error
existent or not implemented
98 Invalid information 500 Server internal error
element contents
101 Message not compatible 500 Server internal error
with call state
102 Recovery on timer expiry 500 Server internal error
103 Parameter non-existent or 500 Server internal error
not implemented, passed on
110 Message with unrecognized 500 Server internal error
parameter, discarded
111 Protocol error 500 Server internal error
127 Interworking, unspecified 500 Server internal error
8.4.2 Receipt of a SIP BYE request
On receipt of a SIP BYE request, the gateway SHALL send a QSIG
DISCONNECT message with cause value 16 (normal call clearing). The
gateway SHALL also disconnect media streams, if established, and
allow QSIG and SIP signalling to complete in accordance with ECMA-143
and RFC-3261 respectively.
NOTE. When responding to a SIP BYE request, in accordance with
RFC 3261 the gateway is also required to respond to any other
Elwell et alia Expires - October 2002 [Page 23]
Interworking between SIP and QSIG April 2002
outstanding transactions, e.g., with a SIP 487 (Request Terminated)
response. This applies in particular if the gateway has not yet
returned a final response to the SIP INVITE request.
8.4.3 Receipt of a SIP CANCEL request
On receipt of a SIP CANCEL request to clear a call for which the
gateway has not sent a SIP final response to the received SIP INVITE
request, the gateway SHALL send a QSIG DISCONNECT message with cause
value 16 (normal call clearing). The gateway SHALL also disconnect
media streams, if established, and allow QSIG and SIP signalling to
complete in accordance with ECMA-143 and RFC-3261 respectively.
8.4.4 Receipt of a SIP 4xx - 6xx response
On receipt of a SIP final response (4xx-6xx) to a SIP INVITE request,
the gateway SHALL transmit a QSIG DISCONNECT message. The cause value
in the QSIG DISCONNECT message SHALL be derived from the SIP 4xx-6xx
response according to table 2. The gateway SHALL also disconnect
media streams, if established, and allow QSIG and SIP signalling to
complete in accordance with ECMA-143 and RFC-3261 respectively.
Table 2 û Mapping of SIP 4xx-6xx responses to QSIG Cause values
SIP response QSIG Cause value
400 Bad request 41 Temporary failure
401 Unauthorized 88 Incompatible destination
402 Payment required 88 Incompatible destination
403 Forbidden 88 Incompatible destination
404 Not found 3 No route to destination
405 Method not allowed 41 Temporary Failure
406 Not acceptable 41 Temporary Failure
407 Proxy Authentication required 41 Temporary Failure
408 Request timeout 41 Temporary Failure
409 Conflict 41 Temporary Failure
410 Gone 1 Unallocated number
411 Length required 41 Temporary Failure
413 Request Entity too long 41 Temporary Failure
414 Request-URI too long 41 Temporary Failure
415 Unsupported media type 65 Bearer Capability Not
implemented
420 Bad extension 41 Temporary Failure
480 Temporarily unavailable 18 No user responding
481 Call/transaction doesn't exist 41 Temporary Failure
482 Loop detected 41 Temporary Failure
483 Too many hops 41 Temporary Failure
484 Address incomplete 28 Invalid number format
485 Ambiguous 1 Unallocated Number
486 Busy here 17 User busy
Elwell et alia Expires - October 2002 [Page 24]
Interworking between SIP and QSIG April 2002
487 Requested Terminated 41 Temporary Failure
488 Not Acceptable Here 65 Bearer Capability Not
implemented
500 Server internal error 41 Temporary Failure
501 Not implemented 41 Temporary Failure
502 Bad gateway 41 Temporary Failure
503 Service unavailable 41 Temporary Failure
504 Gateway time-out 41 Temporary Failure
505 Version not supported 41 Temporary Failure
600 Busy everywhere 17 User busy
603 Decline 21 Call rejected
604 Does not exist anywhere 1 Unallocated number
606 Not acceptable 21 Call Rejected
8.4.5 Timer expiry
The gateway SHALL run protocol timers as specified for QSIG in
ECMA-143 and for SIP in RFC 3261. On expiry of these timers the
actions SHALL be as specified by the respective protocol
specifications.
If the call is to be cleared due to expiry of a QSIG timer, clearing
of the SIP call SHALL be in accordance with 8.4.1, except that if a
final response to a SIP INVITE request needs to be sent, a SIP 408
(Request Timeout) response SHALL be used. If the call is to be
cleared due to expiry of a SIP timer, the gateway SHALL send a QSIG
DISCONNECT message with Cause Value 41 (Temporary Failure) to clear
the call in the PISN.
8.5 Request to change media characteristics
If after a call has been successfully established the gateway
receives a SIP INVITE request to change the media characteristics of
the call, the gateway SHALL send back a SIP 503 (Service unavailable)
response and SHALL NOT change the media characteristics of the
existing call.
9 Number mapping
The SIP æToÆ, æRequest-URIÆ and æFromÆ are in the form of Universal
Resource Identifiers (URIs).
9.1 Mapping from SIP to QSIG
The gateway SHALL map the SIP Request-URI and From header to the QSIG
Called and Calling party number information elements respectively.
The way in which this is achieved is outside the scope of this
specification.
Elwell et alia Expires - October 2002 [Page 25]
Interworking between SIP and QSIG April 2002
The gateway SHALL set the Numbering Plan Identification (NPI) and
Type of Number (TON) fields in the QSIG Called and Calling party
number information elements in accordance with ECMA-155.
In the QSIG Calling party number information element, unless the
gateway performs screening, the screening indicator SHALL be set to
"user provided, not screened" (0). Unless the gateway performs
presentation restriction, the presentation indicator SHALL be set to
"presentation allowed" (0). Support of screening and/or presentation
restriction is outside the scope of this specification.
Unless the gateway has a means of determining the identity of the
user that answers a call from QSIG to SIP, the QSIG Connected number
information SHALL NOT be generated.
9.2 Mapping from QSIG to SIP
The gateway SHALL map the QSIG Called party number information
element to the SIP Request-URI and the SIP To header, both of which
SHOULD contain the same value. The gateway SHALL map the QSIG Calling
party number information element to the SIP From header. The way in
which this is achieved is outside the scope of this specification.
If the Calling party number information element is not received in
the QSIG SETUP message or if it does not contain a number or if the
presentation indicator has the value "Presentation restricted", the
gateway SHALL use its own address to generate the From header.
10 Requirements for support of basic services
This document specifies signalling interworking for basic services
that provide a bi-directional transfer capability for speech,
facsimile and modem media between the two networks.
10.1 Derivation of QSIG Bearer capability information element
The gateway SHALL generate the Bearer Capability Information Element
in the QSIG SETUP message based on the SDP information received along
with the SIP INVITE request. If the SIP INVITE request does not
contain SDP information or the media type in the SDP is only æaudioÆ
then the Bearer capability information element SHALL BE generated
according to table 3. Coding of the Bearer capability information
element for other media types is outside the scope of this
specification.
Table 3 û Bearer capability encoding for æaudioÆ transfer
Field Value
Coding Standard "CCITT standardized coding" (00)
Elwell et alia Expires - October 2002 [Page 26]
Interworking between SIP and QSIG April 2002
Information transfer "3,1 kHz audio" (10000)
capability
Transfer mode "circuit mode" (00)
Information transfer rate "64 Kbits/s" (10000)
Multiplier Octet omitted
User information layer 1 Generated by gateway based on
protocol information of the PISN. Supported
values are
"CCITT recommendation G.711 @-law"
(00010)
"CCITT recommendation G.711 A-law"
(00011)
10.2 Derivation of media type in SDP
The gateway SHALL generate the SDP information to include in the SIP
INVITE request based on the Bearer capability information element
received in the QSIG SETUP message. The media type included in the
SDP SHALL be according to table 4.
Table 4 û Media type setting in SDP based on Bearer capability
information element
Information transfer capability in Media type in SDP
Bearer capability information element
"speech" (00000) audio
"3,1 kHz audio" (10000) audio
"unrestricted digital information" (01000) data
11 Security considerations
The security considerations of RFC 3261 apply.
12 Author's Addresses
John Elwell
Siemens Communications Limited
Technology Drive
Beeston
Nottingham, UK, NG9 1LA
email: john.elwell@siemenscomms.co.uk
Frank Derks
Philips Business Communications
P.O. Box 32
1200 JD, Hilversum
Elwell et alia Expires - October 2002 [Page 27]
Interworking between SIP and QSIG April 2002
The Netherlands
email: frank.derks@philips.com
Olivier Rousseau
Alcatel Business Systems
32,Avenue Kleber
92700 Colombes
France
email: olivier.rousseau@col.bsf.alcatel.fr
Patrick Mourot
Alcatel Business Systems
1,Rue Dr A. Schweitzer
67400 Illkirch
France
email: patrick.mourot@sxb.bsf.alcatel.fr
13 Normative References
[1] ECMA-133 "Private Integrated Services Network (PISN û Reference
configuration for PISN exchanges (PINX)" (International Standard
ISO/IEC 11579-1)
[2] ECMA-143 "Private Integrated Services Network - Circuit-mode
Bearer Services - Inter-Exchange Signalling Procedures and Protocol"
(International Standard ISO/IEC 11572)
[3] ECMA-165 "Private Integrated Services Network - Generic
Functional Protocol for the Support of Supplementary Services -
Inter-Exchange Signalling Procedures and Protocol" (International
Standard ISO/IEC 11582)
[4] ECMA-307 "Corporate Telecommunication Networks - Signalling
Interworking between QSIG and H.323 - Generic Functional Protocol for
the Support of Supplementary Services" (International Standard
ISO/IEC 21409)
[5] J. Postel, " Transmission Control Protocol", RFC 793.
[6] J. Postel, "User Datagram Protocol", RFC 768.
[7] T. Dierks, C.Allen, "The TLS protocol version 1.0", RFC 2246.
[8] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC
2327.
[9] R. Stewart et al., "Stream Control Transmission Protocol" RFC
2960.
Elwell et alia Expires - October 2002 [Page 28]
Interworking between SIP and QSIG April 2002
[10] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation
protocol", RFC 3261, April 2002.
[11] J. Rosenberg, H. Schulzrinne, "Reliability of Provisional
Responses in SIP", RFC BBBB.
[12] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with SDP",
Work in progress, RFC CCCC.
Annex A (informative) û Example message sequences
A.1 Introduction
This annex shows some typical message sequences that can occur for an
interworking between QSIG and SIP.
NOTE. For all message sequence diagrams, there is no message mapping
between QSIG and SIP unless explicitly indicated by dotted lines.
Also, if there are no dotted lines connecting two messages, this
means that these are independent of each other in terms of the time
when they occur.
NOTE. Numbers prefixing SIP method names and response codes in the
diagrams represent sequence numbers. Messages bearing the same
number will have the same value in the CSeq header.
A.2 Message sequences for call establishment from QSIG to SIP
Below are typical message sequences for successful call establishment
from QSIG to SIP
Elwell et alia Expires - October 2002 [Page 29]
Interworking between SIP and QSIG April 2002
.-------------------.
| |
| GATEWAY |
PISN | | IP NETWORK
| `-----+------+------' |
| | | |
| | | |
| QSIG SETUP | | 1-INVITE |
1|----------------------->|......|----------------------->| 2
| | | |
| | | |
| QSIG CALL PROCCEEDING | | 1-100 TRYING |
3|<-----------------------| |<-----------------------+ 4
| | | |
| | | |
| QSIG ALERTING | | 1-180 RINGING |
8|<-----------------------|......|<-----------------------+ 5
| | | |
| | | 2-PRACK |
| | |----------------------->| 6
| | | 2-200 OK |
| | |<-----------------------+ 7
| | | |
| QSIG CONNECT | | 1-200 OK |
11|<-----------------------|......|<-----------------------+ 9
| | | |
| QSIG CONNECT ACK | | 1-ACK |
12|----------------------->| |----------------------->| 10
| | | |
|<======================>| |<======================>|
| AUDIO | | AUDIO |
Figure 3 û Typical message sequence for successful call establishment
from QSIG to SIP using enbloc procedures on both QSIG and SIP
1 The PISN sends a QSIG SETUP message to the gateway to begin a
session with a SIP UA
2 On receipt of the QSIG SETUP message, the gateway generates a SIP
INVITE request and sends it to an appropriate SIP entity in the IP
network based on the called number
3 The gateway sends a QSIG CALL PROCEEDING message to the PISN - no
more QSIG INFORMATION messages will be accepted
4 The IP network sends a SIP 100 (Trying) response to the gateway
5 The IP network sends a SIP 180 (Ringing) response.
6 The gateway may send back a SIP PRACK request to the IP network
based on the inclusion of a Require header or a Supported header with
option tag 100rel in the initial SIP INVITE request
7 The IP network sends a SIP 200 (OK) response to the gateway to
acknowledge the SIP PRACK request
Elwell et alia Expires - October 2002 [Page 30]
Interworking between SIP and QSIG April 2002
8 The gateway maps this SIP 180 (Ringing) response to a QSIG
ALERTING message and sends it to the PISN.
9 The IP network sends a SIP 200 (OK) response when the call is
answered.
10 The gateway sends a SIP ACK request to acknowledge the SIP 200
(OK)response.
11 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT
message and sends it to the PISN.
12 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to
the QSIG CONNECT message.
+------------------------+
PISN | GATEWAY | IP NETWORK
| |
| QSIG SETUP +--------+-------+-------+ |
1|-------------------------->| | |
| | | |
| QSIG SETUP ACK | | |
2|<--------------------------| | |
| | | |
| QSIG INFORMATION | | |
3|-------------------------->| | |
| | | |
| QSIG INFORMATION | | 1-INVITE |
3a|-------------------------->|.......|------------------------>|4
| QSIG CALL PROCEEDING | | 1-100 TRYING |
5|<--------------------------| |<------------------------|6
| | | |
| QSIG ALERTING | | 1-180 RINGING |
10|<--------------------------|.......|<------------------------|7
| | | 2-PRACK |
| | |------------------------>|8
| | | 2-200 OK |
| | |<------------------------|9
| QSIG CONNECT | | 1-200 OK |
13|<--------------------------|.......|<------------------------|11
| | | |
| QSIG CONNECT ACK | | 1-ACK |
14|-------------------------->| |------------------------>|12
| AUDIO | | AUDIO |
|<=========================>| |<=======================>|
Figure 4 û Typical message sequence for successful call establishment
from QSIG to SIP using overlap receiving on QSIG and enbloc sending
on SIP
1 The PISN sends a QSIG SETUP message to the gateway to begin a
session with a SIP UA. The QSIG SETUP message does not contain a
Sending Complete information element.
Elwell et alia Expires - October 2002 [Page 31]
Interworking between SIP and QSIG April 2002
2 The gateway sends a QSIG SETUP ACKNOWLEDGE message to the PISN.
More digits are expected.
3 More digits are sent from the PISN within a QSIG INFORMATION
message.
3a More digits are sent from the PISN within a QSIG INFORMATION
message. The QSIG INFORMATION message contains a Sending Complete
information element
4 The Gateway generates a SIP INVITE request and sends it to an
appropriate SIP entity in the IP network, based on the called number
5 The gateway sends a QSIG CALL PROCEEDING message to the PISN - no
more QSIG INFORMATION messages will be accepted
6 The IP network sends a SIP 100 (Trying) response to the gateway
7 The IP network sends a SIP 180 (Ringing) response.
8 The gateway may send back a SIP PRACK request to the IP network
based on the inclusion of a Require header or a Supported header with
option tag 100rel in the initial SIP INVITE request
9 The IP network sends a SIP 200 (OK) response to the gateway to
acknowledge the SIP PRACK request
10 The gateway maps this SIP 180 (Ringing) response to a QSIG
ALERTING message and sends it to the PINX.
11 The IP network sends a SIP 200 (OK) response when the call is
answered.
12 The gateway sends an SIP ACK request to acknowledge the SIP 200
(OK) response.
13 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT
message and sends it to the PINX.
14 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to
the QSIG CONNECT message.
Elwell et alia Expires - October 2002 [Page 32]
Interworking between SIP and QSIG April 2002
+----------------------+
PISN | GATEWAY | IP NETORK
| |
| QSIG SETUP +-------+-------+------+ |
1 |-------------------------->| | |
| | | |
| QSIG SETUP ACK | | |
2 |<--------------------------| | |
| | | |
| QSIG INFORMATION | | |
3 |-------------------------->| | |
| QSIG INFORMATION | | 1-INVITE |
3 |-------------------------->|.......|------------------------->|4
| | | 1-484 |
| | |<-------------------------|5
| | | 1-ACK |
| | |------------------------->|6
| QSIG INFORMATION | | 2-INVITE |
7 |-------------------------->|.......|------------------------->|4
| | | 2-484 |
| | |<-------------------------|5
| | | 2-ACK |
| | |------------------------->|6
| | | |
| QSIG INFORMATION | | |
| Sending Complete IE | | 3-INVITE |
8 |-------------------------->|.......|------------------------->|10
| QSIG CALL PROCEEDING | | 3-100 TRYING |
9 |<--------------------------| |<-------------------------|11
| | | |
| QSIG ALERTING | | 3-180 RINGING |
15|<--------------------------|.......|<-------------------------|12
| | | 4-PRACK |
| | |------------------------->|13
| | | 4-200 OK |
| | |<-------------------------|14
| QSIG CONNECT | | 3-200 OK |
18|<--------------------------|.......|<-------------------------|16
| | | |
| QSIG CONNECT ACK | | 3-ACK |
19|-------------------------->| |------------------------->|17
| AUIO | | AUDIO |
|<=========================>| |<========================>|
| | | |
Figure 5 û Typical message sequence for successful call establishment
from QSIG to SIP using overlap procedures on both QSIG and SIP
Elwell et alia Expires - October 2002 [Page 33]
Interworking between SIP and QSIG April 2002
1 The PISN sends a QSIG SETUP message to the gateway to begin a
session with a SIP UA. The QSIG SETUP message does not contain a
Sending complete information element.
2 The gateway sends a QSIG SETUP ACKNOWLEDGE message to the PISN.
More digits are expected.
3 More digits are sent from the PISN within a QSIG INFORMATION
message.
4 When the gateway receives the minimum number of digits required to
route the call it generates a SIP INVITE request and sends it to an
appropriate SIP entity in the IP network based on the called number
5 Due to an insufficient number of digits the IP network will return
a SIP 484 (Address Incomplete) response.
6 The SIP 484 (Address Incomplete) response is acknowledged.
7 More digits are received from the PISN in a QSIG INFORMATION
message. A new INVITE is sent with the same Call-ID but an updated
Request-URI.
8 More digits are received from the PISN in a QSIG INFORMATION
message. The QSIG INFORMATION message contains a Sending Complete
information element
9 The gateway sends a QSIG CALL PROCEEDING message to the PISN - no
more information will be accepted
10 The gateway sends a new SIP INVITE request with an updated
Request-URI field.
11 The IP network sends a SIP 100 (Trying) response to the gateway
12 The IP network sends a SIP 180 (Ringing) response.
13 The gateway may send back a SIP PRACK request to the IP network
based on the inclusion of a Require header or a Supported header with
option tag 100rel in the initial SIP INVITE request
14 The IP network sends a SIP 200 (OK) response to the gateway to
acknowledge the SIP PRACK request
15 The gateway maps this SIP 180 (Ringing) response to a QSIG
ALERTING message and sends it to the PISN.
16 The IP network sends a SIP 200 (OK) response when the call is
answered.
17 The gateway sends a SIP ACK request to acknowledge the SIP 200
(OK) response.
18 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT
message.
19 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to
the QSIG CONNECT message.
A.3 Message sequences for call establishment from SIP to QSIG
Below are typical message sequences for successful call establishment
from SIP to QSIG
Elwell et alia Expires - October 2002 [Page 34]
Interworking between SIP and QSIG April 2002
+----------------------+
IP NETWORK | GATEWAY | PISN
| |
| +-------+-------+------+ |
| | | |
| | | |
| 1-INVITE | | QSIG SETUP |
1 |-------------------------->|.......|------------------------->|3
| 1-100 TRYING | | QSIG CALL PROCEEDING |
2 |<--------------------------| |<-------------------------|4
| 1-180 RINGING | | QSIG ALERTING |
6 |<--------------------------|.......|<-------------------------|5
| | | |
| | | |
| 2-PRACK | | |
7 |-------------------------->| | |
| 2-200 OK | | |
8 |<--------------------------| | |
| 1-200 OK | | QSIG CONNECT |
11|<--------------------------|.......|<-------------------------|9
| | | |
| 1-ACK | | QSIG CONNECT ACK |
12|-------------------------->| |------------------------->|10
| AUDIO | | AUDIO |
|<=========================>| |<========================>|
| | | |
Figure 6 û Typical message sequence for successful call establishment
from SIP to QSIG using enbloc procedures
1 The IP network sends a SIP INVITE request to the gateway
2 The gateway sends a SIP 100 (Trying) response to the IP network
3 On receipt of the SIP INVITE request, the gateway sends a QSIG
SETUP message
4 The PISN sends a QSIG CALL PROCEEDING message to the gateway
5 A QSIG ALERTING message is returned to indicate that the end user
in the PISN is being alerted
6 The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing)
response
7 The IP network can send back a SIP PRACK request to the IP network
based on the inclusion of a Require header or a Supported header with
option tag 100rel in the initial SIP INVITE request
8 The gateway sends a SIP 200 (OK) response to acknowledge the SIP
PRACK request
9 The PISN sends a QSIG CONNECT message to the gateway when the call
is answered
10 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to
acknowledge the QSIG CONNECT message
11 The QSIG CONNECT message is mapped to a SIP 200 (OK) response.
Elwell et alia Expires - October 2002 [Page 35]
Interworking between SIP and QSIG April 2002
12 The IP network, upon receiving a SIP INVITE final response (200),
will send a SIP ACK request to acknowledge receipt
+----------------------+
IP NETWORK | GATEWAY | PISN
| |
| 1-INVITE +-------+-------+------+ |
1 |-------------------------->| | |
| 1-484 | | |
2 |<--------------------------| | |
| 1-ACK | | |
3 |-------------------------->| | |
| 2-INVITE | | |
1 |-------------------------->| | |
| 2-484 | | |
2 |<--------------------------| | |
| 2- ACK | | |
3 |-------------------------->| | |
| 3-INVITE | | QSIG SETUP |
4 |-------------------------->|.......|------------------------->|6
| 3-100 TRYING | | QSIG CALL PROCEEDING |
5 |<--------------------------| |<-------------------------|7
| 3-180 RINGING | | QSIG ALERTING |
9 |<--------------------------|.......|<-------------------------|8
| | | |
| | | |
| 4-PRACK | | |
10|-------------------------->| | |
| 5-200 OK | | |
11|<--------------------------| | |
| 3-200 OK | | QSIG CONNECT |
14|<--------------------------|.......|<-------------------------|12
| | | |
| 3-ACK | | QSIG CONNECT ACK |
15|-------------------------->| |------------------------->|13
| AUDIO | | AUDIO |
|<=========================>| |<========================>|
| | | |
Figure 7 û Typical message sequence for successful call establishment
from SIP to QSIG using overlap receiving on SIP and enbloc sending on
QSIG
1 The IP network sends a SIP INVITE request to the gateway
2 Due to an insufficient number of digits the gateway returns a SIP
484(Address Incomplete) response.
3 The IP network acknowledge the SIP 484 (Address Incomplete)
response.
Elwell et alia Expires - October 2002 [Page 36]
Interworking between SIP and QSIG April 2002
4 The IP network sends a new SIP INVITE request with the same Call-
ID and updated Request-URI.
5 The gateway now has all the digits required to route the call to
the PISN. The gateway sends back a SIP 100 (Trying) response
6 The gateway sends a QSIG SETUP message
7 The PISN sends a QSIG CALL PROCEEDING message to the gateway
8 A QSIG ALERTING message is returned to indicate that the end user
in the PISN is being alerted
9 The gateway maps the QSIG ALERTING message to a SIP 180
(Ringing)response
10 The IP network can send back a SIP PRACK request to the IP network
based on the inclusion of a Require header or a Supported header with
option tag 100rel in the initial SIP INVITE request
11 The gateway sends a SIP 200 (OK) response to acknowledge the SIP
PRACK request
12 The PISN sends a QSIG CONNECT message to the gateway when the call
is answered
13 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to
acknowledge the CONNECT message
14 The QSIG CONNECT message is mapped to a SIP 200 (OK) response.
15 The IP network, upon receiving a SIP INVITE final response (200),
will send a SIP ACK request to acknowledge receipt
Elwell et alia Expires - October 2002 [Page 37]
Interworking between SIP and QSIG April 2002
+----------------------+
IP NETWORK | GATEWAY | PISN
| |
| 1-INVITE +-------+-------+------+ |
1 |-------------------------->| | |
| 1-484 | | |
2 |<--------------------------| | |
| 1-ACK | | |
3 |-------------------------->| | |
| 2-INVITE | | QSIG SETUP |
4 |-------------------------->|.......|------------------------->|6
| 2-100 TRYING | | QSIG SETUP ACK |
5 |<--------------------------| |<-------------------------|7
| 3- INVITE | | QSIG INFORMATION |
8 |-------------------------->|.......|------------------------->|10
| 3-100 TRYING | | |
9 |<--------------------------| | QSIG CALL PROCEEDING |
| | |<-------------------------|11
13| 3-180 RINGING | | QSIG ALERTING |
|<--------------------------|.......|<-------------------------|12
| 2-484 | | |
14|<--------------------------| | |
| 2-ACK | | |
15|-------------------------->| | |
| 4-PRACK | | |
16|-------------------------->| | |
| 4-200 OK | | |
17|<--------------------------| | |
| 3-200 OK | | QSIG CONNECT |
20|<--------------------------|.......|<-------------------------|18
| | | |
| 3-ACK | | QSIG CONNECT ACK |
21|-------------------------->| |------------------------->|19
| AUDIO | | AUDIO |
|<=========================>| |<========================>|
| | | |
Figure 8 û Typical message sequence for successful call establishment
from SIP to QSIG using overlap procedures on both SIP and QSIG
1 The IP network sends a SIP INVITE request to the gateway
2 Due to an insufficient number of digits the gateway returns a SIP
484(Address Incomplete) response.
3 The IP network acknowledge the SIP 484 (Address Incomplete)
response.
4 The IP network sends a new SIP INVITE request with the same Call-
ID and updated Request-URI.
Elwell et alia Expires - October 2002 [Page 38]
Interworking between SIP and QSIG April 2002
5 The gateway now has all the digits required to route the call to
the PISN. The gateway sends back a SIP 100 (Trying) response to the
IP network
6 The gateway sends a QSIG SETUP message
7 The PISN needs more digits to route the call and sends a QSIG
SETUP ACKNOWLEDGE message to the gateway
8 The IP network sends a new SIP INVITE request with the same Call-
ID and updated Request-URI.
9 The gateway sends back a SIP 100 (Trying) response to the IP
network
10 The gateway maps the new SIP INVITE request to a QSIG INFORMATION
message
11 The PISN has all the digits required and sends back a QSIG CALL
PROCEEDING message to the gateway
12 A QSIG ALERTING message is returned to indicate that the end user
in the PISN is being alerted
13 The gateway maps the QSIG ALERTING message to a SIP 180
(Ringing)response
14 The gateway sends a SIP 484 (Address Incomplete) response for the
previous SIP INVITE request
15 The IP network acknowledges the SIP 484 (Address Incomplete)
response
16 The IP network can send back a SIP PRACK request to the IP network
based on the inclusion of a Require header or a Supported header with
option tag 100rel in the initial SIP INVITE request
17 The gateway sends a SIP 200 (OK) response to acknowledge the SIP
PRACK request
18 The PISN sends a QSIG CONNECT message to the gateway when the call
is answered
19 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to
acknowledge the QSIG CONNECT message
20 The QSIG CONNECT message is mapped to a SIP 200 (OK) response.
21 The IP network, upon receiving a SIP INVITE final response (200),
will send a SIP ACK request to acknowledge receipt
A.4 Message sequence for call clearing from QSIG to SIP
Below are typical message sequences for Call Clearing from QSIG to
SIP
Elwell et alia Expires - October 2002 [Page 39]
Interworking between SIP and QSIG April 2002
.-------------------.
| |
| GATEWAY |
PISN | | IP NETWORK
| `-----+------+------' |
| | | |
| | | |
| QSIG DISCONNECT | | 2- BYE |
1|----------------------->|......|----------------------->|4
| QSIG RELEASE | | 2-200 OK |
2|<-----------------------| |<-----------------------|5
| QSIG RELEASE COMP | | |
3|----------------------->| | |
| | | |
| | | |
| | | |
Figure 9 û Typical message sequence for call clearing from QSIG to
SIP subsequent to call establishment
1 The PISN sends a QSIG DISCONNECT message to the gateway
2 The gateway sends back a QSIG RELEASE message to the PISN in
response to the QSIG DISCONNECT message
3 The PISN sends a QSIG RELEASE COMPLETE message in response. All
PISN resources are now released.
4 The gateway maps the QSIG DISCONNECT message to a SIP BYE request
5 The IP network sends back a SIP 200 (OK) response to the SIP BYE
request. All IP resources are now released
.-------------------.
| |
| GATEWAY |
PISN | | IP NETWORK
| `-----+------+------' |
| | | |
| | | |
| QSIG DISCONNECT | | 1- 4XX / 6XX |
1|----------------------->|......|----------------------->|4
| QSIG RELEASE | | 1- ACK |
2|<-----------------------| |<-----------------------|5
| QSIG RELEASE COMP | | |
3|----------------------->| | |
| | | |
| | | |
Figure 10 û Typical message sequence for call clearing from QSIG to
SIP during establishment of a call from SIP to QSIG (gateway has not
sent a final response to the SIP INVITE request)
Elwell et alia Expires - October 2002 [Page 40]
Interworking between SIP and QSIG April 2002
1 The PISN sends a QSIG DISCONNECT message to the gateway
2 The gateway sends back a QSIG RELEASE message to the PISN in
response to the QSIG DISCONNECT message
3 The PISN sends a QSIG RELEASE COMPLETE message in response. All
PISN resources are now released.
4 The gateway maps the QSIG DISCONNECT message to a SIP 4xx-6xx
response
5 The IP network sends back a SIP ACK request in response to the SIP
4xx-6xx response. All IP resources are now released
.-------------------.
| |
| GATEWAY |
PISN | | IP NETWORK
| `-----+------+------' |
| | | |
| | | |
| QSIG DISCONNECT | | 1- CANCEL |
1|----------------------->|......|----------------------->|4
| QSIG RELEASE | |1-487 Request Terminated|
2|<-----------------------| |<-----------------------|5
| QSIG RELEASE COMP | | |
3|----------------------->| | 1- 200 OK |
| | |<-----------------------|6
| | | |
| | | |
Figure 11 û Typical message sequence for call clearing from QSIG to
SIP during establishment of a call from QSIG to SIP (gateway has
received a provisional response to the SIP INVITE request but not a
final response)
1 The PISN sends a QSIG DISCONNECT message to the gateway
2 The gateway sends back a QSIG RELEASE message to the PISN in
response to the QSIG DISCONNECT message
3 The PISN sends a QSIG RELEASE COMPLETE message in response. All
PISN resources are now released.
4 The gateway maps the QSIG DISCONNECT message to a SIP CANCEL
request(subject to a provisional response but no final response
having been received)
5 The IP network sends back a SIP 487 (Request Terminated) response
to the SIP INVITE request.
6 The IP network sends back a SIP 200 (OK) response to the SIP
CANCEL request. All IP resources are now released
A.5 Message sequence for call clearing from SIP to QSIG
Below are typical message sequences for Call Clearing from SIP to
QSIG
Elwell et alia Expires - October 2002 [Page 41]
Interworking between SIP and QSIG April 2002
.-------------------.
| |
| GATEWAY |
IP NETWORK | | PISN
| `-----+------+------' |
| | | |
| | | |
| 2- BYE | | QSIG DISCONNECT |
1|----------------------->|......|----------------------->|3
| | | QSIG RELEASE |
| | |<-----------------------|4
| 2-200 OK | | QSIG RELEASE COMP |
2|<-----------------------| |----------------------->|5
| | | |
| | | |
Figure 12 û Typical message sequence for call clearing from SIP to
QSIG subsequent to call establishment
1 The IP network sends a SIP BYE request to the gateway
2 The gateway sends back a SIP 200 (OK) response to the SIP BYE
request. All IP resources are now released
3 The gateway maps the SIP BYE request to a QSIG DISCONNECT message
4 The PISN sends back a QSIG RELEASE message to the gateway in
response to the QSIG DISCONNECT message
5 The gateway sends a QSIG RELEASE COMPLETE message in response. All
PISN resources are now released.
.-------------------.
| |
| GATEWAY |
IP NETWORK | | PISN
| `-----+------+------' |
| | | |
| | | |
| 1- 4XX / 6XX | | QSIG DISCONNECT |
1|----------------------->|......|----------------------->|3
| | | QSIG RELEASE |
| | |<-----------------------|4
| 1- ACK | | QSIG RELEASE COMP |
2|<-----------------------| |----------------------->|5
| | | |
| | | |
| | | |
Figure 13 û Typical message sequence for call clearing from SIP to
QSIG during establishment of a call from QSIG to SIP (gateway has not
previously received a final response to the SIP INVITE request)
Elwell et alia Expires - October 2002 [Page 42]
Interworking between SIP and QSIG April 2002
1 The IP network sends a SIP 4xx-6xx response to the gateway
2 The gateway sends back a SIPACK request in response to the SIP
4xx-6xx response. All IP resources are now released
3 The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT
message
4 The PISN sends back a QSIG RELEASE message to the gateway in
response to the QSIG DISCONNECT message
5 The gateway sends a QSIG RELEASE COMPLETE message in response. All
PISN resources are now released.
.-------------------.
| |
| GATEWAY |
IP NETWORK | | PISN
| `-----+------+------' |
| | | |
| | | |
| 1- CANCEL | | QSIG DISCONNECT |
1|----------------------->|......|----------------------->|4
| | | QSIG RELEASE |
| | |<-----------------------|5
|1-487 Request Terminated| | QSIG RELEASE COMP |
2|<-----------------------| |----------------------->|6
| | | |
| 1- 200 OK | | |
3|<-----------------------| | |
Figure 14 û Typical message sequence for call clearing from SIP to
QSIG during establishment of a call from QSIG to SIP (gateway has
received a provisional response to the SIP INVITE request but not a
final response)
1 The IP network sends a SIP CANCEL request to the gateway
2 The gateway sends back a SIP 487 (Request Terminated) response to
the SIP INVITE request
3 The gateway sends back a SIP 200 (OK) response to the SIP CANCEL
request. All IP resources are now released
4 The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT
message
5 The PISN sends back a QSIG RELEASE message to the gateway in
response to the QSIG DISCONNECT message
6 The gateway sends a QSIG RELEASE COMPLETE message in response. All
PISN resources are now released.
Elwell et alia Expires - October 2002 [Page 43]