A.3 Terminating flows

24.1743GPPRelease 17Stage 3Support of multi-device and multi-identity in the IP Multimedia Subsystem (IMS)TS

A.3.1 UE-B reached by identity D

This call flow illustrates the handling of an identity for terminating calls not registered by UE-A. For simplicity the CSCF nodes have been omitted.

Figure A.3.1-1: UE-B reached by an identity D

1. AS-D receives an INVITE message from PLMN-A, for an example see table A.3.1-1

The Request-URI identifies the target user as D. Based on that, AS-D determines the identities to which it shall forward the request.

The AS-D determines that this request needs to go to UE-B for which the identity in Request-URI is not a native identity and it applies required forwarding behavior, as part of the MiD service.

The AS-D also sends this message to UE(s) of the user owning identity D following procedures defined in TS 24.229 [3].

The AS-D sets the Request-URI to identity B and adds an Additional-Identity header field set to identity D.

Table A.3.1-1: INVITE request (PLMN-A to AS-D)

INVITE tel:+22222222 SIP/2.0

To: <tel:+22222222>

From: <tel:+11111111>;tag=4fa3

P-Asserted-Identity: <sip:+11111111@plmnA.net;user=phone>, <tel:+11111111>

Other SIP header fields and SDP according to 3GPP TS 24.229 [3]

2. AS-D forwards the INVITE message towards S-CSCF-B, for an example see table A.3.1-2

Table A.3.1-2: INVITE request (AS-D to S-CSCF-B)

INVITE tel:+11112222 SIP/2.0

To: <tel:+22222222>

From: <tel:+11111111>;tag=4fa3

P-Asserted-Identity: <sip:+11111111@plmnA.net;user=phone>, tel:+11111111

Additional-Identity: <tel:22222222>

Other SIP header fields and SDP according to 3GPP TS 24.229 [3]

3. S-CSCF-B forwards the INVITE message to AS-B

– AS-B performs terminating services.

4. -AS-B forwards the INVITE message to S-CSCF-B

5. S-CSCF-B forward the INVITE message to UE-B

S-CSCF-B replaces B identity with the UE-B contact in the Request-URI and adds a P-Called-Party-ID header field.

UE-B determines from the Additional-Identity header field that it has been reached using the identity D. The P-Called-Party-Id header field can be ignored.

A.3.2 UE-B reached by native identity on multiple devices

This call flow illustrates the handling of the terminating call case when the request is forwarded towards the user holding the requested identity as native identity who subscribes to the MuD service. It follows normal procedures and is included for completeness.

Figure A.3.2-1: UE-B reached by a native identity on multiple devices

1. S-CSCF-B receives an INVITE message from PLMN-A, for an example see table A.3.2-1

The Request-URI identifies user B as B-native.

Table A.3.2-1: INVITE request (PLMN-A to I/S/P-CSCF-B)

INVITE tel:+11112222 SIP/2.0

To: <tel:+11112222>

From: <tel:+11111111>;tag=4fa3

P-Asserted-Identity: <sip:+11111111@plmnA.net;user=phone>, <tel:+11111111>

Other SIP header fields and SDP according to 3GPP TS 24.229 [3]

2. S-CSCF-B forwards the INVITE message to AS-B

The AS-B determines that it shall forward the request towards UE1-B and UE2-B for which the identity in Request-URI is a native identity.

AS-B can also send this to UEs configured to use the identity from the Request-URI as external alternative identity. This follows the terminating procedure in clause A.3.1.

3. AS-B forwards the INVITE message to the S-CSCF-B

The S-CSCF-B replaces B identity with the UE1-B contact and UE2-B contact , respectively, in the Request-URI and adds a P-Called-Party-ID header field.

4. S-CSCF-B forwards the INVITE message to UE-B

5. UE2-B responds with 200 (OK)

6. The S-CSCF-B forwards the 200 (OK) response to AS-B

The S-CSCF-B inserts a Feature-Caps header field including a "registration-token" header field parameter to identify the registration flow.

NOTE: The AS-B learns the values of the registration-token during registration as specified in TS 24.229 [3]

7. The AS-B forwards the 200 (OK) response to the S-CSCF-A.

8. The S-CSCF-B forwards the 200 (OK) response to PLMN-A.

The S-CSCF-B removes the "registration-token" header field parameter.