Where the S-CSCF provides emergency call
support, the procedures of subclause 5.4.8 shall be applied first.
Upon
1) a third-party registration due to initial
registration on behalf of a served public user identity; or
2) a trigger to an AS for unregistered public
user identity and there is no IP address of that AS associated with that public
user identity stored
the
S-CSCF shall store the IP address of the AS and associate the IP address with
the public user identity and the AS SIP URI along with all URI parameters.
Editor's Note: [WI:IMSProtoc7, CR#5303] The analysis on error cases is
FFS.
The S-CSCF shall determine which authentication
mechanism applies based on the contents of the REGISTER request and the
authentication mechanism assigned in the HSS:
1) if the
REGISTER request contains an Authorization header field with the
"integrity-protected" header field parameter set to "no",
the S-CSCF shall perform the initial registration procedures with IMS-AKA
authentication described in subclauses 5.4.1.2.1 and 5.4.1.2.1A;
2) if the
REGISTER request contains an Authorization header field with the
"integrity-protected" header field parameter set to "yes",
the S-CSCF shall perform the protected registration procedures with IMS-AKA as
a security mechanism as described in subclause 5.4.1.2.2;
2A) if
the REGISTER request contains an Authorization header field with the
"integrity-protected" header field parameter set to
"tls-connected" and with the "algorithm" header field
parameter set to "AKAv2-SHA-256", and if the S-CSCF supports the IMS AKA using HTTP
Digest AKAv2 without IPSec security association, the
S-CSCF shall perform:
a) if the
REGISTER request does not contain an authentication challenge response, the
initial registration procedures for IMS-AKA authentication described in
subclauses 5.4.1.2.1 and 5.4.1.2.1A; or
b) if the
REGISTER request contains an authentication challenge response, the protected
registration procedures with IMS-AKA as a security mechanism as described in
subclause 5.4.1.2.2;
NOTE 1: 3GPP TS 33.203 [19] defines support of IMS
AKA using http Digest AKAv2 without IPSec security association only for WebRTC.
3) if the
REGISTER request does not contain an Authorization header field, then the
S-CSCF shall identify the user by the public user identity as received in the
To header field of the REGISTER request. The S-CSCF shall derive the private
user identity from the public user identity being registered. The S-CSCF shall
derive the private user identity by removing SIP URI
scheme and the following parts of the SIP URI
if present: port number, URI
parameters, and To header field parameters or by alternative mechanisms to derive
the private user identity if operator policy requires to do so. These alternative
mechanisms are not defined in this version of the specification;
4) if the
REGISTER request does not contain an Authorization header field and the access-type field in
the P-Access-Network-Info header field indicated xDSL, Ethernet, or Fiber access, and containing the "network
provided" header field parameter and the S-CSCF
supports NASS-IMS-bundled authentication but does not support SIP digest, then the S-CSCF shall perform the initial registration procedures
with NASS-IMS bundled authentication as a security mechanism as described in
subclause 5.4.1.2.1D;
5) if the
REGISTER request does not contain an Authorization header field and the access-type field in
the P-Access-Network-Info header field indicates it is received from an IP-CAN
different from 3GPP and
containing the "network provided" header field parameter and the
S-CSCF supports SIP digest but does not support NASS-IMS-bundled authentication, then the S-CSCF shall perform the initial registration procedures
with SIP digest as a security mechanism as described in subclauses 5.4.1.2.1 and 5.4.1.2.1B;
6) if the
REGISTER request does not contain an Authorization header field and there is no
P-Access-Network-Info header field containing the "network provided"
field or there is a P-Access-Network-Info header field indicating a 3GPP access
network containing the "network provided”, and the S-CSCF supports
GPRS-IMS-Bundled authentication, the S-CSCF shall perform the initial
registration procedures with GPRS-IMS-Bundled authentication described in
subclause 5.4.1.2.1E;
7) if the
REGISTER request does not contain an Authorization header field, and the
P-Access-Network-Info header field indicates it is received from an access network
other than 3GPP, xDSL, Ethernet or Fiber
and containing the "network provided" header field parameter, and the
S-CSCF supports SIP digest and NASS-IMS bundled authentication, the S-CSCF shall
perform the initial registration procedures with SIP digest as a security
mechanism as described in subclauses 5.4.1.2.1
and 5.4.1.2.1B:
8) if the
REGISTER request does not contain an Authorization header field, and the
P-Access-Network-Info header field indicates it is received from a xDSL,
Ethernet or Fiber access network, and containing the "network provided"
header field parameter, and the S-CSCF supports SIP digest and NASS-IMS bundled
authentication, the S-CSCF sends an authentication request for the user to the
HSS indicating that the authentication scheme is unknown as described in 3GPP
TS 29.228 [14]:
- if the
HSS responds with an authentication scheme of SIP digest, then the S-CSCF shall
perform the initial registration procedures with SIP digest as a security
mechanism as described in subclauses 5.4.1.2.1 and 5.4.1.2.1B; or
- if the
HSS responds with an authentication scheme of NASS-IMS bundled authentication
and the request was received from a P-CSCF in the home network and the P-CSCF
is "TISPAN-enabled", then the S-CSCF shall perform the initial registration
procedures with NASS-IMS bundled authentication as a security mechanism as
described in subclause 5.4.1.2.1D;
9) if the
REGISTER request contains an Authorization header field without an
"integrity-protected" header field parameter, the S-CSCF shall send
an authentication request for the user to the HSS indicating that the
authentication scheme is unknown as described in
3GPP TS 29.228 [14]:
- if the
HSS responds with an authentication scheme of NASS-IMS bundled authentication
and the request was received from a P-CSCF is in the home network and the
P-CSCF is "TISPAN-enabled", then the S-CSCF shall perform the initial
registration procedures with NASS-IMS bundled authentication as a security
mechanism as described in subclause 5.4.1.2.1D; or
- if the
HSS responds with an authentication scheme of SIP digest, then the S-CSCF shall
perform the initial registration procedures with SIP digest as a security
mechanism as described in subclauses 5.4.1.2.1 and 5.4.1.2.1B;
10) if the
REGISTER request contains an Authorization header field with the
"integrity-protected" header field parameter set to
"tls-pending", "tls-yes", "ip-assoc-pending" or
"ip-assoc-yes", the S-CSCF shall perform the protected registration
procedures for SIP digest described in subclause 5.4.1.2.2A;
11) if the
REGISTER request contains an Authorization header field with the
"integrity-protected" header field parameter set to
"auth-done", the S-CSCF shall perform the protected registration
procedures described in subclause 5.4.1.2.2E; and
12) if the
REGISTER request contains a JSON Web Token with the "3gpp-waf" JSON Web Token claim or with the "3gpp-wwsf" JSON
Web Token claim, as defined in RFC 7519 [235], and if the S-CSCF supports
WebRTC, and if the S-CSCF has received authorization
information about WAF or
WWSF entities from the HSS, or per configuration, then the
S-CSCF shall check whether
the WAF or WWSF is not barred, as specified in 3GPP TS 33.203 [9] annex X.
If the WAF or the WWSF is barred, the S-CSCF shall send a 403 (Forbidden) response to the
REGISTER request.
NOTE 2: The S-CSCF needs to be configured to know
which P-CSCFs are "TISPAN-enabled" and uses the Via header field to
determine which P-CSCF forwarded the registration request.
The S-CSCF shall act as the SIP registrar
for all UEs belonging to the IM CN subsystem and with public user identities.
Subclause 5.4.1.2 through
subclause 5.4.1.7 define S-CSCF procedures for SIP registration that do
not relate to emergency. All registration requests are first screened according
to the procedures of subclause 5.4.8.2 to see if they do relate to an
emergency registration.
For all SIP registrations identified:
- as
relating to an emergency; or
- if
priority is supported, as containing an authorised Resource-Priority header
field;
the S-CSCF shall give priority over other
registrations. This allows special treatment of such registrations.
NOTE 3: The special treatment can include filtering,
higher priority processing, routeing, call gapping. The exact meaning of
priority is not defined further in this document, but is left to national
regulation and network configuration.
The S-CSCF shall support the use of the
Path and Service-Route header field. The S-CSCF shall also support the Require
and Supported header fields. The Path header field is only applicable to the
REGISTER request and its 200 (OK) response. The Service-Route header field is
only applicable to the 200 (OK) response of REGISTER. The S-CSCF shall not act
as a redirect server for REGISTER requests.
The network operator defines minimum and
maximum times for each registration. These values are provided within the
S-CSCF.
The procedures for notification concerning
automatically registered public user identities of a user are described in
subclause 5.4.2.1.2.
If the S-CSCF supports HSS based P-CSCF
restoration procedures, and receives a REGISTER request from a P-CSCF that the
S-CSCF considers is in a non-working state, the S-CSCF shall consider this
P-CSCF as being in a working state.
If the S-CSCF supports PCRF based P-CSCF
restoration procedures, and receives a REGISTER request from a P-CSCF that the
S-CSCF considers is in a non-working state, the S-CSCF shall consider this
P-CSCF as being in a working state.
In case a device performing address and/or
port number conversions is provided by a NA(P)T
or NA(P)T-PT, the S-CSCF may need
to modify the SIP signalling according to the procedures described in
annex K if both a "reg-id" and "+sip.instance" header
field parameter are present in the received Contact header field as described
in RFC 5626 [92].
5.4.1.2.1 Unprotected REGISTER
Any REGISTER request received unprotected
by the S-CSCF without an Authorization header field, or with an Authorization
header field having the "integrity-protected" header field parameter
in the Authorization header field set to "no", or without an
"integrity-protected" header field parameter is considered to be an
initial registration. If such an initial registration contains a private user
identity specifically reserved for IM CN subsystem registrations from an MSC Server enhanced for ICS as defined in
3GPP TS 23.003 [3], the S-CSCF shall respond with a 403
(Forbidden) response. The S‑CSCF shall consider this registration attempt as
failed..
NOTE 1: For
NASS-IMS bundled authentication and GPRS-IMS-Bundled Authentication there is no
distinction between a protected and an unprotected REGISTER. There is only an
unprotected REGISTER to consider.
NOTE 2: If
IMS AKA or SIP digest with TLS are
used as a security mechanism, a 200 (OK) final response to an initial
registration will only be sent back after the S-CSCF receives a correct
authentication challenge response in a REGISTER request that is sent integrity
protected.
NOTE 3: A
REGISTER with the registration expiration interval value equal to zero will always
be received protected. However, it is possible that in error conditions a
REGISTER with the registration expiration interval value equal to zero can be
received unprotected. In that instance the procedures below will be applied.
Upon receipt of a REGISTER request that is
part of an initial registration as outlined above, for a public user identity for
which the maximum number of allowed simultaneously registration flows for the
used UE (i.e. linked to the same private user identity and instance ID) is
reached, if the REGISTER is adding a new registration flow, then the S-CSCF
shall reject the REGISTER by generating a 403 (Forbidden) response. If not, the
S-CSCF shall continue with the rest of the procedures of this subclause.
Upon receipt of a REGISTER request that is
part of an initial registration as outlined above, for a user identity linked
to a private user identity and instance ID/reg-id if available, that has previously
registered one or more public user identities, the S-CSCF shall:
1) perform
the procedure below in this subclause for receipt of a REGISTER request for a
public user identity which is not already registered, for the received public
user identity;
2) if the
multiple registrations is not used and if the authentication that in step 1) has
been successful, and there are public user identities (including the public
user identity being registered, if previously registered) that belong to this
user that have been previously registered with the same private user identity,
and with an old contact address different from the one received in the REGISTER
request, and the previous registrations have not expired, perform the network
initiated deregistration procedure (as described in subclause 5.4.1.5) for
the previously registered public user identities belonging to this user including
the public user identity being registered, if previously registered; and
3) if the
multiple registrations is used (i.e., the "reg-id" header field
parameter is included in the REGISTER request), and if the authentication that
concludes the initial registration has been successful, and if the public user identity
being registered has been previously registered with the same private user
identity and the same "+sip.instance" and "reg-id" header
field parameter values, and the previous registration has not expired:
a) identify
the registration flow being replaced;
b) terminate
any dialog, as specified in subclause 5.4.5.1.2, with a status code 480 (Temporarily Unavailable) in the Reason header
field of the BYE request, associated with the
registration flow being replaced; and
c) send a
NOTIFY request to the subscribers to the registration event package for the
public user identity indicated in the REGISTER request, as described in
subclause 5.4.2.1.2.
NOTE 4: The
way the S-CSCF identifies the dialogs associated with the registration flow
being replaced is
implementation specific.
NOTE 5: The
S-CSCF will inform the HSS that the previously registered public user
identities, excluding the public user identity being registered, have been
deregistered.
NOTE 6: Contact
related to emergency registration is not affected. S-CSCF is not able
deregister contact related to emergency registration and will not delete that.
When S-CSCF receives a REGISTER request
with the "integrity-protected" header field parameter in the
Authorization header field set to "no" and a non-empty "response"
Authorization header field parameter, the S-CSCF shall ignore the value of the "response"
header field parameter.
Upon receipt of a REGISTER request that is
part of an initial registration as outlined above, for a public user identity
which is not already registered linked to the same private user identity and the
"+sip.instance" and "reg-id" header field parameters, if
available, the S-CSCF shall:
1) identify
the user by the public user identity as received in the To header field and if
the REGISTER request includes an Authorization header field, identify the
private user identity as received in the "username" Authorization
header field parameter of the REGISTER request;
2) check
if the P-Visited-Network-ID header field is included in the REGISTER request,
and if it is included identify the visited network by the value of this header
field;
3) select
an authentication vector for the user. If no authentication vector for this
user is available, after the S-CSCF has performed the Authentication procedure
with the HSS, as described in 3GPP TS 29.228 [14], the S-CSCF
shall select an authentication vector as described in
3GPP TS 33.203 [19].
Prior
to performing Authentication procedure with the HSS, the S-CSCF decides which
HSS to query, possibly as a result of a query to the Subscription Locator
Functional (SLF) entity as
specified in 3GPP TS 29.228 [14] or use the value as received in
the P-User-Database header field in the REGISTER request as defined in
RFC 4457 [82];
NOTE 7: The
HSS address received in the response to SLF
query or as a value of P-User-Database header field can be used to address the
HSS of the public user identity in further queries.
NOTE 8: At
this point the S-CSCF informs the HSS, that the user currently registering will
be served by the S-CSCF by passing its SIP URI
to the HSS. This will be used by the HSS to direct all subsequent incoming initial
requests for a dialog or standalone transactions destined for this user to this
S-CSCF.
NOTE 9: When
passing its SIP URI to the HSS,
the S-CSCF may include in its SIP URI
the transport protocol and the port number where it wants to be contacted.
4) store
the "icid-value" header field parameter received in the
P-Charging-Vector header field;
5) challenge
the user by generating a 401 (Unauthorized) response for the received REGISTER
request appropriate to the security mechanism in use;
6) send
the so generated 401 (Unauthorized) response towards the UE, and if the URI in the first Path header field has an
"ob" SIP URI parameter,
include a Require header field with the option-tag "outbound" as
described in RFC 5626 [92]; and
7) start
timer reg-await-auth which guards the receipt of the next REGISTER request.
If the received REGISTER request indicates
that the challenge sent previously by the S-CSCF to the UE was deemed to be
invalid by the UE, the S-CSCF shall stop the timer reg-await-auth and proceed
as described in the subclause 5.4.1.2.3.
On sending a 401 (Unauthorized) response to
an unprotected REGISTER request, the S-CSCF shall populate the header fields as
follows:
1) a WWW-Authenticate header field which transports:
a) a
globally unique name of the S-CSCF in the "realm" header field
parameter;
b) the RAND and AUTN
parameters and optional server specific data for the UE in the "nonce"
header field parameter;
c) if the
REGISTER request does not contain an Authorization header field with the
"algorithm" header field parameter set to "AKAv2-SHA-256":
- the
security mechanism, which is "AKAv1-MD5", in the "algorithm"
header field parameter;
- the IK
(Integrity Key) parameter for the P-CSCF in the "ik" header field parameter
(see subclause 7.2A.1); and
- the CK
(Cipher Key) parameter for the P-CSCF in the "ck" header field parameter
(see subclause 7.2A.1); and
d) if the
REGISTER request does contain an Authorization header field with the
"algorithm" header field parameter set to "AKAv2-SHA-256",
and if the S-CSCF
supports the IMS AKA using HTTP Digest AKAv2 without IPSec security association:
- the
security mechanism, which is "AKAv2-SHA-256" in the "algorithm"
header field parameter.
The S-CSCF shall store the RAND
parameter used in the 401 (Unathorized) response for future use in case of a
resynchronisation. If a stored RAND
already exists in the S-CSCF, the S-CSCF shall overwrite the stored RAND with the RAND used in the most recent 401
(Unauthorized) response.
On sending a 401 (Unauthorized) response to
an unprotected REGISTER request, the S-CSCF shall populate the header fields as
follows:
1) a WWW-Authenticate header field as defined in RFC 2617 [21],
which transports:
- a
protection domain in the "realm" header field parameter;
- a "nonce"
header field parameter (generated by the S-CSCF);
- an "algorithm"
header field parameter; if the algorithm value is not provided in the
authentication vector, it shall have the value "MD5"; and
- a "qop"
header field parameter; if the qop value is not provided in the authentication
vector, it shall contain the value "auth".
The procedures for subclause 5.4.1.2.1B
apply.
NOTE: The
S-CSCF is not able to distinguish between SIP Digest with TLS and SIP Digest without TLS
for the case of an unprotected REGISTER request, therefore the procedures are
the same for both.
Upon receipt of a REGISTER request that is
determined to be NASS-IMS bundled authentication, for a user identity linked to
a private user identity that has a registered public user identity but with a
new contact address, the S-CSCF shall:
1) perform
the procedure for receipt of a REGISTER request without the
"integrity-protected" header field parameter in the Authorization
header field or without the Authorization header field, for the received public
user identity; and
2) if the
Contact header field of the REGISTER request does not contain a "reg-id"
header field parameter (i.e., the multiple registrations mechanism is not
used), and the authentication has been successful, and there are public user
identities (including the public user identity being registered, if previously
registered) belonging to this user that have been previously registered with
the same private user identity and with an old contact address different from
the one received in the REGISTER request and if the previous registration have
not expired:
a) terminate
all dialogs, if any, associated with the previously registered public user
identities (including the public user identity being registered, if previously
registered), with a status code 480
(Temporarily Unavailable) in the Reason header field of the BYE request, as specified in subclause 5.4.5.1.2;
b) send a
NOTIFY request, to the subscribers to the registration event package of the previously
registered public user identities, that indicates that all previously
registered public user identities (excluding the public user identity being
registered) belonging to this user identified with its private user identity, have
been deregistered, as described in subclause 5.4.2.1.2. For the public
user identity being registered, the NOTIFY request contains the new contact
information; and
NOTE 1: The
last dialog to be terminated will be the dialog established by the UE
subscribing to the reg event package. When sending the NOTIFY request to the UE
over this dialog, the S-CSCF will terminate this dialog by setting in the
NOTIFY request the Subscription-State header field to the value of
"terminated".
c) delete
all information associated with the previously registered public user
identities.
NOTE 2: Contact
related to emergency registration is not affected. The S-CSCF is not able to deregister
contact related to emergency registration and will not delete it.
Upon receipt of a REGISTER request that is
determined to be NASS-IMS bundled authentication, for a public user identity for
which the maximum number of allowed simultaneously registration flows is for
the used UE (i.e. linked to the same private user identity and instance ID) is
reached, if the REGISTER is adding a new registration flow, then the S-CSCF
shall reject the REGISTER by generating a 403 (Forbidden) response. If not, the
S-CSCF shall continue with the rest of the procedures of this subclause;
Upon receipt of a REGISTER request without
the "integrity-protected" header field parameter in the Authorization
header field or without an Authorization header field, which is not for an
already registered public user identity linked to the same private user
identity, the S-CSCF shall:
1) identify
the user by the public user identity as received in the To header field of the
REGISTER request and if the Authorization header field is present, the private
user identity as received in the Authorization header field of the REGISTER
request. If the Authorization header field is not present, the S-CSCF shall
derive the private user identity from the public user identity being registered
by removing SIP URI scheme and the
following parts of the SIP URI if
present: port number, URI
parameters, and To header field parameters;
2) check whether
one or more Line-Identifiers previously received over the Cx interface, and
stored as a result of a Authentication procedure with the HSS, are available
for the user. If not, the S-CSCF performs the Authentication procedure with the
HSS, as described in 3GPP TS 29.228 [14], in order to obtain
these Line-Identifiers;
3) in the
particular case where the S-CSCF received via the Cx interface one or more
Line-Identifiers, compare each of Line-Identifiers with the
"dsl-location", "eth-location" or "fiber-location"
parameter of the P-Access-Network-Info header field (if present and if it
includes the "network-provided" parameter):
- if one
of these match, the user is considered authenticated, behave as described in
step 5) to 11) of subclause 5.4.1.2.2;
- otherwise
i.e. if these do not match, return a 403 (Forbidden) response to the REGISTER
request; and
4) if no
Line-Identifier is received over the Cx interface, send a 500 (Server Internal
Error) response to the REGISTER request.
Upon receipt of a REGISTER request without
the "integrity-protected" header field parameter in the Authorization
header field or without an Authorization header field, for an already
registered public user identity linked to the same private user identity, and
for existing contact information, the S-CSCF shall behave as described in
subclause 5.4.1.2.2F.
Upon receipt of a REGISTER request without
an Authorization header field, the S-CSCF shall:
1) identify
the user by the public user identity as received in the To header field of the
REGISTER request. The S-CSCF shall derive the private user identity from the
public user identity being registered by removing URI
scheme and the following parts of the URI
if present: port number, URI
parameters, and To header field parameters;
1A) if
the maximum number of simultaneously registration flows allowed for the related
public user identity for the used UE (i.e. linked to the same private user identity
and instance ID) is reached, then the S-CSCF shall reject the REGISTER by
generating a 403 (Forbidden) response. If not, the S-CSCF shall continue with
the rest of the steps;
2) check
if the P-Visited-Network-ID header field is included in the REGISTER request,
and if it is included identify the visited network by the value of this header
field;
3) check
whether an IP address is stored for this UE. If no IP address (or prefix) is
stored for the UE, query the HSS as described in
3GPP TS 29.228 [14] with the derived private user identity and
the public user identity as input and store the received IP address (or prefix)
of the UE; if the S-CSCF receives a prefix from the HSS, it will only check
against prefixes otherwise it will check against the full IP address;
NOTE 1: At
this point the S-CSCF informs the HSS, that the user currently registering will
be served by the S‑CSCF by passing its SIP URI
to the HSS. This will be indicated by the HSS for all further incoming requests
to this user, in order to direct all these requests directly to this S-CSCF.
4) check
whether a "received" header field parameter exists in the Via header
field provided by the UE. If a "received" header field parameter
exists, the S-CSCF shall compare the IP address recorded in the
"received" header field parameter against the UE's IP address stored
during registration. In case of IPv6 stateless autoconfiguration, the S-CSCF
shall compare the prefix of the IP address recorded in the "received"
header field parameter against the UE's IP address prefix stored during
registration. If no "received" header field parameter exists in the
Via header field provided by the UE, then the S-CSCF shall compare IP address
recorded in the "sent-by" parameter against the stored UE IP address.
In case of IPv6 stateless autoconfiguration, S-CSCF shall compare the prefix of
the IP address recorded in the "sent-by" parameter against the UE's
IP address prefix stored during registration. In any case, if the stored IP
address (or prefix) and the (prefix of the) IP address recorded in the Via
header field provided by the UE do not match, the S‑CSCF shall query the HSS as
described in 3GPP TS 29.228 [14] with the derived private user identity and the
public user identity as input and store the received IP address (or prefix) of
the UE. If the stored IP address (or prefix) and the (prefix of the) IP address
recorded in the Via header field provided by the UE still do not match the
S-CSCF shall reject the registration with a 403 (Forbidden) response and skip
the following steps;
5) after
performing the S-CSCF Registration/deregistration notification procedure with
the HSS, as described in 3GPP TS 29.228 [14], store the
following information in the local data:
a) the
list of public user identities, including the registered own public user
identity and its associated set of implicitly registered public user identities
and wildcarded public user identities due to the received REGISTER request.
Each public user identity is identified as either barred or non-barred;
b) all the
service profile(s) corresponding to the public user identities being registered
(explicitly or implicitly), including initial Filter Criteria (the initial
Filter Criteria for the Registered and common parts is stored and the
unregisterd part is retained for possible use later - in the case the S-CSCF is
retained if the user becomes unregistered);
c) if S-CSCF
restoration procedures are supported, the restoration information if received
as specified in 3GPP TS 29.228 [14]; and
d) if PCRF based
P-CSCF restoration procedures are supported, all the user
profile(s) corresponding to the public user identities being registered
(explicitly or implicitly), including the IMSI, if available;
NOTE 2: There
might be more than one set of initial Filter Criteria received because some
implicitly registered public user identities that are part of the same implicit
registration set belong to different service profiles.
6) update
registration bindings as follows:
a) bind to
each non-barred registered public user identity all registered contact
information including all header field parameters contained in the Contact
header field and all associated URI
parameters with the exception of the "pub-gruu" and
"temp-gruu" header field parameters as specified in RFC 5627 [93],
and store information for future use; and
b) if the
Contact URI in the Contact header
field does not contain a "bnc" URI
parameter, then for each binding that contains a "+sip.instance"
Contact header field parameter, assign a new temporary GRUU, as specified in
subclause 5.4.7A.3;
NOTE 3: There
might be more than one contact information available for one public user
identity.
NOTE 4: The
barred public user identities are not bound to the contact information.
7) check
whether a Path header field was included in the REGISTER request and construct
a list of preloaded Route header fields from the list of entries in the
received Path header field. The S-CSCF shall preserve the order of the
preloaded Route header fields and bind them either to the contact address of
the UE or to the registration flow and the associated contact address (if the
multiple registration mechanism is used) and the contact information that was
received in the REGISTER request;
NOTE 5: If
this registration is a reregistration or an initial registration (i.e., there
are previously registered public user identities belonging to the user that
have not been deregistered or expired), then a list of pre-loaded Route header
fields will already exist. If multiple registration mechanism was not used,
then the existing list of pre-loaded Route header fields is bound to a
respective contact address of the UE. However, if multiple registration mechanism
was used, then the existing list of pre-loaded Route header fields is bound to
a registration flow and the associated contact address that was used to send
the REGISTER request. In either case, the new list replaces the old list.
8) determine
the duration of the registration by checking the registration expiration
interval value in the received REGISTER request and bind it either to the
respective contact address of the UE or to the registration flow and the
associated contact address (if the multiple registration mechanism is used). Based
on local policy, the S-CSCF may reduce the duration of the registration or send
back a 423 (Interval Too Brief) response specifying the minimum allowed time
for registration. The local policy can take into account specific criteria such
as the used authentication mechanism to determine the allowed registration
duration;
9) store
the "icid-value" header field parameter received in the
P-Charging-Vector header field;
9A) if an "orig-ioi"
header field parameter is received in the P-Charging-Vector header field, store
the value of the received "orig-ioi" header field parameter; and
NOTE 6: Any received "orig-ioi" header
field parameter will be a type 1 IOI. The type 1 IOI identifies the network
from which the request was sent.
10) create
and send a 200 (OK) response for the REGISTER request as specified in
subclause 5.4.1.2.2F.
When a user de-registers, or is
de-registered by the HSS, the S-CSCF shall delete the IP address stored for the
UE.
Upon receipt of a REGISTER request with the
"integrity-protected" header field parameter in the Authorization
header field set to "yes" or to "tls-connected", the S-CSCF
shall identify the user by the public user identity as received in the To
header field and the private user identity as received in the Authorization
header field of the REGISTER request, and:
If the maximum number of simultaneously
registration flows allowed for the related public user identity for the used UE
(i.e. linked to the same private user identity and instance ID) is reached,
then the S-CSCF shall reject the REGISTER by generating a 403 (Forbidden)
response. If not, the S-CSCF shall continue with rest of the procedures of this
subclause;
In the case that there is no authentication
currently ongoing for this user (i.e. no timer reg-await-auth is running):
1) check
if the user needs to be reauthenticated.
The S-CSCF may require
authentication of the user for any REGISTER request, and shall always require
authentication for REGISTER requests received without the
"integrity-protected" header field parameter in the Authorization
header field set to "yes" or "tls-connected".
If the user needs to be
reauthenticated, the S-CSCF shall proceed with the procedures as described for
the unprotected REGISTER in subclause 5.4.1.2.1, beginning with step 3).
If the user does not need to be reauthenticated, the S-CSCF shall proceed with
the following steps in this paragraph; and
2) check
whether a registration expiration interval value is included in the REGISTER
request and its value. If the registration expiration interval value indicates
a zero value, the S-CSCF shall perform the deregistration procedures as
described in subclause 5.4.1.4. If the registration expiration interval
value does not indicate zero, the S-CSCF:
- if the REGISTER request does not contain a
"reg-id" header field parameter and the contact address indicated in
the Contact header field was not previously registered, send a 403 (Forbidden) response to the UE; and
NOTE 1: New
contact address is always registered via an initial registration.
3) check
whether the public user identity received in the To header field is already
registered. If it is not registered, the S-CSCF shall proceed beginning with
step 4B below. Otherwise, the S-CSCF shall:
- send a 439 (First Hop Lacks Outbound
Support) response to the UE, if the REGISTER request contains the
"reg-id" Contact header field parameter and the "outbound"
option tag in a Supported header field, but the first URI
in the Path header field does not have an "ob" URI parameter; or
- otherwise
proceed beginning with step 6 below.
In the case that a timer
reg-await-auth is running for this user the S-CSCF shall:
1) check
if the Call-ID of the request matches with the Call-ID of the 401
(Unauthorized) response which carried the last challenge. The S-CSCF shall only
proceed further if the Call-IDs match;
2) stop
timer reg-await-auth;
3) check
whether an Authorization header field is included, containing:
a) the
private user identity of the user in the "username" header field
parameter;
b) if the
"integrity-protected" header field parameter is set to "yes",
the "algorithm" header field parameter set to "AKAv1-MD5"
c) if the
"integrity-protected" header field parameter is set to "tls-connected",
the "algorithm" header field parameter set to "AKAv2-SHA-256"
if the S-CSCF supports
the IMS AKA using HTTP Digest AKAv2 without IPSec security association; and
d) the
authentication challenge response needed for the authentication procedure in
the "response" header field parameter.
The S-CSCF shall only
proceed with the following steps in this paragraph if the authentication
challenge response was included;
4) check
whether the received authentication challenge response and the expected
authentication challenge response (calculated by the S-CSCF using XRES and
other parameters as described in RFC 3310 [49] when AKAv1 is used or
as described in RFC 4169 [227] when AKAv2 is used) match. The XRES
parameter was received from the HSS as part of the Authentication Vector. The
S-CSCF shall only proceed with the following steps if the challenge response
received from the UE and the expected response calculated by the S-CSCF match;
4A) if
the Contact header field of the REGISTER request does not contain a "reg-id"
header field parameter (i.e., the multiple registrations mechanism is not
used), and there are public user identities (including the public user identity
being registered, if previously registered) that belong to this user that have
been previously registered with the same private user identity, and with an old
contact address different from the one received in the REGISTER request and if
the previous registrations have not expired:
a) terminate
all dialogs, associated with the previously registered public user identities
(including the public user identity being registered, if previously
registered), with a status code 480
(Temporarily Unavailable) in the Reason header field of the BYE request, as specified in subclause 5.4.5.1.2;
b) send a
NOTIFY request, to the subscribers to the registration event package of the previously
registered public user identities, that indicates that all previously
registered public user identities (excluding the public user identity being
registered) belonging to this user identified with its private user identity, have
been deregistered, as described in subclause 5.4.2.1.2. For the public
user identity being registered, the NOTIFY request contains the new contact
information; and
NOTE 2: The
last dialog to be terminated will be the dialog established by the UE
subscribing to the reg event package. When sending the NOTIFY request to the UE
over this dialog, the S-CSCF will terminate this dialog by setting in the
NOTIFY request the Subscription-State header field to the value of
"terminated".
c) delete
all information associated with the previously registered public user
identities;
NOTE 3: Contact
related to emergency registration is not affected. The S-CSCF is not able to deregister
contact related to emergency registration and will not delete it.
4B) if the REGISTER request
contains the "reg-id" Contact header field parameter and the
"outbound" option tag in a Supported header field, but the first URI in the Path header field does not have an
"ob" URI parameter, send
a 439 (First Hop Lacks Outbound Support) response to the UE;
5) after
performing the S-CSCF Registration/deregistration notification procedure with
the HSS, as described in 3GPP TS 29.228 [14], store the
following information in the local data:
a) the
list of public user identities, including the registered own public user
identity and its associated set of implicitly registered public user identities
and wildcarded public user identities due to the received REGISTER request.
Each public user identity is identified as either barred or non-barred;
b) all the
service profile(s) corresponding to the public user identities being registered
(explicitly or implicitly), including initial Filter Criteria(the initial
Filter Criteria for the Registered and common parts is stored and the unregistered
part is retained for possible use later - in the case of the S-CSCF is retained
if the user becomes unregistered);
c) if S-CSCF
restoration procedures are supported, the restoration information if received
as specified in 3GPP TS 29.228 [14]; and
d) if PCRF based
P-CSCF restoration procedures are supported, all the user
profile(s) corresponding to the public user identities being registered
(explicitly or implicitly), including the IMSI, if available;
NOTE 4: There
might be more than one set of initial Filter Criteria received because some
implicitly registered public user identities that are part of the same implicit
registration set belong to different service profiles.
6) update
registration bindings:
a) if the
Contact URI in the Contact header
field does not contains a "bnc" URI
parameter, then bind to each non-barred registered public user identity all
registered contact information including all header field parameters contained
in the Contact header field and all associated SIP URI
parameters, with the exception of the "pub-gruu" and "temp-gruu"
header field parameters as specified in RFC 5627 [93], and store
information for future use;
b) if the
Contact URI in the Contact header
field contains a "bnc" URI
parameter, as a network option bind each non-barred registered public user
identity to a contact address generated according to the procedures of
RFC 6140 [191].
NOTE 5: It
is assumed that when the Contact header field contains a "bnc"
parameter, the associated public user identities obtained from the HSS are all
of a form compatible with registration procedures as specified in
RFC 6140 [191]; i.e. the set consists only of distinct public user
identities contain global numbers in the international format or wildcarded
public user identities representing multiple global numbers in the
international format. The S-CSCF procedures for handling the error case where
an associated public user identity is incompatible with
RFC 6140 [191] is out of scope of this specification.
c) if the
Contact URI in the Contact header
field does not contain a "bnc" URI
parameter, then for each binding that contains a "+sip.instance"
Contact header field parameter, assign a new temporary GRUU, as specified in
subclause 5.4.7A.3;
d) if the Contact
header field of the REGISTER request contained a "+sip.instance" and
a "reg-id" header field parameter, and the SIP URI
in the Path header field inserted by the P-CSCF contained an "ob" SIP
URI parameter header field, and:
- if the public
user identity has not previously been registered with the same "+sip.instance"
and "reg-id" Contact header field parameter values, then create the registration
flow in addition to any existing registration flow; or
- if the public
user identity has previously been registered with the same "+sip.instance"
and "reg-id" header field parameter values, then determine whether
the request refreshes or replaces an existing registration flow. If the request:
i) refreshes
an existing registration flow, then the S-CSCF shall leave the flow intact; or
ii) replaces
the existing registration flow with a new flow, then the S-CSCF shall:
a) terminate
any dialog, as specified in subclause 5.4.5.1.2, with a status code 480 (Temporarily Unavailable) in the Reason header
field of the BYE request, associated with the
registration flow being replaced; and
b) send a
NOTIFY request to the subscribers to the registration event package for the
public user identity indicated in the REGISTER request, as described in
subclause 5.4.2.1.2;
NOTE 6: The
S-CSCF determines whether this REGISTER request replaces or refreshes an
existing registration flow by examining the SIP URI
in the Path header field inserted into the request by the P-CSCF (see subclause 5.2.2.1).
NOTE 7: The
way the S-CSCF identifies the dialogs associated with the registration flow
being replaced is
implementation specific.
NOTE 8: There
might be more than one contact information available for one
public user identity.
NOTE 9: The
barred public user identities are not bound to the contact information.
NOTE 10: Contact
related to emergency registration is not affected. S-CSCF is not able
deregister contact related to emergency registration and will not delete that.
7) check
whether a Path header field was included in the REGISTER request and construct
a list of preloaded Route header fields from the list of entries in the
received Path header field. The S-CSCF shall preserve the order of the
preloaded Route header fields and bind them either to the contact address of
the UE or the registration flow and the associated contact address (if the
multiple registration mechanism is used) and the contact information that was
received in the REGISTER request;
NOTE 11: If
this registration is a reregistration or an initial registration (i.e., there
are previously registered public user identities belonging to the user that
have not been deregistered or expired), then a list of pre-loaded Route header
fields will already exist. If multiple registration mechanism was not used,
then the existing list of pre-loaded Route header fields is bound to a
respective contact address of the UE. However, if multiple registration mechanism
was used, then the existing list of pre-loaded Route header fields is bound to
a registration flow and the associated contact address that was used to send
the REGISTER request. In either case, the new list replaces the old list.
8) determine
the duration of the registration by checking the value of the registration
expiration interval value in the received REGISTER request and bind it either
to the respective contact address of the UE or to the registration flow and the
associated contact address (if the multiple registration mechanism is used). Based
on local policy, the S-CSCF may reduce the duration of the registration or send
back a 423 (Interval Too Brief) response specifying the minimum allowed time
for registration. The local policy can take into account specific criteria such
as the used authentication mechanism to determine the allowed registration
duration;
9) store
the "icid-value" header field parameter received in the
P-Charging-Vector header field;
10) if an "orig-ioi"
header field parameter is received in the P-Charging-Vector header field, store
the value of the received "orig-ioi" header field parameter; and
NOTE 12: Any
received "orig-ioi" header field parameter will be a type 1 IOI. The
type 1 IOI identifies the network from which the request was sent.
11) create and
send a 200 (OK) response for the REGISTER request as specified in
subclause 5.4.1.2.2F.
Upon receipt of a REGISTER request with the
"integrity-protected" header field parameter in the Authorization
header field set to "tls-pending", "tls-yes",
"ip-assoc-pending", or "ip-assoc-yes", the S-CSCF shall
identify the user by the public user identity as received in the To header field
and the private user identity as received in the Authorization header field of
the REGISTER request, and:
NOTE: Although the REGISTER request with the "integrity-protected" header field parameter set to "ip-assoc-pending" or "ip-assoc-yes" is handled as protected
REGISTER request, the integrity of the request is actually not protected by SIP
digest.
If the maximum number of simultaneously
registration flows allowed for the related public user identity for the used UE
(i.e. linked to the same private user identity and instance ID) is reached,
then the S-CSCF shall reject the REGISTER by generating a 403 (Forbidden)
response. If not, the S-CSCF shall continue with rest of the procedures of this
subclause;
In the case that there is no authentication
currently ongoing for this user (i.e. no timer reg-await-auth is running):
1) check
if the user needs to be reauthenticated. The S-CSCF may require authentication
of the user for any REGISTER request, and shall always require authentication
for REGISTER requests received without the "integrity-protected" header
field parameter in the Authorization header field set to "tls-yes".
If the
user needs to be reauthenticated and the REGISTER did not include an
Authorization header field with a digest response, the S-CSCF shall proceed
with the authentication procedures as described for the initial REGISTER in
subclause 5.4.1.2.1 and subclause 5.4.1.2.1B.
If the
user needs to be reauthenticated and the REGISTER included an Authorization
header field with a digest response, the S-CSCF shall proceed with the
authentication procedures as described for the initial REGISTER in subclause 5.4.1.2.1
and subclause 5.4.1.2.1B and include the "stale" header field parameter
with value "true" in the WWW-Authenticate
header field.
In the case that a timer reg-await-auth is
running for this user the S-CSCF shall:
1) check
if the Call-ID of the request matches with the Call-ID of the 401
(Unauthorized) response which carried the last challenge. The S-CSCF shall only
proceed further if the Call-IDs match;
2) stop
timer reg-await-auth;
3) in the
case the algorithm is "MD5", check the following additional fields:
- a "realm"
header field parameter matching the "realm" header field parameter in
the authentication challenge;
- an "algorithm"
header field parameter which matches the "algorithm" header field
parameter sent in the authentication challenge;
- "nonce"
header field parameter matching the "nonce" header field parameter in
the authentication challenge;
- a "cnonce"
header field parameter; and
- a
nonce-count field.
The
S-CSCF shall only proceed with the following steps in this paragraph if the
authentication challenge response was included;
4) check
whether the received authentication challenge response and the expected
authentication challenge response match. The expected response is calculated by
the S-CSCF as described in RFC 2617 [21] using the H(A1) value
provided by the HSS. If the received authentication challenge response and the
expected authentication challenge response match, then the UE is considered
authenticated. If the UE is considered authenticated, and if the "integrity-protected"
header field parameter in the Authorization header field is set to the value
"tls-pending" or "tls-yes", then the S-CSCF shall associate
the registration with the local state of "tls-protected";
NOTE 1: The
S-CSCF can have a local security policy to treat messages other than initial
REGISTER requests, messages relating to emergency services, and error messages,
differently depending on whether the registration is associated with the state
"tls-protected".
4A) if the REGISTER request
contains the "reg-id" Contact header field parameter and the
"outbound" option tag in a Supported header field, but the first URI in the Path header does not have an
"ob" URI parameter, send
a 439 (First Hop Lacks Outbound Support) response to the UE;
5) after
performing the S-CSCF Registration/deregistration notification procedure with
the HSS, as described in 3GPP TS 29.228 [14], store the
following information in the local data:
a) the
list of public user identities, including the registered own public user
identity and its associated set of implicitly registered public user identities
and wildcarded public user identities due to the received REGISTER request.
Each public user identity is identified as either barred or non-barred;
b) all the
service profile(s) corresponding to the public user identities being registered
(explicitly or implicitly), including initial Filter Criteria(the initial
Filter Criteria for the Registered and common parts is stored and the
unregistered part is retained for possible use later - in the case of the
S-CSCF is retained if the user becomes unregistered);
c) if S-CSCF
restoration procedures are supported, the restoration information, if received,
as specified in 3GPP TS 29.228 [14]; and
d) if PCRF based
P-CSCF restoration procedures are supported, all the user
profile(s) corresponding to the public user identities being registered
(explicitly or implicitly), including the IMSI, if available;
NOTE 2: There
might be more than one set of initial Filter Criteria received because some
implicitly registered public user identities that are part of the same implicit
registration set belong to different service profiles.
6) update
registration bindings:
a) if the
Contact URI in the Contact header
field does not contains a "bnc" URI
parameter, then bind to each non-barred registered public user identity all
registered contact information including all header field parameters contained
in the Contact header field and all associated URI
parameters, with the exception of the "pub-gruu" and
"temp-gruu" header field parameters as specified in RFC 5627 [93],
and store information for future use;
b) if the
Contact URI in the Contact header
field contains a "bnc" URI
parameter, as a network option bind each non-barred registered public user
identity to a contact address as specified in RFC 6140 [191].
NOTE 3: It
is assumed that when the Contact header field contains a "bnc"
parameter, the associated public user identities obtained from the HSS are all
of a form compatible with registration procedures as specified in
RFC 6140 [191]; i.e. the set consists only of distinct public user
identities contain global numbers in the international format or wildcarded public
user identities representing multiple global numbers in the international
format. The S-CSCF procedures for handling the error case where an associated
public user identity is incompatible with RFC 6140 [191] is out of
scope of this specification.
c) if the
Contact URI in the Contact header
field does not contain a "bnc" URI
parameter, then for each binding that contains a "+sip.instance"
Contact header field parameter, assign a new temporary GRUU, as specified in
subclause 5.4.7A.3;
d) if the
Contact header field of the REGISTER request does not contain a "reg-id"
header field parameter (i.e., the multiple registrations mechanism is not
used), and there are public user identities (including the public user identity
being registered, if previously registered) that belong to this user that have
been previously registered with the same private user identity, and with an old
contact address different from the one received in the REGISTER request and if
the previous registrations have not expired:
- terminate
all dialogs, associated with the previously registered public user identities
(including the public user identity being registered, if previously
registered), with a status code 480
(Temporarily Unavailable) in the Reason header field of the BYE request, as specified in subclause 5.4.5.1.2;
- send a
NOTIFY request, to the subscribers to the registration event package of the previously
registered public user identities, that indicates that all previously
registered public user identities (excluding the public user identity being
registered) belonging to this user identified with its private user identity, have
been deregistered, as described in subclause 5.4.2.1.2. For the public
user identity being registered, the NOTIFY request contains the new contact
information; and
NOTE 4: The
last dialog to be terminated will be the dialog established by the UE
subscribing to the reg event package. When sending the NOTIFY request to the UE
over this dialog, the S-CSCF will terminate this dialog by setting in the
NOTIFY request the Subscription-State header field to the value of
"terminated".
- delete
all information associated with the previously registered public user
identities;
NOTE 5: Contact
related to emergency registration is not affected. The S-CSCF is not able to
deregister contact related to emergency registration and will not delete it.
e) if the Contact
header field of the REGISTER request contained a "+sip.instance" and
a "reg-id" header field parameter, and the SIP URI
in the Path header field inserted by the P-CSCF contained an "ob" SIP
URI parameter header field, and:
- if the public
user identity has not previously been registered with the same "+sip.instance"
and "reg-id" Contact header field parameter values, then create the registration
flow in addition to any existing registration flow; or
- if the public
user identity has previously been registered with the same "+sip.instance"
and "reg-id" header field parameter values, then determine whether
the request refreshes or replaces an existing registration flow. If the request:
i) refreshes
an existing registration flow, then the S-CSCF shall leave the flow intact; or
ii) replaces
the existing registration flow with a new flow, then the S-CSCF shall:
a) terminate
any dialog, as specified in subclause 5.4.5.1.2, with a status code 480 (Temporarily Unavailable) in the Reason header
field of the BYE request, associated with the
registration flow being replaced; and
b) send a
NOTIFY request to the subscribers to the registration event package for the
public user identity indicated in the REGISTER request, as described in
subclause 5.4.2.1.2; and
f) store
the used nonce as a valid nonce for this registration or registration flow (if
multiple registration mechanism is used) for an operator configured duration.
NOTE 6: The
S-CSCF determines whether this REGISTER request replaces or refreshes an
existing registration flow by examining the SIP URI
in the Path header field inserted into the request by the P-CSCF (see
subclause 5.2.2.1).
NOTE 7: The
way the S-CSCF identifies the dialogs associated with the registration flow
being replaced is
implementation specific.
NOTE 8: There
might be more than one contact information available for one public user identity.
NOTE 9: The
barred public user identities are not bound to the contact information.
NOTE 10: Contact
related to emergency registration is not affected. S-CSCF is not able
deregister contact related to emergency registration and will not delete that.
7) check
whether a Path header field was included in the REGISTER request and construct
a list of preloaded Route header fields from the list of entries in the
received Path header field. The S-CSCF shall preserve the order of the
preloaded Route header fields and bind them to either the contact address of
the UE or the registration flow and the associated contact address (if the
multiple registration mechanism is used) and contact information that was
received in the REGISTER request;
NOTE 11: If
this registration is a reregistration or an initial registration (i.e., there
are previously registered public user identities belonging to the user that
have not been deregistered or expired), then a list of pre-loaded Route header
fields will already exist. If multiple registration mechanism was not used,
then the existing list of pre-loaded Route header fields is bound to a
respective contact address of the UE. However, if multiple registration mechanism
was used, then the existing list of pre-loaded Route header fields is bound to
a registration flow and the associated contact address that was used to send
the REGISTER request. In either case, the new list replaces the old list.
8) determine
the duration of the registration by checking the value of the registration
expiration interval value in the received REGISTER request and bind it either
to the respective contact address of the UE or to the registration flow and the
associated contact address (if the multiple registration mechanism is used). Based
on local policy, the S-CSCF may reduce the duration of the registration or send
back a 423 (Interval Too Brief) response specifying the minimum allowed time
for registration. The local policy can take into account specific criteria such
as the used authentication mechanism to determine the allowed registration
duration;
9) store
the "icid-value" header field parameter received in the
P-Charging-Vector header field;
10) if an "orig-ioi"
header field parameter is received in the P-Charging-Vector header field, store
the value of the received "orig-ioi" header field parameter; and
NOTE 12: Any
received "orig-ioi" header field parameter will be a type 1 IOI. The
type 1 IOI identifies the network from which the request was sent.
11) create and
send a 200 (OK) response for the REGISTER request as specified in
subclause 5.4.1.2.2F. The S-CSCF shall also store the nonce-count value in
the received REGISTER request and include an Authentication-Info header field containing
the fields described in RFC 2617 [21] as follows:
- a "nextnonce"
header field parameter if the S-CSCF requires a new nonce for subsequent
authentication responses from the UE. In that case, the S-CSCF shall consider
this nonce as a valid nonce for this registration or registration flow (if
multiple registration mechanism is used) for an operator configured duration;
- a "qop"
header field parameter matching the "qop" Authorization header field parameter
sent by the UE;
- a "rspauth"
header field parameter with a response-digest calculated as described in
RFC 2617 [21];
- a "cnonce"
header field parameter value matching the cnonce in the Authorization header field
sent by the UE; and
- a "nonce-count"
header field parameter matching the "nonce-count" Authorization
header field parameter sent by the UE.
The procedures for subclause 5.4.1.2.2A
apply.
There is no protected REGISTER when
NASS-IMS bundled authentication is used as a security mechanism. The procedures
of subclause 5.4.1.2.1D apply to all REGISTER requests.
There is no protected REGISTER when
GPRS-IMS-Bundled authentication is used as a security mechanism. The procedures
of subclause 5.4.1.2.1E apply to all REGISTER requests.
The S-CSCF shall not perform authentication
of the user for any REGISTER request with the "integrity-protected" header
field parameter in the Authorization header set to "auth-done".
In this release of this document, when the
registration procedure as specified in this subclause is performed, i.e., the
REGISTER request contains the "integrity-protected" header field parameter
in the Authorization header set to "auth-done", the S-CSCF shall not
employ outbound registration as described in RFC 5626 [92].
Upon receipt of a REGISTER request with the
"integrity-protected" header field parameter in the Authorization
header set to "auth-done", the S-CSCF shall identify the user by the
public user identity as received in the To header field and the private user
identity as received in the Authorization header field of the REGISTER request.
In addition the S-CSCF shall check whether a
registration expiration interval value is included in the REGISTER request and
its value. If the registration expiration interval value indicates a zero
value, the S-CSCF shall perform the deregistration procedures as described in
subclause 5.4.1.4. If the registration expiration interval value does not
indicate zero, the S-CSCF shall:
1) if the REGISTER request
contains the "reg-id" header field parameter in the Contact header
field, respond with a 403 (Forbidden) response to the REGISTER request; and
2) if
there are public user identities (including the public user identity being
registered, if previously registered) that belong to this user that have been
previously registered with the same private user identity, and with an old
contact address different from the one received in the REGISTER request and if
the previous registrations have not expired:
a) terminate
all dialogs, associated with the previously registered public user identities
(including the public user identity being registered, if previously
registered), with a status code 480
(Temporarily Unavailable) in the Reason header field of the BYE request, as specified in subclause 5.4.5.1.2;
b) send a
NOTIFY request, to the subscribers to the registration event package of the previously
registered public user identities, that indicates that all previously registered
public user identities (excluding the public user identity being registered)
belonging to this user identified with its private user identity, have been
deregistered, as described in subclause 5.4.2.1.2. For the public user
identity being registered, the NOTIFY request contains the new contact
information; and
NOTE 1: The
last dialog to be terminated will be the dialog established by the user
(identified with its private user identity) subscribing to its own reg event
package using the old contact address. When sending the NOTIFY request over this
dialog, the S-CSCF will terminate this dialog by setting in the NOTIFY request the
Subscription-State header field to the value of "terminated".
c) delete
all information associated with the previously registered public user
identities;
Subsequently, the S-CSCF shall check
whether the public user identity received in the To header field is already
registered. If it is not registered, the S-CSCF shall proceed beginning with
step 1 below. Otherwise, the S-CSCF shall proceed beginning with step 2 below.
1) after
performing the S-CSCF Registration/deregistration notification procedure with
the HSS, as described in 3GPP TS 29.228 [14], store the
following information in the local data:
a) the
list of public user identities, including the registered own public user
identity and its associated set of implicitly registered public user identities
and wildcarded public user identities due to the received REGISTER request.
Each public user identity is identified as either barred or non-barred;
b) all the
service profile(s) corresponding to the public user identities being registered
(explicitly or implicitly), including initial Filter Criteria(the initial
Filter Criteria for the Registered and common parts is stored and the unregistered part is
retained for possible use later - in the case of the S-CSCF is retained if the
user becomes unregistered); and
c) if PCRF based
P-CSCF restoration procedures are supported, all the user
profile(s) corresponding to the public user identities being registered
(explicitly or implicitly), including the IMSI, if available;
NOTE 2: There
might be more than one set of initial Filter Criteria received because some
implicitly registered public user identities that are part of the same implicit
registration set belong to different service profiles.
2) update
registration bindings:
a) if the
Contact URI in the Contact header
field does not contains a "bnc" URI
parameter, then bind to each non-barred registered public user identity all
registered contact information including all header parameters contained in the
Contact header and all associated URI
parameters, with the exception of the URI
"pub-gruu" and "temp-gruu" parameters as specified in RFC 5627 [93],
and store information for future use;
b) if the
Contact URI in the Contact header
field contains a "bnc" URI
parameter, as a network option bind each non-barred registered public user
identity to a contact address as specified in RFC 6140 [191].
NOTE 3: It
is assumed that when the Contact header field contains a "bnc"
parameter, the associated public user identities obtained from the HSS are all
of a form compatible with registration procedures as specified in
RFC 6140 [191]; i.e. the set consists only of distinct public user identities
contain global numbers in the international format or wildcarded public user
identities representing multiple global numbers in the international format.
The S-CSCF procedures for handling the error case where an associated public
user identity is incompatible with RFC 6140 [191] is out of scope of
this specification.
c) if the
Contact URI in the Contact header
field does not contain a "bnc" URI
parameter, then for each binding that contains a "+sip.instance"
header field parameter, assign a new temporary GRUU, as specified in
subclause 5.4.7A.3.
NOTE 4: There
might be more than one contact information available for one public user identity.
NOTE 5: The
barred public user identities are not bound to the contact information.
3) check
whether a Path header was included in the REGISTER request and construct a list
of preloaded Route headers from the list of entries in the received Path header
field. The S-CSCF shall preserve the order of the preloaded Route header fields
and bind them to the contact information that was received in the REGISTER request;
NOTE 6: If
this registration is a reregistration or an initial registration (i.e., there
are previously registered public user identities belonging to the user that
have not been deregistered or expired), then a list of pre-loaded Route headers
will already exist. The new list replaces the old list.
4) determine
the duration of the registration by checking the value of the registration
expiration interval value in the received REGISTER request. Based on local
policy, the S-CSCF may reduce the duration of the registration or send back a
423 (Interval Too Brief) response specifying the minimum allowed time for
registration. The local policy can take into account specific criteria such as
the used authentication mechanism to determine the allowed registration
duration;
5) store
the "icid-value" header field parameter received in the
P-Charging-Vector header;
6) if an "orig-ioi"
header field parameter is received in the P-Charging-Vector header, store the
value of the received "orig-ioi" header field parameter; and
NOTE 7: Any
received "orig-ioi" header field parameter will be a type 1 IOI. The
type 1 IOI identifies the network from which the request was sent.
7) create and
send a 200 (OK) response for the REGISTER request as specified in
subclause 5.4.1.2.2F.
If a 200 (OK) response is to be sent for a
REGISTER request, the S-CSCF shall, in addition to any contents identified
elsewhere in subclause 5.4.1.2, include:
a) the
list of received Path header fields;
b) a
P-Associated-URI header field containing
the list of the registered distinct public user identity and its associated set
of implicitly registered distinct public user identities. The first URI in the list of public user identities supplied by
the HSS to the S-CSCF will indicate the default public user identity to be used
by the S-CSCF. The public user identity indicated as the default public user
identity must be a registered public user identity. The S-CSCF shall place the
default public user identity as the first entry in the list of URIs present in
the P-Associated-URI header field.
The default public user identity will be used by the P-CSCF in conjunction with
the procedures for the P-Asserted-Identity header field, as described in subclause 5.2.6.3.
If the S-CSCF received a display name from the HSS for a public user identity,
then the S-CSCF shall populate the P-Associated-URI
header field entry for that public identity with the associated display name. The
S-CSCF shall not add a barred public user identity to the list of URIs in the
P-Associated-URI header field;
NOTE 1: The
P-Associated-URI header field lists
only the public user identity and its associated set of implicitly registered
public user identities that have been registered, rather than the list of
user's URIs that may be either registered or unregistered as specified in RFC 7315 [52].
If the registered
public user identity which is not barred does not have any other associated
public user identities or wildcarded public user identities, the P-Associated-URI header field lists only the registered public
user identity itself, rather than an empty P-Associated-URI
header field as specified in RFC 7315 [52]. The P-Associated-URI header field does not list wildcarded public
user identities.
c) a
Service-Route header field containing:
A) the SIP URI identifying the S-CSCF containing an indication
that subsequent requests routed via this service route (i.e. from the P-CSCF to
the S-CSCF) was sent by the UE using either the contact address of the UE or the
registration flow and the associated contact address (if the multiple
registration mechanism is used) that has been registered and are treated as for
the UE-originating case.
NOTE 2: This
indication can e.g. be in a parameter in the URI,
a character string in the user part of the URI
or be a port number in the URI.
The
S-CSCF shall use a different SIP URI
for each registration. If the multiple registration mechanism is used, the
S-CSCF shall also use a different SIP URI
for each registration flow associated with the registration;
B) if
network topology hiding is required a SIP URI
identifying an IBCF as the topmost entry; and
NOTE 3: In
accordance with the procedures described in RFC 3608 [38], an IBCF
does not insert its own routable SIP URI
to the Service-Route header field.
C) if
1) S-CSCF
supports indicating the traffic leg associated with a URI
as specified in RFC 7549 [225];
2) the UE
is roaming;
3) the P-CSCF
is not in the home network; and
4) required
by local policy
then
the S-CSCF may append an
"iotl" SIP URI parameter
with a value set to "visitedA-homeA" to the S-CSCF
SIP URI in the Service-Route
header field;
d) if the
P-CSCF is in the same network as the S-CSCF a P-Charging-Function-Addresses
header field containing the values received from the HSS. It can be determined
if the P-CSCF is in the same network as the S-CSCF by the contents of the
P-Visited-Network-ID header field included in the REGISTER request;
NOTE 4: The
P-CSCF does not check the P-Charging-Function-Addresses header field, providing
this header field to the visiting network could cause undefined charging
behaviour.
e) a
P-Charging-Vector header field containing the "orig-ioi" header field
parameter, if received in the REGISTER request, a type 1 "term-ioi"
header field parameter and the "icid-value" header field
parameter. The S-CSCF shall set the type 1 "term-ioi" header field
parameter to a value that identifies the sending network of the response, the "orig-ioi"
header field parameter is set to the previously received value of "orig-ioi"
header field parameter and the "icid-value" header field
parameter is set to the previously received value of "icid-value"
header field parameter in the request;
f) a
Contact header field listing all contact addresses for this public user
identity, including all saved header field parameters and URI parameters (including all ICSI values and IARI
values) received in the Contact header field of the REGISTER request,
g) GRUUs in
the Contact header field. If the REGISTER request contained a Required or
Supported header field containing the value "gruu" then for each
contact address in the Contact header field that has a "+sip.instance"
header field parameter:
i) add
"pub-gruu" header field parameter containing the public GRUU representing
(as specified in subclause 5.4.7A.2) the association between the public
user identity from the To header field in the REGISTER request and the instance
ID contained in the "+sip.instance" header field parameter;
ii) if the
Contact URI in the Contact header
field does not contain a "bnc" URI
parameter, then add a "temp-gruu" header field parameters. containing
the most recently assigned temporary GRUU representing (as specified in
subclause 5.4.7A) the association between the public user identity from
the To header field in the REGISTER request and the instance ID contained in
the "+sip.instance" header field parameter; and
iii) if the
S-CSCF supports RFC 6140 [191]
and the Contact URI
in the Contact header field contains a "bnc" URI
parameter, then add a "temp-gruu-cookie" header field parameter
containing a value generated as specified in RFC 6140 [191];
h) if the
received REGISTER request contained both a "reg-id" and
"+sip.instance" header field parameters in the Contact header field,
and the first URI within the Path
header field contains the "ob" SIP URI
parameter a Require header field with the "outbound" option-tag as
described in RFC 5626 [92];
NOTE 5: There
might be other contact addresses available, that this UE or other UEs have
registered for the same public user identity.
i) if
debugging configuration data exists for the address of record in the To header
field, an empty P-Debug-ID header field;
j) optionally,
a Feature-Caps header field, as specified in RFC 6809 [190], including the "+g.3gpp.icsi-ref" header field parameter set to the ICSI values contained in the service profile of the
served user except the ones that require explicit support indication by the
P-CSCF of one or more specific media capabilities. The specific media
capabilities are indicated as supported by the presence of one or more feature
capability indicators as listed in subclause 7.9A.7 in the a Feature-Caps
header field received in the REGISTER request, according to RFC 6809 [190]
for the corresponding registration or registration flow (if multiple
registration mechanism is used). The absence of feature capability indicators
as listed in subclause 7.9A.7 in the a Feature-Caps header field received
in the REGISTER request means that the P-CSCF is not supporting indication of
media capabilities and the S-CSCF should assume that all media capabilities
required are supported. The associated media capabilities that need to be
explicitly indicated as supported by the IMS-AGW controlled by the P-CSCF (IMS-ALG) are locally configured in the S-CSCF; and
k) if the home network supports calling number
verification, as described in draft-ietf-stir-rfc4474bis [252], a
Feature-Caps header field, as specified in RFC 6809 [190], including the "+g.3gpp.verstat" header field parameter;
NOTE 6: If the network has indicated support for the
calling number verification to a UE during registration, the network needs to
perform calling number verification for all calls delivered to the registered
contact address.
and send the so created 200 (OK) response
to the UE.
For all service profiles in the implicit
registration set, the S-CSCF shall send a third-party REGISTER request, as
described in subclause 5.4.1.7, to each AS that matches the Filter
Criteria of the service profile from the HSS for the REGISTER event; and,
NOTE 7: If this registration is a reregistration, the Filter Criteria already
exists in the local data.
NOTE 8: If the same AS matches the Filter Criteria of
several service profiles for the event of REGISTER request, then the AS will receive
several third-party REGISTER requests. Each of these requests will include a
public user identity from the corresponding service profile.
The S-CSCF shall consider the public user
identity being registered to be bound either to the contact address of the UE or
to the registration flow and the associated contact address (if the multiple
registration mechanism is used), as specified in the Contact header field, for
the duration indicated in the registration expiration interval value.
In the case that the expiration timer from
the UE is too short to be accepted by the S-CSCF, the S-CSCF shall:
- reject
the REGISTER request with a 423 (Interval Too Brief) response, containing a
Min-Expires header field with the minimum registration time the S-CSCF will
accept.
On receiving a failure response to one of
the third-party REGISTER requests, based on the information in the Filter
Criteria the S-CSCF may:
- abort
sending third-party REGISTER requests; and
- initiate
network-initiated deregistration procedure.
If the Filter Criteria does not contain
instruction to the S-CSCF regarding the failure of the contact to the AS, the
S-CSCF shall not initiate network-initiated deregistration procedure.
In the case that the REGISTER request from
the UE contains multiple SIP URIs which are different addresses as Contact
header field entries, the S-CSCF shall store:
- the
entry in the Contact header field with the highest value of the "q"
header field parameter; or
- an
entry decided by the S-CSCF based on local policy;
and include the stored entry in the 200
(OK) response.
In the case that the REGISTER request from
the UE contains multiple SIP URIs which are the same addresses with the same value
of the "q" Contact header field parameter, the S-CSCF shall not store
multiple entries with the same "q" value but store one of the entries
with the same "q" value based on local policy along with any entries
that have different "q" values and include only the stored entries in
the 200 (OK) response.
NOTE 1: The
UE can register multiple SIP URIs in the Contact header field simultanously,
provided they all contain the same IP address and port number. In this case the
S-CSCF behaviour is as defined RFC 3261 [26] (i.e multiple Contact
header field entries are bound to the public user identity in the To header field
and are returned in the 200 (OK) response).
NOTE 2: If
the timer reg-await-auth expires, the S-CSCF will consider the authentication
to have failed. If the public user identity was already registered, the S-CSCF
will leave it registered, as described in 3GPP TS 33.203 [19].
If the S-CSCF receives a new initial
REGISTER request before the reg-await-auth timer expires, the S-CSCF shall:
1) stop
the reg-await-auth timer; and
2) initiate
the authentication procedures for initial registration as if there is no
authentication currently ongoing for this user and send a 401 (Unauthorized)
response containing a new challenge as described in subclause 5.4.1.
For any error response, the S-CSCF shall
insert a P-Charging-Vector header field containing the "orig-ioi"
header field parameter, if received in the REGISTER request, a type 1 "term-ioi"
header field parameter
and the "icid-value" header field parameter.
The S-CSCF shall set the type 1 "term-ioi" header field parameter to
a value that identifies the sending network of the response, the "orig-ioi"
header field parameter is set to the previously received value of "orig-ioi"
header field and the "icid-value" header field parameter is set to the
previously received value of "icid-value" header field parameter in the request.
NOTE 3: Any
previously received "orig-ioi" header field parameter will be a type
1 IOI. The type 1 IOI identifies the visited network of the registered user.
If the Contact header field in the REGISTER
request from the UE contains an invalid Contact URI
as defined in RFC 6140 [191] (e.g., the Contact URI contains both a "bnc" and
"user" URI parameter)
then the S-CSCF shall reject the REGISTER request with a 400 (Bad Request)
response.
In the case that the REGISTER request, that
contains the authentication challenge response from the UE does not match with
the expected REGISTER request (e.g. wrong Call-Id or authentication challenge
response) and the request has the "integrity-protected" header field parameter
in the Authorization header field set to "yes", the S-CSCF shall:
- send a
403 (Forbidden) response to the UE. The S‑CSCF shall consider this
authentication attempt as failed. The S-CSCF shall not update the registration
state of the subscriber.
NOTE 1: If
the UE was registered before, it stays registered until the registration
expiration time expires.
In the case that the REGISTER request from
the UE containing an "auts" Authorization header field parameter,
indicating that the SQN was deemed to be out of range by the UE), the S-CSCF
will fetch new authentication vectors from the HSS. In order to indicate a
resynchronisation, the S-CSCF shall include the value of the "auts"
header field parameter received from the UE and the stored RAND, when fetching the new authentication vectors.
On receipt of the new authentication vectors from the HSS, the S-CSCF shall
either:
- send a
401 (Unauthorized) response to initiate a further authentication attempt, using
these new vectors; or
- respond
with a 403 (Forbidden) response if the authentication attempt is to be
abandoned. The S-CSCF shall not update the registration state of the
subscriber.
NOTE 2: If the UE was registered before, it stays registered
until the registration expiration time expires.
NOTE 3: Since the UE responds only to two consecutive
invalid challenges, the S-CSCF will send a 401 (Unauthorized) response that
contains a new challenge only twice.
NOTE 4: In the case of an "auts"
Authorization header field parameter being present in the REGISTER request, the
"response" Authorization header field parameter in the same REGISTER
request will not be taken into account by the S-CSCF.
In the case that the S-CSCF receives a
REGISTER request with the "integrity-protected" header field parameter
in the Authorization header field set to "yes", for which the public
user identity received in the To header field and the private user identity
received in the "username" Authorization header field parameter of
the REGISTER request do not match to any registered user at this S-CSCF, if the
S-CSCF supports S-CSCF restoration procedures, the S-CSCF shall behave as
described in subclause 5.4.1.2.2, otherwise the S-CSCF shall:
- respond
with a 500
(Server Internal Error) response to the UE.
NOTE 5: This error is not raised if there is a match
on the private user identity, but no match on the public user identity.
In the case that the REGISTER request, that
contains the authentication challenge response from the UE does not match with
the expected REGISTER request (e.g. wrong Call-Id or authentication challenge
response) and the request has the "integrity-protected" header field parameter
in the Authorization header field set to either "tls-pending",
"tls-yes", "ip-assoc-pending", or "ip-assoc-yes",
the S-CSCF shall do one of the following:
- send a
403 (Forbidden) response to the UE. The S CSCF
shall consider this authentication attempt as failed. The S-CSCF shall not
update the registration state of the subscriber; or
- rechallenge
the user by issuing a 401 (Unauthorized) response including a challenge as per
the authentication procedures described in subclause 5.4.1.2.1B.
NOTE 1: If
the UE was registered before, it stays registered until the registration
expiration time expires.
In the case that the REGISTER request from
the UE contains an invalid "nonce" Authorization header field
parameter with a valid challenge response for that nonce (indicating that the
client knows the correct username/password), or when the nonce-count value sent
by the UE is not the expected value, the S-CSCF shall:
- send a
401 (Unauthorized) response to initiate a further authentication attempt with a
fresh nonce and the "stale" header field parameter set to "true"
in the WWW-Authenticate header
field.
In the case that the S-CSCF receives a
REGISTER request with the "integrity-protected" header field parameter
in the Authorization header field set to "tls-pending", "tls-yes",
"ip-assoc-pending", or "ip-assoc-yes", for which the public
user identity received in the To header field and the private user identity
received in the Authorization header field of the REGISTER request do not match
to any registered or initial registration pending user at this S-CSCF, if the
S-CSCF supports S-CSCF restoration procedures, the S-CSCF shall behave as
described in subclause 5.4.1.2.2A, otherwise the S-CSCF shall:
- respond
with a 500 (Server Internal Error) response to the UE.
NOTE 2: This
error is not raised if there is a match on the private user identity, but no
match on the public user identity.
The procedures for subclause 5.4.1.2.3B
apply.
There are no abnormal cases for NASS-IMS
bundled authentication.
There are no abnormal cases for
GPRS-IMS-Bundled authentication.
Authentication and reauthentication is
performed by the registration procedures as described in
subclause 5.4.1.2.
5.4.1.4 User-initiated deregistration
When S-CSCF receives a REGISTER request
with the registration expiration interval value containing the value zero, the
S-CSCF shall:
1) verify
that the REGISTER request is associated with an existing registered contact or
an existing flow or, if the S-CSCF restoration procedures are supported by this
S-CSCF, attempt to restore a contact or flow from HSS associated with the
REGISTER request. If no associated contact or flow exists then the S-CSCF shall
send a 481 (Call Leg/Transaction Does Not Exist) response to the UE and skip the
remaining procedures in this subclause;
2) if IMS
AKA is in use as the security mechanism, check whether the
"integrity-protected" header field parameter in the Authorization
header field set to "yes", indicating that the REGISTER request was
received integrity protected. The S-CSCF shall only proceed with the following
steps if the "integrity-protected" header field parameter is set to
"yes";
3) if SIP
digest without TLS or SIP digest
with TLS is in use as a security
mechanism, check whether the "integrity-protected" header field parameter
in the Authorization header field set to "tls-yes" or
"ip-assoc-yes", indicating that the REGISTER request was received from
a previously registered user. If the "integrity-protected" header
field parameter is set to "tls-pending", "ip-assoc-pending"
or is not present the S-CSCF shall ensure authentication is performed as
described in subclause 5.4.1.2.1 (and consequently subclause 5.4.1.2.1B
or 5.4.1.2.1C) if local policy requires. The S-CSCF shall only proceed with the
following steps if the "integrity-protected" header field parameter
is set to "tls-yes", "ip-assoc-yes", or the required
authentication is successfully performed if required by local policy;
4) if
NASS-IMS bundled authentication is in use as a security mechanism, only proceed
with the following steps if the "integrity-protected" header field parameter
in the Authorization header field does not exist or without an Authorization
header field, and one or more Line-Identifiers previously received over the Cx interface,
stored as a result of an Authentication procedure with the HSS, as described in
3GPP TS 29.228 [14], are available for the user;
4A) if
the security mechanism as described in subclause 5.4.1.2.2E is in use,
check whether the "integrity-protected" header field parameter in the
Authorization header field set to "auth-done". The S-CSCF shall only
proceed with the following steps if the "integrity-protected" header
field parameter is set to "auth-done";
5) release
all INVITE dialogs that include this user's contact addresses or the flows that
are being deregistered, and where these dialogs were initiated by or terminated
towards these contact addresses and the same public user identity found that
was To header field that was received REGISTER request or with one of the
implicitly registered public user identities by applying the steps listed in
subclause 5.4.5.1.2;
6) examine
the Contact header field in the REGISTER request, and:
a) if the
value "*" is not included in the Contact header field and:
i) if the
"reg-id" header field parameter is not included in the Contact header
field, then:
- remove
the binding (i.e. deregister) between the public user identity found in the To
header field together with the implicitly registered public user identities and
the contact addresses specified in the REGISTER request. The S-CSCF shall only
remove the contact addresses that were registered by this UE;
ii) if the
"reg-id" header field parameter and "+sip.instance" header
field parameter are included in the Contact header field, and the UE supports
multiple registrations (i.e. the "outbound" option tag is included in
the Supported header field), then:
- remove
the binding (i.e. deregister) between the public user identity indicated in the
To header field (together with the associated implicitly registered public user
identities) and the flow identified by the "reg-id" header field
parameter;
7) if the S-CSCF
receives a REGISTER request with the value "*" in the Contact header field
and the value zero in the Expires header field, remove all contact addresses that
were bound to the public user identity found in the To header field and have
been registered by this UE identified with its private user identity;
8) for all
service profiles in the implicit registration set send a third-party REGISTER
request, as described in subclause 5.4.1.7, to each AS that matches the
Filter Criteria of the service profile from the HSS for the REGISTER event;
9) if this
is a deregistration request for the only public user identity currently
registered with its associated set of implicitly registered public user
identities (i.e. no other is registered) and there are still active multimedia
sessions that includes this user's registered contact address, where the
session was initiated by or terminated towards the contact with the registered
contact address for that public user identity which is currently registered or
with one of the implicitly registered public user identities, release only each
of these multimedia sessions associated with the registered contact address by
applying the steps listed in subclause 5.4.5.1.2. The S-CSCF shall only
release dialogs associated to the multimedia sessions originated or terminated
towards the registered user's contact address; and
10) send a
200 (OK) response to a REGISTER request that contains a list of Contact header
fields enumerating all contacts and flows that are currently registered, and
all contacts that have been deregistered. For each contact
address and the flow that has been deregistered, the Contact header field shall contain
the contact address and the "reg-id" header
field parameter that identifies the flow, if a flow was deregistered, and the
associated information, and the registration expiration interval value shall be
set to zero.
If all public user identities of the UE are
deregistered, then the S-CSCF may consider the UE and P-CSCF subscriptions to
the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request
with an Expires header field containing a value of zero).
If the Authorization header field of the
REGISTER request contained an "integrity-protected" header field parameter
set to the value "no", the S-CSCF shall apply the procedures
described in subclause 5.4.1.2.1.
On completion of the above procedures in
this subclause and of the S-CSCF Registration/deregistration notification procedure
with the HSS, as described in 3GPP TS 29.228 [14], for one or
more public user identities, the S-CSCF shall:
1) update or remove
those public user identities, their registration state and the associated
service profiles from the local data; and
2) if all the contacts bound to the public user
identities have been deregistered and there is no ongoing session due to the
public user identities, then remove all the stored AS IP addresses which are
associated with those public user identities.
Based on operators' policy the S-CSCF can
request the HSS to either be kept or cleared as the S-CSCF allocated to this
subscriber. If emergency contacts are still registered for this subscriber, the
S-CSCF requests the HSS to be kept as the S-CSCF allocated to this subscriber.
If case that the S-CSCF receives a REGISTER
request with the "integrity-protected" header field parameter in the
Authorization header set to "yes" or to "tls-connected",
for which the public user identity received in the To header and the private
user identity received in the Authorization header of the REGISTER request do
not match to any registered user at this S-CSCF, if the S-CSCF supports S-CSCF restoration
procedures as specified in 3GPP TS 23.380 [7D], the S-CSCF shall
behave as described in subclause 5.4.1.4.1, otherwise the S-CSCF shall:
- respond
with a 500
(Server Internal Error) response to the UE.
NOTE: This
error is not raised if there is a match on the private user identity, but no
match on the public user identity.
The procedures for subclause 5.4.1.4.2
apply.
There are no abnormal cases for NASS-IMS
bundled authentication.
There are no abnormal cases for
GPRS-IMS-Bundled authentication.
NOTE 1: A network-initiated deregistration event that occurs at the S-CSCF can
be received from the HSS or can be an internal event in the S-CSCF.
For any registered public user identity,
the S-CSCF can deregister:
- all
contact addresses bound to the indicated public user identity (i.e. deregister
the respective public user identity);
- some
contact addresses bound to the indicated public user identity;
- a
particular contact address bound to the indicated public user identity; or
- one or
more registration flows and the associated contact address bound to the
indicated public user identity, when the UE supports multiple registration
procedure;
by sending a single NOTIFY request.
Prior to initiating the network-initiated deregistration for the
only currently registered public user identity and its associated set of
implicitly registered public user identities and wildcarded public user
identities that have been registered either with the same contact address of the
UE or the same registration flow and the associated contact address (if the
multiple registration mechanism is used), i.e. there are no other public user identities
registered either with this contact address or with this registration flow and
the associated contact address (if the multiple registration mechanism is used),
and there are still active multimedia sessions belonging either to this contact
address or to this registration flow and the associated contact address (if the
multiple registration mechanism is used), the S-CSCF shall release only
multimedia sessions belonging to this contact address or to this registration
flow and the associated contact address (if the multiple registration mechanism
is used) as described
in the following paragraph. The multimedia sessions for
the same public user identity, if registered either with another contact address
or another registration flow and the associated contact address (if the
multiple registration mechanism is used) remain unchanged.
Prior to initiating the network-initiated deregistration while there
are still active multimedia sessions that are associated with this user and
contact, the S-CSCF shall release none, some or all of these multimedia
sessions by applying the steps listed in subclause 5.4.5.1.2 under the following
conditions:
- when
the S-CSCF does not expect the UE to reregister a given public user identity
and its associated set of implicitly registered public user identities that
have been registered with respective contact address (i.e. S-CSCF will set the
event attribute within the respective <contact> element to
"rejected" for the NOTIFY request, as described below), the S-CSCF
shall release all sessions that are associated with the registered contact
address for the public user identities using the contact address that is being
deregistered, which includes the implicitly registered public user identities.
- when
the S-CSCF expects the UE to reregister a given public user identity and its
associated set of implicitly registered public user identities that have been
registered with respective contact address (i.e. S-CSCF will set the event
attribute within the respective <contact> element to
"deactivated" for the NOTIFY request, as described below), the S-CSCF
shall only release sessions that currently include the user's contact address,
where the session was initiated by or terminated towards the user with the contact
address registered to one of the public user identities using the contact
address that is being deregistered, which includes the implicitly registered
public user identities.
When a network-initiated deregistration
event occurs for one or more public user identities that are bound either to
one or more contact addresses or registration flows and the associated contact
addresses (if the multiple registration mechanism is used), the S-CSCF shall
send a NOTIFY request to all subscribers that have subscribed to the respective reg
event package. For each NOTIFY request, the S-CSCF
shall:
1) set the
Request-URI and Route header field
to the saved route information during subscription;
2) set the
Event header field to the "reg" value;
3) in the
body of the NOTIFY request, include as many <registration> elements as
many public user identities the S-CSCF is aware of the user owns;
4) set the
aor attribute within each <registration> element to one public user
identity:
a) set the
<uri> sub-element inside each <contact> sub-element of each
<registration> element to the respective contact address provided by the
UE;
b) if the
public user identity:
i) has
been deregistered (i.e. all contact addresses and all registration flows and
associated contact addresses bound to the indicated public user identity are
removed) then:
- set the
state attribute within the <registration> element to "terminated";
- set the
state attribute within each <contact> element belonging to this UE to
"terminated"; and
- set the
event attribute within each <contact> element belonging to this UE to either
"unregistered", or "deactivated" if the S-CSCF expects the
UE to reregister or "rejected" if the S-CSCF does not expect the UE
to reregister; or
NOTE 2: If
the multiple registration mechanism is used, then the reg-id header field
parameter will be included as an <unknown-param> element within each
respective <contact> element.
NOTE 3: The
UE will consider its public user identity as deregistered when the binding between
the respective public user identity and all contact addresses and all registration
flows and associated contact addresses (if the multiple registration mechanism is
used) belonging to the UE have been removed.
ii) has
been kept registered then:
I) set the
state attribute within the <registration> element to "active";
II) set the
state attribute within each <contact> element to:
- for the
binding between the public user identity and either the contact address or a
registration flow and associated contact addresses (if the multiple
registration mechanism is used) to be removed set the state attribute within
the <contact> element to "terminated", and event attribute
element to either "unregistered", or "deactivated" if the
S-CSCF expects the UE to reregister or "rejected" if the S-CSCF does
not expect the UE to reregister; or
- for the
binding between the public user identity and either the contact address or the
registration flow and associated contact addresses (if the multiple
registration mechanism is used) which remain unchanged, if any, leave the
<contact> element unmodified, and if the contact has been assigned GRUUs and
the Contact URI did not contain a "bnc"
SIP URI parameter then set the
<pub-gruu> and <temp-gruu> sub-elements of the <contact>
element as specified in RFC 5628 [94] and include the
<unknown-param> sub-element within each <contact> to any additional
header field parameters contained in the Contact header field of the REGISTER
request according to RFC 3680 [43]; and
NOTE 4: There
might be more than one contact information available for one public user
identity. When deregistering this UE, the S-CSCF will only modify the
<contact> elements that were originally registered by this UE using its
private user identity. The <contact> elements of the same public user identity,
if registered by another UE using different private user identities remain
unchanged.
5) add a
P-Charging-Vector header field with the "icid-value" header field parameter set to the
value populated in the initial request for the dialog and a type 1
"orig-ioi" header field parameter. The S-CSCF
shall set the type 1 "orig-ioi" header field parameter to a value
that identifies the sending network of the request. The S-CSCF
shall not include the type 1 "term-ioi" header field parameter.
The S-CSCF shall only include the
non-barred public user identities in the NOTIFY request.
When sending a final NOTIFY request with all <registration> element(s)
having their state attribute set to
"terminated" (i.e. all public user identities have been deregistered
or expired), the S-CSCF shall also terminate the subscription to the
registration event package by setting the Subscription-State header field to
the value of "terminated".
Also, for all service profiles in the
implicit registration set the S-CSCF shall send a third-party REGISTER request,
as described in subclause 5.4.1.7, to each AS that matches the Filter
Criteria of the service profile from the HSS as if a equivalent REGISTER
request had been received from the user deregistering that public user
identity, or combination of public user identities.
On completion of the above procedures for
one or more public user identities linked to the same private user identity,
the S-CSCF shall consider those public user identities and the associated
implicitly registered public user identities which have no contact address or a
registration flow and associated contact addresses (if the multiple registration
mechanism is used) bound to them as deregistered. On completion of the S-CSCF
Registration/deregistration notification procedure with the HSS, as described
in 3GPP TS 29.228 [14], the S-CSCF shall:
1) update or remove
those public user identities linked to the same private user identity, their
registration state and the associated service profiles from the local data
(based on operators' policy the S-CSCF can request of the HSS to either be kept
or cleared as the S-CSCF allocated to this subscriber); and
2) if all the contacts bound to the public user
identities have been deregistered and there is no ongoing session due to the
public user identities, then remove all the stored AS IP addresses which are
associated with those public user identities.
On the completion of the Network initiated
de-registration by the HSS procedure, as described in
3GPP TS 29.228 [14], the S-CSCF shall remove:
1) those public user
identities, their registration state and the associated service profiles from
the local data; and
2) if all the contacts bound to the public user
identities have been deregistered and there is no ongoing session due to the
public user identities, then remove all the stored AS IP addresses which are
associated with those public user identities.
The S-CSCF may request a subscriber to
reauthenticate at any time, based on a number of possible operator settable
triggers.
NOTE 1: Triggers
for re-authentication include e.g. a current registration of the UE is set to expire
at a predetermined time; one or more error conditions in the S-CSCF; the S-CSCF
mistrusts the UE.
If the S-CSCF is informed that a private
user identity needs to be re-authenticated, the S-CSCF shall generate a NOTIFY
request on all dialogs which have been established due to subscription to the
reg event package of that user. For each NOTIFY request the S-CSCF shall:
1) set the
Request-URI and Route header field
to the saved route information during subscription;
2) set the
Event header field to the "reg" value;
3) in the
body of the NOTIFY request, include as many <registration> elements as
many public user identities the S-CSCF is aware of the user owns:
a) set the
<uri> sub-element inside the <contact> sub-element of each
<registration> element to the contact address provided by the UE;
b) set the
aor attribute within each <registration> element to one public user
identity;
c) set the
state attribute within each <registration> element to "active";
d) set the
state attribute within each <contact> element to "active";
e) set the
event attribute within each <contact> element that was registered by this
UE to "shortened";
f) set the
expiry attribute within each <contact> element that was registered by
this UE to an operator defined value; and
g) if the
Contact URI did not contain a "bnc"
SIP URI parameter then set the
<pub-gruu> and <temp-gruu> sub-elements within each <contact>
element as specified in subclause 5.4.2.1.2; and
NOTE 2: There
might be more than one contact information available for one public user
identity. The S-CSCF will only modify the <contact> elements that were
originally registered by this UE using its private user identity. The S-CSCF
will not modify the <contact> elements for the same public user
identitity, if registered by another UE using different private user identity.
4) set a
P-Charging-Vector header field with the "icid-value" header field parameter set to the
value populated in the initial request for the dialog and a type 1
"orig-ioi" header field parameter. The S-CSCF
shall set the type 1 "orig-ioi" header field parameter to a value
that identifies the sending network of the request. The S-CSCF
shall not include the type 1 "term-ioi" header field parameter.
Afterwards the S-CSCF shall wait for the
user to reauthenticate (see subclause 5.4.1.2).
NOTE 3: Network
initiated re-authentication can occur due to internal processing within the
S-CSCF.
The S-CSCF shall only include the
non-barred public user identities in the NOTIFY request.
When generating the NOTIFY request, the
S-CSCF shall shorten the validity of all registration lifetimes associated with
this private user identity to an operator defined value that will allow the
user to be re-authenticated.
5.4.1.7 Notification of Application Servers about registration
status
During registration, the S-CSCF shall
include the P-Access-Network-Info header fields (as received in the REGISTER
request from the UE and the P-CSCF) and a P-Visited-Network-ID header field (as
received in the REGISTER request from the UE) in the third-party REGISTER request
sent towards the ASs, if the AS is part of the trust domain. If the AS is not
part of the trust domain, the S-CSCF shall not include any
P-Access-Network-Info header field or P-Visited-Network-ID header field. The
S-CSCF shall not include a P-Access-Network-Info header field in any responses
to the REGISTER request.
If the registration procedure described in
subclauses 5.4.1.2, 5.4.1.4 or 5.4.1.5 (as appropriate) was successful,
the S-CSCF shall send a third-party REGISTER request to each AS with the
following information:
a) the
Request-URI, which shall contain
the AS's SIP URI;
b) the
From header field, which shall contain the S-CSCF's SIP URI;
c) the To
header field, which shall contain a non-barred public user identity belonging
to the service profile of the processed Filter Criteria. It may be either a
public user identity as contained in the REGISTER request received from the UE
or one of the implicitly registered public user identities in the service
profile, as configured by the operator;
NOTE 1: For the
whole implicit registration set only one public user identity per service
profile appears in the third-party REGISTER requests. Thus, based on
third-party REGISTER requests only, the ASs will not have complete information
on the registration state of each public user identity in the implicit
registration set. The only way to have a complete and continuously updated
information (even upon administrative change in subscriber's profile) is to
subscribe to the reg event package.
d) the
Contact header field, which shall contain the S-CSCF's SIP URI;
e) for
initial registration and user-initiated reregistration
(subclause 5.4.1.2), the registration expiration interval value, which
shall contain the same value that the S-CSCF returned in the 200 (OK) response
for the REGISTER request received from the UE;
f) for
user-initiated deregistration (subclause 5.4.1.4) and network-initiated
deregistration (subclause 5.4.1.5), the registration expiration interval
value, which shall contain the value zero;
NOTE 2: The
user can have one or more contacts registered after a third-party
deregister. If an AS needs more detailed knowledge of the user registration
status, the AS can subscribe to the reg event package.
g) for
initial registration and user-initiated reregistration
(subclause 5.4.1.2), a message body, if there is Filter Criteria
indicating the need to include HSS provided data for the REGISTER event (e.g.
HSS may provide AS specific data to be included in the third-party REGISTER) or
if there is Filter Criteria indicating the need to include the contents of the
incoming REGISTER request or the contents of the 200 (OK) response to the
incoming REGISTER request in the body of the third-party REGISTER. The S-CSCF
shall format the MIME body and set the value of the Content-Type header field to
include the MIME type specified in subclause 5.4.1.7A;
NOTE 3: When the
AS is outside the trust domain for any header field that is permitted in the
REGISTER request received from the UE or final response to the
REGISTER request received from the UE, including an Include Register Request or Include Register Response indication in the
initial Filter Criteria would cause the incoming REGISTER request or 200 (OK) response to the
incoming REGISTER request contents to be delivered
to the AS revealing information that AS is not trusted to obtain. Include
Register Request and Include Register Response indication
is therefore not included in the initial Filter Criteria for an AS that exists
outside the trust domain for any such header field.
h) for
initial registration and user-initiated reregistration, the P-Charging-Vector
header field, which shall contain the same "icid-value" header field
parameter that the S-CSCF received in the REGISTER request from the UE. The
S-CSCF shall insert a type 3 orig-ioi parameter in place of any received "orig-ioi"
header field parameter and shall set the type 3 "orig-ioi" header
field parameter to a value that identifies the sending network of the request.
The S-CSCF shall not include the type 3 "term-ioi" header field
parameter;
i) for
initial registration and user-initiated reregistration, a
P-Charging-Function-Addresses header field, which shall contain the values
received from the HSS if the message is forwarded within the S-CSCF home network;
j) in
case the received REGISTER request contained a P-User-Database header field and
the AS belongs to the same operator as the S-CSCF, optionally a P-User-Database
header field which shall contain the received value;
k) if
debugging configuration data exists for the address of record in the To header
field, an empty P-Debug-ID header field; and
l) if the
S-CSCF supports using a token to identify the registration for initial
registration and user initiated reregistration, a "+g.3gpp.registration-token" Contact header field parameter, as defined in subclause 7.9.7,
set to a value identifying this registration. The value shall be the same until the UE is deregistered.
For
third-party REGISTER upon user-initiated reregistration, user-initiated
deregistration or network-initiated deregistration, the S-CSCF shall send SIP REGISTER request
towards the IP address associated with the corresponding registered public user
identity stored as described in subclause 5.4.0.
When the S-CSCF receives any response to a
third-party REGISTER request, the S-CSCF shall store the value of the "term-ioi"
header field parameter received in the P-Charging-Vector header field, if
present.
NOTE 4: Any
received "term-ioi" header field parameter will be a type 3 IOI. The
type 3 IOI identifies the service provider from which the response was sent.
If the S-CSCF fails to receive a SIP response or receives a
408 (Request Timeout) response or a 5xx response to a third-party REGISTER, the S-CSCF shall:
- if the default handling defined in the
filter criteria indicates the value "SESSION_CONTINUED" as specified
in 3GPP TS 29.228 [14] or no default handling is indicated, no
further action is needed; and
- if the default handling defined in
the filter criteria indicates the value "SESSION_TERMINATED" as
specified in 3GPP TS 29.228 [14], initiate the network-initiated
deregistration as described in subclause 5.4.1.5 for the currently registered public user identity and its associated
set of implicitly registered non-barred public user identities bound to the
contact(s) registered in the REGISTER request causing the third-party
REGISTER request.
If there is a service information XML
element provided in the HSS Filter Criteria for an AS (see
3GPP TS 29.228 [14]), then in the third-party REGISTER request
the S-CSCF shall:
- include
in the message body the service information within the <service-info> XML
which is a child XML element of an <ims-3gpp> element with the
"version" attribute set to "1" element as described in
subclause 7.6; and
- set
the value of the content type to the MIME type specified in subclause 7.6.
If there is an Include Register Request XML
element provided in the HSS Filter Criteria for an AS (see 3GPP TS 29.228 [14]),
then in the third-party REGISTER request the S-CSCF shall:
- include
in the message body the incoming SIP REGISTER request within a "message/sip"
MIME body as defined in RFC 3261 [26]; and
- set
the value of the content type to "message/sip".
If there is an Include Register Response XML
element provided in the HSS Filter Criteria for an AS (see
3GPP TS 29.228 [14]), then in the third-party REGISTER request,
the S-CSCF shall:
- include
in the message body the 200 (OK) response to the incoming SIP REGISTER request
within a "message/sip" MIME body as defined in RFC 3261 [26];
and
- set the
value of the content type to "message/sip".
If there is more than one message body to
be included in the third-party REGISTER request then in the third-party REGISTER
request the S-CSCF shall:
- include
a multipart message body and set the value of the Content-Type header field to
"multipart/mixed" as specified in RFC 2046 [149] and RFC 5621 [150];
and
- set
the Content-Type of the elements of the MIME body to the content type specified
for the body.
If there is only one message body to be
included in the third-party REGISTER request then the S-CSCF sets the
Content-Type header field to the content type specified for the body.
NOTE 1: The
S-CSCF can receive an update of subscriber data notification on the Cx
interface, from the HSS, which can affect the stored information about served
public user identities. According to
3GPP TS 29.228 [14], the changes are guaranteed not to affect the
default public user identity within the registration implicit set.
When receiving a Push-Profile-Request (PPR)
from the HSS (as described in 3GPP TS 29.228 [14]), modifying
the service profile of served public user identities, the S-CSCF shall:
1) if the
modification consists in the addition of a new non-barred public user identity
to an implicit set, or in the change of status from barred to non-barred for a
public user identity already in the implicit set, add the public user identity
to the list of registered, non-barred public user identities;
2) if the modification consists in the deletion of
a public user identity while there are no active multimedia session belonging
to this public user identity, or in the change of status from non-barred to barred
of a public user identity in an implicit set, remove the public user identity
from the list of registered, non-barred public user identities;
NOTE 2: As
the S-CSCF checks the barring status of the public user identity on receipt of
a initial request for a dialog, or a standalone transaction, the above
procedures have no impact on transactions or dialogs already in progress and
are effective only for new transactions and dialogs.
3) if the
modification consists of deletion of a public user identity from an implicit
registration set while there are active multimedia session belonging to this
public user identity and contact, release these multimedia sessions as
described in subclause 5.4.5.1.2 and after all multimedia sessions are
released, remove the public user identity from the list of registered,
non-barred public user identities; and
4) synchronize
with the UE and IM CN entities, by either:
- performing
the procedures for notification of the reg-event subscribers about registration
state, as described in subclause 5.4.2.1.2; or
- triggering
the UE to re-register, by:
a) depending
on operator configuration, rejecting a request from the UE using a 504 (Server
Time-out) response and indicating in the response that S-CSCF restoration
procedures are supported, in accordance with subclause 5.4.3.2; or
b) shortening
the life time of the current registration, as described in
subclause 5.4.1.6,
e.g. when a new trigger point of Register method is added in the iFCs.
NOTE 3: The
UE procedure in response to receiving a rejection as described in item a)
(see subclause 5.1.2A.1.6) is specified for UEs since 3GPP Rel-8.
When an incoming SUBSCRIBE request
addressed to S-CSCF arrives containing the Event header field with the reg
event package, the S-CSCF shall:
0) if the Request-URI
of the SUBSCRIBE request contains a URI
for which currently no binding exists, then send a 480 (Temporarily
Unavailable) response indicating that the subscription was not successful and
skip the remainder of the steps;
1) check
if, based on the local policy, the request was generated by a subscriber who is
authorised to subscribe to the registration state of this particular user. The
authorized subscribers include:
- all
public user identities this particular user owns, that the S-CSCF is aware of,
and which are not-barred;
- all
the entities identified by the Path header field (i.e. the P-CSCF to which this
user is attached to or the IBCF which encrypted the Path header field); and
- all
the ASs listed in the initial filter criteria that are part of the trust
domain;
if the
request is received from a subscriber which is not auhorized to subscribe to
the registration state of this particular user, then send a 403 (Forbidden)
response indicating that the subscription was not successful and skip the
remainder of the steps;
NOTE 1: The
S-CSCF finds the identity for authentication of the subscription in the P-Asserted-Identity
header field received in the SUBSCRIBE request.
1A) if
the Request-URI of the SUBSCRIBE
request identifies a public user identity that was implicitly registered using
the registration procedures defined in RFC 6140 [191] and performs
the functions of an external attached network, and the registration is
currently active, then skip the remainder of the procedure in this subclause
and route the SUBSCRIBE request to the UE performing the functions of an
externally attached network using the procedures defined in
subclause 5.4.3.3;
1B) store
the "icid-value" header field parameter received in the
P-Charging-Vector header field;
2) store
the value of the "orig-ioi" header field parameter received in the
P-Charging-Vector header field if present;
NOTE 2: Any
received "orig-ioi" header field parameter will be either a type 1
IOI or a type 3 IOI. The type 1 IOI identifies the sending network and the type
3 IOI identifies the service provider from which the request was sent.
3) generate
a 200 (OK) response acknowledging the SUBSCRIBE request and indicating that the
authorised subscription was successful as described in RFC 3680 [43]
and RFC 6665 [28]. The S-CSCF shall populate the header fields as
follows:
- an
Expires header field, set to either the same or a decreased value as the
Expires header field in SUBSCRIBE request;
- if the
request originated from an ASs listed in the initial filter criteria, a
P-Charging-Vector header field containing the "orig-ioi" header field
parameter, if received in the SUBSCRIBE request, a type 3 "term-ioi"
header field parameter and the "icid-value" header field parameter. The S-CSCF shall set the type 3 "term-ioi" header field
parameter to a value that identifies the sending network of the response, the "orig-ioi"
header field parameter is set to the previously received value of "orig-ioi"
header field parameter and the "icid-value" header field parameter is set to the
previously received value of "icid-value" header field parameter in
the request; and
- if the
request originated from a public user identity this particular user owns, or
any of the entities identified by the Path header field, a P-Charging-Vector
header field containing the "orig-ioi" header field parameter, if
received in the SUBSCRIBE request, a type 1 "term-ioi" header field
parameter, and the "icid-value" header field parameter. The S-CSCF
shall set the type 1 "term-ioi" header field parameter to a value
that identifies the sending network of the response, the "orig-ioi"
header field parameter is set to the previously received value of "orig-ioi"
header field parameter and the "icid-value" header field parameter is set to the
previously received value of "icid-value" header field parameter in
the request.
The
S-CSCF may set the Contact header field to an identifier uniquely associated to
the SUBSCRIBE request and generated within the S-CSCF, that may help the S-CSCF
to correlate refreshes for the SUBSCRIBE dialog; and
NOTE 3: The
S-CSCF could use such unique identifiers to distinguish between UEs, when two
or more users, holding a shared subscription, register under the same public
user identity.
4) determine
the applicable private user identity as the private user identity included in a
REGISTER request:
- which
created (implicitly or explictly) a binding of the public user identity in the
Request-URI of the SUBSCRIBE
request to an contact address; and
- for
which one of the following is true:
a) the 200
(OK) response to the REGISTER request contained the Service-Route header field
with the S-CSCF URI matching the URI in the top Route header field of the SUBSCRIBE
request (i.e. the SUBSCRIBE request originated by a served UE); or
b) the 200
(OK) response to the REGISTER request contained a Path header field with a URI matching the URI
in the P-Asserted-Identity header field of the SUBSCRIBE request (i.e. the
SUBSCRIBE request originated by a P-CSCF serving a UE).
NOTE 4: If
the URI in the P-Asserted-Identity
header field of the initial SUBSCRIBE request matches URIs of several Path
header fields (e.g. the SUBSCRIBE request is originated by Rel-7 P-CSCF), the
applicable private user identity is not determined.
Afterwards the S-CSCF shall perform the
procedures for notification about registration state as described in
subclause 5.4.2.1.2.
If the SUBSCRIBE request originated from an
AS listed in the initial filter criteria, for any response that is not a 2xx
response, the S-CSCF shall insert a P-Charging-Vector header field containing
the "orig-ioi" header field parameter, if received in the SUBSCRIBE
request, a type 3 "term-ioi" header field parameter and the "icid-value"
header field parameter. The S-CSCF shall set the type 3
"term-ioi" header field parameter to a value that identifies the
sending network of the response, the "orig-ioi" header field
parameter is set to the previously received value of "orig-ioi"
header field parameter and
the "icid-value" header field parameter is set to the previously
received value of "icid-value" header field parameter in the request.
If the SUBSCRIBE request originated from a
public user identity this particular user owns, or any of the entities
identified by the Path header field, for any response that is not a 2xx
response, the S-CSCF shall insert a P-Charging-Vector header field containing
the "orig-ioi" header field parameter, if received in the SUBSCRIBE
request, a type 1 "term-ioi" header field parameter and the "icid-value"
header field parameter. The S-CSCF shall set the type 1
"term-ioi" header field parameter to a value that identifies the
sending network of the response, the "orig-ioi" header field
parameter is set to the previously received value of "orig-ioi"
header field parameter and
the "icid-value" header field parameter is set to the previously
received value of "icid-value" header field parameter in the request.
When the S-CSCF receives a subscription
refresh request for a dialog that was established by the UE subscribing to the
reg event package, the S-CSCF shall accept the request irrespective if the
user's public user identity specified in the SUBSCRIBE request is either
registered or has been deregistered.
The UE can bind any one of its public user
identities either to its contact address or to a registration flow and the
associated contact address (if the multiple registration mechanism is used) via
a single registration procedure. When multiple registrations mechanism is used
to register a public user identity and bind it to a registration flow and the
associated contact address, the S-CSCF shall generate a NOTIFY request that
includes one <contact> element for each binding between a public user
identity and a registration flow and the associated contact address.
NOTE 1: If
the UE binds a given public user identity to the same contact address but
several registration flows and the associated contact address (via several
registrations), then the NOTIFY request will contain one <contact>
element for each registration flow and the associated contact address. Each
respective <contact> elements will contain the same contact address in
the <uri> sub-element, but different value
in the "id" attribute and different
"reg-id" value included in the respective <unknown-param>
element.
For every successful registration that
creates a new binding between a public user identity and either its contact
address or the registration flow and the associated contact address (if the
multiple registration mechanism is used, the NOTIFY request shall always
include a new <contact> element containing new value in the "id" sub-element, the state attribute set to "active",
and event attribute set to either "registered" or
"created".
Any successful registration (that creates a
new binding between a public user identity and either its contact address or a registration
flow and associated contact address) may additionally replace or remove one or
more existing bindings. In the NOTIFY request, for each replaced or removed
binding, the <contact> element shall have the state attribute set to
"terminated" and the event attribute set to "unregistered", "deactivated", or "rejected".
NOTE 2: When
multiple registrations mechanism is not used, if the UE registers new contact
address then all registrations, if any, using an old contact address are
deregistered, i.e. the new registration replaces the old registrations. Hence,
for each deregistered public user identity, the NOTIFY request will have the
state attribute within the <registration> element set to
"terminated" and the state attribute in the <contact> element
set to "terminated" and the event attribute set to "unregistered", "deactivated", or "rejected".
NOTE 3: If
the UE uses a multiple registrations mechanism to bind a public user identity to
a new registration flow the registration flow and the associated contact
address, and if the new registration flow replaces an existing registration
flow, then for the registration flow and the associated contact address being
replaced, the respective <contact> element in the NOTIFY request will
have the state attribute set to "terminated" and the event attribute set
to "unregistered", "deactivated", or "rejected".
The S-CSCF shall send a NOTIFY request:
- when
an event pertaining to the user occurs. In this case the NOTIFY request is sent on all dialogs which have been established due to
subscription to the reg event package of that user; and
- as
specified in RFC 6665 [28].
When
sending a NOTIFY request, the S-CSCF shall not use the default filtering policy
as specified in RFC 3680 [43], i.e. the S-CSCF shall always include
in every NOTIFY request the state information of all registered public user
identities of the user (i.e. the full state information).
NOTE 4: Contact
information related to emergency registration is not included.
When generating NOTIFY requests, the S-CSCF
shall not preclude any valid reg event package parameters in accordance with
RFC 3680 [43].
For each NOTIFY request triggered by an
event and on all dialogs which have been established due to subscription to the
reg event package of that user, the S-CSCF shall:
1) set the
Request-URI and Route header field
to the saved route information during subscription;
2) set the
Event header field to the "reg" value;
3) in the
body of the NOTIFY request, include one <registration> elements for each public
user identity that the S-CSCF is aware the user owns.
If the
user shares one or more public user identities with other users, the S-CSCF
shall include any contact addresses registered by other users of the shared
public user identity in the NOTIFY request;
4) for each
<registration> element:
a) set the
aor attribute to one public user identity or if the public user identity of
this <registration> element is a wildcarded public user identity, then
choose arbitrarily a public user identity that matches the wildcarded public
user identity and the service profile of the wildcarded public user identity
and set the aor attribute to this public user identity;
NOTE 5: If the public user identity of this
<registration> element is a wildcarded public user identity, the value of the aor attribute will not be
used by the receiver of the NOTIFY.
b) set the
<uri> sub-element inside each <contact> sub-element of the
<registration> element to the contact address provided by the respective
UE as follows:
I) if the
aor attribute of the <registration> element contains a SIP URI and if the Contact URI
did not contain a "bnc" SIP URI
parameter, then for each contact address that contains a "+sip.instance"
Contact header field parameter, include <pub-gruu> and <temp-gruu> sub-elements
within the corresponding <contact> element. The S-CSCF shall set the contents
of these elements as specified in RFC 5628 [94]; or
II) if the
aor attribute of the <registration> element contains a tel-URI, determine its alias SIP URI and if the Contact URI
did not contain a "bnc" SIP URI
parameter then include a copy of the <pub-gruu> and <temp-gruu> sub-elements
from that equivalent element;
c) if the
respective UE has provided a display-name in a Contact header field, set the
<display-name> sub-element inside the respective <contact>
sub-element of the <registration> element to the value provided by the UE
according to RFC3680 [43];
d) if the
user owns a wildcarded public user identity then include a
<wildcardedIdentity> sub-element as described in subclause 7.10.2;
e) if the
public user identity set in step a):
I) has been
deregistered either by the UE or the S-CSCF (i.e. upon the deregistration, there
are no binding left between this public user identity and either a contact address
or a registration flows and associated contact addresses that belong to this
user) then:
- set the
state attribute within the <registration> element to
"terminated";
- set the
state attribute within each <contact> element belonging to this user to
"terminated"; and
- set the
event attribute within each <contact> element to "deactivated",
"expired", "unregistered", "rejected" or
"probation" according to RFC 3680 [43].
If the
public user identity has been deregistered for this user and this deregistration
has already been indicated in the NOTIFY request, and no new registration for
this user has occurred, its <registration> element shall not be included
in the subsequent NOTIFY requests;
II) has been
registered by the UE (i.e. the public user identity has not been previously bound
either to a contact address or to a registration flow and the associated
contact address (if the multiple registration mechanism is used)) then:
- set the
<unknown-param> element to any additional header field parameters
contained in the Contact header field of the REGISTER request according to
RFC 3680 [43];
NOTE 6: If
the multiple registration mechanism is used, then the reg-id header field
parameter will be included as an <unknown-param> element.
- if the
subscription contains, for the applicable private user identity (determined as
described in subclause 5.4.2.1.1) and the public user identity, any of the
policies described in subclause 7.10.3, then include the policy associated
with the applicable private user identity and the public user identity using
coding described in subclause 7.10.3;
- set the
state attribute within the <registration> element to "active";
and:
- set the
state attribute within the <contact> element belonging to this user to
"active", include new value for the
"id" attribute within the
<contact> sub-element, and set the event attribute within this <contact>
element to "registered";
NOTE 7: If
this registration, that created new binding, additionally replaces or removes
one or more existing registrations, then for the replaced or removed
registrations the respective <registration> elements and <contact>
elements will be modified accordingly.
III) has
been re-registered (i.e. it has been previously registered) then:
- set the
state attribute within the <registration> element to "active";
- if the
subscription contains, for the applicable private user identity (determined as
described in subclause 5.4.2.1.1) and the public user identity, any of the
policies described in subclause 7.10.3, then include the policy associated
with the applicable private user identity and the public user identity using
coding described in subclause 7.10.3;
- set the
<unknown-param> element to any additional header field parameters
contained in the Contact header field of the REGISTER request according to
RFC 3680 [43];
- for
contact addresses to be registered: set the state attribute within the
<contact> element to "active"; and set the event attribute
within the <contact> element to "registered";
- for
contact addresses to be re-registered, set the state attribute within the
<contact> element to "active"; and set the event attribute
within the <contact> element to "refreshed" or
"shortened" according to RFC 3680 [43]; and
- for
contact addresses that remain unchanged, if any, leave the <contact>
element unmodified (i.e. the event attribute within the <contact> element
includes the last event that caused the transition to the respective state);
IV) has been
automatically registered or registered by the S-CSCF, and has not been
previously automatically registered:
- set the
<unknown-param> element to any additional header field parameters
contained in the Contact header field of the REGISTER request according to
RFC 3680 [43];
- set the
state attribute within the <registration> element to "active";
- set the
state attribute within the <contact> element to "active"; and
- set the
event attribute within the <contact> element to "created"; or
V) is hosted
(unregistered case) at the S-CSCF:
- set the
state attribute within the <registration> element to
"terminated";
- set the
state attribute within each <contact> element to "terminated";
and
- set the
event attribute within each <contact> element to
"unregistered".
The
S-CSCF shall also terminate the subscription to the registration event package
by setting the Subscription-State header field to the value of "terminated";
and
NOTE 8: The
value of "init" for the state attribute within the
<registration> element is not used.
f) set the callid and cseq attributes for
the <contact> as specified in RFC 3680 [43],
and the first-cseq attribute as specified in RFC 5628 [94]; and
NOTE 9: Errata of RFC 5628 clarifies the usage
of the first-cseq attribute of the <temp-gruu> element.
5) set the P-Charging-Vector
header field with the "icid-value"
header field parameter set to the value populated in the initial request for
the dialog, and
- if the
NOTIFY request is sent towards an AS listed in the initial filter criteria a type 3 "orig-ioi"
header field parameter. The S-CSCF shall set the type
3 "orig-ioi" header field parameter to a value that identifies the
sending network of the request. The S-CSCF shall not include the type 3 "term-ioi"
header field parameter; and
- if the NOTIFY
request is sent towards a public user identity this particular user owns, or
any of the entities identified by the Path header field, a type 1 "orig-ioi"
header field parameter. The S-CSCF shall set the type 1
"orig-ioi" header field parameter to a value that identifies the
sending network of the request. The S-CSCF shall not include the type 1 "term-ioi"
header field parameter.
NOTE 10: When
sending a
NOTIFY request to a subscriber subscribing or
unsubscribing to the reg event package, or when the S-CSCF terminates the
subscription, the event attribute within the <contact> element includes
the last event that caused the transition to the respective state.
The S-CSCF shall only include the
non-barred public user identities in the NOTIFY request.
EXAMPLE 1: If
sip:user1_public1@home1.net is registered, the public user identity
sip:user1_public2@home1.net can automatically be registered. Therefore the entries
in the body of the NOTIFY request look like:
<?xml version="1.0"?>
<reginfo
xmlns="urn:ietf:params:xml:ns:reginfo"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:eri="urn:3gpp:ns:extRegInfo:1.0"
version="0" state="full">
<registration
aor="sip:user1_public1@home1.net" id="as9"
state="active">
<contact
id="76" state="active" event="registered">
<uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>
<unknown-param name="audio"/>
</contact>
</registration>
<registration
aor="sip:user1_public2@home1.net" id="as10"
state="active">
<contact
id="86" state="active" event="created">
<uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>
<unknown-param name="audio"/>
</contact>
<cp:actions>
<eri:rph
ns="wps" val="1"/>
<eri:privSender/>
</cp:actions>
</registration>
</reginfo>
EXAMPLE 2: If
sip:user1_public1@home1.net is registered, the public user identity sip:ep_user1@home1.net
can automatically be registered. sip:ep_user1@home1.net is a dedicated identity
out of the related range indicated in the <wildcardedIdentity> element. Therefore
the entries in the body of the NOTIFY request look like:
<?xml version="1.0"?>
<reginfo
xmlns="urn:ietf:params:xmlns:reginfo"
xmlns:ere="urn:3gpp:ns:extRegExp:1.0"
version="0" state="full">
<registration
aor="sip:user1_public1@home1.net" id="as10"
state="active">
<contact
id="86" state="active" event="created">
<uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>
</contact>
</registration>
<registration
aor="sip:ep_user1@home1.net" id="as11"
state="active">
<contact
id="86" state="active" event="created">
<uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>
</contact>
<ere:wildcardedIdentity>sip:ep_user!.*!@home1.net
</ere:wildcardedIdentity>
</registration>
</reginfo>
When sending a final NOTIFY request with all <registration> element(s)
having their state attribute set to
"terminated" (i.e. all public user identities have been deregistered,
expired or are hosted (unregistered case) at the S-CSCF), the S-CSCF shall also
terminate the subscription to the registration event package by setting the
Subscription-State header field to the value of "terminated".
When all of a UE's contact addresses have
been deregistered (i.e. there is no <contact> element set to
"active" for this UE), the S-CSCF shall consider subscription to the
reg event package belonging to the UE cancelled (i.e. as if the UE had sent a
SUBSCRIBE request with an Expires header field containing a value of zero).
The S-CSCF shall only include the
non-barred public user identities in the NOTIFY request.
When the S-CSCF receives any response to
the NOTIFY request, the S-CSCF shall store the value of the "term-ioi"
header field parameter received in the P-Charging-Vector header field, if
present.
NOTE 11: Any
received "term-ioi" header field parameter will be a type 3 IOI if
received from an AS or a type 1 IOI if received from a public user identity
this particular user owns, or any of the entities identified by the Path header
field. The type 3 IOI identifies the service provider from which the response
was sent and the type 1 IOI identifies the network from which the response was
sent.
When an incoming SUBSCRIBE request
addressed to S-CSCF arrives containing the Event header field with the debug
event package, the S-CSCF shall:
1) check
if, based on the local policy, the request was generated by a subscriber who is
authorised to subscribe to the registration state of this particular user. The
authorized subscribers include:
- all
public user identities this particular user owns, that the S-CSCF is aware of,
and which are not-barred;
- all
the entities identified by the Path header field (i.e. the P-CSCF to which this
user is attached to or the IBCF which encrypted the Path header field); and
- all
the ASs listed in the initial filter criteria that are part of the trust domain;
NOTE 1: An
AS acting as a proxy copies the P-Debug-ID header from an incoming to an
outgoing request, and an AS acting as a B2BUA retrieves debugging configuration
via the Sh interface, if Sh is available. Therefore, only an AS in a different
network from the S-CSCF and acting as a B2BUA needs to subscribe to debug
event.
NOTE 2: The
S-CSCF finds the identity for authentication of the subscription in the
P-Asserted-Identity header field received in the SUBSCRIBE request.
1A) store
the "icid-value" header field parameter received in the
P-Charging-Vector header field;
2) store
the value of the "orig-ioi" header field parameter received in the
P-Charging-Vector header field if present; and
NOTE 3: Any
received "orig-ioi" header field parameter will be either a type 1 or
a type 3 IOI. The type 1 IOI identifies the sending network and the type 3 IOI identifies
the service provider from which the request was sent.
3) generate
a 200 (OK) response acknowledging the SUBSCRIBE request and indicating that the
authorised subscription was successful as described in draft-dawes-sipping-debug [140]. The S-CSCF shall populate
the header fields as follows:
- an
Expires header field, set to either the same or a decreased value as the
Expires header field in SUBSCRIBE request;
- if the
request originated from an ASs listed in the initial filter criteria, a
P-Charging-Vector header field containing the "orig-ioi" header field
parameter, if received in the SUBSCRIBE request, a type 3 "term‑ioi"
header field parameter and the "icid-value" header field parameter. The S-CSCF shall set the type 3 "term-ioi" header field
parameter to a value that identifies the sending network of the response, the
"orig-ioi" header field parameter is set to the previously received
value of "orig-ioi" header field parameter and the "icid-value" header field
parameter is set to the previously received value of "icid-value"
header field parameter in the request; and
- if the
request originated from a public user identity this particular user owns, or
any of the entities identified by the Path header field, a P-Charging-Vector
header field containing the "orig-ioi" header field parameter, if
received in the SUBSCRIBE request, a type 1 "term-ioi" header field
parameter and the
"icid-value" header field parameter. The
S-CSCF shall set the type 1 "term-ioi" header field parameter to a
value that identifies the sending network of the response, the "orig-ioi"
header field parameter is set to the previously received value of "orig-ioi"
header field parameter and the "icid-value" header field parameter is set to the
previously received value of "icid-value" header field parameter in
the request.
The
S-CSCF may set the Contact header field to an identifier uniquely associated to
the SUBSCRIBE request and generated within the S-CSCF, that may help the S-CSCF
to correlate refreshes for the SUBSCRIBE.
NOTE 4: The
S-CSCF could use such unique identifiers to distinguish between UEs, when two
or more users, holding a shared subscription, register under the same public
user identity.
Afterwards the S-CSCF shall perform the
procedures for notification about debug configuration state as described in
subclause 5.4.2.1.4.
For any response that is not a 2xx
response, the S-CSCF shall insert a P-Charging-Vector header field containing
the "orig-ioi" header field parameter, if received in the SUBSCRIBE
request, a type 3 "term-ioi" header field parameter and the "icid-value"
header field parameter. The S-CSCF shall set the type 3
"term-ioi" header field parameter to a value that identifies the
sending network of the response, the "orig-ioi" header field parameter
is set to the previously received value of "orig-ioi" header field
parameter and the
"icid-value" header field parameter is set to the previously received
value of "icid-value" header field parameter in the request.
If the SUBSCRIBE request originated from a
public user identity this particular user owns, or any of the entities
identified by the Path header field, for any response that is not a 2xx
response, the S-CSCF shall insert a P-Charging-Vector header field containing
the "orig-ioi" header field parameter, if received in the SUBSCRIBE
request, a type 1 "term-ioi" header field parameter and the "icid-value"
header field parameter. The S-CSCF shall set the type 1
"term-ioi" header field parameter to a value that identifies the
sending network of the response, the "orig-ioi" header field
parameter is set to the previously received value of "orig-ioi"
header field parameter and
the "icid-value" header field parameter is set to the previously
received value of "icid-value" header field parameter in the request.
When the S-CSCF receives a subscription
refresh request for a dialog that was established by the UE subscribing to the
debug event package, the S-CSCF shall accept the request irrespective if the
user's public user identity specified in the SUBSCRIBE request is either
registered or has been deregistered.
The S-CSCF shall send a NOTIFY request:
- when
an event that changes the debugging configuration of the user occurs. In this
case the
NOTIFY request is sent on all dialogs which have been
established due to subscription to the debug event package of that user; and
- as
specified in RFC 6665 [28].
The S-CSCF
shall set the P-Charging-Vector header field with the "icid-value"
header field parameter set to the value populated in the initial request for
the dialog and:
- if the NOTIFY
request is sent towards an AS listed in the initial filter criteria a type 3 "orig-ioi"
header field parameter. The S-CSCF shall set the type
3 "orig-ioi" header field parameter to a value that identifies the
sending network of the request. The S-CSCF shall not include the type 3 "term-ioi"
header field parameter; and
- if the NOTIFY
request is sent towards a public user identity this particular user owns, or
any of the entities identified by the Path header field, a type 1 "orig-ioi"
header field parameter. The S-CSCF shall set the type 1
"orig-ioi" header field parameter to a value that identifies the
sending network of the request. The S-CSCF shall not include the type 1 "term-ioi"
header field parameter.
The S-CSCF
shall generate the body of the NOTIFY request as specified in draft-dawes-sipping-debug [140].
EXAMPLE: For
user alice@atlanta.com
subscribed to her debug configuration, the entries in the body of the NOTIFY
request look like:
<?xml version="1.0"?>
<debuginfo
xmlns="urn:ietf:params:xml:ns:debuginfo"
version="0"
state="full">
<debugconfig
aor="alice@atlanta.com" id="r01" state="active"
expires="43200">
<session id="r03">
<start-trigger>
<method>INVITE</method>
<from>alice@atlanta.com</from>
</start-trigger>
<stop-trigger>
<time-period>P7M30S</time-period>
</stop-trigger>
<control>
<trace-depth>minimum</trace-depth>
<debug-id>1A346D</debug-id>
</control>
</session>
</debugconfig>
</debuginfo>
NOTE 1: If multiple sessions are to be debugged, then
multiple <session></session> elements are included in the XML, each
one with a different debug-id attribute.
When all of a UE's debug configurations
have expired (i.e. there is no <debugconfig> element set to
"active" for this UE), the S-CSCF shall consider subscription to the
debug event package belonging to the UE cancelled (i.e. as if the UE had sent a
SUBSCRIBE request with an Expires header field containing a value of zero).
When the S-CSCF receives any response to
the NOTIFY request, the S-CSCF shall store the value of the "term-ioi"
header field parameter received in the P-Charging-Vector header field, if
present.
NOTE 2: Any
received "term-ioi" header field parameter will be a type 3 IOI if
received from an AS or a type 1 IOI if received from a public user identity
this particular user owns, or any of the entities identified by the Path header
field. The type 3 IOI identifies the service provider from which the response
was sent and the type 1 IOI identifies the network from which the response was
sent.
Based on operator policy, the S-CSCF may
subscribe to the load-control event package with one or more target SIP
entities. The list of target SIP entities is provisioned.
Subscription to the load-control event
package is triggered by internal events (e.g. the physical device hosting the
SIP entity is power-cycled) or through a management interface.
The S-CSCF shall perform subscriptions to
the load-control event package to a target entity in accordance with RFC 6665 [28]
and with RFC 7200 [201]. When subscribing to the load-control event,
the S-CSCF shall:
1) Send a
SUBSCRIBE request in accordance with RFC 6665 [28] and with RFC 7200 [201]
to the target entity, with the following elements:
- an Expires header field set to a network
specific value;
2) If the
target entity is located in a different network and local policy requires the application
of IBCF capabilities, forward the request to an IBCF acting as an exit point.
The S-CSCF shall automatically refresh ongoing subscription
to the load-control event package either 600 seconds before the expiration time
if the initial subscription was for greater than 1200 seconds, or when half of
the time has expired if the initial subscription was for 1200 seconds or less.
The S-CSCF can terminate a subscription according
to RFC 6665 [28].
Upon receipt of a NOTIFY request with the
Subscription-State header field set to "terminated" and the S-CSCF
has retained the SIP dialog state information for the associated subscription,
once the NOTIFY transaction is terminated, the S-CSCF can remove all the stored
information related to the associated subscription.
Upon receipt of an initial request or a
stand-alone transaction, the S-CSCF shall:
- perform
the procedures for the UE-originating case as described in
subclause 5.4.3.2 if the request makes use of the information for
UE-originating calls, which was added to the Service-Route header field entry
of the S-CSCF during registration (see subclause 5.4.1.2.2F), e.g. the
message is received at a certain port or the topmost Route header field contains
a specific user part or parameter; or,
- perform
the procedures for the UE-originating case as described in
subclause 5.4.3.2 if the topmost Route header field of the request
contains the "orig" parameter. The S-CSCF shall remove the
"orig" parameter from the topmost Route header field; or,
- perform
the procedures for the UE-terminating case as described in
subclause 5.4.3.3 if this information is not used by the request.
For all SIP transactions identified:
- if
priority is supported, as containing an authorised Resource-Priority header
field or a temporarily authorised Resource-Priority header field, or, if such
an option is supported, relating to a dialog which previously contained an
authorised Resource-Priority header field;
the S-CSCF shall give priority over other
transactions or dialogs. This allows special treatment of such transactions or
dialogs.
NOTE 1: The
special treatment can include filtering, higher priority processing, routeing,
call gapping. The exact meaning of priority is not defined further in this
document, but is left to national regulation and network configuration.
When the S-CSCF receives from the UE an
initial request for a dialog, which contains a GRUU and an "ob" SIP URI
parameter in the Contact header field, and multiple contact addresses have been
registered for the specific GRUU, then for all subsequent in-dialog requests
sent toward the UE's, the S-CSCF shall populate the Request-URI with the registered contact address from which
the UE sent the initial request for the dialog.
NOTE 2: When
a given contact address is registered, the S-CSCF can use a dedicated value in
its Service-Route header field entry to identify the given contact address.
When the S-CSCF receives an initial request for a dialog, the S-CSCF can find
out from which contact address the initial request was sent by looking at the
preloaded Route header field (constructed from the Service-Route header field
returned in the response for the REGISTER request) which contains the entry of
the S-CSCF.
When performing SIP digest without TLS, when the S-CSCF receives from the served user
an initial request for a dialog or a request for a standalone transaction, the
S-CSCF may perform the steps in subclause 5.4.3.6 to challenge the request
based on local policy.
NOTE 3: If
the user registration is associated with the state "tls-protected",
then the execution of Proxy-Authorization as described in
subclause 5.4.3.6 is still possible, although it is unlikely this would
add additional security provided the P-CSCF is trusted. Thus, in most cases the
state "tls-protected" will be reason for the S-CSCF to not desire
Proxy-Authentication for this user.
NOTE 4: The
option for the S-CSCF to challenge the request does not apply to a request from
an AS acting as an originating UA.
When performing GPRS-IMS-Bundled
authentication, when the S-CSCF receives from the served user an initial
request for a dialog or a request for a standalone transaction, the S-CSCF
shall check whether a "received" header field parameter exists in the
Via header field provided by the UE. If a "received" header field parameter
exists, S-CSCF shall compare the (prefix of the) IP address received in the
"received" header field parameter against the UE's IP address (or
prefix) stored during registration. If no "received" header field parameter
exists in the Via header field provided by the UE, then S-CSCF shall compare
the (prefix of the) IP address received in the "sent-by" parameter
against the IP address (or prefix) stored during registration. If the stored IP
address (or prefix) and the (prefix of the) IP address in the "received"
Via header field parameter provided by the UE do not match, the S-CSCF shall
reject the request with a 403 (Forbidden) response. In case the stored IP address
(or prefix) and the (prefix of the) IP address in the "received" Via
header field parameter provided by the UE do match, the S-CSCF shall proceed as
described in the remainder of this subclause.
If the S-CSCF supports HSS based P-CSCF
restoration, and receives a request from a P-CSCF that the S-CSCF considers is not
reachable, the S-CSCF shall consider this P-CSCF as being reachable.
If the S-CSCF supports PCRF based P-CSCF
restoration, and receives a request from a P-CSCF that the S-CSCF considers is
in a not reachable, the S-CSCF shall consider this P-CSCF as being reachable.
When the S-CSCF receives from the served
user or from a PSI an initial request for a dialog or a request for a
standalone transaction, and the request is received either from a functional
entity within the same trust domain or contains a valid original dialog
identifier (see step 3) or the dialog identifier (From, To and Call-ID header
fields) relates to an existing request processed by the S-CSCF, then prior to
forwarding the request, the S-CSCF shall:
0) if the
request is received from a P-CSCF that does not support the trust domain
handling of the P-Served-User header field then remove any P-Served-User header
fields;
1) determine
the served user as follows:
a) if the
request contains a P-Served-User header field then
i) determine
the served user by taking the identity contained in a P-Served-User header
field as defined in RFC 5502 [133]. Then check whether the determined
served user is a barred public user identity. In case the said header field
contains the served user identity is a barred public user identity for the
user, then the S-CSCF shall reject the request by generating a 403 (Forbidden)
response. Otherwise, the S-CSCF shall save the public user identity of the
served user and continue with the rest of the steps;
NOTE 5: If the P-Served-User header
field contains a barred public user identity, then the message has been
received, either directly or indirectly, from a non-compliant entity which
should have had generated the content with a non-barred public user identity.
b) if the
request does not contain a P-Served-User header field then
i) determine
the served user by taking the identity contained in one of the URI(s) of the P-Asserted-Identity header field. In
case the determined served user is a barred public user identity, then the
S-CSCF shall reject the request by generating a 403 (Forbidden) response.
Otherwise, the S-CSCF shall save the public user identity of the served user
and continue with the rest of the steps; and
ii) if the
P-Asserted-Identity header field contains two URIs and the URI other than the determined served user is not an
alias of the determined served user or is barred then act based on local
policy, e.g. reject the request by generating a 403 (Forbidden) response or
remove the URI not identifying the
determined served user from the P-Asserted-Identity header field;
NOTE 6: If
the P-Asserted-Identity header field contains a barred public user identity,
then the message has been received, either directly or indirectly, from a
non-compliant entity which should have had generated the content with a
non-barred public user identity.
1A) if
the Contact is a GRUU, but is not valid as defined in subclause 5.4.7A.4,
then return a 4xx response as specified in RFC 5627 [93];
2) store
the value of the "orig-ioi" header field parameter received in the
P-Charging-Vector header field if present, and remove it from any forwarded
request;
NOTE 7: Any
received "orig-ioi" header field parameter will be either a type 1 IOI
or a type 3 IOI. The type 1 IOI identifies the network from which the request
was sent and the type 3 IOI identifies the service provider from which the
request was sent (AS initiating a session on behalf of a user or a PSI);
3) check
if an original dialog identifier that the S-CSCF previously placed in a Route
header field is present in the topmost Route header field of the incoming
request.
- If not
present, the S-CSCF shall build an ordered list of initial filter criteria
based on the public user identity of the served user (as determined in step 1) of
the received request as described in 3GPP TS 23.218 [5].
- If
present, the request has been sent from an AS in response to a previously sent
request, an ordered list of initial filter criteria already exists and the
S-CSCF shall not change the ordered list of initial filter criteria even if the
AS has changed the P-Served-User header field or the P-Asserted-Identity header
field;
NOTE 8: An original dialog
identifier is sent to each AS invoked due to iFC evaluation such that the
S-CSCF can associate requests as part of the same sequence that trigger iFC
evaluation in priority order (and not rely on SIP dialog information that can change
due to B2BUA AS). If the same original dialog
identifier is included in more than one request from a particular AS (based on
service logic in the AS), then the S-CSCF will continue the iFC evaluation
sequence rather than build a new ordered list of iFC;
4) remove
its own SIP URI from the topmost
Route header field;
4A) if a reference location
was received from the HSS at registration as part of the user profile and the
request does not contain a message body with the content type application/pidf+xml
in accordance with RFC 6442 [89] and does not contain a
P-Access-Network-Info header field containing the "network-provided"
parameter, the S-CSCF shall insert a P-Access-Network-Info header field
constructed according to the reference location received from the HSS and
containing the "network-provided" parameter. The access type information
received from the HSS shall be mapped into the corresponding access-type
parameter of the P-Access-Network-Info header field and the location
information shall be mapped into the location parameter corresponding to the
access-type parameter, i.e. into "dsl-location" parameter,
"fiber-location" parameter or "eth-location" parameter;
4B) if
there was an original dialog identifier present in the topmost Route header field
of the incoming request and the request is received from a functional entity within
the same trust domain and contains a P-Asserted-Service header field, continue
the procedure with step 5;
4C) if the request contains a P-Preferred-Service
header field, check whether the ICSI value contained in the P-Preferred-Service
header field is part of the set of the subscribed services for the served user
and determine, using operator-configured data, whether the contents of the
request match the ICSI for the subscribed service. The operator-configured data
used to determine if there is a matching between the request and the ICSI value
may be based on any information in the request (e.g. SDP media capabilities,
Content-Type header field, request method). Then:
a) if
there is no match between the request and the ICSI value, as an operator option, the S-CSCF may reject the request by
generating a 403 (Forbidden) response. Otherwise remove the P-Preferred-Service
header field and continue with the rest of the steps; and
b) if there
is a match between the request and the ICSI value, then
include a P-Asserted-Service header field in the request containing the ICSI
value contained in the P-Preferred-Service header field, remove the
P-Preferred-Service header field, and continue the procedure with step 5;
4D) if the request does not contain a
P-Preferred-Service header field, check, using
operator-configured data, whether the contents of the request
match a subscribed
service for each and any of the subscribed services for the served
user:
a) if not,
as an operator option, the S-CSCF may reject the request
by generating a 403 (Forbidden) response; and
b) if so, and
if the request is related to an IMS communication service and the IMS
communication service requires the use of an ICSI value then select an ICSI
value for the related IMS communication service and include a
P-Asserted-Service header field in the request containing the selected ICSI
value; and
NOTE 9: If more than one ICSI values match the contents of the request, the
S-CSCF selects an ICSI value based on local policy.
c) if so,
and if the request is related to an IMS communication
service and the IMS communication service does not require the use of an ICSI
value then continue without including an ICSI value; and
d) if so, and
if the request does not relate to an IMS communication service (or if the S-CSCF is unable to unambiguously determine the service
being requested but decides to allow the session to continue)
then continue without including an ICSI value;
5) check
whether the initial request matches any unexecuted initial filter criteria. If
there is a match, then the S-CSCF shall select the first matching unexecuted
initial filter criteria from the ordered list of initial filter criteria and
the S-CSCF shall:
a) insert
the AS URI to be contacted into
the Route header field as the topmost entry followed by its own URI populated as specified in the
subclause 5.4.3.4;
NOTE 10: If
the AS is accessed via an ISC gateway function, then the URI
will be the address of the ISC gateway function.
b) if the
S-CSCF supports the P-Served-User extension as specified in RFC 5502 [133]
and draft-mohali-dispatch-originating-cdiv-parameter [239] insert
P-Served-User header field populated with the served user identity as
determined in step 1. If required by operator policy, the S-CSCF shall:
- if the
associated session case is "Originating" as specified in
3GPP TS 29.228 [14], include the sescase header field parameter
set to "orig" and the regstate header field parameter set to "reg";
- if the
associated session case is "Originating_Unregistered" as specified in
3GPP TS 29.228 [14], include the sescase header field parameter
set to "orig" and the regstate header field parameter set to "unreg";
- if the
associated session case is "Originating_CDIV" as specified in
3GPP TS 29.228 [14], include the "orig-cdiv" header
field parameter, defined in draft-mohali-dispatch-originating-cdiv-parameter [239];
and
c) if the
AS is located outside the trust domain then the S-CSCF shall remove the
access-network-charging-info parameter in the P-Charging-Vector header field from
the request that is forwarded to the AS; if the AS is located within the trust
domain, then the S-CSCF shall retain the access-network-charging-info parameter
in the P-Charging-Vector header field in the request that is forwarded to the
AS;
d) insert
a type 3 "orig-ioi" header field parameter in place of any received "orig-ioi"
header field parameters in the P-Charging-Vector header field. The S-CSCF shall
set the type 3 "orig-ioi" header field parameter to a value that
identifies the sending network of the request. The S-CSCF shall not include the
type 3 "term-ioi" header field parameter;
e) remove
the "transit-ioi" header field parameter, if received;
f) based
on operator policy insert in a Relayed-Charge header field the value of the
received "transit-ioi" header field parameter in the
P-Charging-Vector header field;
g) if the
S-CSCF supports using a token to identify the registration and if a registration exists, insert a "+g.3gpp.registration-token" Feature-Caps header field parameter, as defined in subclause 7.9A.8,
set to the same value as included in the "+g.3gpp.registration-token"
Contact header field parameter of the third party REGISTER
request sent to the AS
when the UE registered; and
h) if an IP address associated with the served
user and the AS SIP URI is stored as described in subclause 5.4.0 exists, then the S-CSCF
forwards the SIP message to the IP address associated with the served user and
the AS SIP URI;
NOTE 11: Depending
on the result of processing the filter criteria the S-CSCF might contact one or
more AS(s) before processing the outgoing Request-URI.
NOTE 12: An AS can activate or deactivate its own filter
criteria via the Sh interface. As the S-CSCF checks initial filter criteria
only on receipt of an initial request for a dialog, or a standalone
transaction, a modified service profile will have no impact on transactions or
dialogs already in progress and the modified profile will be effective only for
new transactions and dialogs. If the S-CSCF receives a modification of the iFC
during their execution, then it should not update the stored initial Filter Criteria until the iFC
related to the initial request have been completely executed.
6) if
there was no original dialog identifier present in the topmost Route header field
of the incoming request store the value of the "icid-value" header
field parameter received in the P-Charging-Vector header field and retain the "icid-value"
header field parameter in the P-Charging-Vector header field. Optionally, the
S-CSCF may generate a new, globally unique ICID and insert the new value in the
"icid-value" header field parameter of the P-Charging-Vector header field
when forwarding the message. If the S-CSCF creates a new ICID, then it is
responsible for maintaining the two ICID values in the subsequent messaging;
7) in step
5, if the initial request did not match any unexecuted initial filter criteria
(i.e. the request is not forwarded to an AS):
a) remove the
received "transit-ioi" from the P-Charging-Vector header field, if present;
b) insert a
type 2 "orig-ioi" header field parameter into the P-Charging-Vector
header field. The S-CSCF shall set the type 2 "orig-ioi" header field
parameter to a value that identifies the sending network. The S-CSCF shall not
include the type 2 "term-ioi" header field parameter; and
c) remove
the Relayed-Charge header field, if present;
8) insert
a P-Charging-Function-Addresses header field populated with values received
from the HSS if the request does not contain a P-Charging-Function-Addresses
header field and the message is forwarded within the S-CSCF home network,
including towards AS;
9) if
there was no original dialog identifier present in the topmost Route header field
of the incoming request and if the served user is not considered a privileged
sender then:
a) if the
P-Asserted-Identity header field contains only a SIP URI
and if the S-CSCF has knowledge that the SIP URI
contained in the received P-Asserted-Identity header field is an alias SIP URI for a tel URI,
add a second P-Asserted-Identity header field containing this tel-URI, including the display name associated with the
tel URI, if available; and
b) if the
P-Asserted-Identity header field contains only a tel URI,
the S-CSCF shall add a second P-Asserted-Identity header field containing a SIP
URI. The added SIP URI shall contain in the user part a "+"
followed by the international public telecommunication number contained in tel URI, and user's home domain name in the hostport
part. The added SIP URI shall
contain the same value in the display name as contained in the tel URI. The S-CSCF shall also add a "user"
SIP URI parameter equals
"phone" to the SIP URI;
NOTE 13: If
tel URI is shared URI so is the alias SIP URI.
10) if the
request is not forwarded to an AS and if the outgoing Request-URI is:
- a SIP URI with the user part starting with a + and the "user"
SIP URI parameter equals
"phone", and if configured per local operator policy, the S-CSCF
shall perform the procedure described here. Local policy can dictate whether
this procedure is performed for all domains of the SIP URI,
only if the domain belongs to the home network, or not at all. If local policy
indicates that the procedure is to be performed, then the S-CSCF shall
translate the international public telecommunications number contained in the
user part of the SIP URI (see
RFC 3966 [22]) to a globally routeable SIP URI
using either an ENUM/DNS translation mechanism with the format specified in
RFC 6116 [24], or any other available database. Database aspects of
ENUM are outside the scope of the present document. An S-CSCF that implements
the additional routeing functionality described in annex I may forward the
request without attempting translation. If an agreement exists between the home
network and the visited network to support roaming architecture for voice over IMS with local
breakout, the S-CSCF does not enable NP capabilities, and the S-CSCF decides to loopback the call to the
visited network, the S-CSCF may forward the request
without attempting translation. If a translation is in fact performed and it succeeds,
the S-CSCF shall update the Request-URI
with the globally routeable SIP URI
either returned by ENUM/DNS or obtained from any other available database. If
this translation fails, the request may be forwarded to a BGCF or any other
appropriate entity (e.g. a MRFC to play an announcement) in the originator's
home network or the S-CSCF may send an appropriate SIP response to the
originator. When forwarding the request to a BGCF or any other appropriate
entity, the S-CSCF shall leave the original Request-URI
containing the SIP URI with "user"
SIP URI parameter equals phone
unmodified. If the request is forwarded, the S-CSCF shall remove the
access-network-charging-info parameter from the P-Charging-Vector header field prior
to forwarding the message;
- a SIP URI with a "user" SIP URI parameter equals "dialstring" and the
domain name of the SIP URI belongs
to the home network (i.e. the local number analysis and handling is either
failed in the appropriate AS or the request has not been forwarded to AS for
local number analysis and handling at all), either forward the request to any
appropriate entity (e.g a MRFC to play an announcement) in the originator's
home network or send an appropriate SIP response to the originator;
- a SIP URI with a local number (see
RFC 3966 [22]) in the user part and a "user" SIP URI parameter equals "phone" and the
domain name of the SIP URI belongs
to the home network (i.e. the local number analysis and handling is either
failed in the appropriate AS or the request has not been forwarded to AS for
local number analysis and handling at all), either forward the request to to a
BGCFor any appropriate entity (e.g a MRFC to play an announcement) in the
originator's home network or send an appropriate SIP response to the originator;
- a tel URI containing a global number (see
RFC 3966 [22]) in the international format, the S-CSCF shall
translate the E.164 address to a globally routeable SIP URI
using either an ENUM/DNS translation mechanism with the format specified in
RFC 6116 [24], or any other available database. Database aspects of
ENUM are outside the scope of the present document. An S-CSCF that implements
the additional routeing functionality described in annex I may forward the
request without attempting translation. If an agreement exists between the home
network and the visited network to support roaming architecture for voice over IMS with local
breakout, the S-CSCF does not enable NP capabilities, and the S-CSCF decides to loopback the call to the
visited network, the S-CSCF may forward the request
without attempting translation. If this translation is in fact performed and
it succeeds, the S-CSCF shall update the Request-URI
with the globally routeable SIP URI
returned by ENUM/DNS or any other available database. If this translation
fails, the request may be forwarded to a BGCF or any other appropriate entity
(e.g a MRFC to play an announcement) in the originator's home network or the
S-CSCF may send an appropriate SIP response to the originator. When forwarding
the request to a BGCF or any other appropriate entity, the S-CSCF shall leave
the original Request-URI
containing the tel URI unmodified.
If the request is forwarded, the S-CSCF shall remove the
access-network-charging-info parameter from the P-Charging-Vector header field prior
to forwarding the message;
- a tel URI containing a local number (see
RFC 3966 [22]) (i.e. the local number analysis and handling is either
failed in the appropriate AS or the request has not been forwarded to AS for
local number analysis and handling at all), either forward the request to a
BGCF or any other appropriate entity (e.g. a MRFC to play an announcement) in
the originator's home network or send an appropriate SIP response to the
originator;
- a pres
URI or an im URI, the S-CSCF shall forward the request as
specified in RFC 3861 [63]. In this case, the S-CSCF shall not modify
the received Request-URI: and
- a
service URN, e.g. a service URN with a top-level service type of
"sos" as specified in RFC 5031 [69]. In this case the S-CSCF
shall not modify the received Request-URI.
NOTE 14: If
there is no SIP-based transport found after applying the procedure specified in
RFC 3861 [63], the S-CSCF can forward the request to a translating
gateway.
Additional procedures apply if the S-CSCF
supports NP capabilities and these capabilities are enabled by local policy,
and the database used for translation from an international public
telecommunications number to a SIP URI
also provides NP data (for example, based on the PSTN Enumservice as defined by
RFC 4769 [114] or other appropriate data bases). If the above
translation from an international public telecommunications number to a SIP URI failed, but NP data was obtained from the
database and there is no "npdi" parameter in the received request,
then the S-CSCF shall, based on operator policy, replace the URI in the Request-URI
with the obtained NP data, prior to forwarding the request to the BGCF or other
appropriate entity. If the received request already contains a tel-URI "npdi" parameter, then the S-CSCF may
update the URI with the obtained
NP data. The URI is updated by the
S-CSCF by adding NP parameters defined by RFC 4694 [112]. If the
Request-URI is a tel-URI, then an "npdi" tel-URI parameter is added to indicate that NP data
retrieval has been performed, and if the number is ported, an "rn"
tel-URI parameter is added to
identify the ported-to routeing number. If the Request-URI
is in the form of a SIP URI
user=phone, the "npdi" and "rn" tel-URI
parameters are added as described above to the userinfo part of the SIP URI;
NOTE 15: When
the S-CSCF replaces the tel-URI in
the Request-URI with the obtained
NP data, all tel URI parameters in
the received Request-URI will be
replaced by the obtained NP data.
10A) if the
request is not forwarded to an AS and if local policy requires the application
of additional routeing capabilities, as defined in annex I, the S-CSCF shall
apply the additional routeing capabilities if they are locally available or
forward the request to an entity that implements the additional routeing
capabilities;
10B) if an
agreement exists between the home network and the visited network to support Roaming Architecture for Voice over
IMS with Local Breakout then continue with the following steps. Otherwise
continue with step 11. If:
- the
top most Route header contains an indication that this is the UE-originating
case;
NOTE 16: This
indication can e.g. be in a URI
parameter, a character string in the user part of the URI
or can be a port number in the URI
added by the S-CSCF during the registration in the Service-Route header field.
- the UE
is roaming (as identified by the P-Visited-Network-ID header field value in the
original REGISTER request); and
- the
request is an INVITE request;
determine
if loopback routeing is applicable for this request using local policy, and
save this decision for subsequent processing along with the following
information:
a) any URI representing the TRF address preference
received from the visited network; and
b) the
ICID received in the request.
In
addition, the S-CSCF shall also include in the request a Feature-Caps header field with the "+g.3gpp.home-visited"
header field parameter according
to RFC 6809 [190] with the "+g.3gpp.home-visited" header
field parameter set to
the identifier of the visited network received in the P-Visited-Network-ID
header field in the original registration request;
10C) if the
request is an INVITE request, then determine whether loopback is applied for
this request. The information saved in step 10B, and the presence or absence of
the Feature-Caps header
field with the "+g.3gpp.home-visited" header field parameter in the received INVITE
request are taken into account in making this decision:
a) if
loopback routeing is not to be performed for this request remove any "+g.3gpp.trf"
header field parameter or "+g.3gpp.home-visited" header field
parameter from the Feature-Caps header field of the outgoing request;
b) if
loopback routeing is applied for this request;
i) remove all entries in the Route
header field;
ii) if a "+g.3gpp.trf"
header field parameter with a parameter value containing a valid URI, is included in the Feature-Caps header field
of the request, insert the URI in
a Route header field;
iii) if a "+g.3gpp.trf"
header field parameter, with a parameter value containing a valid URI is not included in the Feature-Caps header
field of the request, insert a locally configured TRF address, associated with
the visited network for this call, in the Route header field;
iv) remove
any "+g.3gpp.home-visited" header field parameter from the
Feature-Caps header field of the outgoing request;
v) insert the "+g.3gpp.loopback" header field parameter as specified in subclause 7.9A.4 in the Feature-Caps header field of
the request, in accordance with the RFC 6809 [190].
If providing the
identifier of the home network is supported by the S-CSCF and the visited
network, the S‑CSCF may based on operator agreement insert the "+g.3gpp.loopback"
header field parameter set
to the identifier of the home network;
vi) if included
in the incoming request, remove the "+g.3gpp.trf" header field
parameter from the Feature-Caps header field from the outgoing request;
vii) remove a
type 2 "orig-ioi" header field parameter that was added in step 7 from
the P-Charging-Vector header field and insert a type 1 "orig-ioi"
header field parameter into the P-Charging-Vector header field. The S-CSCF
shall set the type 1 "orig-ioi" header field parameter to a value
that identifies the network in which the S-CSCF resides. The S-CSCF shall not
include the "term-ioi" header field parameter; and
viii) if
the S-CSCF supports indicating the traffic leg associated with a URI as specified in RFC 7549 [225] and if
an "iotl" SIP URI
parameter is not included in the TRF URI
in the Route header field and if required by local policy, append an "iotl" URI parameter with a value set to "homeA-visitedA" to
the URI in the Route header field; and
c) if the
final decision on loopback routeing is deferred to a subsequent entity in the
home network, the BGCF, then the S-CSCF includes, if absent, in the request a Feature-Caps header field with the "+g.3gpp.home-visited" header
field parameter, with the parameter value set to the identifier of the visited
network received in the P-Visited-Network-ID header field in the original registration
request. The S-CSCF is expected to know by means of network configuration that
such a subsequent entity exists; and
NOTE 17: The subsequent
entity in the home network, the BGCF, will remove the "+g.3gpp.home-visited" header field parameter from the Feature-Caps header field
when a final routeing decision is taken.
11) determine
the destination address (e.g. DNS access) using the URI
placed in the topmost Route header field if present, otherwise based on the
Request-URI. If the destination
requires interconnect functionalities (e.g. the destination address is of an IP
address type other than the IP address type used in the IM CN subsystem), the
S-CSCF shall forward the request to the destination address via an IBCF in the
same network;
12) if network
hiding is needed due to local policy, put the address of the IBCF to the
topmost Route header field;
13) in case
of an initial request for a dialog:
a) determine
the need for GRUU processing. GRUU processing is required if:
- an
original dialog identifier that the S-CSCF previously placed in a Route header field
is not present in the topmost Route header field of the incoming request (this
means the request is not returning after having been sent to an AS), and
- the
contact address contains a GRUU that was either assigned by the S-CSCF that is
valid as specified in subclause 5.4.7A.4 or a temporary GRUU self assigned
by the UE based on the "temp-gruu-cookie" header parameter provided
to the UE;
NOTE 18: The
procedures for determining that a URI
is a temporary GRUU
assigned by the UE are specified in subclause 7.1.2.3 of RFC 6140 [191].
b) if GRUU
processing is not required and the initial request originated from a served
user, then determine the need to record-route for other reasons:
- if the
request is routed to an AS which is part of the trust domain, the S-CSCF shall decide,
based on operator policy, whether to record-route or not. The decision is
configured in the S-CSCF using any information in the received request that may
otherwise be used for the initial filter criteria. If the request is
record-routed the S-CSCF shall create a Record-Route header field containing
its own SIP URI;
- if the request
is a SUBSCRIBE request and routed elsewhere, the S-CSCF shall decide, based on
operator policy, whether to record-route or not. The decision is configured in
the S-CSCF using any information in the received request (e.g. event package
name). If the request is record-routed the S-CSCF shall create a Record-Route
header field containing its own SIP URI;
or
NOTE 19: Some subscriptions to event
packages (e.g. presence) can result in virtually persistent subscriptions and
if the S-CSCF Record-Routes this can prevent reassignment of the S-CSCF.
NOTE 20: If the S-CSCF does not Record-Route
the initial SUBSCRIBE request, it will not be possible to perform SIP digest authentication
of SIP requests sent inside the SIP dialog related to the associated
subscription.
- if the
request not a SUBSCRIBE request and is routed elsewhere, create a Record-Route
header field containing its own SIP URI;
NOTE 21: For
requests originated from a PSI the S-CSCF can decide whether to record-route or
not based on operator policy.
c) if GRUU
processing is required, the S-CSCF shall create a Record-Route header field containing
its own SIP URI;
d) if GRUU
processing is required, the S-CSCF shall save an indication that GRUU-routeing
is to be performed for in-dialog requests that reach the S-CSCF because of the
Record-route header field added in step c);
NOTE 22: The
manner of representing the GRUU-routeing indication is a private matter for the
S-CSCF. The indication is used during termination processing of in-dialog
requests to cause the S-CSCF to replace a Request-URI
containing a GRUU with the corresponding registered contact address. It can be
saved using values in the Record-Route header field, or in dialog state.
14) based on
the destination user (Request-URI),
remove any P-Access-Network-Info header field and the
access-network-charging-info parameter in the P-Charging-Vector header field prior
to forwarding the message;
14A) if the request is not routed to an AS, to a BGCF or to
an entity that implements the additional routeing
functionality, remove the P-Served-User header field prior to forwarding the request;
14B) if the S-CSCF supports indicating the traffic leg as specified in RFC 7549 [225],
the request is not routed to an AS, to a BGCF or to an
entity that implements the additional routeing
functionality, loopback
routeing is not to be performed for this request, required by local policy and the Request-URI
contains a SIP URI, append the
"iotl" SIP URI parameter
set to "homeA-homeB" to the Request-URI;
15) route
the request based on SIP routeing procedures;
16) if the
request is an INVITE request, save the Contact, CSeq and Record-Route header
field values received in the request such that the S-CSCF is able to release
the session if needed;
17) if the
request matches a trigger for starting logging of SIP signalling, as described
in draft-dawes-sipping-debug [140],
start to log SIP signalling for this dialog according to its debug
configuration; and
18) if the
S-CSCF supports using a token to identify the registration and if the request
is not forwarded to an AS, remove the "+g.3gpp.registration-token" Feature-Caps header field parameter, defined in
subclause 7.9A.8, if received in the request.
When the S-CSCF receives, an initial
request for a dialog or a request for a standalone transaction, from an AS
acting on behalf of an unregistered user, the S-CSCF shall:
1) execute
the procedures described in the steps 1, 2, 3, 4, 4B, 4C, 4D, 5, 6, 7, 8, 9,
10, 11, 12, 13, 14, 15 and 16 in the above paragraph (when the S-CSCF receives,
from a registered served user, an initial request for a dialog or a request for
a standalone transaction).
NOTE 23: When
the S-CSCF does not have the user profile, before executing the actions as
listed above, it initiates the S-CSCF Registration/deregistration notification procedure,
as described in 3GPP TS 29.228 [14]; with the purpose of
downloading the relevant user profile (i.e. for unregistered user) and informs
the HSS that the user is unregistered. The S-CSCF will assess triggering of
services for the unregistered user, as described in
3GPP TS 29.228 [14]. When requesting the user profile, and the
request received by the S-CSCF contains a P-Profile-Key header field, the
S-CSCF can include the header field value in S-CSCF Registration/deregistration
notification. If the response from the HSS includes a Wildcarded Public
Identity AVP, and if the request
received by the S-CSCF did not include a P-Profile-Key header field, the S-CSCF
uses the AVP value to set the P-Profile-Key
header field before forwarding the request to an AS.
When the S-CSCF receives a request
initiated by the served user for which the S-CSCF does not have the user
profile or does not trust the data that it has (e.g. due to restart), the
S-CSCF shall attempt to retrieve the user profile from the HSS. If the S-CSCF receives
a Diameter result code of DIAMETER_UNABLE_TO_COMPLY as defined in 3GPP TS 29.228 [14], the S-CSCF supports S-CSCF restoration procedures, and the Request-URI of the request does not match an emergency
service URN, i.e. a service URN with a top-level service type of
"sos" as specified in RFC 5031 [69], then the S-CSCF shall:
I) reject
the request by returning a 504 (Server Time-out) response to the UE;
II) assume
that the UE supports version 1 of the XML Schema for the 3GPP IM CN subsystem
XML body if support for the 3GPP IM CN subsystem XML body as described in
subclause 7.6 in the Accept header field is not indicated; and
III) include
in the 504 (Server Time-out) response:
- a
Content-Type header field with the value set to associated MIME type of the 3GPP
IM CN subsystem XML body as described in subclause 7.6.1;
- a
P-Asserted-Identity header field set to the value of the SIP URI of the S-CSCF included in the Service-Route
header field (see subclause 5.4.1.2.2F) during the registration of the
user whose UE sent the request causing this response; and
- a 3GPP IM CN subsystem XML body:
a) an <ims-3gpp>
element with the "version" attribute set to "1" and with an
<alternative-service> child element, set to the parameters of the
alternative service;
i) a
<type> child element, set to "restoration" (see table 7.6.2)
to indicate that S-CSCF restoration procedures are supported;
ii) a
<reason> child element, set to an operator configurable reason; and
iii) an <action>
child element, set to "initial-registration" (see table 7.6.3).
NOTE 24: These
procedures do not prevent the usage of unspecified reliability or recovery
techniques above and beyond those specified in this subclause.
Depending on operator configuration (see
subclause 5.4.1.8), when the S-CSCF receives a request with a Request-URI that does not match an emergency service URN,
i.e. a service URN with a top-level service type of "sos" as
specified in RFC 5031 [69], the request initiated by the served user
for which the S-CSCF has modified but not synchronized the service profile for
the served user and the S-CSCF supports S-CSCF restoration procedures, then the
S-CSCF shall reject the request as described in items I), II) and III).
If the
S-CSCF:
a) fails to receive a SIP response within a
configurable time; or
b) receives a 408 (Request
Timeout) response or a
5xx response from the AS without previously receiving
a 1xx response to the original SIP request, and without previously receiving a
SIP request from the AS that contained the same original dialog identifier as
the original request;
the S-CSCF
shall:
- if the default handling defined in the
filter criteria indicates the value "SESSION_CONTINUED" as specified
in 3GPP TS 29.228 [14] or no default handling is
indicated, execute the procedure from step 5; and
- if the default handling defined in
the filter criteria indicates the value "SESSION_TERMINATED" as
specified in 3GPP TS 29.228 [14],
either forward the received response or, if the request is an initial INVITE
request, send a 408 (Request Timeout) response or a 5xx response towards the
served UE as appropriate (without verifying the matching of filter criteria of
lower priority and without proceeding for further steps).
If the
S-CSCF receives any final response from the AS, the S-CSCF shall forward the
response towards the served UE (without verifying the
matching of filter criteria of lower priority and without proceeding for
further steps).
When the S-CSCF receives any response to
the above request containing a Relayed-Charge header field, and the next hop is
not an AS, the S-CSCF shall remove the Relayed-Charge header field from the
forwarded response.
When the S-CSCF receives any response to
the above request, the S-CSCF may:
1) apply
any privacy required by RFC 3323 [33] and RFC 3325 [34] to
the P-Asserted-Identity header field.
NOTE 25: The
P-Asserted-Identity header field would normally only be expected in 1xx or 2xx
responses.
NOTE 26: The
optional procedure above is in addition to any procedure for the application of
privacy at the edge of the trust domain specified by RFC 3325 [34].
When the S-CSCF receives any response to
the above request, the S-CSCF shall:
1) If
logging is in progress for this dialog, check whether a trigger for stopping
logging of SIP signalling has occurred, as described in draft-dawes-sipping-debug [140]. If a stop trigger event
has occurred then stop logging of signalling, else determine, by checking its
debug configuration, whether to log the response.
When the S-CSCF receives any response to
the above request containing a "term-ioi" header field parameter in
the P-Charging-Vector header field, the S-CSCF shall:
1) store
the value of the received "term-ioi" header field parameter if
present;
2) remove
all received "orig-ioi", "term-ioi" and
"transit-ioi" header field parameters from the forwarded response;
3) include
the stored "orig-ioi" header field parameter if received in the
request;
4) include
a type 1 "term-ioi" header field parameter if next hop is not an AS,
or a type 3 "term-ioi" header field parameter. The
"term-ioi" header field parameter is set to a value that identifies
the sending network of the response
NOTE 27: Any
received "term-ioi" header field parameter will be a type 2 IOI, if
received from an S-CSCF, or type 3 IOI, if received from an AS, or type 1 IOI
if the S-CSCF performed
loopback routeing for this request. A type 2 IOI identifies
the sending network of the response, a type 3 IOI identifies the sending
service provider of the response, and a type 1 IOI identifies the visited
network of the served user.
5) include
any received "transit-ioi" header field parameter, from the
P-Charging-Vector header field, in a Relayed-Charge header field, if the next
hop is an AS.
When the S-CSCF receives any 1xx or 2xx
response to the initial request for a dialog, if the response corresponds to an
INVITE request, the S-CSCF shall save the Contact and Record-Route header field
values in the response in order to be able to release the session if needed.
When the S-CSCF receives any 1xx or 2xx
response to an initial request for a dialog or a request for a standalone
transaction, if the response is forwarded within the S-CSCF home network and not to an AS, the
S-CSCF shall insert a P-Charging-Function-Addresses header field populated with
values received from the HSS.
When
the S-CSCF, upon sending an initial INVITE request that
includes an IP address in the SDP offer (in "c=" parameter), receives an error response indicating that the IP address type is
not supported, (e.g., the S-CSCF receives the 488 (Not
Acceptable Here) with 301 Warning header field indicating "incompatible network
address format"), the S-CSCF
shall either:
- fork the initial INVITE request to the
IBCF; or
- process the error
response and forward it using the Via header field.
NOTE 28: If
the S-CSCF knows that the originating UE supports both IPv6 and IPv4
addresses simultaneously, the S-CSCF will forward the error response
to the UE using the Via header field.
Editor's Note: How the S-CSCF determines
whether the UE supports both IPv6 and IPv4 addressing simultaneously is for
further study.
When the S-CSCF receives from the served
user a target refresh request for a dialog, prior to forwarding the request the
S-CSCF shall:
0A) if
the dialog is related to an IMS communication service determine whether the
contents of the request (e.g. SDP media capabilities, Content-Type header field)
match the IMS communication service as received as the ICSI value in the
P-Asserted-Service header field in the initial request. As an operator option, if the contents of the request
do not match the IMS communication service the S-CSCF
may reject the request by generating a status code reflecting which added
contents are not matching. Otherwise, continue with the rest of the steps;
1) remove
its own URI from the topmost Route
header field;
2) create
a Record-Route header field containing its own SIP URI;
3) for
INVITE dialogs (i.e. dialogs initiated by an INVITE request), save the Contact
and CSeq header field values received in the request such that the S-CSCF is
able to release the session if needed;
4) in case
the request is routed towards the destination user (Request-URI) or in case the request is routed to an AS
located outside the trust domain, remove the access-network-charging-info
parameter in the P-Charging-Vector header field;
5) route
the request based on the topmost Route header field; and
6) if the
request was sent on a dialog for which logging of signalling is in progress,
check whether a trigger for stopping logging of SIP signalling has occurred, as
described in draft-dawes-sipping-debug [140].
If a stop trigger event has occurred then stop logging of signalling, else
determine, by checking its debug configuration, whether to log the response.
When the S-CSCF receives any response to
the above request, the S-CSCF shall:
1) If
logging is in progress for this dialog, check whether a trigger for stopping
logging of SIP signalling has occurred, as described in draft-dawes-sipping-debug [140]. If a stop trigger event
has occurred then stop logging of signalling, else determine, by checking its
debug configuration, whether to log the response.
When the S-CSCF receives any 1xx or 2xx
response to the target refresh request for an INVITE dialog, the S-CSCF shall replace
the saved Contact header field values in the response such that the S-CSCF is
able to release the session if needed.
If the S-CSCF inserted in the initial
request for the dialog the header field parameters into the Feature-Caps header
field then the S-CSCF shall include the header field parameters with the same parameter
values into the Feature-Caps header field in any target refresh request for the
dialog, and in each 1xx or 2xx response to target refresh request sent in the
same direction.
When the S-CSCF receives from the served
user a subsequent request other than a target refresh request for a dialog,
prior to forwarding the request the S-CSCF shall:
1) remove
its own URI from the topmost Route
header field;
2) in case
the request is routed towards the destination user (Request-URI) or in case the request is routed to an AS
located outside the trust domain, remove the access-network-charging-info
parameter in the P-Charging-Vector header field; and
3) route
the request based on the topmost Route header field; and
4) if the
request was sent on a dialog for which logging of signalling is in progress,
check whether a trigger for stopping logging of SIP signalling has occurred, as
described in draft-dawes-sipping-debug [140].
If a stop trigger event has occurred, stop logging of signalling, else
determine, by checking its debug configuration, whether to log the request.
When the S-CSCF receives any response to
the above request, the S-CSCF shall:
1) If
logging is in progress for this dialog, check whether a trigger for stopping
logging of SIP signalling has occurred, as described in draft-dawes-sipping-debug [140]. If a stop trigger event
has occurred then stop logging of signalling, else determine, by checking its
debug configuration, whether to log the response.
With the exception of 305 (Use Proxy)
responses, the S-CSCF shall not recurse on 3xx responses.
5.4.3.3 Requests terminated at the served user
For all SIP transactions identified:
- if
priority is supported, as containing an authorised Resource-Priority header
field or a temporarily authorised Resource-Priority header field, or, if such
an option is supported, relating to a dialog which previously contained an
authorised Resource-Priority header field;
the S-CSCF shall give priority over other
transactions or dialogs. This allows special treatment for such transactions or
dialogs.
NOTE 1: The
special treatment can include filtering, higher priority processing, routeing,
call gapping. The exact meaning of priority is not defined further in this
document, but is left to national regulation and network configuration.
When the S-CSCF receives, destined for a
registered served user, an initial request for a dialog or a request for a
standalone transaction, and the request is received either from a functional
entity within the same trust domain or contains a valid original dialog
identifier or the dialog identifier (From, To and Call-ID header fields)
relates to an existing request processed by the S-CSCF, then prior to
forwarding the request, the S-CSCF shall:
1) check
if an original dialog identifier that the S-CSCF previously placed in a Route
header field is present in the topmost Route header field of the incoming
request.
- If
present, the request has been sent from an AS in response to a previously sent
request.
- If not
present, it indicates that the request is visiting the S-CSCF for the first
time and in this case the S-CSCF shall determine the served user by taking the
identity contained in the Request-URI.
If the Request-URI is a temporary
GRUU assigned by the S-CSCF as defined in subclause 5.4.7A.3, then take
the public user identity that is associated with the temporary GRUU to be the
served user identity. Then check whether the determined served user identity is
a barred public user identity. In case the served user identity is a barred
public user identity for the user, then the S-CSCF shall reject the request by
generating a 404 (Not Found) response. Otherwise, the S-CSCF shall save the Request-URI from the request, the served user identity and
the public user identity of the served user and continue with the rest of the
steps;
NOTE 2: An original dialog
identifier is sent to each AS invoked due to iFC evaluation such that the
S-CSCF can associate requests as part of the same sequence that trigger iFC
evaluation in priority order (and not rely on SIP dialog information that can change
due to B2BUA AS). If the same original dialog
identifier is included in more than one request from a particular AS (based on
service logic in the AS), then the S-CSCF will continue the iFC evaluation
sequence rather than build a new ordered list of iFC;
2) remove
its own URI from the topmost Route
header field;
2A) if
there was no original dialog identifier present in the topmost Route header field
of the incoming request build an ordered list of initial filter criteria based
on the public user identity in the Request-URI
of the received request as described in 3GPP TS 23.218 [5].
3) if
there was an original dialog identifier present in the topmost Route header field
of the incoming request then check whether the Request-URI
matches the saved Request-URI. The
Request-URI and saved Request-URI are considered a match:
a) if the canonical
forms of the two Request-URI are equal
to the saved value of the Request-URI;
b) if the
Request-URI is a GRUU (public or
temporary) and the saved value of the Request-URI
is a GRUU (public or temporary) and both GRUUs represent the same public user
identity or represent public user identities that are alias SIP URIs of each
other; or
c) if the
Request-URI is an alias SIP URI of the saved value of the Request-URI.
NOTE 3: The
canonical form of the Request-URI
is obtained by removing all URI
parameters (including the user-param), and by converting any escaped characters
into unescaped form. The alias SIP URI
is defined in subclause 3.1.
If
there is no match, then the S-CSCF shall decide whether to trigger the
originating services to be executed after retargeting. The decision is
configured in the S-CSCF and may use any information in the received request
that is used for the initial filter criteria or an operator policy. The S-CSCF
shall decide either to:
a) stop
evaluating current iFC. In that case, if the request is an INVITE request, save
the Contact, CSeq and Record-Route header field values received in the request
such that the S-CSCF is able to release the session if needed, forward the
request based on the topmost Route header field or if not available forward the
request based on the Request-URI
(routeing based on Request-URI is
specified in steps 7 and 10 through 14a from subclause 5.4.3.2) and skip
the following steps; or
b) stop
evaluating current iFC and build an ordered list of iFC with the originating
services to be executed after retargeting as described in
3GPP TS 23.218 [5] criteria based on the public user identity of
the served user and start the evaluation of that iFC as described in subclause 5.4.3.2
starting at step 4B of subclause 5.4.3.2;
NOTE 4: The
S-CSCF assesses triggering of services for the originating services after
retargeting means it evaluates IFCs with a SessionCase set to ORIGINATING_CDIV,
as defined in 3GPP TS 29.228 [14]. If the P-Served-User
extension specified in RFC 5502 [133] is supported, the S-CSCF uses
the "orig-cdiv" header field parameter defined in
draft-mohali-dispatch-originating-cdiv-parameter [239].
NOTE 5: The
identity of the served user can be obtained from the History-Info header field (see
RFC 7044 [66]) or the P-Served User header field as specified in RFC 5502 [133].
The served user can be a public user identity, a public GRUU, or a temporary
GRUU. It needs to be ensure, that all ASs in the iFC can determine the served
user correctly.
NOTE 6: The
S-CSCF determines whether to apply a) or b) based on information in the initial
Filter Criteria.
3A) if
the Request-URI is a GRUU, but is
not valid as defined in subclause 5.4.7A.4, then return a 4xx response as
specified in RFC 5627 [93];
3B) if the
Request-URI contains a public GRUU
and the saved value of the Request-URI
is a temporary GRUU, then replace the Request-URI
with the saved value of the Request-URI;
3C) if
the request contains a P-Asserted-Service header field check whether the IMS
communication service identified by the ICSI value contained in the
P-Asserted-Service header field is allowed by the subscribed services for the
served user:
a) if so,
continue from step 4; and
b) if
not, as an operator option, the
S-CSCF may reject the request by generating a 403 (Forbidden) response.
Otherwise, remove the P-Asserted-Service header field and continue with the
rest of the steps;
3D) if
the request does not contain a P-Asserted-Service header field check if the
contents of the request matches a subscribed service (e.g. SDP media
capabilities, Content-Type header field) for each and any of
the subscribed services for the served user:
a) if not,
as an operator option, the S-CSCF may reject the
request by generating a 403 (Forbidden) response. Otherwise, continue with the
rest of the steps; and
b) if so, and if the request is related to an IMS
communication service and the IMS communication service requires the use of an
ICSI value then include a P-Asserted-Service header field in the request
containing the ICSI value for the related IMS communication service, and use it
as a header field in the initial request when matching initial filter criteria
in step 4; and
c) if so,
and if the request is related to an IMS communication
service and the IMS communication service does not require the use of an ICSI
value then continue without including an ICSI value; and
d) if so, and
if the request does not relate to an IMS communication service (or if the S-CSCF is unable to unambiguously determine the service
being requested but decides to allow the session to continue)
then continue without inclding an ICSI value;
4) check
whether the initial request matches any unexecuted initial filter criteria based
on the public user identity of the served user in the priority order and apply
the filter criteria on the SIP method as described in
3GPP TS 23.218 [5] subclause 6.5. If there is a match, then
the S-CSCF shall select the first matching unexecuted initial filter criteria
and:
a) if the
Request-URI is a temporary GRUU as
defined in subclause 5.4.7A.3, then replace the Request-URI with the public GRUU that is associated with
the temporary GRUU (i.e. the public GRUU representing the same public user
identity and instance ID as the temporary GRUU);
b) insert
the AS URI to be contacted into
the Route header field as the topmost entry followed by its own URI populated as specified in the
subclause 5.4.3.4;
c) if the S-CSCF supports the P-Served-User
extension as specified in RFC 5502 [133], insert the P-Served-User
header field populated with the served user identity as determined in step 1.
If required by operator policy, the S-CSCF shall:
- if the
associated session case is "Terminating" as specified in
3GPP TS 29.228 [14], include the sescase
header field parameter set to "term" and the regstate header field
parameter set to "reg";
- if the
associated session case is "Terminating_Unregistered" as specified in
3GPP TS 29.228 [14], include the sescase
header field parameter set to "term" and the regstate header field
parameter set to "unreg";
d) insert
a type 3 "orig-ioi" header field parameter replacing any received
"orig-ioi" header field parameter in the P-Charging-Vector header
field. The type 3 "orig-ioi" header field parameter identifies the
sending network of the request message. The S-CSCF shall not include the type 3
"term-ioi" header field parameter;
e) remove
the "transit-ioi" header field parameter, if received;
f) based
on operator policy insert a Relayed-Charge header field containing the value of
the received "transit-ioi" header field parameter in the
P-Charging-Vector header field; and
g) if an IP address associated with the served
user and the AS SIP URI is stored as described in subclause 5.4.0 exists, then the S-CSCF
forwards the SIP message to the IP address associated with the served user and
the AS SIP URI;
NOTE 7: Depending
on the result of the previous process, the S-CSCF can contact one or more AS(s)
before processing the outgoing Request-URI.
NOTE 8: If
the Request-URI of the received
terminating request contains a temporary GRUU, then step 4 replaces the
Request-URI with the associated
public GRUU before invoking the AS, and step 3B restores the original temporary
GRUU when the request is returned from the AS.
NOTE 9: An
AS can activate or deactivate its own filter criteria via the Sh interface. As
the S-CSCF checks initial filter criteria only on receipt of an initial request
for a dialog, or a standalone transaction, a modified service profile will have
no impact on transactions or dialogs already in progress and the modified
profile will be effective only for new transactions and dialogs. If the S-CSCF
receives a modification of the iFC during their execution, then it should not
update the stored
initial Filter Criteria until the iFC related to the initial request have been
completely executed.
5) if
there was no original dialog identifier present in the topmost Route header field
of the incoming request insert a P-Charging-Function-Addresses header field, if
not present, populated with values received from the HSS if the message is
forwarded within the S-CSCF home network, including towards AS;
6) if
there was no original dialog identifier present in the topmost Route header field
of the incoming request store the value of the "icid-value" header
field parameter received in the P-Charging-Vector header field and retain the "icid-value"
header field parameter in the P-Charging-Vector header field;
7) if
there was no original dialog identifier present in the topmost Route header field
of the incoming request:
- store
the value of the "orig-ioi" header field parameter received in the
P-Charging-Vector header field, if present;
- remove
received "orig-ioi", "term-ioi" and "transit-ioi"
header field parameters from the forwarded request if next hop is not an AS;
- include
a type 1 "orig-ioi" header field parameter if next hop is not an AS;
and
- remove
any received Relayed-Charge header field;
NOTE 10: Any
received "orig-ioi" header field parameter will be a type 2 IOI. or
type 3 IOI. A type 2 IOI identifies the sending network of the request message,
a type 3 IOI identifies the sending service provider of the request message.
7A) if there
was an original dialog identifier present in the topmost Route header field of
the incoming request:
- store
the value of the "orig-ioi" header field parameter received in the
P-Charging-Vector header field, if present;
- remove
the received "orig-ioi" header field parameter if next hop is not an
AS; and
- include
a type 1 "orig-ioi" header field parameter if next hop is not an AS;
NOTE 11: Any
received "orig-ioi" header field parameter will be a type 3 IOI. A
type 3 IOI identifies the sending service provider of the request message.
8) in the
case:
i) there
are no Route header fields in the request; and
ii) there
are bindings saved during registration or re-registration as described in
subclause 5.4.1.2 which are not marked as created by an emergency
registration as described in subclause 5.4.8.2;
then,
create a target set of potential routes from the list of preloaded routes associated
with the bindings in item 8) ii), as follows:
a) if the
Request-URI contains a valid GRUU assigned
by the S-CSCF as defined in subclause 5.4.7A.4 that does not contain a
"bnc" URI parameter,
then the target set is determined by following the procedures for Request Targeting specified in RFC 5627 [93],
using the public user identity and instance ID derived from the GRUU using the
procedures of subclause 5.4.7A;
b) if the
Request-URI contains a valid public
GRUU assigned by the S-CSCF as defined in subclause 5.4.7A.4 that contains
a "bnc" URI parameter
then the target set is determined by following the procedures for routeing of public GRUUs specified in RFC 6140 [191].
NOTE 12: The
procedures for Request
Targeting for public GRUUs in subclause 7.1.1
of RFC 6140 [191]
involve
copying the "sg" SIP URI
parameter from the Public GRUU into the Request-URI
along with the bound registered Contact Address.
NOTE 13: In
this release of the specification, use of preloaded routes saved during
registration or re-registration which created or refreshed bindings marked as
created by an emergency registration is out of scope.
c) if the
Request-URI contains a temporary
GRUU not assigned by the S-CSCF but that contains "temp-gruu-cookie"
information provided by the S-CSCF to the UE in a "temp-gruu-cookie"
header field parameter as specified in RFC 6140 [191] then the target
set is determined by following the procedures for Request Targeting for temporary
GRUUs specified in RFC 6140 [191]; or
NOTE 14: The
procedures for obtaining the "temp-gruu-cookie" information from the
temporary GRUU and for routeing of temporary
GRUUs are specified in subclause 7.1.2.3
of RFC 6140 [191].
d) if the
Request-URI contains a public user
identity or a GRUU not assigned by the S-CSCF, then the target set is all the
registered contacts saved for the destination public user identity;
9) if
necessary perform the caller preferences to callee capabilities matching
according to RFC 3841 [56B] to the target set;
NOTE 15: This
might eliminate entries and reorder the target set.
NOTE 16: The S-CSCF performs caller
preferences to callee capabilities matching also to select among multiple
targets set to a single instance-id, when the UE has registered multiple
registration flows.
10) in case
there are no Route header fields in the request:
a) if there
is more than one route in the target set determined in steps 8) and 9) above:
- if the
fork directive in the Request-Disposition header field was set to
"no-fork", use the contact with the highest qvalue parameter to build
the target URI. In case no qvalue
parameters were provided, the S-CSCF shall decide
locally what contact address to be used to build the target URI;
- if the
fork directive in the Request-Disposition header field was not set to
"no-fork", fork the request or perform sequential search based on the
relative preference indicated by the qvalue parameter of the Contact header field
in the REGISTER request, as described in RFC 3261 [26]. In case no
qvalue parameters were provided, then the S-CSCF determine the contact address
to be used to build the target URI
as directed by the Request-Disposition header field as described in
RFC 3841 [56B]. If the Request-Disposition header field is not present, the
S-CSCF shall decide locally whether to fork
or perform sequential search among the contact addresses;
- in case
that no route is chosen, return a 480 (Temporarily unavailable) response or
another appropriate unsuccessful SIP response and terminate these procedures;
and
- per the
rules defined in RFC 5626 [92], the S-SCSF shall not populate the
target set with more than one contact with the same public user identity and
instance-id at a time. If a request for a particular public user identity and
instance-id fails with a 430 response, the S-CSCF shall replace the failed
branch with another target with the same public user identity and instance-id,
but a different reg-id;
b) If no "Loose-Route
Indication" indicating
the HSS requires the loose-route mechanism as described in
3GPP TS 29.228 [14] has been received,
in the service profile of the served public user identity, from the HSS during
registration, build the Request-URI
with the contents of the target URI
determined in the previous step, otherwise the Request-URI
is retained as received;
c) insert
a P-Called-Party-ID SIP header field containing the contents of the Request-URI (if no "Loose-Route Indication" indicating the HSS requires the
loose-route mechanism as described in 3GPP TS 29.228 [14] has
been received, in the service profile of the served public user identity, from
the HSS during registration, then exclude "rn" tel-URI parameter and "npdi" tel-URI parameter as defined in RFC 4694 [112]) received
in the request unless the Request-URI
contains a temporary GRUU in which case insert the public GRUU in the
P-Called-Party-ID;
d) build
the Route header field with the Path values from the chosen route and if "Loose-Route
Indication" indicating the HSS requires the loose-route mechanism as described in
3GPP TS 29.228 [14] has been received, in
the service profile of the served user identity, from the HSS during
registration and the selected contact address was not registered as described
in RFC 5626 [92], add the content of the target URI determined in step a), as last URI of the route. If the selected contact address was
registered as described in RFC 5626 [92], the target URI determined in step a) is not added to the Route
header field; and
e) save
the Request-URI and the total
number of Record-Route header fields as part of the dialog request state.
NOTE 17: For
each initial dialog request terminated at a served user two pieces of state are
maintained to assist in processing GRUUs: the chosen contact address to which
the request is routed; and the position of an entry for the S-CSCF in the
Record-Route header field that will be responsible for GRUU translation, if
needed (the position is the number of entries in the list before the entry was
added). The entry will be added in step 5) of the below procedures for handling
S-CSCF receipt any 1xx or 2xx response to the initial request for a dialog. The
S-CSCF can record-route multiple times, but only one of those (the last) will
be responsible for gruu translation at the terminating end.
11) if the
request is an INVITE request, save the Contact, CSeq and Record-Route header
field values received in the request such that the S-CSCF is able to release
the session if needed;
12) optionally,
apply any privacy required by RFC 3323 [33] and RFC 3325 [34] to
the P-Asserted-Identity header field and privacy required by RFC 7044 [66].
The S-CSCF shall not remove any priv-value from the Privacy header field;
NOTE 18: keeping the priv-value in the
Privacy header field is necessary to indicate to the UE that the public user
identity was not sent because of restriction. Although RFC 3323 [33]
states that when a privacy service performs one of the functions corresponding
to a privacy level listed in the Privacy header field, it SHOULD remove the
corresponding priv-value from the Privacy header field, there is no harm that
the S-CSCF does not remove the priv-values as there will be no other entity
that would perform the privacy service after the S-CSCF.
NOTE 19: The
optional procedure above is in addition to any procedure for the application of
privacy at the edge of the trust domain specified by RFC 3325 [34].
13) in case
of an initial request for a dialog, either:
- if the
request is routed to an AS which is part of the trust domain, the S-CSCF shall decide,
based on operator policy, whether to record-route or not. The decision is
configured in the S-CSCF using any information in the received request that may
otherwise be used for the initial filter criteria. If the request is
record-routed the S-CSCF shall create a Record-Route header field containing its
own SIP URI; or
- if the
request is routed elsewhere, create a Record-Route header field containing its
own SIP URI;
13A) if the
request is routed towards the UE remove the P-User-Database header field and
P-Served-User header field if present;
13B) if the
request is sent on a dialog for which logging of signalling is not in progress,
and the request contains a P-Debug-ID header field, remove the P-Debug-ID
header field before forwarding the request;
13C) if the
request was sent on a dialog for which logging of signalling is in progress,
check whether a trigger for stopping logging of SIP signalling has occurred, as
described in draft-dawes-sipping-debug [140].
If a stop trigger event has occurred, stop logging of signalling, else
determine, by checking its debug configuration, whether to log the request;
13D) if the
request is routed towards the UE,
- the
S-CSCF supports indicating the traffic leg as specified in RFC 7549 [225];
- the UE is roaming;
and
- required
by local policy;
then:
- if the bottommost Route header field does
not contain the "tokenized-by" header field parameter
and an "iotl" SIP URI
parameter is not already included, append an "iotl" SIP URI
parameter set to "homeB-visitedB" to the URI of the bottommost Route header field; and
- if the bottommost Route header field contains
the "tokenized-by" header field parameter
and an "iotl" SIP URI
parameter is not already included, append an "iotl" SIP URI
parameter set to "homeB-visitedB" to the URI of the second Route header field from the bottom;
NOTE 20: The bottommost Route header field contains an
"iotl" SIP URI parameter
if the P‑CSCF added the "iotl" SIP URI
parameter in the Path header field during registration and if the visited
network does not apply topology hiding. The second Route header field from the
bottom contains an "iotl" SIP URI
parameter if the P‑CSCF added the "iotl" SIP URI
parameter in the Path header field during registration and if the visited
network applied topology hiding.
13E) if
the S-CSCF supports HSS based P-CSCF restoration and the S-CSCF considers the
P-CSCF, identified by the bottommost Route header field, is not reachable:
- reject
the request with a 480 (Temporarily Unavailable) response; and
- initiate
the HSS based P-CSCF restoration procedure towards the served user as specified
in 3GPP TS 23.380 [7D];
13F) if the S-CSCF supports PCRF based P-CSCF restoration procedures,
insert a Restoration-Info header field including the IMSI value contained in the user profile of the registered served user as a quoted string
defined in 3GPP TS 29.228 [14];
NOTE 21: If PCRF based
P-CSCF restoration procedure is operated between the home network and
the visited network, the operator policy depends on an agreement with the
visited network operator.
13G) if the S-CSCF
supports PCRF based P-CSCF restoration procedures,
- the request contains a topmost Route header field pointing to a P-CSCF, and
- the S-CSCF considers the P-CSCF is in a non-working state,
remove all entries in the Route header field and add a Route header field
set to the URI associated with an alternative
P-CSCF; and
NOTE 22: How the SIP URI of the alternative P-CSCF is
obtained by the S-CSCF is implementation dependent. The S-CSCF can make sure that selected P-CSCF support the PCRF based P-CSCF
restoration procedures based on local configuration.
NOTE 23: It is implementation dependent as to how the
S-CSCF determines the P-CSCF is in non-working state.
14) forward
the request based on the topmost Route header field.
If the S-CSCF receives any response to the
above request, the S-CSCF shall:
1) If
logging is in progress for this dialog, check whether a trigger for stopping
logging of SIP signalling has occurred, as described in draft-dawes-sipping-debug [140]. If a stop trigger event
has occurred then stop logging of signalling, else determine, by checking its
debug configuration, whether to log the response.
If the
S-CSCF supports HSS based P-CSCF restoration and
a) receives a 404 (Not Found) response;
b) fails to receive any SIP response from a
P-CSCF serving a non-roaming user within a configurable time; or
NOTE 24: The configurable time
needs to be less than timer B and timer F.
c) receives a 408 (Request Timeout) response or a 504 (Server Time-out) response:
- including a Restoration-Info header field
defined in subclause 7.2.11 set to "noresponse"; and
- the "+g.3gpp.ics" Contact header
field parameter with a value set to "server" was not included in the
REGISTER request when the UE registered;
NOTE 25: If this Contact header field parameter is not
included the S-CSCF can deduce that the P-CSCF did not respond to the request.
the S-CSCF
shall:
- send a
480 (Temporarily Unavailable) response;
-
initiate the HSS based P-CSCF restoration procedure towards the served user as
specified in 3GPP TS 23.380 [7D]; and
- if b)
or c) above applied consider the P-CSCF as not reachable.
If the
S-CSCF supports PCRF based P-CSCF restoration and receives a 404 (Not Found)
response, the S-CSCF shall consider the P-CSCF to be in a non-working state and
shall initiate the PCRF based P-CSCF
restoration procedure towards the served user as specified in
3GPP TS 23.380 [7D].
If the
S-CSCF:
a) fails to receive a SIP response within a
configurable time; or
b) receives a 408 (Request
Timeout) response or a
5xx response from the AS without previously receiving
a 1xx response to the original SIP request, and without previously receiving a
SIP request from the AS that contained the same original dialog identifier as
the original request;
the S-CSCF
shall:
- if the default handling defined in the
filter criteria indicates the value "SESSION_CONTINUED" as specified
in 3GPP TS 29.228 [14] or no default handling is
indicated, execute the procedure from step 4; and
- if the default handling defined in
the filter criteria indicates the value "SESSION_TERMINATED" as
specified in 3GPP TS 29.228 [14],
either forward the received response or, if the request is an initial INVITE
request, send a 408 (Request Timeout) response or a 5xx response towards the
originating UE as appropriate (without verifying the matching of filter
criteria of lower priority and without proceeding for further steps).
If the
S-CSCF receives any final response from the AS, the S-CSCF shall forward the
response towards the originating UE (without verifying
the matching of filter criteria of lower priority and without proceeding for
further steps).
When the S-CSCF receives any response to
the above request and forwards it to an AS, the S-CSCF shall remove any "orig-ioi",
"term-ioi" and "transit-ioi" header field parameter if
received in a P-Charging-Vector header field, insert a P-Charging-Vector header
field containing the "orig-ioi" header field parameter, if received
in the request, a type 3 "term-ioi" header field parameter, and based
on operator option insert a Relayed-Charge header field in the response. The
S-CSCF shall set the type 3 "term-ioi" header field parameter to a
value that identifies the sending network of the response, the "orig-ioi"
header field parameter is set to the previously received value of "orig-ioi"
header field parameter and include in the Relayed-Charge header field the received
"transit-ioi" header field parameter from the P-Charging-Vector
header field.
NOTE 26: Any received "term-ioi" header field
parameter will be a type 1 IOI or a type 3 IOI. The type 1 IOI identifies the
network from which the response was sent and the type 3 IOI identifies the
service provider from which the response was sent.
When the S-CSCF receives, destined for an
unregistered served user or a statically pre-configured PSI, an initial request
for a dialog or a request for a standalone transaction, the S-CSCF shall:
1) Void.
2) execute
the procedures described in 1, 2, 3, 3C, 3D, 4, 5, 6, 7, 11, 13, 13B, 13C and
14 in the above paragraph (when the S-CSCF receives, destined for the
registered served user, an initial request for a dialog or a request for a
standalone transaction).
3) In case
that no more AS needs to be contacted, then S-CSCF shall return an appropriate
unsuccessful SIP response. This response may be a 480 (Temporarily unavailable)
and terminate these procedures.
NOTE 27: When the S-CSCF does not have the user profile,
before executing the actions as listed above, it initiates the S-CSCF
Registration/deregistration notification procedure, as described in
3GPP TS 29.228 [14]; with the purpose of downloading the
relevant user profile (i.e. for unregistered user) and informs the HSS that the
user is unregistered. The S-CSCF will assess triggering of services for the
unregistered user, as described in 3GPP TS 29.228 [14]. When
requesting the user profile the S-CSCF can include the information in the P-Profile-Key
header field in S-CSCF Registration/deregistration notification. When requesting the user profile,
and the request received by the S-CSCF contains a P-Profile-Key header field,
the S-CSCF can include the header field value in S-CSCF
Registration/deregistration notification. If the response from the HSS includes
a Wildcarded Public Identity AVP,
and if the request received by the S-CSCF did not include a P-Profile-Key
header field, the S-CSCF uses the AVP
value to set the P-Profile-Key header field before forwarding the request to an
AS.
Prior to performing S-CSCF
Registration/Deregistration procedure with the HSS, the S-CSCF decides which
HSS to query, possibly as a result of a query to the Subscription Locator
Functional (SLF) entity as
specified in 3GPP TS 29.228 [14] or use the value as received in
the P-User-Database header field in the initial request for a dialog or a
request for a standalone transaction as defined in RFC 4457 [82]. The
HSS address received in the response to SLF
query can be used to address the HSS of the public user identity with further
queries.
If the
HSS indicates to the S-CSCF that there is already another S-CSCF assigned for
the user, the S-CSCF shall return a 305 (Use Proxy) response containing
the SIP URI of the assigned S-CSCF
received from the HSS in the Contact header field.
When the S-CSCF receives any response to
the above request containing a Relayed-Charge header field, and the next hop is
not an AS, the S-CSCF shall remove the Relayed-Charge header field.
When the S-CSCF receives any 1xx or 2xx
response to the initial request for a dialog (whether the user is registered or
not), the S-CSCF shall:
1) if the
response corresponds to an INVITE request, save the Contact and Record-Route
header field values in the response such that the S-CSCF is able to release the
session if needed;
2) if the response is not forwarded to
an AS (i.e. the response is related to a request that was matched to the first
executed initial filter criteria):
a) remove the
received "transit-ioi" header field parameter if present and insert a
type 2 "term-ioi" header field parameter in the P-Charging-Vector
header field of the outgoing response. The type 2 "term-ioi" header
field is set to a value that identifies the sending network of the response and
the "orig-ioi" header field parameter is set to the previously
received value of "orig-ioi" header field parameter. Values of "orig-ioi"
and "term-ioi" header field parameters in the received response are
removed; and
b) if the
S-CSCF supports using a token to identify the registration, remove the "+g.3gpp.registration-token" Feature-Caps header field parameter, defined in
subclause 7.9A.8, if received in the response;
3) in case
the served user is not considered a privileged sender then:
a) if the
P-Asserted-Identity header field contains only a SIP URI
and in the case where the S-CSCF has knowledge that the SIP URI contained in the received P-Asserted-Identity
header field is an alias SIP URI
for a tel URI, the S-CSCF shall
add a second P-Asserted-Identity header field containing this tel URI, including the display name associated with the
tel URI, if available; and
b) if the
P-Asserted-Identity header field contains only a tel URI,
the S-CSCF shall add a second P-Asserted-Identity header field containing a SIP
URI. The added SIP URI shall contain in the user part a "+"
followed by the international public telecommunication number contained in tel URI, and user's home domain name in the hostport
part. The added SIP URI shall
contain the same value in the display name as contained in the tel URI. The S-CSCF shall also add a "user"
SIP URI parameter equals
"phone" to the SIP URI;
4) in case
the response is sent towards the originating user, the S-CSCF may retain the
P-Access-Network-Info header field based on local policy rules and the
destination user (Request-URI);
5) save an
indication that GRUU routeing is to be performed for subsequent requests sent
within this same dialog if:
a) there
is a record-route position saved as part of the initial dialog request state;
and
b) the
contact address in the response is a valid GRUU assigned by the S-CSCF as
specified in subclause 5.4.7A.4 or a temporary GRUU self assigned by the
UE based on the "temp-gruu-cookie" header field parameter provided to
the UE;
6) if the
S-CSCF supports using a token to identify the registration and if a registration exists, add a "+g.3gpp.registration-token" Feature-Caps header field parameter, as defined in
subclause 7.9A.8, set to the same value as included in the "+g.3gpp.registration-token"
Contact header field parameter of the third party REGISTER
request sent to the AS when the UE
registered; and
NOTE 28: There could be several responses returned for a
single request, and the decision to insert or modify the Record-Route needs to
be applied to each. But a response might also return to the S-CSCF multiple
times as it is routed back through AS. The S-CSCF will take this into account
when carrying out step 5) to ensure that the information is stored only once.
7) if the response is
forwarded within the S-CSCF home network and not to an AS,
insert a P-Charging-Function-Addresses header field populated with values
received from the HSS.
When the S-CSCF receives a response to a
request for a standalone transaction (whether the user is registered or not), then:
1) in case
the served user is not considered a privileged sender then:
a) if the
P-Asserted-Identity header field contains only a SIP URI
and in the case where the S-CSCF has knowledge that the SIP URI contained in the received P-Asserted-Identity
header field is an alias SIP URI
for a tel URI, the S-CSCF shall
add a second P-Asserted-Identity header field containing this tel URI, including the display name associated with the
tel URI, if available; and
b) if the
P-Asserted-Identity header field contains only a tel URI,
the S-CSCF shall add a second P-Asserted-Identity header field containing a SIP
URI. The added SIP URI shall contain in the user part a "+"
followed by the international public telecommunication number contained in tel URI, and user's home domain name in the hostport
part. The added SIP URI shall
contain the same value in the display name as contained in the tel URI. The S-CSCF shall also add a "user"
SIP URI parameter equals
"phone" to the SIP URI; and
2) in case
the response is forwarded to an AS that is located within the trust domain, the
S-CSCF shall retain the access-network-charging-info parameter in the
P-Charging-Vector header field; otherwise, the S-CSCF shall remove the
access-network-charging-info parameter in the P-Charging-Vector header field.
When the S-CSCF receives the 200 (OK)
response for a standalone transaction request, the S-CSCF shall:
1) insert
a P-Charging-Function-Addresses header field populated with values received
from the HSS if the message is forwarded within the S-CSCF home network,
including towards an AS;
1A) if the S-CSCF
supports using a token to identify the registration and if a registration exists, add a "+g.3gpp.registration-token" Feature-Caps header field parameter, as defined in
subclause 7.9A.8, set to the same value as included in the "+g.3gpp.registration-token" Contact header field parameter of the third
party REGISTER request sent to the AS when the UE registered;
1B) if the S-CSCF supports
using a token to identify the registration in case the response is not
forwarded to an AS the S-CSCF shall remove the "+g.3gpp.registration-token" Feature-Caps header field parameter, defined in
subclause 7.9A.8, if received in the response; and
2) if the response is not forwarded to
an AS (i.e. the response is related to a request that was matched to the first
executed initial filter criteria), remove the received
"orig-ioi", "term-ioi" and "transit-ioi"
header field parameter if present and insert a type 2 "term-ioi"
header field parameter in the P-Charging-Vector header field of the outgoing
response. The type 2 "term-ioi" header field parameter is set to a
value that identifies the sending network of the response and the type 2 "orig-ioi"
header field parameter is set to the previously received value of "orig-ioi"
header field parameter.
NOTE 29: If the S-CSCF forked the request of a stand
alone transaction to multiple UEs and receives multiple 200 (OK) responses, the
S-CSCF will select and return only one 200 (OK) response. The criteria that the
S-CSCF employs when selecting the 200 (OK) response is based on the operator's
policy (e.g. return the first 200 (OK) response that was received).
When the S-CSCF receives, destined for a
served user, a target refresh request for a dialog, prior to forwarding the
request, the S-CSCF shall:
0) if the
dialog is related to an IMS communication service determine whether the
contents of the request (e.g. SDP media capabilities, Content-Type header field)
match the IMS communication service as received as the ICSI value in the
P-Asserted-Service header field in the initial request. As an operator option, if the contents of the request
do not match the IMS communication service the S-CSCF
may reject the request by generating a status code reflecting which added
contents are not matching. Otherwise, continue with the rest of the steps;
1) if the
incoming request is received on a dialog for which GRUU routeing is to be
performed and the Request-URI is
not the GRUU for this dialog, then return a response of 400 (Bad Request).
2) if the
incoming request is received on a dialog for which GRUU routeing is to be
performed and the Request-URI
contains the GRUU for this dialog then:
i) if the
Request-URI contains a valid GRUU assigned
by the S-CSCF as defined in subclause 5.4.7A.4 that does not contain a
"bnc" URI parameter,
then perform the procedures for Request Targeting specified in RFC 5627 [93],
using the public user identity and instance ID derived from the Request-URI, as specified in subclause 5.4.7A;
ii) if the
Request-URI contains a valid public
GRUU assigned by the S-CSCF as defined in subclause 5.4.7A.4 that contains
a "bnc" URI parameter
then the target set is determined by following the procedures for routeing of public GRUUs specified in RFC 6140 [191].
or
NOTE 30: The procedures for Request Targeting for public GRUUs in subclause 7.1.1 of RFC 6140 [191] involve copying the "sg" SIP URI
parameter from the Public GRUU into the Request-URI
along with the bound registered Contact Address.
iii) if the
Request-URI contains a temporary
GRUU not assigned by the S-CSCF but that contains "temp-gruu-cookie"
information provided by the S-CSCF to the UE in a "temp-gruu-cookie"
header field parameter as specified in RFC 6140 [191] then the target
set is determined by following the procedures for routeing
of temporary GRUUs specified
in RFC 6140 [191];
NOTE 31: The procedures for obtaining the
"temp-gruu-cookie" information from the temporary GRUU and for
routeing of temporary GRUUs
are specified in subclause 7.1.2.3
of RFC 6140 [191].
iv) if no
contact can be selected, return a response of 480 (Temporarily Unavailable);
3) remove
its own URI from the topmost Route
header field;
4) for
INVITE dialogs (i.e. dialogs initiated by an INVITE request), save the Contact
and CSeq header field values received in the request such that the S-CSCF is
able to release the session if needed;
5) create
a Record-Route header field containing its own SIP URI;
5A) if
the request is sent on a dialog for which logging of signalling is not in
progress, and the request contains a P-Debug-ID header field, remove the
P-Debug-ID header field before forwarding the request;
5B) if
the request was sent on a dialog for which logging of signalling is in
progress, check whether a trigger for stopping logging of SIP signalling has
occurred, as described in draft-dawes-sipping-debug [140].
If a stop trigger event has occurred, stop logging of signalling, else
determine, by checking its debug configuration, whether to log the request; and
6) forward
the request based on the topmost Route header field.
When the S-CSCF receives any response to
the above request, the S-CSCF shall:
1) If
logging is in progress for this dialog, check whether a trigger for stopping
logging of SIP signalling has occurred, as described in draft-dawes-sipping-debug [140]. If a stop trigger event
has occurred then stop logging of signalling, else determine, by checking its
debug configuration, whether to log the response.
When the S-CSCF receives any 1xx or 2xx
response to the target refresh request for a dialog (whether the user is
registered or not), the S-CSCF shall:
1) for
INVITE dialogs, replace the saved Contact header field values in the response
such that the S-CSCF is able to release the session if needed; and
2) in case
the response is forwarded to an AS that is located within the trust domain, the
S-CSCF shall retain the access-network-charging-info parameter in the
P-Charging-Vector header field; otherwise, the S-CSCF shall remove the
access-network-charging-info parameter in the P-Charging-Vector header field.
When the S-CSCF receives, destined for the
served user, a subsequent request other than target refresh request for a
dialog, prior to forwarding the request, the S-CSCF shall:
1) if the
incoming request is received on a dialog for which GRUU routeing is to be
performed and the Request-URI is
not the GRUU for this dialog, then return a response of 400 (Bad Request).
2) if the
incoming request is received on a dialog for which GRUU routeing is to be
performed and the Request-URI
contains the GRUU for this dialog then:
i) if the
Request-URI contains a valid GRUU assigned
by the S-CSCF as defined in subclause 5.4.7A.4 that does not contain a
"bnc" URI parameter,
then perform the procedures for Request Targeting specified in RFC 5627 [93],
using the public user identity and instance ID derived from the Request-URI, as specified in subclause 5.4.7A;
ii) if the
Request-URI contains a valid public
GRUU assigned by the S-CSCF as defined in subclause 5.4.7A.4 that contains
a "bnc" URI parameter
then the target set is determined by following the procedures for routeing of public
GRUUs specified in RFC 6140 [191]; or
NOTE 32: The procedures for Request Targeting for public GRUUs in subclause 7.1.1 of RFC 6140 [191] involve copying the "sg" SIP URI
parameter from the Public GRUU into the Request-URI
along with the bound registered Contact Address.
iii) if the
Request-URI contains a temporary
GRUU not assigned by the S-CSCF but that contains "temp-gruu-cookie"
information provided by the S-CSCF to the UE in a "temp-gruu-cookie" header field parameter as specified in RFC 6140 [191]
then the target set is determined by following the
procedures for
routeing of temporary
GRUUs specified in RFC 6140 [191].
NOTE 33: The procedures for obtaining the
"temp-gruu-cookie" information from the temporary GRUU and for
routeing of temporary GRUUs
are specified in subclause 7.1.2.3
of RFC 6140 [191].
iv) if no
contact can be selected, return a response of 480 (Temporarily Unavailable).
3) remove
its own URI from the topmost Route
header field;
3A) if
the request is sent on a dialog for which logging of signalling is not in
progress, and the request contains a P-Debug-ID header field, remove the
P-Debug-ID header field before forwarding the request;
3B) if
the request was sent on a dialog for which logging of signalling is in
progress, check whether a trigger for stopping logging of SIP signalling has
occurred, as described in draft-dawes-sipping-debug [140].
If a stop trigger event has occurred, stop logging of signalling, else
determine, by checking its debug configuration, whether to log the request; and
4) forward
the request based on the topmost Route header field.
When the S-CSCF receives any response to
the above request, the S-CSCF shall:
1) If
logging is in progress for this dialog, check whether a trigger for stopping
logging of SIP signalling has occurred, as described in draft-dawes-sipping-debug [140]. If a stop trigger event
has occurred then stop logging of signalling, else determine, by checking its
debug configuration, whether to log the response.
When the S-CSCF receives a response to a a
subsequent request other than target refresh request for a dialog, in case the
response is forwarded to an AS that is located within the trust domain, the
S-CSCF shall retain the access-network-charging-info parameter from the
P-Charging-Vector header field; otherwise, the S-CSCF shall remove the
access-network-charging-info parameter from the P-Charging-Vector header field.
With the exception of 305 (Use Proxy)
responses, the S-CSCF shall not recurse on 3xx responses.
The original dialog identifier is an
implementation specific token that the S-CSCF encodes into the own S-CSCF URI in a Route header field, prior to forwarding
the request to an AS. This is possible because the S-CSCF is the only entity
that creates and consumes the value.
The token may identify the original dialog
of the request, so in case an AS acting as a B2BUA changes the dialog, the
S-CSCF is able to identify the original dialog when the request returns to the
S-CSCF. In a case of a standalone transaction, the token indicates that the
request has been sent to the S-CSCF from an AS in response to a previously sent
request. The token can be encoded in different ways, such as e.g., a character
string in the user-part of the S-CSCF URI,
a parameter in the S‑CSCF URI or
port number in the S-CSCF URI.
The S-CSCF shall ensure that the value
chosen is unique so that the S-CSCF may recognize the value when received in a
subsequent message of one or more dialogs and make the proper association
between related dialogs that pass through an AS.
An
original dialog identifier is sent to each AS invoked due to iFC evaluation
such that the S-CSCF can associate requests as part of the same sequence that
trigger iFC evaluation in priority order (and not rely on SIP dialog
information that may change due to B2BUA AS).
NOTE: If
the same original dialog identifier is included in more than one request from a
particular AS (based on service logic in the AS), then the S-CSCF will continue
the iFC evaluation sequence. If the AS wants iFC evaluation to start from the
beginning for a request, then AS should not include an original dialog
identifier;
When the S-CSCF receives from the UE a
request (excluding REGISTER), and SIP digest without TLS
or SIP digest with TLS is
supported and in use for this UE, the S-CSCF may perform the following steps if
authentication of SIP request methods initiated by the UE excluding REGISTER is
desired:
1) The
S-CSCF shall identify the user by the public user identity as received in the
P-Asserted-Identity header field;
2) If the
public user identity does not match one of the registered public user
identities, and the public user identity does not match one of the registered
wildcarded public user identities, the S-CSCF may reject the request with a 400
(Bad Request) response or silently discard the request;
3) If the
request does not contain a Proxy-Authorization header field or the
Proxy-Authorization header field does not contain a digest response, the S-CSCF
shall:
a) challenge
the user by generating a 407 (Proxy Authentication Required) response for the
received request, including a Proxy-Authenticate header field as defined in
RFC 2617 [21], which includes:
- a "realm"
header field parameter;
- a "nonce"
header field parameter, with a newly generated value by the S-CSCF;
- an "algorithm"
header field parameter; if the algorithm value is not provided in the
authentication vector, it shall have the value "MD5"; and
- a "qop"
header field parameter; if the qop value is not provided in the authentication
vector, it shall have the value "auth".
The
challenge parameters, with the exception of the "nonce" header field
parameter, shall be the same as the ones used for the last successfull
registration.
NOTE 1: The
usage
of the same parameters for authentication of non-registration SIP requests
requires the storage of these parameters during authentication of REGISTER
requests, as retrieval of authentication vectors is only specified for REGISTER
requests.
b) send
the so generated 407 (Proxy Authentication Required) response towards the UE;
c) retain
the nonce and initialize the corresponding nonce count to a value of 1; and
d) start
timer request-await-auth.
4) If the
request contains a Proxy-Authorization header field, the S-CSCF shall:
a) check
whether the Proxy-Authorization header field contains:
- the
private user identity of the user in the "username" header field
parameter;
- an "algorithm"
header field parameter value which matches the "algorithm" header
field parameter in the authentication challenge (i.e. "MD5");
- a "response"
header field parameter with the authentication challenge response;
- a "realm"
header field parameter matching the "realm" header field parameter in
the authentication challenge;
- "nonce"
header field parameter matching a nonce that is deemed valid by the S-CSCF for
the related registration or registration flow (i.e. a nonce that was set in a a
Proxy-Authenticate header field of a 407 (Proxy Authentication Required) response
to a non-REGISTER request for which the associated validity duration has not
expired or in a WWW-Authenticate
header field of a 401 (Unauthorized) response to a REGISTER request for
which the associated validity duration has not expired, a nonce sent
in a "nextnonce" header field parameter sent in a Authentication-Info
header field of a 200 OK (OK) to REGISTER request ) or if an authentication is
ongoing for this request (i.e. a associated "req-await-auth" is
running) matching the nonce that was sent in a Proxy-Authenticate header field
of the 407 (Proxy Authentication Required) response to this request;
NOTE 2: The
related registration flow or registration is identified by the couple
instance-id and reg-id if the multiple registration mechanism is used or by
contact address if not.
- a "uri"
header field parameter matching the SIP Request-URI;
- a "cnonce"
header field parameter; and
- a "nonce-count"
header field parameter with a value that equals the nonce-count expected by the
S-CSCF. The S-CSCF may choose to accept a nonce-count which is greater than the
expected nonce-count. If the S-CSCF uses this nonce-count and authentication is
successful and the S-CSCF increments it for any subsequent authentication
responses.
If any
of the above checks do not succeed, the S-CSCF shall proceed as described in
subclause 5.4.3.6.2, and skip the remainder of this procedure; and
b) check
whether the received authentication challenge response and the expected
authentication challenge response match. The S-CSCF shall compute the expected
digest response as described in RFC 2617 [21] using the H(A1) value
contained within the authentication vector, and other digest parameters (i.e.
nonce, cnonce, nonce-count, qop).
In the case where the digest response does
not match the expected digest response calculated by the S-CSCF, the S-CSCF
shall consider the authentication attempt as failed and do one of the
following:
1) rechallenge
the user by issuing a 407 (Proxy Authentication Required) response including a
challenge as per procedures described in this subclause; or
2) reject
the request by issuing a 403 (Forbidden) response; or
3) reject
the request without sending a response.
In the case where the digest response
matches the expected digest response calculated by the S-CSCF, the S-CSCF shall:
1) consider
the identity of the user verified and the request authenticated and continue
with the procedures as described in subclause 5.4.3;
2) if the
used nonce was not considered valid before the authentication succed (i.e a
"req-await-auth" was running), add this nonce to the list of the valid nonces for the related registration or registration flow (if multiple
registration mechanism is used) for an operator configured duration; and
3) stop
the related "request-await-auth" running if any.
If the timer request-await-auth expires,
the S-CSCF shall consider the authentication to have failed.
In the case that SIP digest is used and the
request from the UE contains an invalid "nonce" Authorization header
field parameter with a valid challenge response for that nonce (indicating that
the client knows the correct username/password), or when the "nonce-count"
Authorization header field parameter value sent by the UE is not the expected
value, or when the Proxy-Authorization header field does not include the
correct parameters, the S-CSCF shall:
- send a
407 (Proxy Authentication Required) response to initiate a further
authentication attempt with a fresh nonce and the "stale" header
field parameter set to "true" in the Proxy-Authenticate header field.
When the S-CSCF cannot forward an initial
incoming request to an Application Server due to overload control mechanism, it
shall either
- if the default handling defined in the
filter criteria indicates the value "SESSION_CONTINUED" as specified
in 3GPP TS 29.228 [14] or no default handling is
indicated, execute the procedure from step 5 in
subclause 5.4.3.2 or from step 4 in subclause 5.4.3.3 depending on
the type of request; and
- if the default handling defined in
the filter criteria indicates the value "SESSION_TERMINATED" as
specified in 3GPP TS 29.228 [14], reject
the request as specified in RFC 7339 [199] and RFC 7200 [201]
(without verifying the matching of filter criteria of lower priority and
without proceeding for further steps).
When the S-CSCF receives an INVITE request,
either from the served user or destined to the served user, the S-CSCF may
require the periodic refreshment of the session to avoid hung states in the
S-CSCF. If the S-CSCF requires the session to be refreshed, the S-CSCF shall
apply the procedures described in RFC 4028 [58] clause 8.
NOTE 1: Requesting
the session to be refreshed requires support by at least one of the UEs. This
functionality cannot automatically be granted, i.e. at least one of the
involved UEs needs to support it.
For interworking with a visiting network,
where the P-CSCF of the visiting network does not support priority but it is
intended or required to give users of that P-CSCF priority in the home network,
the S-CSCF in the home network shall recognize the need for priority treatment if
such detection is not alternately provided via an IBCF in the home network.
NOTE 2: Various
mechanisms can be applied to recognize the need for priority treatment (e.g.,
based on the dialled digits). The exact mechanisms are left to national
regulation and network configuration.
When an S-CSCF interworks with a visiting
network that does not support priority, and the S-CSCF recognizes the need for
priority treatment, the S-CSCF shall insert the temporarily authorised
Resource-Priority header field with appropriate namespace and priority value in
the INVITE request.
When the S-CSCF receives an initial INVITE
request destined for the served user, the S-CSCF shall either:
a) examine
the SDP offer (the
"c=" parameter) to detect if it contains an
IP address type that is not supported by the IM CN subsystem; or
NOTE 3: The
S-CSCF can, based on local policy, assume that a UE supports the IP address
type of the SDP offer for media if it is identical to the address type of a
contact that the UE has registered.
b) process
the initial INVITE request without examining the SDP.
NOTE 4: If
the S-CSCF knows that the terminating UE supports both IPv6 and IPv4
addressing simultaneously, the S-CSCF will forward the initial
INVITE request to the UE without examining the SDP.
Editor's Note: How the S-CSCF determines
whether the UE supports both IPv6 and IPv4 addressing simultaneously is for
further study.
NOTE 5: If
the SDP offer contained an IP address type that is not supported by the IM CN
subsystem, the S-CSCF will receive the 488 (Not Acceptable Here) response with 301 Warning header field indicating "incompatible network address format".
Subsequently, when the S-CSCF detects that
the SDP offer contained an IP address type that is not supported by the IM CN
subsystem (i.e., either case a) or b)), the S-CSCF shall either:
- return
a 305 (Use
Proxy) response to the I-CSCF with the Contact field containing the SIP URI of the IBCF, or
- forward the initial INVITE request to the
IBCF. When forwarding the initial INVITE request, the
S-CSCF shall not insert its SIP URI
into the Record-Route header field.
If overlap signalling using the multiple-INVITE
method is supported as a network option, several INVITE requests with the same
Call ID and the same From header field (including "tag" header field
parameter) can be received outside of an existing dialog. Such INVITE requests
relate to the same call. If the S-CSCF receives an INVITE request from the
served user outside an existing dialog with the same Call ID and From header field
as a previous INVITE request during a certain period of time, it shall route
the new INVITE request to the same next hop as the previous INVITE request.
Editor’s note [CR 4476, WI EMC_PC]: It is FFS
how the S-CSCF processes a terminating request towards a Public User Identity
that was only registered with IMS using an emergency bearer, even if the
request includes a Priority header field with the "psap-callback"
header field value.
When the S-CSCF receives the request
containing the access-network-charging-info parameter in the P-Charging-Vector,
the S-CSCF shall store the access-network-charging-info parameter from the
P-Charging-Vector header field. The S-CSCF shall retain
access-network-charging-info parameter in the P-Charging-Vector header field when
the request is forwarded to an AS. However, the S-CSCF shall not include the
access-network-charging-info parameter in the P-Charging-Vector header field when
the request is forwarded outside the home network of the S-CSCF.
When the S-CSCF receives any request or
response (excluding CANCEL requests and responses) related to a UE-originated
dialog or standalone transaction, the S-CSCF shall insert previously saved
values into the P-Charging-Vector header field before forwarding the message
within the S-CSCF home network, including towards AS.
When the S-CSCF receives any request or
response (excluding ACK requests and CANCEL requests and responses) related to
a UE-originated dialog or standalone transaction, the S-CSCF may insert
previously saved values into the P-Charging-Function-Addresses header field
before forwarding the message within the S-CSCF home network, including towards
AS.
When the S-CSCF receives 180 (Ringing) or
200 (OK) (to INVITE) responses containing the access-network-charging-info
parameter in the P-Charging-Vector, the S-CSCF shall store the access-network-charging-info
parameter from the P-Charging-Vector header field. The S-CSCF shall retain the
access-network-charging-info parameter in the P-Charging-Vector header field when
the response is forwarded to an AS. However, the S-CSCF shall not include the access-network-charging-info
parameter in the P-Charging-Vector header field when the response is forwarded
outside the home network of the S-CSCF.
When the S-CSCF receives any request or
response (excluding CANCEL requests and responses) related to a UE-terminated
dialog or standalone transaction, the S-CSCF shall insert previously saved
values into the P-Charging-Vector header field before forwarding the message
within the S-CSCF home network, including towards AS.
When the S-CSCF receives any request or response
(excluding ACK requests and CANCEL requests and responses) related to a
UE-terminated dialog or standalone transaction, the S-CSCF may insert
previously saved values into the P-Charging-Function-Addresses header field
before forwarding the message within the S-CSCF home network, including towards
AS.
When the S-CSCF receives an error response
(to INVITE) for an existing early dialog, and if the S-CSCF does not forward
the response immediately (if the S-CSCF forked the INVITE request it may wait
for additional final responses), the S-CSCF does not have knowledge of having
received an 199 (Early Dialog Terminated) provisional response on the same
early dialog, and the associated INVITE request included the "199"
option-tag in the Supported header field, and the INVITE request did not
include the "100rel" option tag in the Require header field, the
S-CSCF shall trigger and send an unreliable 199 (Early Dialog Terminated) provisional
response, using the same "tag" To header field parameter value as the
error response, as specified in RFC 6228 [142].
When the S-CSCF has forked an initial
INVITE request, and it has received:
- a 2xx
response associated with one of the early dialogs, the S-CSCF shall in each
CANCEL request it generates as specified in RFC 3261 [26] insert a
Reason header field with a "SIP" protocol header field parameter
value, a "200" cause header field parameter value, and a "Call
completed elsewhere" text header field parameter value, as specified in
RFC 3326 [34A]; or
- a 6xx
response associated with one of the early dialogs, the S-CSCF shall, in each
CANCEL request it generates as specified in RFC 3261 [26] insert a
Reason header field with "SIP" protocol header field parameter value,
a cause header field parameter value representing the response code (e.g. "603")
in the received response, and a text header field parameter with a value
associated with the response code (e.g. a "Declined" value in the
case of a "603" response code), as specified in
RFC 3326 [34A].
Upon receipt of a network internal
indication to release a session which is currently being established, the
S-CSCF shall:
1) cancel
the related dialogs by sending the CANCEL request according to the procedures
described in RFC 3261 [26]; and
2) send an
appropriate response to the sender of the original INVITE request.
Upon receipt of a network internal
indication to release an existing multimedia session, the S-CSCF shall:
1) if the
S-CSCF serves the calling user of the session, generate a BYE request destined for
the called user based on the information saved for the related dialog,
including:
- a
Request-URI, set to the stored
Contact header field provided by the called user;
- a To
header field, set to the To header field value as received in the 200 (OK)
response for the initial INVITE request;
- a From
header field, set to the From header field value as received in the initial
INVITE request;
- a
Call-ID header field, set to the Call-Id header field value as received in the
initial INVITE request;
- a CSeq
header field, set to the CSeq value that was stored for the direction from the
calling to the called user, incremented by one;
- a
Route header field, set to the routeing information towards the called user as
stored for the dialog;
- a Reason header field that
contains proper SIP response code;
- further
header fields, based on local policy;
- treat
the BYE request as if received directly from the calling user, i.e. the S-CSCF
shall send the BYE request to the internal service control and based on the
outcome further on towards the called user; and
2) if the
S-CSCF serves the calling user of the session, generate an additional BYE
request destined for the calling user based on the information saved for the
related dialog, including:
- a
Request-URI, set to a contact
address obtained from the stored Contact header field if provided by the
calling user. If the stored Contact header field contained either a public or a
temporary GRUU, the S-CSCF shall set the Request-URI
either to:
a) the
contact address bound to the respective GRUU, if the stored Contact header
field did not include an "ob" SIP URI parameter; or
b) the contact
address that the UE used to send the initial INVITE request, if the stored
Contact header field included an "ob" SIP
URI parameter;
NOTE 1: Since
the same public GRUU can be bound to multiple contact addresses of the UE that
were registered as specified in RFC 5626 [92], the S-CSCF selects the
contact address that the UE used to send the initial INVITE request.
- a To
header field, set to the From header field value as received in the initial
INVITE request;
- a From
header field, set to the To header field value as received in the 200 (OK)
response for the initial INVITE request;
- a
Call-ID header field, set to the Call-Id header field value as received in the
initial INVITE request;
- a CSeq
header field, set to the CSeq value that was stored for the direction from the
called to the calling user, incremented by one – if no CSeq value was stored
for that session the S-CSCF shall generate and apply a random number within the
valid range for CSeqs;
- a
Route header field, set to the routeing information towards the calling user as
stored for the dialog;
- a Reason header field that
contains proper SIP response code;
- further
header fields, based on local policy;
- send
the BYE request directly to the calling user.
3) if the
S-CSCF serves the called user of the session, generate a BYE request destined
for the called user based on the information saved for the related dialog,
including:
- a
Request-URI, set to a contact
address that the S-CSCF uses to send the in-dialog requests towards the called
UE as defined in RFC 5626 [92] and RFC 5627 [93];
- a To
header, set to the To header value as received in the 200 (OK) response for the
initial INVITE request;
- a From
header, set to the From header value as received in the initial INVITE request;
- a
Call-ID header, set to the Call-Id header value as received in the initial
INVITE request;
- a CSeq
header, set to the CSeq value that was stored for the direction from the
calling to the called user, incremented by one;
- a
Route header, set to the routeing information towards the called user as stored
for the dialog;
- a Reason header that
contains proper SIP response code;
- further
headers, based on local policy;
- send
the BYE request directly to the called user; and
4) if the
S-CSCF serves the called user of the session, generate an additional BYE
request destined for the calling user based on the information saved for the
related dialog, including:
- a
Request-URI, set to the stored
Contact header field provided by the calling user;
- a To
header, set to the From header field value as received in the initial INVITE
request;
- a From
header, set to the To header field value as received in the 200 (OK) response
for the initial INVITE request;
- a
Call-ID header, set to the Call-Id header field value as received in the
initial INVITE request;
- a CSeq
header, set to the CSeq value that was stored for the direction from the called
to the calling user, incremented by one – if no CSeq value was stored for that
session the BYE shall generate and apply a random number within the valid range
for CSeqs;
- a
Route header field, set to the routeing information towards the calling user as
stored for the dialog;
- a Reason header field
that contains proper SIP response code;
- further
headers, based on local policy;
- treat
the BYE request as if received directly from the called user, i.e. the S-CSCF
shall send the BYE request to the internal service control and based on the
outcome further on towards the calling user..
Upon receipt of the 2xx responses for both
BYE requests, the S-CSCF shall release all information related to the dialog
and the related multimedia session.
When:
1) the
registration lifetime of the only public user identity currently registered
with its associated set of implicitly registered public user identities (i.e.
no other is registered) and bound either to the contact address of the UE or to
the registration flow and the associated contact address (if the multiple
registration mechanism is used) expires;
2) there
are still active multimedia sessions that includes either this user's contact
address or the registration flow and the associated contact address (if the
multiple registration mechanism is used);
3) the
session was initiated by or terminated towards the user using the public user
identity currently registered or with one of the implicitly registered public
used identities bound either to the contact address of the UE or to the registration flow and the associated
contact address (if the multiple registration mechanism is used);
then the S-CSCF shall:
- release
each of these multimedia sessions by applying the steps listed in the
subclause 5.4.5.1.2. The S-CSCF shall only release dialogs associated with
the multi media sessions originated or terminated towards the registered user's
contact address or the registration flow and the associated contact address (if
the multiple registration mechanism is used).
Upon receipt of a request on a dialog for
which the S-CSCF initiated session release, the S-CSCF shall terminate the
received request and answer it with a 481 (Call/Transaction Does Not Exist)
response.
Upon receipt of a 2xx response for a BYE
request matching an existing dialog, the S-CSCF shall delete all the stored
information related to the dialog.
If the S-CSCF requested the session to be
refreshed periodically, and the S-CSCF got the indication that the session will
be refreshed, when the session timer expires, the S-CSCF shall delete all the
stored information related to the dialog.
Void.
For a
reINVITE request or UPDATE request from the UE within the same dialog, the
S-CSCF shall store the updated access-network-charging-info parameter from
P-Charging-Vector header field in the received SIP request. The S-CSCF shall retain the access-network-charging-info parameter
in the P-Charging-Vector header field when the request is forwarded to an AS.
However, the S-CSCF shall not include the access-network-charging-info
parameter in the P-Charging-Vector header field when the request is forwarded
outside the home network of the S-CSCF.
For a reINVITE request from the UE, if the
request is to be forwarded to an AS that is located within the trust domain,
the S-CSCF shall retain the access-network-charging-info parameter from the
P-Charging-Vector header field; otherwise, the S-CSCF shall remove the
access-network-charging-info parameter from the P-Charging-Vector header field.
For a reINVITE request or UPDATE request
destined towards the UE within the same dialog, when the S-CSCF receives the 200
(OK) response (to the INVITE request or UPDATE request), the S-CSCF shall store
the updated access-network-charging-info parameter from the P-Charging-Vector
header field. The S-CSCF shall retain the access-network-charging-info
parameter in the P-Charging-Vector header field when the response is forwarded
to the AS. However, the S-CSCF shall not include the
access-network-charging-info parameter in the P-Charging-Vector header field when
the 200 (OK) response is forwarded outside the home network of the S-CSCF.
For any SIP response to an INVITE request,
if the response is to be forwarded to an AS that is located within the trust
domain, the S-CSCF shall retain the access-network-charging-info parameter from
the P-Charging-Vector header field; otherwise, the S-CSCF shall remove the
access-network-charging-info parameter from the P-Charging-Vector header field.
The
S-CSCF provides a service of assigning and translating GRUUs for use by registered
UEs, unless "Loose-Route Indication" indicating the HSS requires
the loose-route mechanism as described in 3GPP TS 29.228 [14] has been
provisioned in the service profile of the registered public user identity. This is conducted as specified
in RFC 5627 [93] and RFC 5628 [94]. Two kinds of GRUUs are
assigned: public GRUUs and temporary GRUUs.
NOTE: If
the UE performs the functions of an external attached network (e.g an
enterprise network) the UE could have self allocated its own GRUUs. In this version of the specification only UE self allocated public GRUUs are supported. Routeing to a specific UE self-allocated
public GRUUs requires that "Loose-Route Indication" indicating
the HSS requires the loose-route mechanism as described in
3GPP TS 29.228 [14] is provisioned in the service profile of the
served public user identity. Use of UE self-allocated temporary GRUUs is not
supported in this version of the specification and requests addressed to UE
self allocated temporary GRUUs will fail to be routed to the UE.
Each
assigned GRUU represents an association between a public user identity and an
instance ID provided by a registering UE. It is used to address a particular UE
that possesses the instance ID and registers with the public user identity. The
GRUU also denotes a contact address registered with a public user identity when
the contact address has a "+sip.instance" header field parameter
containing the GRUU instance ID.
The S-CSCF issues GRUUs as part of the registration process, and also
reports GRUUs as part of notifications for subscriptions to the "reg"
event package. The S-CSCF always issues GRUUs in pairs – a public GRUU and a
temporary GRUU. In case of implicit registration the S-CSCF assigns a unique
public GRUU and a unique temporary GRUU for each public user identity.
The S-CSCF may also support the procedures for allocating public GRUUs
and supporting the generation of temporary GRUUs by the
functionality within the UE that performs the role of registrar as specified in RFC 6140 [191]
as well as the
procedures to route requests containing such GRUUs.
Each public GRUU shall conform to all
requirements specified in RFC 5627 [93].
If the Contact URI
in the Contact header field does not contain a "bnc" URI parameter, then the S-CSCF constructs a public
GRUU by adding a "gr" SIP URI
parameter to the canonical for m of the SIP URI
which contains a public user identity.
If the Contact URI
in the Contact header field contains a "bnc" URI
parameter and if the S-CSCF supports RFC 6140 [191], then the S-CSCF
constructs a public GRUU by adding both "bnc" and "gr" SIP URI parameters to the canonical form of the SIP URI from the To header field of the REGISTER
request
The "gr" SIP URI parameter serves as an indicator that the URI is in fact a GRUU and if the
"+sip.instance" header field parameter from the Contact address
contains an IMEI URN or a MEID URN then it carries a value that encodes the IMEI
based instance ID that is defined in 3GPP TS 23.003 [3] or the
MEID based instance ID which is defined in draft-atarius-device-id-meid-urn [187]
otherwise it carries the value received in the "+sip.instance" header
field parameter.
By default, the value of the "gr"
SIP URI parameter is a copy of the
value of the "+sip.instance" header field parameter from a Contact
address registered with the S-CSCF, with escaping of special characters as
specified in RFC3261 [26].
The public GRUU that is returned in the "pub-gruu"
parameter in the 200 (OK) response to the REGISTER request is constructed using
the canonical form of the SIP URI
of the public user identity from the To header field of the REGISTER request
provided that public user identity is not barred. If the public user identity
from the To header field of the REGISTER request is barred then the public GRUU
that is returned in the "pub-gruu" parameter in the 200 (OK) response
to the REGISTER request is constructed using the canonical form of the SIP URI of the default public user identity.
NOTE 1: The
default public user identity is always provisioned as a SIP URI.
If the "+sip.instance" header
field parameter from the Contact address contains an IMEI URN, as specified in RFC 7254 [153]
or an MEID URN, as specified in draft-atarius-device-id-meid-urn [187],
then the value of the "gr" SIP URI
parameter is generated by the S-CSCF using the name-based UUID algorithm
defined in RFC 4122 [154]. The following applies to the algorithm:
1) the "name
space ID" shall be a UUID generated for use across the administrative
domain and shall use the algorithm for creating a UUID from truly random
numbers specified in RFC 4122 [154];
NOTE 2: If
the generated UUID is changed, then newly created GRUUs will not match those
that were created with the previous UUID. Therefore, the UUID needs to remain
the same in order to create consistent GRUUs. This means that the namespace
UUID needs to be the same for all S-CSCFs within the domain for which the
public GRUU is hosted (it cannot be generated at run time by the S-CSCF as that
would produce different values).
2) SHA-1
shall be used as the hash algorithm; and
3) the
"name" is made up of a concatenation of the ASCII representation (see
RFC 20 [212]) of:
a) if
IMEI, the TAC and SNR portions of the IMEI; or
b) if
MEID, the Manufacturer Code and the Serial Number portions of the MEID;
from
the "+sip.instance" header field parameter.
Only the IMEI shall be use for generating
an instance ID for a multi-mode UE that supports both 3GPP and 3GPP2 defined
radio access networks, and the S-CSCF shall follow the procedures for an IMEI
as described above.
The S-CSCF shall store the "gr"
parameter used in a public GRUU and the associated value received in a
"+sip.instance" header field parameter.
The public GRUU for a particular
association of public user identity and instance ID is persistent. The same
public GRUU will be returned each time a registration is performed with a
particular pair of public user identity and instance ID.
NOTE 1: For
UEs performing the functions of an external attached network that support RFC 6140 [191]
the S-CSCF does not allocate temporary GRUUs but
assists the functionality within the UE that performs the role of registrar in
allocating it's own temporary GRUUs by providing to the UE the "temp-gruu-cookie"
header field parameter that uniquely identifies the registration. The
functionality within the UE that performs the role of registrar then is able to
allocate its own temporary GRUUs as per RFC 6140 [191] procedures.
Each temporary GRUU shall conform to all
requirements specified in RFC 5627 [93].
Because of the limited lifetime of an
temporary GRUU, only the S-CSCF that created a temporary GRUU is required to understand
how to translate that GRUU to the corresponsing public user identity and instance
ID.
The temporary GRUU that is returned in the "temp-gruu"
parameter in the 200 (OK) response to the REGISTER request is mapped to the
public user identity from the To header field of the REGISTER request provided
that public user identity is not barred. If the public user identity from the
To header field of the REGISTER request is barred then the temporary GRUU that
is returned in the "temp-gruu" parameter in the 200 (OK) response to
the REGISTER request is mapped to the default public user identity.
NOTE 2: The
default public user identity is always provisioned as a SIP URI.
The specific representation of a temporary
GRUU may be decided by each S-CSCF implementation. Temporary GRUUs must route
to the assigning S-CSCF without requiring each assigned GRUU to be stored in
the HSS.
The S-CSCF may choose a representation of
temporary GRUUs that requires no extra state to be retained, such as that
specified in RFC 5627 [93]. Alternatively, the S-CSCF may choose a stateful representation.
This is an implementation choice.
NOTE 3: One
possible implementation is for the S-CSCF to have a statically configured
wildcard PSI that routes to it, with each temporary GRUU being encoded so that
it matches the wildcard.
The S-CSCF shall recognize those GRUUs it
has assigned, verify their validity, and extract the associated public user
identity or stored identity of the UE that represents the functionality within
the UE that performs the role of registrar and instance ID. This is true for
both public GRUUs and temporary GRUUs.
NOTE 1: The
S-CSCF only validates and extracts the associated public user identity and
instance ID for GRUUs that it assigned.
GRUUs are distinguished from other URIs by
the presence of a "gr" SIP URI
parameter. Public GRUUs are distinguished from temporary GRUUs by the presence
of a value for the "gr" SIP URI
parameter.
The instance ID is obtained from a public
GRUU by using the "gr" parameter to retrieve the stored associated
instance ID. The public user identity or stored identity of the UE that
represents the functionality within the UE that performs the role of registrar is
extracted from a public GRUU by removing the "gr" SIP URI parameter.
The S-CSCF can recognize a public GRUU as
valid if the "gr" parameter contains a value that was stored in the
S-CSCF during generation of the public GRUU, and the derived public user
identity compares equal, according to the comparison rules of RFC3261 [26],
to a public user identity active within the S-CSCF or a stored identity of the
UE that represents the functionality within the UE that performs the role of
registrar from which a public GRUU was created. When validating public GRUUs
the S-CSCF shall ignore the presence of any "sg" SIP URI parameter when determining if a public GRUU is
one allocated by the S-CSCF.
NOTE 2: The
UE that supports RFC 6140 [191] and performs the functions of an
external attached network, adds a unique "sg" SIP URI parameter value to the public GRUU supplied by
the S-CSCF when generating public GRUUs for its registering UAs.
The public user identity and instance ID
are derived from a temporary GRUU via implementation specific means consistent
with the way temporary GRUUs are constructed. The S-CSCF shall determine the validity
of a temporary GRUU in conformance with RFC 5627 [93], and if the
GRUU was allocated using RFC 6140 [191] procedures then in conformance with
RFC 6140 [191] or using implementation
specific means.
The S-CSCF regards a UE self-allocated
public GRUU as valid if "Loose-Route Indication" indicating the HSS requires
the loose-route mechanism as described in 3GPP TS 29.228 [14] is
provisioned in the service profile of the served public user identity.
S-CSCF
shall handle the emergency registration as per the needs of the normal
registration.
NOTE: Emergency specific procedures for the Cx
interface are specified in annex G in 3GPP TS 29.228 [14].
When the S-CSCF receives a REGISTER request;
and the Contact header field includes a "sos" SIP URI parameter that indicates that this is an
emergency registration, the S-CSCF shall perform the actions as specified in
subclause 5.4.1.1 with the following additions:
1) when handling
unprotected REGISTER request or protected REGISTER request, the S-CSCF:
a) shall
deregister only contacts that were registered as part of emergency
registration; and
b) shall
not deregister contacts that were registered as part of non-emergency registration;
NOTE 1: other
conditions triggering contact deregistration are described in
subclause 5.4.1.
2) for the
protected REGISTER request, when the S-CSCF receives a REGISTER request with
the "integrity-protected" header field parameter in the Authorization
header field set to "yes", "tls-yes" or
"ip-assoc-yes", i.e. for the protected REGISTER request, and the
Contact header field includes a "sos" SIP URI
parameter that indicates that this is an emergency registration, the S-CSCF
shall identify the user by the public user identity as received in the To
header field and the private user identity as received in the Authorization
header field of the REGISTER request;
3) if
operator policy does not require that emergency service requests are forwarded
to the S-CSCF, the S-CSCF shall not include a Service-Route header field in the
200 (OK) response to the REGISTER request;
4) the
S-CSCF shall not include a temporary GRUU in the 200 (OK) response to the
REGISTER request;
5) the
S-CSCF shall in the Contact header field of the 200 (OK) response to the
REGISTER request include only the URI that was
successfully emergency registered and in this URI include the "sos" SIP URI
parameter;
NOTE 2 Only including the emergency registered
contact in the 200 (OK) response to the REGISTER request deviates from bullet 8
in section 10.3 of RFC 3261 [26].
NOTE 3: In the case where the S-CSCF returns a GRUU
in the Contact header field of the 200 (OK) response to the REGISTER request,
the "sos" SIP
URI parameter is appended to the URI
and not included as a Contact header field parameter. The public GRUU that is
returned in the 200 (OK) response includes the "sos" SIP URI parameter as a
parameter of the URI included in
the "pub-gruu" Contact header field parameter.
6) store
the Path header field and the contact information including all header field parameters
contained in the Contact header field;
NOTE 4: The Path header field and contact information
used for the emergency dialogs destined for the UE and obtained during the
emergency registration can be different than the Path header field used for the
non-emergency communication and obtained during the non-emergency registration.
NOTE 5: The S-CSCF will not perform the network
initiated deregistration procedure for an emergency registration, but will let
it expire. A new emergency registration will overwrite any previous emergency
registration.
7) the
S-CSCF shall not send any third-party REGISTER requests to any AS;
8) the
S-CSCF shall not include an empty P-Debug-ID header field;
NOTE 6: Including an empty P-Debug-ID header field in
a 200 (OK) response to an emergency registration could delay emergency call
setup as it causes the UE to subscribe to the debug event package.
9) determine
the duration of the registration by checking the value of the registration
expiration interval value in the received REGISTER request and based on local
policy; and
NOTE 7: The value of the emergency registration time
is subject to national regulation and can be subject to roaming agreements.
10) for any
bindings created by the emergency registration, mark those bindings as created
by an emergency registration.
When S-CSCF receives a REGISTER request
with the registration expiration interval value containing zero and the Contact
header field contains a contact address that has been registered for emergency
service (i.e. the "sos" SIP URI
parameter that indicates that this is an emergency registration is included in
the Contact header field), the S-CSCF shall reject the REGISTER request by
sending a 501 (Not Implemented) response.
NOTE: The
UE cannot deregister its emergency public user identity.
The S-CSCF shall not perform a
network-initiated emergency deregistration.
If a given public user identity and the
associated contact address have been registered via emergency registration, the
S-CSCF shall not reauthenticate this public user identity.
If a S-CSCF receives a SUBSCRIBE request
addressed to S-CSCF containing the Event header field with the reg event
package with the Contact header field that contains a contact address that has
been registered for emergency service, the S-CSCF shall reject the SUBSCRIBE
request for the reg-event package by sending a 489 (Bad Event) response.
When the user performs an emergency
registration or when the emergency registration expires, the S-CSCF shall not
send a NOTIFY
request to the subscribers to the reg event package of
the respective user.
The contact address that has been
registered for emergency service shall not be included in the NOTIFY requests sent to the subscribers to the reg event package of the user.
