A.6 Signalling flows for CS domain to IM CN subsystem transfer

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

A.6.1 Introduction

The signalling flows for CS domain to IM CN subsystem transfer demonstrate how a VCC UE transfers the call from the CS domain to the IM CN subsystem. The following signalling flows are included:

– subclause A.6.2 shows the successful transfer for a call, currently in the CS domain, and which is transferred to the IM CN subsystem; and

– subclause A.6.3 shows the case where a transfer request for a call, currently in the CS domain, cannot be complied with at the VCC application due to the failure to match the request with an anchored call for that user.

A.6.2 Signalling flows for CS domain to IM CN subsystem transfer

Figure A.6.2-1 shows the signalling flows for a domain transfer of the access leg from the CS domain to the IM CN subsystem. This example assumes that the VCC user is currently registered in the IM CN subsystem. If the VCC user is not currently registered in the IM CN subsystem prior to determination of domain transfer, it is required that registration procedures are initiated before updating the access leg.

Figure A.6.2-1: CS domain to IM CN subsystem transfer

The details of the signalling flows are as follows:

1. CS bearer (VCC UE to MGW)

The call is ongoing in the CS domain.

2. IP bearer (MGW to remote end)

IP bearer over which the voice call is transmitted toward to the remote end.

3. Determination of domain transfer

As a result of changes in radio conditions or availability of IM services via IPCAN, the VCC UE decides that the ongoing call in the CS domain will be transferred to the IM CN subsystem.

4. SIP INVITE request (VCC UE to intermediate IM CN subsystem entities) – see example in table A.6.2-4

The VCC UE sends a SIP INVITE request to initiate session set up in the IM CN subsystem. The SIP INVITE request is sent from the VCC UE to the home S-CSCF (S-CSCF#1) via P-CSCF#1. The Request-URI header is set to the VDI (which is a PSI pointing at the DTF).

Table A.6.2-4: SIP INVITE request (VCC UE to intermediate IM CN subsystem entities)

INVITE sip:domain.xfer@dtf1.home1.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: <sip:pcscf1.home1.net:7531;lr;comp=sigcomp>, <sip:scscf1.home1.net;lr>

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

P-Access-Network-Info: IEEE-802.11b;

Privacy: none

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

To: <sip:domain.xfer@dtf1.home1.net>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Require: sec-agree

Proxy-Require: sec-agree

Supported: precondition, 100rel

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531

Contact: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp>

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

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 none

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

5. SIP 100 (Trying) response (intermediate IM CN subsystem entities to VCC UE)

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

There is no VCC specific content to this response.

6. Evaluation of filter criteria

In this example, and by evaluation of the initial filter criteria, based on the VDI in the Request-URI header of the originating request for a registered VCC user, the S-CSCF routes the request to the DTF in the VCC application.

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

The SIP INVITE request is forwarded from S-CSCF#1 in the home network to the VCC application which is at an AS. The AS acts as a routeing B2BUA.

Table A.6.2-7: SIP INVITE request (intermediate IM CN subsystem entities to VCC application)

INVITE sip:domain.xfer@dtf1.home1.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1

Via: SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK240f34.1

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 68

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

Route: <sip:domain.xfer@dtf1.home1.net>

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

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

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

P-Access-Network-Info: IEEE-802.11b;

Privacy: none

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

To: <sip:domain.xfer@dtf1.home1.net>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: precondition, 100rel

Contact: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp>

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

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 none

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

8. SIP reINVITE request (DTF to intermediate IM CN subsystem entities) – see example in table A.6.2-8

The remote end is informed of the change in access leg from CS domain to IM CN subsystem by sending a SIP reINVITE request from the DTF 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.6.2-8: SIP reINVITE request (DTF to remote end via intermediate IM CN subsystem entities)

INVITE <sip:[5555::eee:fff:aaa:bbb]:8805 SIP/2.0

Via: SIP/2.0/UDP domain.xfer@dtf1.home1.net;branch=z9hG4bK332b23.1

Max-Forwards: 67

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

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

P-Access-Network-Info: IEEE-802.11b;

Privacy: none

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

To: <sip:user2_public1@home2.net>; tag=1234

Call-ID: dc14b1t10b3teghmlk501444

Cseq: 127 INVITE

Supported: precondition, 100rel

Contact: <sip:[7777::eee:ddd:ccc:aaa]>

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 none

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

9. SIP reINVITE request (intermediate IM CN subsystem entities to remote end) – see example in table A.6.2-9

The intermediate IM CN subsystem entities forwards the SIP reINVITE request to the remote end.

Table A.6.2-9: SIP reINVITE request (intermediate IM CN subsystem entities to remote end)

INVITE <sip:[5555::eee:fff:aaa:bbb]:8805 SIP/2.0

Via: SIP/2.0/UDP icscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP domain.xfer@dtf1.home1.net;branch=z9hG4bK332b23.1

Max-Forwards: 66

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

Privacy: none

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

To: <sip:user2_public1@home2.net>; tag=1234

Call-ID: dc14b1t10b3teghmlk501444

Cseq: 127 INVITE

Supported: precondition, 100rel

Contact: <sip:[7777::eee:ddd:ccc:aaa]>

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 none

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

10. SIP 183 (Session Progress) response (remote end to intermediate IM CN subsystem entities)

The SIP endpoints complete SDP offer/answer procedures, including any reservation of bearer resource on the IP-CAN, and any exchange of alerting indication, in accordance with standard basic call procedures. VCC imposes no restriction on this operation.

11. SIP 183 (Session Progress) response (intermediate IM CN subsystem entities to DTF

The SIP endpoints complete SDP offer/answer procedures, including any reservation of bearer resource on the IP-CAN, and any exchange of alerting indication, in accordance with standard basic call procedures. VCC imposes no restriction on this operation.

12. SIP 183 (Session Progress) response (VCC application to 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 183 (Session Progress) response is forwarded to the VCC UE indicating the supported media at the VCC application so that the VCC UE can start to reserve resources for IP bearer setup.

13. SIP 183 (Session Progress) response (intermediate IM CN subsystem entities to VCC UE)

The intermediate IM CN subsystem entities forward the 183 (Session Progress) response to the VCC UE.

14a – 14h. SIP PRACK request and SIP 200 (OK) response

The SDP offer/answer exchange is completed.

The SIP PRACK request does not carry SDP as the final codec decision is already made as part of the initial offer/answer exchange.

The remote end acknowledges receipt of the SIP PRACK request by sending a SIP 200 (OK) response.

15. SIP 200 (OK) response (remote end to intermediate IM CN subsystem entities)

The remote end acknowledges receipt of the SIP reINVITE request by sending a SIP 200 (OK) response to the intermediate IM CN subsystem entities.

There is no VCC specific content to this response.

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

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

There is no VCC specific content to this response.

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

The SIP ACK request is sent from the DTF to the intermediate IM CN subsystem entities thus completing session update for the remote leg.

There is no VCC specific content to this response.

18. SIP ACK request (intermediate IM CN subsystem entities to remote end)

The SIP ACK request is forwarded to the remote end via the intermediate IM CN subsystem entities thus completing session update for the remote leg.

There is no VCC specific content to this response.

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

Final acknowledgement of receipt of the SIP INVITE request required to change the access leg. This SIP 200 (OK) response indicates successful receipt and processing of the SIP INVITE request which was sent to initiate domain transfer. This response is sent 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.

There is no VCC specific content to this response.

20. SIP 200 (OK) response (intermediate IM CN subsystem entities to VCC UE)

Final acknowledgement of receipt of the SIP INVITE request required to change the access leg. This SIP 200 (OK) response indicates successful receipt and processing of the SIP INVITE request which was sent to initiate domain transfer. The intermediate IM CN subsystem entities forwarded this response to the VCC UE.

There is no VCC specific content to this response.

21. SIP ACK request (VCC UE to intermediate IM CN subsystem entities)

The SIP ACK request is sent from the VCC UE to the intermediate IM CN subsystem entities thus completing session setup for the updated access leg.

There is no VCC specific content to this request.

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

The SIP ACK request is forwarded by the intermediate IM CN subsystem entities to the DTF thus completing session setup for the updated access leg.

There is no VCC specific content to this request.

23. IP bearer

IP bearer is established between VCC UE and remote end allowing voice call to continue via PS domain.

24. SIP BYE request (DTF to intermediate IM CN subsystem entities)

In order to release the access leg on the transferring-out access leg, the SIP BYE request is sent from the DTF, via 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.

25. SIP BYE request (intermediate IM CN subsystem entities to MGCF)

The SIP BYE request is forwarded to the MGCF by the intermediate IM CN subsystem entities in order to initiate call release in the CS domain.

There is no VCC specific content to this request.

26. ISUP REL message (MGCF to VMSC)

MGCF converts SIP BYE request to an ISUP REL message sent to the MSC#1 in the home CS network. REL Cause Value No. 16 (Normal clearing) is used.

27. ISUP RLC message (VMSC to MGCF)

The ISUP RLC message is sent by MSC#1 to the MGCF in response to the ISUP REL message.

28. DISCONNECT message (VMSC to VCC UE)

The DISCONNECT message from MSC#1 to the VCC UE includes Cause Value No. 16, thus initiating call clearing.

29. RELEASE message (VCC UE to VMSC)

The VCC UE responds to the DISCONNECT message by sending the RELEASE message to MSC#1 and enters the “release request” status.

30. RELEASE COMPLETE message (VMSC to VCC UE)

MSC#1 sends the RELEASE COMPLETE message to the VCC UE thus releasing the MM connection.

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

This SIP 200 (OK) response is for the SIP BYE request and is sent to the intermediate IM CN subsystem entities from the MGCF.

There is no VCC specific content to this response.

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

This SIP 200 (OK) response is for the SIP BYE request and is forwarded to the DTF by the intermediate IM CN subsystem entities.

There is no VCC specific content to this response.

A.6.3 Signalling flows for unsuccessful CS domain to IM CN subsystem transfer

Figure A.6.3-1 shows the signalling flows for the unsuccessful call transfer when transferring the call from the CS domain to the IM CN subsystem. The assumption is that VCC UE is not roaming and the MGCF is in the subscriber’s IM CN subsystem. It is also assumed that VCC UE is already registered to IM CN subsystem network.

Figure A.6.3-1: Unsuccessful scenario when transferring call from CS to IM CN subsystem

The details of the signalling flows are as follows:

Step 1 through 7 are according to subclause A.6.2.

8. DTF

When DTF receives VDN indicating the domain transfer, it does not recognize the call leg associated with Calling Party Number CgPN or P-Asserted-Identity.

9. SIP 480 (Temporarily Unavailable) response (DTF to intermediate IM CN subsystem entities) – see example in table A.6.3-9

The DTF sends a SIP 480 (Temporarily Unavailable) response to the intermediate IM CN subsystem entities.

Table A.6.3-9: SIP 480 (Temporarily Unavailable) response (DTF to intermediate IM CN subsystem entities)

SIP/2.0 480 Temporarily Unavailable

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK354216.1, SIP/2.0/UDP pcscf1.visited1.net:7531;comp=sigcomp;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>

P-Asserted-Identity: <sip:domain.xfer@dtf1.home1.net>

Privacy: none

From: <sip:domain.xfer@dtf1.home1.net>;tag=1234

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Contact: <sip:[5555::eee:fff:ggg:hhh]>

Content-Length: 0

10. SIP 480 (Temporarily Unavailable) response (intermediate IM CN subsystem entities to VCC UE) – see example in table A.6.3-10

The error message is forwarded from intermediate IM CN subsystem entities to VCC UE according to standard procedures.

Table A.6.3-10: SIP 480 (Temporarily Unavailable) response (intermediate IM CN subsystem entities to VCC UE)

SIP/2.0 480 Temporarily Unavailable

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];branch=z9hG4bKnashds7

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>

P-Asserted-Identity: <sip:domain.xfer@stf1.home1.net >

Privacy: none

From: <sip:domain.xfer@dtf1.home1.net>;tag=1234

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Contact: <sip:[5555::eee:fff:ggg:hhh]>

Content-Length: 0

11. VCC UE continues the call in CS domain.