NOTE 5: In some cases, it may be possible for the gateway to provide
credentials to the SIP UAS that is rejecting an INVITE due to
authorization failure. If the gateway can authenticate itself, then
obviously it should do so and proceed with the call. Only if the
gateway cannot authorize itself should the gateway clear the call in
the QSIG network with this cause value.
NOTE 6: For some response codes, the gateway may be able to retry the
INVITE request in order to work around the problem. In particular,
this may be the case with response codes indicating a protocol error.
The gateway SHOULD clear the call in the QSIG network with the
indicated cause value only if retry is not possible or fails.
NOTE 7: The circumstances in which SIP response code 487 can be
expected to arise do not require it to be mapped to a QSIG cause
code, since the QSIG call will normally already be cleared or in the
process of clearing. If QSIG call clearing does, however, need to be
initiated, the default cause value should be used.
NOTE 8: When the Warning header is present in a SIP 606 or 488
message, the warning code should be examined to determine whether it
is reasonable to generate cause value 65. This cause value should be
generated only if there is a chance that a new call attempt with
different content in the Bearer capability information element will
avoid the problem. In other circumstances, the default cause value
should be used.
8.4.5 Gateway-Initiated Call Clearing
If the gateway initiates clearing of the QSIG call owing to QSIG
timer expiry, QSIG protocol error, or use of the QSIG RESTART message
in accordance with [2], the gateway SHALL also initiate clearing of
the SIP call in accordance with Section 8.4.1. If this involves the
sending of a final response to a SIP INVITE request, the gateway
SHALL use response code 480 (Temporarily Unavailable) if optional
QSIG timer T301 has expired or, otherwise, response code 408 (Request
timeout) or 500 (Server internal error), as appropriate.
If the gateway initiates clearing of the SIP call owing to SIP timer
expiry or SIP protocol error in accordance with [10], the gateway
SHALL also initiate clearing of the QSIG call in accordance with [2]
using cause value 102 (Recovery on timer expiry) or 41 (Temporary
failure), as appropriate.
8.5. Request to Change Media Characteristics
If after a call has been successfully established the gateway
receives a SIP INVITE request to change the media characteristics of
the call in a way that would be incompatible with the bearer
capability in use within the PISN, the gateway SHALL send back a SIP
488 (Not Acceptable Here) response and SHALL NOT change the media
characteristics of the existing call.
9. Number Mapping
In QSIG, users are identified by numbers, as defined in [1]. Numbers
are conveyed within the Called party number, Calling party number,
and Connected number information elements. The Calling party number
and Connected number information elements also contain a presentation
indicator, which can indicate that privacy is required (presentation
restricted), and a screening indicator, which indicates the source
and authentication status of the number.
In SIP, users are identified by Universal Resource Identifiers (URIs)
conveyed within the Request-URI and various headers, including the
From and To headers specified in [10] and optionally the P-Asserted-
Identity header specified in [14]. In addition, privacy is indicated
by the Privacy header specified in [13].
This clause specifies the mapping between QSIG Called party number,
Calling party number, and Connected number information elements and
corresponding elements in SIP.
A gateway MAY implement the P-Asserted-Identity header in accordance
with [14]. If a gateway implements the P-Asserted-Identity header,
it SHALL also implement the Privacy header in accordance with [13].
If a gateway does not implement the P-Asserted-Identity header, it
MAY implement the Privacy header.
9.1. Mapping from QSIG to SIP
The method used to convert a number to a URI is outside the scope of
this specification. However, the gateway SHOULD take account of the
Numbering Plan (NPI) and Type Of Number (TON) fields in the QSIG
information element concerned when interpreting a number.
Some aspects of mapping depend on whether the gateway is in the same
trust domain (as defined in [14]) as the next hop SIP node (i.e., the
proxy or UA to which the INVITE request is sent or from which INVITE
request is received) to honour requests for identity privacy in the
Privacy header. This will be network-dependent, and it is
RECOMMENDED that gateways supporting the P-Asserted-Identity header
hold a configurable list of next hop nodes that are to be trusted in
this respect.
9.1.1. Using Information from the QSIG Called Party Number Information
Element
When mapping a QSIG SETUP message to a SIP INVITE request, the
gateway SHALL convert the number in the QSIG Called party number
information to a URI and include that URI in the SIP Request-URI and
in the To header.
9.1.2. Using Information from the QSIG Calling Party Number Information
Element
When mapping a QSIG SETUP message to a SIP INVITE request, the
gateway SHALL use the Calling party number information element, if
present, as follows.
If the information element contains a number, the gateway SHALL
attempt to derive a URI from that number. Further behaviour depends
on whether a URI has been derived and the value of the presentation
indication.
9.1.2.1. No URI derived, and presentation indicator does not have value
"presentation restricted"
In this case (including the case where the Calling party number
information element is absent), the gateway SHALL include a URI
identifying the gateway in the From header. Also, if the gateway
supports the mechanism defined in [14], the gateway SHALL NOT
generate a P-Asserted-Identity header.
9.1.2.2. No URI derived, and presentation indicator has value
"presentation restricted"
In this case, the gateway SHALL generate an anonymous From header.
Also, if the gateway supports the mechanism defined in [14], the
gateway SHALL generate a Privacy header field with parameter
priv-value = "id" and SHALL NOT generate a P-Asserted-Identity
header. The inclusion of additional values of the priv-value
parameter in the Privacy header is outside the scope of this
specification.
9.1.2.3. URI derived, and presentation indicator has value
"presentation restricted"
If the gateway supports the P-Asserted-Identity header and trusts the
next hop proxy to honour the Privacy header, the gateway SHALL
generate a P-Asserted-Identity header containing the derived URI,
SHALL generate a Privacy header with parameter priv-value = "id", and
SHALL generate an anonymous From header. The inclusion of additional
values of the priv-value parameter in the Privacy header is outside
the scope of this specification.
If the gateway does not support the P-Asserted-Identity header or
does not trust the proxy to honour the Privacy header, the gateway
SHALL behave as in Section 9.1.2.2.
9.1.2.4. URI derived, and presentation indicator does not have value
"presentation restricted"
In this case, the gateway SHALL generate a P-Asserted-Identity header
containing the derived URI if the gateway supports this header, SHALL
NOT generate a Privacy header, and SHALL include the derived URI in
the From header. In addition, the gateway MAY use S/MIME, as
described in Section 23 of [10], to sign a copy of the From header
included in a message/sipfrag body of the INVITE request as described
in [20].
9.1.3. Using Information from the QSIG Connected Number Information
Element
When mapping a QSIG CONNECT message to a SIP 200 (OK) response to an
INVITE request, the gateway SHALL use the Connected number
information element, if present, as follows.
If the information element contains a number, the gateway SHALL
attempt to derive a URI from that number. Further behaviour depends
on whether a URI has been derived and the value of the presentation
indication.
9.1.3.1. No URI derived, and presentation indicator does not have value
"presentation restricted"
In this case (including the case where the Connected number
information element is absent), the gateway SHALL NOT generate a
P-Asserted-Identity header and SHALL NOT generate a Privacy header.
9.1.3.2. No URI derived, and presentation indicator has value
"presentation restricted"
In this case, if the gateway supports the mechanism defined in [14],
the gateway SHALL generate a Privacy header field with parameter
priv-value = "id" and SHALL NOT generate a P-Asserted-Identity
header. The inclusion of additional values of the priv-value
parameter in the Privacy header is outside the scope of this
specification.
9.1.3.3. URI derived, and presentation indicator has value
"presentation restricted"
If the gateway supports the P-Asserted-Identity header and trusts the
next hop proxy to honour the Privacy header, the gateway SHALL
generate a P-Asserted-Identity header containing the derived URI and
SHALL generate a Privacy header with parameter priv-value = "id".
The inclusion of additional values of the priv-value parameter in the
Privacy header is outside the scope of this specification.
If the gateway does not support the P-Asserted-Identity header or
does not trust the proxy to honour the Privacy header, the gateway
SHALL behave as in Section 9.1.3.2.
9.1.3.4. URI derived, and presentation indicator does not have value
"presentation restricted"
In this case, the gateway SHALL generate a P-Asserted-Identity header
containing the derived URI if the gateway supports this header and
SHALL NOT generate a Privacy header. In addition, the gateway MAY
use S/MIME, as described in Section 23 of [10], to sign a To header
containing the derived URI, the To header being included in a
message/sipfrag body of the INVITE response as described in [20].
NOTE: The To header in the message/sipfrag body may differ from the
to header in the response’s headers.
9.2. Mapping from SIP to QSIG
The method used to convert a URI to a number is outside the scope of
this specification. However, NPI and TON fields in the QSIG
information element concerned SHALL be set to appropriate values in
accordance with [1].
Some aspects of mapping depend on whether the gateway trusts the next
hop SIP node (i.e., the proxy or UA to which the INVITE request is
sent or from which INVITE request is received) to provide accurate
information in the P-Asserted-Identity header. This will be
network-dependent, and it is RECOMMENDED that gateways hold a
configurable list of next hop nodes that are to be trusted in this
respect.
Some aspects of mapping depend on whether the gateway is prepared to
use a URI in the From header to derive a number for the Calling party
number information element. The default behaviour SHOULD be not to
use an unsigned or unvalidated From header for this purpose, since in
principle the information comes from an untrusted source (the remote
UA). However, it is recognised that some network administrations may
believe that the benefits to be derived from supplying a calling
party number outweigh any risks of supplying false information.
Therefore, a gateway MAY be configurable to use an unsigned or
unvalidated From header for this purpose.
9.2.1. Generating the QSIG Called Party Number Information Element
When mapping a SIP INVITE request to a QSIG SETUP message, the
gateway SHALL convert the URI in the SIP Request-URI to a number and
include that number in the QSIG Called party number information
element.
NOTE: The To header should not be used for this purpose. This is
because re-targeting of the request in the SIP network can change the
Request-URI but leave the To header unchanged. It is important that
routing in the QSIG network be based on the final target from the SIP
network.
9.2.2. Generating the QSIG Calling Party Number Information Element
When mapping a SIP INVITE request to a QSIG SETUP message, the
gateway SHALL generate a Calling party number information element as
follows.
If the SIP INVITE request contains an S/MIME signed message/sipfrag
body [20] containing a From header, and if the gateway supports this
capability and can verify the authenticity and trustworthiness of
this information, the gateway SHALL attempt to derive a number from
the URI in that header. If no number is derived from a
message/sipfrag body, if the SIP INVITE request contains a P-
Asserted-Identity header, and if the gateway supports that header and
trusts the information therein, the gateway SHALL attempt to derive a
number from the URI in that header. If a number is derived from one
of these headers, the gateway SHALL include it in the Calling party
number information element and include value "network provided" in
the screening indicator.
If no number is derivable as described above and if the gateway is
prepared to use the unsigned or unvalidated From header, the gateway
SHALL attempt to derive a number from the URI in the From header. If
a number is derived from the From header, the gateway SHALL include
it in the Calling party number information element and include value
"user provided, not screened" in the screening indicator.
If no number is derivable, the gateway SHALL NOT include a number in
the Calling party number information element.
If the SIP INVITE request contains a Privacy header with value "id"
in parameter priv-value and the gateway supports this header, or if
the value in the From header indicates anonymous, the gateway SHALL
include value "presentation restricted" in the presentation
indicator. Based on local policy, the gateway MAY use the presence
of other priv-values to set the presentation indicator to
"presentation restricted". Otherwise the gateway SHALL include value
"presentation allowed" if a number is present or "not available due
to interworking" if no number is present.
If the resulting Calling party number information element contains no
number and contains value "not available due to interworking" in the
presentation indicator, the gateway MAY omit the information element
from the QSIG SETUP message.
9.2.3. Generating the QSIG Connected Number Information Element
When mapping a SIP 2xx response to an INVITE request to a QSIG
CONNECT message, the gateway SHALL generate a Connected number
information element as follows.
If the SIP 2xx response contains an S/MIME signed message/sipfrag
[20] body containing a To header and the gateway supports this
capability and can verify the authenticity and trustworthiness of
this information, the gateway SHALL attempt to derive a number from
the URI in that header. If no number is derived from a
message/sipfrag body, if the SIP 2xx response contains a
P-Asserted-Identity header, and if the gateway supports that header
and trusts the information therein, the gateway SHALL attempt to
derive a number from the URI in that header. If a number is derived
from one of these headers, the gateway SHALL include it in the
Connected number information element and include value "network
provided" in the screening indicator.
If no number is derivable as described above, the gateway SHOULD NOT
include a number in the Connected number information element.
If the SIP 2xx response contains a Privacy header with value "id" in
parameter priv-value and the gateway supports this header, the
gateway SHALL include value "presentation restricted" in the
presentation indicator. Based on local policy, the gateway MAY use
the presence of other priv-values to set the presentation indicator
to "presentation restricted". Otherwise, the gateway SHALL include
value "presentation allowed" if a number is present or "not available
due to interworking" if no number is present.
If the resulting Connected number information element contains no
number and value "not available due to interworking" in the
presentation indicator, the gateway MAY omit the information element
from the QSIG CONNECT message.
10. Requirements for Support of Basic Services
This document specifies signalling interworking for basic services
that provide a bi-directional transfer capability for speech,
facsimile, and modem media between the two networks.
10.1. Derivation of QSIG Bearer Capability Information Element
The gateway SHALL generate the Bearer Capability Information Element
in the QSIG SETUP message based on SDP offer information received
along with the SIP INVITE request. If the SIP INVITE request does
not contain SDP offer information or the media type in the SDP offer
information is only ’audio’, then the Bearer capability information
element SHALL BE generated according to Table 3. Coding of the
Bearer capability information element for other media types is
outside the scope of this specification.
In addition, the gateway MAY include a Low layer compatibility
information element and/or High layer compatibility information in
the QSIG SETUP message if the gateway is able to derive relevant
information from the SDP offer information. Specific mappings are
outside the scope of this specification.
Table 3: Bearer capability encoding for ’audio’ transfer
Field Value
-----------------------------------------------------------------
Coding Standard "CCITT standardized coding" (00)
Information transfer "3,1 kHz audio" (10000)
capability
Transfer mode "circuit mode" (00)
Information transfer rate "64 Kbits/s" (10000)
Multiplier Octet omitted
User information layer 1 Generated by gateway based on
protocol Information of the PISN. Supported
values are
"CCITT recommendation G.711 mu-law"
(00010)
"CCITT recommendation G.711 A-law"
(00011)
10.2. Derivation of Media Type in SDP
The gateway SHALL generate SDP offer information to include in the
SIP INVITE request based on information in the QSIG SETUP message.
The gateway MAY take account of QSIG Low layer compatibility and/or
High layer compatibility information elements, if present in the QSIG
SETUP message, when deriving SDP offer information, in which case
specific mappings are outside the scope of this specification.
Otherwise, the gateway shall generate SDP offer information based
only on the Bearer capability information element in the QSIG SETUP
message, in which case the media type SHALL be derived according to
Table 4.
Table 4: Media type setting in SDP based on Bearer capability
information element
Information transfer capability in Media type in SDP
Bearer capability information element
---------------------------------------------------------------
"speech" (00000) audio
"3,1 kHz audio" (10000) audio
11. Security Considerations
11.1. General
Normal considerations apply for UA use of SIP security measures,
including digest authentication, TLS, and S/MIME as described in
[10].
The translation of QSIG information elements into SIP headers can
introduce some privacy and security concerns. For example, care
needs to be taken to provide adequate privacy for a user requesting
presentation restriction if the Calling party number information
element is openly mapped to the From header. Procedures for dealing
with this particular situation are specified in Section 9.1.2.
However, since the mapping specified in this document is mainly
concerned with translating information elements into the headers and
fields used to route SIP requests, gateways consequently reveal
(through this translation process) the minimum possible amount of
information.
There are some concerns, however, that arise from the other direction
of mapping, the mapping of SIP headers to QSIG information elements,
which are enumerated in the following paragraphs.
11.2. Calls from QSIG to Invalid or Restricted Numbers
When end users dial numbers in a PISN, their selections populate the
Called party number information element in the QSIG SETUP message.
Similarly, the SIP URI or tel URL and its optional parameters in the
Request-URI of a SIP INVITE request, which can be created directly by
end users of a SIP device, map to that information element at a
gateway. However, in a PISN, policy can prevent the user from
dialing certain (invalid or restricted) numbers. Thus, gateway
implementers may wish to provide a means for gateway administrators
to apply policies restricting the use of certain SIP URIs or tel
URLs, or SIP URI or tel URL parameters, when authorizing a call from
SIP to QSIG.
11.3. Abuse of SIP Response Code
Some additional risks may result from the mapping of SIP response
codes to QSIG cause values. SIP user agents could conceivably
respond to an INVITE request from a gateway with any arbitrary SIP
response code, and thus they can dictate (within the boundaries of
the mappings supported by the gateway) the Q.850 cause code that will
be sent by the gateway in the resulting QSIG call clearing message.
Generally speaking, the manner in which a call is rejected is
unlikely to provide any avenue for fraud or denial of service (e.g.,
by signalling that a call should not be billed, or that the network
should take critical resources off-line). However, gateway
implementers may wish to make provision for gateway administrators to
modify the response code to cause value mappings to avoid any
undesirable network-specific behaviour resulting from the mappings
recommended in Section 8.4.4.
11.4. Use of the To Header URI
This specification requires the gateway to map the Request-URI rather
than the To header in a SIP INVITE request to the Called party number
information element in a QSIG SETUP message. Although a SIP UA is
expected to put the same URI in the To header and in the Request-URI,
this is not policed by other SIP entities. Therefore, a To header
URI that differs from the Request-URI received at the gateway cannot
be used as a reliable indication that the call has been re-targeted
in the SIP network or as a reliable indication of the original
target. Gateway implementers making use of the To header for mapping
to QSIG elements (e.g., as part of QSIG call diversion signalling)
may wish to make provision for disabling this mapping when deployed
in situations where the reliability of the QSIG elements concerned is
important.
11.5. Use of the From Header URI
The arbitrary population of the From header of requests by SIP user
agents has some well-understood security implications for devices
that rely on the From header as an accurate representation of the
identity of the originator. Any gateway that intends to use an
unsigned or unverified From header to populate the Calling party
number information element of a QSIG SETUP message should
authenticate the originator of the request and make sure that it is
authorized to assert that calling number (or make use of some more
secure method to ascertain the identity of the caller). Note that
gateways, like all other SIP user agents, MUST support Digest
authentication as described in [10]. Similar considerations apply to
the use of the SIP P-Asserted-Identity header for mapping to the QSIG
Calling party number or Connected number information element, i.e.,
the source of this information should be authenticated. Use of a
signed message/sipfrag body to derive a QSIG Calling party number or
Connected number information element is another secure alternative.
11.6. Abuse of Early Media