Content for TS 24.174 Word version: 18.0.0

4.5 Signalling requirements p. 11

4.5.1 General p. 11

Configuration of the MiD services by the user should take place over the Ut interface using XCAP as enabling protocol as described in TS 24.623.

The enhancements to the XML schema for use over the Ut interface is described in clause 4.8.

4.5.2 Activation/deactivation of MuD/MiD services p. 11

4.5.2.1 General |R17| p. 11

The services and individual identities can be activated or deactivated following procedures in the following clauses.

4.5.2.2 Activation of MuD and MiD services |R17| p. 11

The MuD and MiD services are activated at provisioning and deactivated at withdrawal or at the user's request.

If the MuD, MiD or both services are activated, the user controls whether identities can be used for incoming and outgoing calls by activation/deactivation of identities.

4.5.2.3 Activation/deactivation of identities |R17| p. 11

Via activation/deactivation of identities in case of MiD service, the user controls if the identity is active on its device. Via activation/deactivation of identities in case of MuD service, the user controls if the identity is active on each device in federation separately. If the user of MuD service is also using MiD service, the user controls if each identity is active on each device separately. There is a separate <ue-instance> element for each of the device, distinguishable by the "identity" attribute. The "identity" attribute takes the form of a pvalue as derfined in RFC 3261 and can be set by the operator to a value linked with the IMS private user identity. The "alias" attribute is modifiable by the user and is filled with a user-friendly identifier making the UE instance easier distinguishable among all the devices in federation.

The user of MuD, MiD or both services decides which of the identities that it is allowed to use and can be registered are active and can be used for incoming and outgoing calls by changing the "Activated" attribute in the <Registered-identity> elements in the service configuration data.

The user of MiD service decides which of the identities that have been allowed to be used for the user but cannot be registered are active and can be used for incoming and outgoing calls by changing the "Activated" attribute in the <Shared-identity> elements in the service configuration data.

The user decides if it permits another user to use its native identity. The user decides which users among those who have been allowed to use its identity, can use this identity for incoming and outgoing calls by changing the "Activated" attribute in the <Delegated-user> elements in the service configuration data.

4.5.3 Invocation and operation p. 12

4.5.3.1 Actions at the UE of user A p. 12

4.5.3.1.1 General |R17| p. 12

If user A wishes to use a native identity, the UE shall include in the outgoing INVITE or MESSAGE request the From header field and may include the P-Preferred-Identity header field(s) as specified in TS 24.229. The From header field and the P-Preferred-Identity header field (if included) shall contain the native identity.

If user A wishes to use an alternative identity or a virtual identity that the UE has registered, the UE shall include in the outgoing INVITE or MESSAGE request the From header field and the P-Preferred-Identity header field. The P-Preferred-Identity header field and the From header field shall contain the alternative identity or the virtual identity.

If user A wishes to use the identity C, the UE shall include in any outgoing INVITE or MESSAGE requests, an Additional-Identity header field, defined in TS 24.229, set to the selected identity and shall include the native identity in the From header field. The UE can learn the identity C by device configuration as specified in TS 24.175 or by using the service configuration in clause 4.8.

The UE may support being configured with the identities to be used using one or more of the following methods:

the "MultiIdentity" interior node of the EFMuDMiDConfigData file described in TS 31.102;
the "MultiIdentity" interior node of the EFMuDMiDConfigData file described in TS 31.103; and
the "MultiIdentity" interior node of TS 24.175.

If the UE is configured with both the "MultiIdentity" interior node of TS 24.175 and the "MultiIdentity" interior node of the EFMuDMiDConfigData file described in TS 31.102 or TS 31.103, then the Media_type_restriction_policy node of the EFMuDMiDConfigData file shall take precedence.

When establishing an emergency session and performing the emergency related procedures defined in TS 24.229, the UE shall only use the native identity.

A UE supporting the MuD service may synchronize the local call log with the network stored call log as specified in OMA-TS-CPM_Message_Storage_Using_RESTFul_API [9] and OMA-TS-REST_NetAPI_NMS [10]. If the served user in the "From" header field is an identity not registered by the UE, the UE shall deduce that the call was originated using the Additional-Identity header field.

4.5.3.1.2 Call pull handling |R17| p. 12

The UE may pull a session from another federated UE by performing the following steps:

the UE learns about the session to pull by subscribing to the dialog event package, specified in RFC 4235;
the UE sends an INVITE request towards the far end populated as follows:
1. the Request-URI is set to the uri in the <target> element of the <remote> element;
2. a Replaces header field containing the dialog identifiers contained as attributes in the <dialog> element of the <dialog-info> element; and
3. any other header field or body as determined by the service logic; and
when the UE receives a response to the INVITE request above the UE follows general procedures in TS 24.229.

4.5.3.1.3 Call push handling |R17| p. 13

The UE may push a session to another federated UE by performing the following steps:

the UE learns the status and identities of the other federated UEs using the dialog event package, specified in RFC 4235 and extended as specified in clause 7.X.2 in TS 24.229; and
the UE sends a REFER request towards the target UE populated as follows:

NOTE 1:
In this Release of the present document only one UE is targeted in the transfer.
1. the Request-URI is set to the own public user identity and includes a "gr" SIP URI parameter set to the value of the "identity" attribute for the target UE received in the <ue-instance> element in the <dialog-info> element in the dialog event notification; and
  
  NOTE 2:
  The value in the "identity" attribute has the same format as a GRUU, but is not a GRUU assigned by the S-CSCF. It only has local significance.
2. a Refer-to header field set to the SIP URI of the remote end and including in the headers portion of the SIP URI the headers and bodies determined by the service logic.

4.5.3.2 Actions at the AS serving user A p. 13

4.5.3.2.1 General p. 13

Upon receiving an incoming initial INVITE, REFER or MESSAGE request containing an Additional-Identity header field, the AS shall determine the served user as specified in clause 5.7.1.3A.2 of TS 24.229 and shall check if any of the served user's registered identities is also included in the Additional-Identity header field. If the Additional-Identity header field contains a served user's registered identity the AS shall remove the Additional-Identity header field from the request and shall forward the request in accordance with procedures defined in TS 24.229. Otherwise, if the received Additional-Identity header field does not contain any of the served user's registered identities the AS shall:

verify that the user is authorized to use the identity received in the Additional-Identity header field as specified in clause 4.5.3.2.2; and
if the user is not authorized to use the identity included in the Additional-Identity header field, then the AS shall reject the incoming request. The originating request may be rejected by operator policy with a 403 (Forbidden) response including a warning header field 399 "Identity not allowed".

If the user is authorized to use the identity in the Additional-Identity header field then the AS shall generate a new SIP request based on the received SIP request in accordance with the procedures in clause 5.7.3 of TS 24.229 with the following clarifications:

remove any P-Served-User header field and insert a P-Served-User header field with the identity taken from the Additional-Identity header field in the received request;
remove any existing Route header field and insert a Route header field pointing to an I-CSCF or to the S-CSCF hosting the identity in the Additional-Identity header field in the received request;
in the Route header field above, append the "orig" parameter to the URI; and
insert the Additional-Identity header field with the same value as in the received SIP request.

The AS shall send the generated SIP request and may refrain from the invocation of other MMTel services serving the native identity.

If the AS updates the Call Log as specified in OMA-TS-CPM_Message_Storage_Using_RESTFul_API [9] the AS shall populate the "From" attribute of the call log object with the value in the Additional-Identity header field, provided the user is authorized to use this identity.

4.5.3.2.2 Authorization of the Additional-Identity header field p. 14

The AS serving user A shall authorize the usage of the identity contained in the Additional-Identity header field as the originating identity by checking:

if the identity contained in the Additional-Identity header field is included in the user's service data associated to the native identity of the originating user; and
if the "Activated" attribute of the <Shared-identity> element of the <multi-identity> element in the service configuration data is set to "true".

Otherwise, user A is not authorized to use the identity contained in the Additional-Identity header field as the originating identity.

4.5.3.2.3 Call pull handling |R17| p. 14

An AS supporting call pull handling, when receiving an INVITE request as specified in clause 4.5.3.1.2 shall verify that the calling user is allowed to pull a call. If the call pull is allowed, the AS forwards the received INVITE request in accordance with TS 24.229, otherwise the AS rejects the request with an appropriate response code.

4.5.3.2.4 Call push handling |R17| p. 14

An AS supporting call push handling, when receiving a REFER request as specified in clause 4.5.3.1.3 shall

verify that the user is allowed to push a call; and
if the call push is allowed, based on local policy, either
1. forward the REFER request towards the REFER target; or
2. start 3pcc procedures as specified in TS 24.628 to:
  1. transfer the originating leg from the originator of the REFER reqeust to the REFER target; and
  2. if necessary, update the terminating leg.

The AS shall use the "gr" SIP URI parameter in the Request-URI to identify the REFER target UE. If the AS knows that the content of the "gr" SIP URI parameter is not a GRUU assigned by the S-CSCF the AS shall remove the "gr" SIP URI parameter from the Request-URI before forwarding the request.

4.5.3.3 Actions at the AS serving identity C p. 14

Upon receiving an incoming INVITE or MESSAGE request containing an Additional-Identity header field, the AS shall:

determine the served user as defined in TS 24.229;
if the user identified in the P-Asserted-Identity is not allowed to use the identity in the Additional-Identity header field, reject the request using a 403 (Forbidden) response including a warning header field 399 "Identity not allowed" and skip the rest of the steps;
replace the identity in the From header field with the identity in the Additional-Identity header field;
depending on local configuration, related to the operator policy and regulatory requirements, allowing to determine whether an originating external alternative identity or an originating virtual identity is to be used as an originating identity (calling party number):
1. if the P-Asserted-Identity header can be modified, replace the identity in the P-Asserted-Identity header field with the identity in the Additional-Identity header field; or
2. if the P-Asserted-Identity header cannot be modified, set the Privacy header field "id" to keep the native identity private in the P-Asserted-Identity header field as defined in RFC 3325;
if the identity of the originating user can be verified, based on local policy initiate addition of an Identity header field attesting the identity C;
remove the Additional-Identity header field received in the request; and
perform any other originating services as performed by the service logic,

before forwarding the request downstream.

4.5.3.4 Actions at the AS serving identity D p. 15

For a terminating user, upon receiving an incoming INVITE or MESSAGE request, the AS shall perform any terminating services as performed by the service logic before forwarding the request downstream.

If the AS service determines based on configuration that the AS shall forward the request to any of the identities that can use the identity received in the Request-URI, the AS shall for each forwarded request modify the request as follows:

the Request-URI is set to the identity configured in the AS; and
an Additional-Identity header field, defined in TS 24.229, is added and set to the identity received in the Request-URI.

If the AS supports calling number verification using signature verification and attestation information as specified in TS 24.229, the AS treats the forwarding to the identities above as diversions, i.e. uses the "div" PASSporT as specified in RFC 8946.

If the AS identifies the INVITE request as a PSAP callback, the MiD service shall not be triggered.

4.5.3.5 Actions at the AS serving user B p. 15

Upon receiving an INVITE or MESSAGE request not containing an Additional-Identity header field and if the terminating user is subscribed to the MuD service, the AS shall when sending the request to the UEs verify whether the identity in the Request-URI is activated by the MiD service and on the target UE. The AS shall only send the request to a target UE if the identity is active both in the MiD service and on the target UE. If the user does not subscribe to the MiD service, but the user has the received identity configured in the implicit registration set, the AS considers the identity to be activated by the MiD service.

Upon receiving an INVITE or MESSAGE request containing an Additional-Identity header field and if the terminating user is subscribed to the MuD and the MiD service, the AS shall when sending the request to the UEs verify whether the identity in the Additional-Identity header field is activated by the MiD service and on the target UE. The AS shall only send the request to a target UE if the identity is active both in the MiD service and on the target UE. The AS may refrain from the invocation of other MMTel services configured for the user of the native identity.

If the AS updates the Call Log as specified in OMA-TS-CPM_Message_Storage_Using_RESTFul_API [9] the AS shall populate the "To" attribute of the call log object with the value in the Additional-Identity header field, provided the user is authorized to use this identity.

An AS supporting call pull and call push handling, uses the procedures specified in clauses 4.5.3.2.3 and 4.5.3.2.4.

4.5.3.6 Actions at the UE of user B p. 15

A UE supporting the MiD service shall support the receipt of the Additional-Identity header field, defined in TS 24.229, in SIP requests initiating a dialog or standalone transaction.

A UE supporting the MuD service may synchronize the local call log with the network stored call log as specified in OMA-TS-CPM_Message_Storage_Using_RESTFul_API [9] and OMA-TS-REST_NetAPI_NMS [10]. If the served user in the "To" header field is an identity not registered by the UE, the UE shall deduce that the call was originated using the Additional-Identity header field.

A UE supporting call pull and call push handling uses the procedures specified in clauses 4.5.3.1.2 and 4.5.3.1.3.