A.5.5 Signalling flow for termination directed to CS domain
(coming from the CS domain)

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

Figure A.5.5-1 illustrate an example signalling flow of a voice call to a VCC UE coming in through the CS domain, getting anchored to the VCC application within the IM subsystem and then delivered to the terminating VCC UE through the CS domain.

In this example, the terminating UE is in his/her HPLMN.

In this example, this PLMN does not utilise terminating CAMEL service logic. Rather this example illustrates HSS(HLR) directed call diversion to the IM CN subsystem where the HSS(HLR), through internal network implementation, can obtain the IMRN.

Figure A.5.5-1: Terminating call coming in through CS domain and delivered through the CS domain

Figure A.5.5-1: Terminating call coming in through CS domain and delivered through the CS domain (continued)

The details of the signalling flows are as follows:

1. ISUP IAM (coming into this PLMN through the CS domain)

A call request makes an entry into this PLMN. First entry point is the GMSC.
This Initial Address Message contains the MSISDN of the called party
In this example the MSISDN is +1-212-123.2222.

2. MAP SEND_ROUTING_INFORMATION (GMSC to HSS/HLR)

GMSC makes a query to the HSS/HLR for routeing information for onward routeing of the incoming call request.
This GMSC query SEND_ROUTING_INFORMATION contain the MSISDN of the called party.

3. Derivation of IMRN

Internal network actions – not indicated here as those actions are implementation and network dependent – are taken. The result is that (for this example) a decision is make to route the call further onwards into the IM CN subsystem.

In particular an IMRN is obtained in these internal network actions.

For this example the derived IMRN is +1-212-123-3333.

NOTE 1: It is an implementation and network option whether the derivation of the IMRN takes in the decision to anchor the call to the DTF.

4. MAP SEND_ROUTING_INFORMATION_RESULT (HSS/HLR to GMSC)

The HSS/HLR replies to the query by GMSC with the SEND_ROUTING_INFORMATION_RESULT providing with it the IMRN

5. ISUP IAM (GMSC to MGCFa)

GMSC sends out IAM (IMRN). The IMRN is that which will direct the routeing of the IAM to the MGCF.
In this example, the IAM (IMRN = +1-241-555-3333) is routed to MGCFa.

6. SIP INVITE request (MGCFa towards the CSAF through the intermediate IM CN subsystem entities) – see example in table A.5.5-6

The MGCF interworks the IAM (IMRN) into the appropriate SIP message and initiates the SIP INVITE request towards the CSAF via the intermediate IM CN subsystem entities.

Table A.5.5-6: SIP INVITE request (MGCFa towards the CSAF through the intermediate IM CN subsystem entities)

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

Via: SIP/2.0/UDP mgcf1.home1.net;branch=z9hG4bK779s24.0

Max-Forwards: 70

Route: <sip:icscf1_s.home1.net;lr>

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

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

Privacy: none

From: <tel:+1-212-555-1111>;tag=171828

To: <tel:+1-212-555-3333>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel

Contact: <sip:mgcf1.home1.net>

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd

s=-

c=IN IP6 5555::aaa:bbb:ccc:ddd

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=rtpmap:96 telephone-event

a=maxptime:20

7. H.248 interaction with the MGW

The MGCF interacts with the MGW for the necessary resource allocation.

8. SIP 100 (Trying) response (intermediate IM CN subsystem entities to MGCFa)

The intermediate IM CN subsystem entities respond to the MGCFa with a SIP 100 (Trying) response.

There is no VCC specific content to this response.

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

The IMRN is a PSI. The intermediate IM CN subsystem entities are configured to route this PSI to the CSAF. In this particular case, the I-CSCF performs the routeing over the Ma interface. For this example, there is no IBCF before the I-CSCF and no intermediate entities Record-Route the request.

Table A.5.5-9: SIP INVITE request (intermediate IM CN subsystem entities to the CSAF)

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

Via: SIP/2.0/UDP mgcf1.home1.net;branch=z9hG4bK779s24.0, SIP/2.0/UDP icscf1_s.home1.net;branch=z9hG4bK312a32.1

Max-Forwards: 69

Route: <sip:as.home1.net;lr>

P-Asserted-Identity:

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

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

10. SIP 100 (Trying) response (CSAF to intermediate IM CN subsystem entities)

The CSAF responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.

There is no VCC specific content to this response.

11. Retrieval of the called party details from IMRN

From the IMRN the CSAF retrieves the called party details. This retrieval process is implementation dependent.

NOTE 2: It is a further implementation dependent option whether the decision to anchor the call such that VCC feature can be made available to the called party is made at this step.

12. Interaction between CSAF and DTF

Information is exchanged between the CSAF and DTF. The nature of this signalling is outside the scope of this version of the specification.

13. Anchoring

The DTF performs the anchoring of the session.

14. 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.

15. Domain selection

A decision has now to be made on which domain the terminating call is to be delivered. This decision is implementation specific.

For this example, the decision is to deliver the terminating call through the CS domain.

16. Derivation of the CSRN

Having made the decision of delivering the call (for this example) in the CS domain, the DSF derives the CSRN. The CSRN will allow the call to be routed further into the CS domain. The derivation of the CSRN is implementation specific.

For this example, the CSRN = +1-241-555-4444

17. Interaction between DTF and DSF

Information is exchanged between the DTF and DSF. The nature of this signalling is outside the scope of this version of the specification.

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

Having derived the CSRN, the DTF now acts a routeing B2BUA and initiates a SIP INVITE request with the CSRN as the Request-URI. The SIP INVITE request is sent 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.

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

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

Via: SIP/2.0/UDP;branch=z9hG4bK312a32.1

Max-Forwards: 68

Route: <sip:s-cscf.home1.net;lr>

P-Asserted-Identity:

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

Privacy:

From:

To: <tel:+1-212-555-2222>

Call-ID: dc14b1t10b3teghmlk501444

Cseq:

Supported:

Contact: <sip:dtf2.home2.net>

Allow:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

19. SIP 100 (Trying) response (intermediate IM CN subsystem entities to DTF)

The intermediate IM CN subsystem entities respond to the DTF with a SIP 100 (Trying) response.

There is no VCC specific content to this response.

20. SIP INVITE request (intermediate IM CN subsystem entities to MGCFb)

The intermediate IM CN subsystem delivers the SIP INVITE request to the MGCF. In this example this is a different MCGF than the MGCF which receives the ISUP IAM carrying the IMRN. In this example the SIP INVITE request with the CSRN is directed to MGCFb.

This example signalling flow involving different MGCF further illustrates a pragmatic example of call distribution to different MGCFs of one network.

21. SIP 100 (Trying) response (MGCFb to intermediate IM CN subsystem entities)

The MGCF responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.

There is no VCC specific content to this response.

22. ISUP IAM (MGCFb to VMSC)

The MGCF interworks the SIP INVITE request to the ISUP and initiates the ISUP IAM carrying the CSRN towards the VMSC.

23. H.248 interaction with the MGW

The MGCF interacts with the MGW for the necessary resource allocation.

24. Retrieval of the called party details from CSRN

The VMSC can from the CSRN retrieve the details of the called party and with that initiates a paging procedure towards the terminating UE.

25. SETUP message (VMSC to terminating VCC UE)

After the UE has successfully accessed the network, the VMSC sends to the VCC UE the 24.008 SETUP message.

There is no VCC specific content in this message.

For this example, the VMSC allows early local alerting.

26. CALL_CONFIRM message (Terminating VCC UE to VMSC)

The terminating UE acknowledges and confirms acceptance of the incoming call by sending a CONFIRM back to the VMSC. There is no VCC specific content in this message.

27. ALERTING message (terminating VCC UE to VMSC)

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

28. ACM, CPG, SIP 180 (Ringing) response and SIP PRACK request (VMSC to MGCFb through IM CN subsystem to the originating end)

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

29. Resource allocation (MSC to terminating VCC UE and VMSC)

The VMSC starts resource allocation towards the terminating VCC UE.

30. Resource allocation (VMSC to MGWb)

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

31. 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 content in this message.

32. CONNECT_ACK message (VMSC to terminating VCC UE)

VMSC connects up the user plane and return a CONNECT_ACKNOWLEDGE message to the terminating VCC UE.

There is no VCC specific content in this message.

Through connect all the way back to originating UE is not initiated.

33. ISUP ANM (VMSC to MGCFb)

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

There is no VCC specific content in this message.

34. SIP 200 (OK) response (MGCFb to intermediate IM CN subsystem entities meant for DTF)

Upon the receipt of the ANM from the VMSC, and after the connection of the media flow, the MGCFb sends the SIP 200 (OK) final response to the received SIP INVITE request ( in step 15) back to the DTF via the intermediate IM CN subsystem entities.

There is no VCC specific content to this response.

35. SIP 200 (OK) response (intermediate IM CN subsystem entities to DTF)

The SIP 200 (OK) final response is forwarded to the VCC application, by the intermediate IM CN subsystem entities.

There is no VCC specific content to this response.

36. SIP 200 (OK) response (DTF to intermediate IM CN subsystem entities meant for MGCFa)

The DTF sends the SIP 200 (OK) final response back to the MGCFa relating to the received SIP INVITE request ( in step 8). This is sent through 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.

There is no VCC specific content to this response.

37. SIP 200 (OK) response (intermediate IM CN subsystem entities delivering to MGCFa)

The SIP 200 (OK) final response is forwarded to the MGCFa by the intermediate IM CN subsystem entities.

There is no VCC specific content to this response.

38. ISUP ANM (MGCFa to GMSC)

The MGCF indicates call has been answered back to the GMSC with ISUP ANM.

There is no VCC specific content in this message.

39. SIP ACK request (MGCFa to intermediate IM CN subsystem entities meant for DTF)

Having indicate the call has been answered to the GMSC, MGCFa acknowledges the SIP 200 (OK) response with the SIP ACK request to the DTF. This is sent through the intermediate IM CN subsystem entities.

There is no VCC specific content to this request.

40. ISUP ANM (GMSC towards originating end)

GMSC sends an indication of call answer towards the originating side.

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

The intermediate IM CN subsystem entities deliver the SIP ACK request to the DTF.

There is no VCC specific content to this request.

42. SIP ACK request (DTF to intermediate IM CN subsystem entities meant for MGCFb)

DTF in turn acknowledges the MGCFb with the SIP ACK request. This is sent through 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.

There is no VCC specific content to this request.

43. SIP ACK request (intermediate IM CN subsystem entities to MGCFb)

The SIP ACK request is delivered to the MGCFb by the intermediate IM CN subsystem entities.

There is no VCC specific content to this request.