A.5.2 Signalling flows for termination to a CS UE not registered in IMS

24.2923GPPIP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS)Release 17Stage 3TS

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

Figure A.5.2-1 shows the termination of a call to a CS UE not registered in the IM CN subsystem.

Figure A.5.2-1: CS UE Termination to UE not registered in the IM CN subsystem

The details of the signalling flows are as follows:

Steps 1 through 5 are identical to the example is subclause A.5.1.

6. Domain selection

The SCC AS acting performs terminating access domain selection based on operator and user preferences, registration and call states; in this example, the user is not registered in the IM CN subsystem and the SCC AS selects breakout to the CS domain to terminate the call.

7. CSRN retrieval

The SCC AS determines the CS domain Routing Number (CSRN).

NOTE: CSRN retrieval is implementation specific.

8. SIP INVITE request (from SCC AS to intermediate IM CN subsystem entities) – see example in table A.5.2-8

The SCC AS acting as a routing B2BUA generates a SIP INVITE request.

Table A.5.2-8: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities)

INVITE tel:+1-212-555-2222 SIP/2.0

Via: SIP/2.0/UDP sccas.home1.net;branch=z9hG4bKnas34r5

Max-Forwards: 65

Feature-Caps:+g.3gpp.ics

Route: <sip: cb03a0s09a2sdfglkj490333@scscf1.home1.net;lr>;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"

Record-Route:<sip:sccas.home1.net;lr>

P-Access-Network-Info:

P-Asserted-Identity:

P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4ee]; ecf=[5555::6aa:7bb:8cc:9dd]

P-Charging-Vector:

P-Asserted-Service:

Accept-Contact:

Privacy:

From: <sip:user1_public1@home2.net>;tag=274890

To:

Call-ID:

Cseq:

Supported:

Accept:

Contact:

Allow:

Content-Type:

Content-Length: (…)

Request-URI: the CSRN.

Feature-Caps: The header field contains g.3gpp.ics feature-capability indicator indicating support of IMS Centralized Services.

Via: the SCC AS, acting as a B2BUA, replaces the Via header field with one containing only its own SIP URI.

9. SIP 100 (Trying) response (from intermediate IM CN subsystem entities to SCC AS)

The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response. There is no ICS specific content in this response.

10. SIP INVITE request (from intermediate IM CN subsystem entities to BGCF)

The S-CSCF determines the destination is in the CS domain (e.g. after ENUM/DNS translation fails to translate the CSRN in tel URI format to a globally routeable SIP URI). The S-CSCF forwards the INVITE request to a BGCF in the local network.

11. SIP 100 (Trying) response (from BGCF to intermediate IM CN subsystem entities)

The BGCF responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is no ICS specific content in this response.

12. SIP INVITE request (from BGCF to MGCF)

The BGCF analyzes the destination address and allocates a MGCF to handle the termination. The BGCF forwards the INVITE request to the MGCF.

In this example, the BGCF does not add itself to the Record-Route header field and will therefore not be in the session path of subsequent SIP requests.

13. SIP 100 (Trying) response (from MGCF to BGCF)

The MGCF responds to the MGCF with a SIP 100 (Trying) response. There is no ICS specific content in this response.

14-18. SIP 183 (Session Progress) response

The SIP 183 (Session Progress) response is routed to the originating IM CN subsystem via the SCC AS and intermediate IM CN subsystem entities. In this example the SCC AS includes the contents of the Contact header from the received SIP 183 (Session Progress) response.

19-22. SIP PRACK request and SIP 200 (OK) response

The SIP PRACK request and its SIP 200 (OK) response are routed end-to-end between the originating IM CN subsystem, intermediate IM CN subsystem entities, SCC AS and MGCF. There is no specific ICS content in these messages. In this example the SCC AS includes the contents of the Contact header from the received SIP PRACK request.

23-26. SIP UPDATE request and SIP 200 (OK) response

When the originating endpoint has completed its resource reservation, the intermediate IM CN subsystem entities receive an UPDATE request. The UPDATE request and its SIP 200 (OK) response are routed end-to-end between the originating IM CN subsystem, intermediate IM CN subsystem entities, SCC AS and MGCF. There is no specific ICS content in these messages. In this example the SCC AS includes the contents of the Contact header from the received SIP UPDATE request.

27-31. SIP 180 (Ringing) response (from MGCF to intermediate IM CN subsystem entities)

The SIP 180 (Ringing) response is routed to the originating IM CN subsystem via the SCC AS and intermediate IM CN subsystem entities. The MGCF does not include "100rel" in the Require header field as the 180 (Ringing) does not contain SDP and therefore need not be sent reliably.

32-36. SIP 200 (OK) response

The 200 (OK) response is routed to the originating IM CN subsystem via the SCC AS and intermediate IM CN subsystem entities.

37-41. SIP ACK request

A SIP ACK request is routed end-to-end from the originating IM CN subsystem to the MGCF. There is no ICS specific content in this message.