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.
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.
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.
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.
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)".
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
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.
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.
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.
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.
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.
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.
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