A.5.3 Signalling flows for termination to CS domain

24.2063GPPStage 3TSVoice call continuity between Circuit Switched (CS) and IP Multimedia Subsystem (IMS)

Figure A.5.3-1 shows the termination of a call that is capable of being subject to VCC, where the calling party call has been routed through the IM CN subsystem and where the called party is terminating in its home CS domain.

Figure A.5.3-1: Terminating call directed to CS

The details of the signalling flows are as follows:

Steps 1 to 5 are identical to the previous example in subclause A.5.2.

6. The DSF selects the terminating domain

The DSF performs domain selection based on operator and user preferences, registration and call states; in this example the DSF selects the CS domain to terminate the voice call.

7. Interaction between the DSF and CSAF

The DSF in combination with the CSAF determines the CS domain Routeing Number (CSRN).

The CSRN is a dynamic routeing number used for routeing into CS domain, i.e. to find the outgoing MGCF and then the terminating user’s VMSC.

The interaction between the DSF and CSAF is outside the scope of this version of the specification.

8. Interaction between the DTF and DSF

In this example, information is exchanged between the DTF and DSF. The nature of this signalling is outside the scope of this version of the specification.

9. SIP INVITE request (DTF to intermediate IM CN subsystem entities) – see example in table A.5.3-9

Since the service execution continues as an terminating case, the DTF initiates a SIP INVITE request with the CSRN as the Request-URI and in the To header, and sends the SIP INVITE request back to the intermediate IM CN subsystem entities.

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID headers from one side of the B2BUA to the other.

The DTF inserts the original SDP from the originating SIP INVITE request.

Table A.5.3-9: SIP INVITE request (DTF to intermediate IM CN subsystem entities)

INVITE tel:+1-241-555-4444 SIP/2.0

Via: SIP/2.0/UDP sip:dtf2.home2.net; branch=z9jG4bK332b23.3, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK431h23.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 65

Route: <sip:scscf2.home2.net;lr>; dia-id=6574839201

Record-Route: <sip:dtf2.home2.net;lr>, <sip:scscf2.home2.net;lr>, <sip:scscf1.home1.net;lr>, <sip:pcscf1.home1.net;lr>

P-Asserted-Identity: "John Doe" <tel:+1-212-555-1111>

P-Access-Network-Info:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi="type 3ashome1.net"

Privacy: none

Supported:

From:

To: <tel:+1-241-555-4444>

Call-ID:

Cseq:

Contact:

Allow:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

10. SIP INVITE request (intermediate IM CN subsystem entities to MGCF) – see example in table A.5.3-10

The intermediate IM CN subsystem entities deliver the SIP INVITE request to the MGCF. In this example, the MGCF is reached using a single BGCF.

Table A.5.3-10: SIP INVITE request (intermediate IM CN subsystem entities to MGCF)

INVITE tel:+1-241-555-4444 SIP/2.0

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP sip:dtf2.home2.net; branch=z9jG4bK332b23.3, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK431h23.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 63

Route: <sip:mgcf2.home2.net;lr>;

Record-Route: <sip:scscf2.home2.net;lr>, <sip:dtf2.home2.net;lr>, <sip:scscf2.home2.net;lr>, <sip:scscf1.home1.net;lr>, <sip:pcscf1.home1.net;lr>

P-Asserted-Identity: "John Doe" <tel:+1-212-555-1111>

P-Access-Network-Info:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi="type 3ashome1.net"; term-ioi="home2.net"

Privacy:

Supported:

From:

To: <tel:+1-241-555-4444>

Call-ID:

Cseq:

Contact:

Allow:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

11a-11d. SIP 183 (Session Progress) response / SIP PRACK request / SIP 200 (OK) response and Reliable exchange of SDP

Reliable exchange of SDP is initiated using the SIP 183 (Session Progress) response and the SIP PRACK request and response.

12. H.248 interaction with the IM-MGW

When the outgoing MGCF receives a SIP INVITE request with an SDP offer it will first interact with the IM-MGW to pick an outgoing channel and determine media capabilities, then can proceed with further SDP offer/answer with the originating UE and finally will instruct IM-MGW to reserve the resources necessary for the media streams.

13. ISUP IAM (MGCF to VMSC)

The MGCF interworks the SIP INVITE request into ISUP and initiates the ISUP IAM carrying the CSRN towards the VMSC on which the terminating VCC UE is currently registered (for the interworking ISUP / SIP function see 3GPP TS 29.163 [10]).

14. SETUP message (VMSC to terminating VCC UE)

The VMSC can derive from the CSRN the details of the called party and then initiates a paging procedure towards the terminating VCC UE.

After the VCC UE has successfully accessed the network, the VMSC sends to the UE the SETUP message (see 3GPP TS 24.008 [5]). There is no VCC specific information in the SETUP message.

15. ALERTING (terminating UE to VMSC)

For this example, the VMSC allows early local alerting. With the generation of local alerting, ALERTING is sent back from the UE to the VMSC. There is no VCC specific information in the ALERTING message.

16. ISUP ACM (VMSC to MGCF)

17a-17d. ISUP CPG, SIP 180 (Ringing) response and SIP PRACK request (end to end)

On receipt of the ALERTING message from the terminating VCC UE, the VMSC and the MGCF exchange ISUP to indicate that the called party confirmed the call and did start ringing the end user.

The VMSC starts resource allocation towards the terminating VCC UE.

Between VMSC and the IM-MGW resource allocation is also started.

18. CONNECT message (terminating VCC UE to VMSC)

When the user answers the call, the terminating VCC UE sends a CONNECT message to the VMSC. After sending the CONNECT message, the terminating VCC UE is ready to connect to user plane resources.

There is no VCC specific information in the CONNECT message.

19. CONNECT_ACK message (VMSC to terminating VCC UE)

The VMSC connects up the user plane and return CONNECT_ACK message to the terminating UE. Through connect all the way back to originating UE is not initiated.

There is no VCC specific information in the CONNECT_ACK message.

20. ISUP ANM (VMSC to MGCF)

The VMSC having through connected the user plane sends an indication of answer to the MGCF. This is the ISUP ANM.

21. H.248 interaction to start the media flow (MGCF to IM-MGW)

MGCF initiates a H.248 interaction to make the connection in the IM-MGW bi-directional.

22. SIP 200 (OK) final response (MGCF to intermediate IM CN subsystem entities)

Upon the receipt of the ISUP ANM from the MSC, and after the connection of the media flow, the MGCF sends the SIP 200 (OK) final response to the received SIP INVITE request (6) toward the IM CN subsystem. The SIP 200 (OK) response is sent by the MGCF on the behalf the terminating VCC UE over the signalling path to the terminating user’s S-CSCF.

There is no VCC specific content to this response.

23. SIP 200 (OK) final response (from intermediate IM CN subsystem entities to DTF)

The intermediate IM CN subsystem entities forward the SIP 200 (OK) final response to the DTF.

There is no VCC specific content to this response.

24. SIP 200 (OK) final response (from DTF to intermediate IM CN subsystem entities)

The SIP 200 (OK) final response is sent back to the terminating user’s S-CSCF by the DTF.

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID headers from one side of the B2BUA to the other.

There is no VCC specific content to this response.

25. SIP 200 (OK) final response (intermediate IM CN subsystem entities to originating IM CN subsystem)

The SIP 200 (OK) response is returned to the originating UE through the originating IM CN subsystem, by the terminating user’s intermediate IM CN subsystem entities.

There is no VCC specific content to this response.

26. SIP ACK request (from the originating IM CN subsystem to intermediate IM CN subsystem entities)

The originating UE sends the final acknowledgement to the terminating user’s IM CN subsystem through the originating IM CN subsystem to the intermediate IM CN subsystem entities of the terminating user.

There is no VCC specific content to this request.

27. SIP ACK request (intermediate IM CN subsystem entities to DTF)

The terminating user intermediate IM CN subsystem entities forward the SIP ACK request to the DTF.

There is no VCC specific content to this request.

28. SIP ACK request (DTF to intermediate IM CN subsystem entities)

The DTF sends the SIP ACK request back to terminating user’s intermediate IM CN subsystem entities.

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID headers from one side of the B2BUA to the other.

There is no VCC specific content to this request.

29. SIP ACK request (intermediate IM CN subsystem entities to MGCF)

The terminating user’s intermediate IM CN subsystem entities forward the SIP ACK request to the MGCF and that concludes the terminating call signalling.

There is no VCC specific content to this request.