A.4 MuD call flows: Synchronization of call logs

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

A.4.1 General

The call flows in the following clauses illustrate typical scenarios to synchronize local call logs in federated UEs with the network stored call log.

The network call log storage is hosted in the AS. The AS updates the call log objects as appropriate based on the SIP call control signalling. The UE uses HTTP over the Ut reference point to subscribe to changes in the centralized call log, and use the notifications received to update the own local call log. The UE and the AS procedures and signalling related to the call log synchronization are based on the "strict synchronization" mechanism in accordance to OMA-TS-CPM_Message_Storage_Using_RESTFul_API [9] and OMA-TS-REST_NetAPI_NMS.

Incoming and outgoing calls of user A follow normal procedures as specified in TS 24.229 [3] but for simplicity only the AS node is shown (the CSCF, MRF, IBCF nodes have been omitted).

In the examples, "solid" lines represent the HTTP signalling between the UE and the AS and "dashed" lines represent the SIP call control signalling.

A.4.2 Subscription to notifications of network call log changes

This call flow illustrates subscription to notifications of network call log changes for the user of the MuD service which has two UEs. Subscription to notifications of network call log changes needs to be done separately for each UE.

NOTE 1: The UE can also read an individual subscription to a call log notification, update an individual subscription to notifications of network call log changes or unsubscribe to call log notifications.

Figure A.4.2-1: Subscription to notifications of network call log changes

1. UE1-A sends an HTTP POST request to AS-A

To subscribe to notifications of network call log changes, the UE1-A sends the HTTP POST request with "{apiRoot}/nms/{apiVersion}/{storeName}/{boxId}/subscriptions" as a request URI and the "NmsSubscription" data structure as a request body to the AS-A.

NOTE 2: The "NmsSubscription" data structure is defined in OMA-TS-REST_NetAPI_NMS.

The UE1-A includes in the "NmsSubscription":

– a UE1-A_callback_URI where the UE1-A wants to receive the requested notifications in the "callbackReference" attribute;

– changes in the call log the UE1-A is interested to receive in the "filter" attribute i.e. flag for an indication of a call log entry with enriched calling information received in association with the call (type = Flag, name = $CPM_CallLog_EnCall);

and can include:

– period of time (in seconds) notifications are provided for in the "duration" attribute; and

– subscription restart token indicating the point at which this UE1-A subscription is to start in the "restartToken" attribute (e.g., if the UE1-A has been offline for a period).

NOTE 3: If the "restartToken" attribute is absent, any changes from the time this UE1-A subscription is created will be notified by the AS-A.

2. AS-A sends a HTTP response "201 Created" to UE1-A

The AS-A creates a new Individual Subscription resource and sends a "201 Created" response to the UE1-A. The AS-A includes in the "201 Created" response:

– a Location header field containing the URI of the created resource i.e. "{apiRoot}/nms/{apiVersion}/{storeName}/{boxId}/subscriptions/{subscriptionId-1}"; and

– "NmsSubscription" data structure.

The AS-A includes in the "NmsSubscription" data structure subscription data for the UE1-A:

– period of time (in seconds) which the UE1-A subscription will still be valid in the "duration" attribute;

– index of the next notification to be issued to the UE1-A in the "index" attribute; and

– subscription restart token indicating the point at which this UE1-A subscription currently starts in the "restartToken" attribute,

and can include:

– the maximum number of events that can be delivered in a NmsEventList in the "maxEvents" attribute if "maxEvents" attribute was not provided by the UE1-A.

3. UE2-A sends an HTTP POST request to AS-A

This step is same as step 1, but in the "NmsSubscription" data structure the UE2-A includes its own subscription data e.g. the "callbackReference" attribute contains a UE2-A_callback_URI where the UE2-A wants to receive the requested notifications.

4. AS-A sends a HTTP response "201 Created" to UE2-A

This step is same as step 2, but the AS-A creates a new Individual Subscription resource for the UE2-A. The "NmsSubscription" data structure contains subscription data for the UE2-A. The URI of the created resource is indicated in a Location header field:
"{apiRoot}/nms/{apiVersion}/{storeName}/{boxId}/subscriptions/{subscriptionId-2}".

A.4.3 Synchronization of list of outgoing calls

This call flow illustrates synchronization of list of outgoing calls when the user of the MuD service has two UEs and both UEs subscribed to notifications of network call log changes, as shown in clause A.4.2.

Figure A.4.3-1: Synchronization of list of outgoing calls

1. – 10 User A makes a call towards UE-B from UE1-A

The call flow between the UE1-A and the UE-B via the AS-A follows normal procedures as specified in TS 24.229 [3]. The UE-B answered call.

NOTE 1: For simplicity SIP "100 Trying", "183 Session Progress" responses, SIP ACK requests etc. are not shown.

11. UE1-A updates local call log

After call release i.e. in this example sending SIP 200 OK response to the UE-B, the UE1-A adds outgoing call to the UE-B in the local call log.

12. AS-A updates UE-A network call log

After call release i.e. in this example sending SIP 200 OK response to the UE-B, the AS-A adds a call log entry with enriched calling information in the UE-A’s network call log.

13. AS-A sends a HTTP POST request to UE1-A

The AS-A observes changes in the call log for which the UE1-A has subscribed to and sends an HTTP POST request with "callbackReference" as a request URI (i.e. UE1-A_callback_URI) and the "NmsEventList" data structure as a request body, containing the call log object.

NOTE 2: The "NmsEventList" data structure is defined in OMA-TS-REST_NetAPI_NMS [10] and Call log object is defined in OMA-TS-CPM_Message_Storage_Using_RESTFul_API [9].

14. UE1-A sends a HTTP response "204 No Content" to AS-A

Upon successful reception of the HTTP POST request the UE1-A:

– stores received "index" attribute;

– stores received "restartToken" attribute; and

– sends an HTTP "204 No Content" response to the AS-A.

15. UE1-A local call log update

The UE1-A may update its local call log with the call log object for the outgoing call from the UE1-A to the UE-B as needed.

16. AS-A sends a HTTP POST request to UE2-A

The AS-A observes changes in the call log for which the UE2-A has subscribed to and sends an HTTP POST request with "callbackReference" as a request URI (i.e. UE2-A_callback_URI) and the "NmsEventList" data structure as a request body, containing the call log object.

17. UE2-A sends a HTTP response "204 No Content" to AS-A

Upon successful reception of the HTTP POST request the UE1-A:

– stores received "index" attribute;

– stores received "restartToken" attribute; and

– sends an HTTP "204 No Content" response to the AS-A.

18. UE2-A local call log update

Based on information received from the AS-A in the HTTP POST request, the UE2-A adds the outgoing call log object from the UE-A to the UE-B in the local call log.

A.4.4 Synchronization of missed call notifications

This call flow illustrates synchronization of missed call notifications when the user of the MuD service has two UEs and both UEs subscribed to notifications of network call log changes, as shown in clause A.4.2.

Figure A.4.4-1: Synchronization of missed call notifications

1. – 6 UE-B makes a call towards UE-A

The call flow between the UE-B and the user A UE’s via the AS-A follows normal procedures as specified in TS 24.229 [3]. The user A subscribed to MuD service and the AS-A forwards SIP initial INVITE request to the UE1-A and the UE2-A. The user A did not answer call from the UE-B.

NOTE 1: For simplicity SIP "100 Trying", "183 Session Progress" responses, SIP ACK requests etc. are not shown.

7a. UE1-A updates local call log

After sending of an unsuccessful SIP response on SIP initial INVITE request (i.e. in this example SIP "480 Temporarily Unavailable" response) to the UE-B, the UE1-A adds incoming call from the UE-B in the local call log and marks it as "Missed" and flagged as "Not seen".

7b. UE2-A updates local call log

After sending of an unsuccessful SIP response on SIP initial INVITE request (i.e. in this example SIP "480 Temporarily Unavailable" response) to the UE-B, the UE2-A adds incoming call from the UE-B in the local call log and marks it as "Missed" and flagged as "Not seen".

8. AS-A updates UE-A network call log

After sending of unsuccessful SIP response on SIP initial INVITE request (i.e. in this example SIP "480 Temporarily Unavailable" response) to the UE-B, the AS-A creates a call log entry with enriched calling information in the UE-A’s network call log: incoming call from the UE-B is marked as "LEFT_MESSAGE".

NOTE 2: The following values are specified for the incoming call: "ANSWERED", "LEFT_MESSAGE", "HUNG_UP", "REJECTED", "BUSY" or "BLACKLISTED", see attribute "Call-Disposition" defined in clause 5.3.9.3 of OMA-TS-CPM_Message_Storage_Using_RESTFul_API [9].

9. AS-A sends a HTTP POST request to UE1-A

10. UE1-A sends a HTTP response "204 No Content" to AS-A

Upon successful reception of the HTTP POST request the UE1-A:

– stores received "index" attribute;

– stores received "restartToken" attribute; and

– sends an HTTP "204 No Content" response to the AS-A.

11. UE1-A local call log update

The UE1-A may update the local call object if needed with information from the call log object for the incoming call from the UE-B.

12. AS-A sends a HTTP POST request to UE2-A

13. UE2-A sends a HTTP response "204 No Content" to AS-A

Upon successful reception of the HTTP POST request the UE2-A:

– stores received "index" attribute;

– stores received "restartToken" attribute; and

– sends an HTTP "204 No Content" response to the AS-A.

14. UE2-A local call log update

The UE2-A may update the local call object if needed with information from the call log object for the incoming call from the UE-B.

15. User A checked UE2-A local call log

The user A checked UE2-A local call log and flag "Not seen" is deleted from call log.

16. UE2-A sends HTTP PUT request to AS-A

The UE2-A indicates to the AS-A that the call from the UE-B needs to be flagged as "Seen" by sending the HTTP PUT request.

NOTE 3: Flag "/Seen" is added to the flaglist of a call log object in accordance to clause 6.6.1.1. of OMA-TS-CPM_Message_Storage_Using_RESTFul_API [9] and clause 6.3.4 of OMA-TS-REST_NetAPI_NMS [10].

17. AS-A sends a HTTP response "200 OK" to UE2-A

The AS-A responds with HTTP "200 OK" response to the UE2-A.

18. AS-A updates UE-A network call log

The AS-A adds flag "/Seen" to the call log object for the incoming call from the UE-B.

19. AS-A sends a HTTP POST request to UE1-A

Since the AS-A observes changes in the call log for which the UE1-A has subscribed to (flag "/Seen" added to the call log object for the incoming call from the UE-B), the AS-A sends an HTTP POST request with "callbackReference" as a request URI (i.e. UE1-A_callback_URI) and the "NmsEventList" data structure as a request body containing the call log object with the flag "/Seen".

20. UE1-A sends a HTTP response "204 No Content" to AS-A

Upon successful reception of the HTTP POST request the UE1-A:

– stores received "index" attribute;

– stores received "restartToken" attribute; and

– sends an HTTP "204 No Content" response to the AS-A.

21. UE1-A local call log update

The UE1-A updates local call log and deletes flag "Not seen" for the incoming call from the UE-B.

22. AS-A sends a HTTP POST request to UE2-A

Since the AS-A observes changes in the call log for which the UE2-A has subscribed to (flag "/Seen" added to the call log object for the incoming call from the UE-B), the AS-A sends an HTTP POST request with "callbackReference" as a request URI (i.e. UE2-A_callback_URI) and the "NmsEventList" data structure as a request body containing the call log object with the flag "/Seen".

23. UE2-A sends a HTTP response "204 No Content" to AS-A

Upon successful reception of the HTTP POST request the UE2-A:

– stores received "index" attribute;

– stores received "restartToken" attribute; and

– sends an HTTP "204 No Content" response to the AS-A.

24. UE2-A local call log update

The UE2-A observes that local call update is not needed since the UE2-A deleted flag "Not seen" for the incoming call from the UE-B in step 15.

Annex B (normative):
IP-Connectivity Access Network specific concepts when using GPRS (Iu mode only) to access IM CN subsystem