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

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

A.7.1 Introduction

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

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

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

– subclause A.7.4 shows a domain transfer request from the IM CN subsystem to the CS domain using CAMEL, and which is rejected by the VCC application at the VMSC.

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

Figure A.7.2-1 shows an example signalling flows for the domain transfer from the IM CN subsystem to the CS domain. The figure assumes that the UE is already registered with the CS domain prior to the decision to initiate transfer and that a call is anchored in the IM CN subsystem and the remote UE can be an IM UE.

In this example, the communication between the CS domain and the DTF to resolve and process the request for domain transfer is supported through CAMEL.

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

The details of the signalling flows are as follows:

There is an ongoing IP bearer between the VCC UE and the remote end.

1. Determination of Domain Transfer to CS domain

VCC UE can make a decision for domain transfer. It can be triggered in case that the access technology of VCC UE is changed or the user preference or the operator policy is changed in consequence of the access technology change and so on.

2. CC SETUP messages (VCC UE to MSC)

The VCC UE sends the CS SETUP message towards MSC with the VDN as the called party number.

NOTE 1: VDN (VCC Domain Transfer Number) is not a routeable number towards the VCC application. It is an MSISDN used by the UE to request a domain transfer towards the VCC application.

3. CAMEL INITIAL DP (VMSC to gsmSCF)

On receipt of the SETUP message, the VMSC, in this example signalling flow, triggers a CAMEL activity which results in sending a CAMEL IDP message to the gsmSCF. The CAMEL IDP message contains at least:

– the IMSI ie. 004412345678

– the calling party number ie. 12125551111;

– the called party number that of the VDN, ie. 12415555555

4. Handling of request for domain transfer

The gsmSCF channels the request for domain transfer to the CAMEL service function which determines that the call needs to be rerouted to the IM CN subsystem. The CAMEL service function can optionally assist the CSAF with the allocation of an IMRN.

NOTE 2: The gsmSCF and the CAMEL service function are connected through an unspecified interface left to vendor implementation.

5. Interaction between the CAMEL service function and the CSAF

The CAMEL service function can optionally assist the CSAF with the allocation of an IMRN. In this example, the CSAF accepts the request for domain transfer and assigns an IMRN, (IMRN = 12415553333).

NOTE 3: The signalling to support communication between the the CAMEL service function and CSAF is not specified in this version of the specification.

6. CAMEL CONNECT (gsmSCF to VMSC)

The CAMEL service function causes the gsmSCF to respond to the CAMEL IDP message with a CAMEL CONNECT message containing:

– the IMRN = 12415553333

7. CC CALL PROCEEDING message (VMSC to VCC UE)

As VMSC can now proceed with the call, VMSC indicates the CALL PROCEEDING message back to the UE.

8. ISUP IAM (VMSC to MGCF)

The VMSC initiates the CS call towards the MGCF by sending the IAM with the called party number (i.e. IMRN) to indicate the VCC application.

NOTE 4: The IMRN is a routeable MSISDN number towards the VCC application.

9. MGCF allocates and configures MGW

MGCF retrieves SDP from the ISUP IAM according to the 3GPP TS 29.163 [10]. The MGCF communicates with the IM-MGW to configure the media bearer.

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

The MGCF initiates a SIP INVITE request towards the I-CSCF in the home IM CN subsystem of the originating VCC user with the PSI of the VCC application as the called party number. The tel-URI format of the IMRN as a PSI (i.e. VCC application PSI) can be used for routeing towards the VCC application in the IM CN subsystem. I-CSCF routes the SIP INVITE request based on one of the standard procedures specified in "PSI based Application Server termination – direct/indirect/DNS routeing/service logic" procedures in 3GPP TS 23.228 [4].

The MGCF initiates a SIP INVITE request, containing an initial SDP. 3GPP TS 29.163 [10] specifies the principles of interworking between the 3GPP IM CN subsystem and ISUP based CS network, in order to support IM voice calls.

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

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

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

Max-Forwards: 70

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

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

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

Privacy: none

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition

Contact: <sip:mgcf1.home1.net>

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:xxx;yyy

s=-

c=IN IP6 5555::aaa:bbb:xxx;yyy

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

Request-URI: Contains the VCC application PSI, as a PSI based on the IMRN obtained from CS network signalling. The VCC application PSI is equivalent to the tel-URI format of the IMRN.

From: Contains the calling party number to indicate the CS part of the caller. (e.g. Tel: +1-1-212-555-1111).

To: Contains the VCC application PSI as the destination address. The actual destination address used for domain transfer from IM CN subsystem to CS domain is kept in the VCC application by the CS originating procedures described in subclause 7 and subclause A.4.

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

The IM CN subsystem entities route the SIP INVITE request towards the CSAF based on the CSAF PSI.

Table A.7.2-11: 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 scscf1.home1.net;branch=z9hG4bK764z87,

SIP/2.0/UDP icscf1.home1.net;branch=z9hG4bK332b23.1,

SIP/2.0/UDP mgcf1.home1.net;branch=z9hG4bk731b87

Max-Forwards: 68

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

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

P-Charging-Vector: icid-value=”AyretyU0dm+601IrT5tAFrbHLso=023551024”; orig-ioi=home1.net

Privacy: none

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition

Contact: <sip:mgcf1.home1.net>

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:xxx;yyy

s=-

c=IN IP6 5555::aaa:bbb:xxx;yyy

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

12. VCC application initiates domain transfer

The CSAF and DTF in combination act as a routeing B2BUA, associating the incoming SIP INVITE with the ongoing session in the IM CN subsystem..

NOTE 5: During the initial IM CN subsystem origination procedure, the CSAF will keep the called party number and the calling party number for anchoring, domain transfer and so on.

13. Interaction between CSAF and DTF

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

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

The DTF forwards the SIP reINVITE request back to the S-CSCF.

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.7.2-14: SIP reINVITE request (VCC application to intermediate IM CN subsystem entities)

INVITE sip:[5555::eee:fff:aaa:bbb]:8805;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP dtf1.home1.net;branch=z9hG4bK764z87,

Max-Forwards: 67

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

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

P-Charging-Vector: icid-value=”AyretyU0dm+601IrT5tAFrbHLso=023551024”; orig-ioi=home1.net

Privacy: none

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

To: <sip:user2_public2@home2.net>;tag=314159

Call-ID: cb03a0s09a2sdfglkj590123

Cseq: 127 INVITE

Supported: 100rel, precondition

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

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:xxx;yyy

s=-

c=IN IP6 5555::aaa:bbb:xxx;yyy

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

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

Request-URI: Contains the SIP-URI represented as an IP address indicating the called party UE, as retrieved from the VCC application.

From: Contains the tel-URI indicating the remote VCC UE-A. A tag has same value in the existing dialog.

To: Contains the SIP-URI of the called party UE.

NOTE 6: If the called party UE is also the VCC UE, To header will be a tel-URI.

Contact: Contains the SIP-URI indicating the VCC application.

15. SIP reINVITE request (intermediate IM CN subsystem entities to remote UE) – see example in table A.7.2-15

The S-CSCF routes the SIP reINVITE request towards the remote end.

Table A.7.2-12: SIP reINVITE request (VCC application to the remote UE through the intermediate IM CN subsystem entities)

INVITE sip:[5555::eee:fff:aaa:bbb]:8805;comp=sigcomp SIP/2.0

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

Max-Forwards: 65

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

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

P-Charging-Vector: icid-value=”AyretyU0dm+601IrT5tAFrbHLso=023551024”; orig-ioi=home1.net

Privacy: none

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

To: <sip:user2_public2@home2.net>;tag=314159

Call-ID: cb03a0s09a2sdfglkj590123

Cseq: 127 INVITE

Supported: 100rel, precondition

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

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:xxx;yyy

s=-

c=IN IP6 5555::aaa:bbb:xxx;yyy

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

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

16. SIP 200 (OK) response (Remote UE to the intermediate IM CN subsystem entities)

The remote UE indicates the successful completion of the SIP reINVITE request.

There is no VCC specific content to this response.

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

Indicate the successful completion of the SIP reINVITE request.

There is no VCC specific content to this response.

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

The DTF responds to the SIP 200 (OK) response with a SIP ACK request.

There is no VCC specific content to this request.

19. SIP ACK request (intermediate IM CN subsystem entities to remote UE)

The intermediate IM CN subsystem entities forward the SIP ACK request to the remote UE.

There is no VCC specific content to this request.

20. Interaction between DTF and CSAF

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

21. SIP 200 (OK) response (CSAF to the intermediate IM CN subsystem entities)

The CSAF indicates the successful completion of the SIP INVITE request generated by the MGCF.

The VCC application 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.

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

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

There is no VCC specific content to this response.

23. ISUP ANM (MGCF to VMSC)

24. CC CONNECT message (VMSC to the CS part of UE-A)

25. CC CONNECT ACK message (CS part of UE-A to the VMSC)

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

The MGCF generates a SIP ACK request in response to the SIP 200 (OK) response.

There is no VCC specific content to this request.

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

The intermediate IM CN subsystem entities forward the SIP ACK request to the CSAF.

There is no VCC specific content to this request.

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

On receiving the SIP 200 (OK) response (step 17), the DTF sends a BYE request to the IP multimedia side of the VCC UE via the intermediate IM CN subsystem entities.

There is no VCC specific content to this request.

29. SIP BYE request (intermediate IM CN subsystem entities to VCC UE)

The intermediate IM CN subsystem entities forward the SIP BYE request to the VCC UE.

There is no VCC specific content to this request.

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

The IP multimedia part of the VCC UE responds to the SIP BYE request to indicate the successful completion of the domain transfer.

There is no VCC specific content to this response.

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

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

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

Figure A.7.3-1: unsuccessful call transfer when transferring call from IM CN subsystem to CS domain

The details of the signalling flows are as follows:

Step 1 through 11 are according to subclause A.7.2.

12. CSAF and DTF interaction

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

13. VCC application

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

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

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

Table A.7.3-14: 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 icscf1.home1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP mgcf1.home1.net;branch=z9hG4bk731b87

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

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

Privacy: none

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

To: <sip:mgcf1.home1.net>; tag=171828

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

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

Content-Length: 0

15. SIP 480 (Temporarily Unavailable) response (intermediate IM CN subsystem entities to MGCF) – see example in table A.7.3-15

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

Table A.7.3-15: SIP 480 (Temporarily Unavailable) response (intermediate IM CN subsystem entities to MGCF)

SIP/2.0 480 Temporarily Unavailable

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

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

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

Privacy: none

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

To: <sip:mgcf1.home1.net>; tag=171828

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

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

Content-Length: 0

16. ISUP REL (MGCF to VMSC)

Upon unsuccessful call setup, MGCF sends REL to VMSC.

17. ISUP RLC (VMSC to MGCF)

VMSC sends RLC to MGCF to confirm the REL.

18. CC DISCONNECT message (VMSC to VCC UE)

VMSC sends the DISCONNECT message to VCC UE.

19. CC RELEASE message (VCC UE to VMSC)

VCC UE acknowledges the DISCONNECT message by sending RELEASE message to VMSC.

20. CC RELEASE COMPLETE message (VMSC to VCC UE)

VMSC sends a RELEASE COMPLETE message to VCC UE to confirm the RELEASE message.

21. VCC UE continues the call in IM CN subsystem

VCC UE continues the call in IM CN subsystem.

A.7.4 Signalling flows with domain transfer rejection at VMSC (using CAMEL)

Figure A.7.4-1 shows the domain transfer attempt from the IM CN subsystem to the CS domain using CAMEL, and which is rejected by the VCC application at the VMSC. The domain transfer request is then abandoned, and the IMS call for which the domain transfer has been requested continues in the IM CN subsystem.

The decision to execute the request from the VCC UE for a domain transfer is subject to operator policy.

NOTE: For domain transfer, the use of CAMEL in the context of VCC is optional. In this example the VMSC supports and uses CAMEL service logic.

Figure A.7.4-1: Domain transfer rejection at VMSC (using CAMEL)

The details of the signalling flows are as follows:

Steps 1, 2 and 3 are identical to the steps 1, 2 and 3 from the example in subclause A.7.2.

4. Domain transfer decision

The gsmSCF channels the request for domain transfer to the CAMEL service function which determines if the call needs to be routed to the IM CN subsystem.

5. Interaction between CAMEL service function and CSAF

The CAMEL service function can optionally assist the CSAF with the allocation of an IMRN. The CSAF rejects the domain transfer request from the VCC UE to the CS domain according to the operator policy.

In this example the VDN is not a routeable number towards the IM CN subsystem and the VCC application failed to assign a new IMRN for this call i.e. insufficient IMRN.

6. CAMEL RELEASE CALL (gsmSCF to VMSC)

The CAMEL service function causes the gsmSCF to respond to the CAMEL IDP message with a CAMEL RELEASE CALL message. The CAMEL RELEASE CALL message contains a release cause number #63 “Service or option not available, unspecified”.

7, 8 and 9. DISCONNECT, RELEASE and RELEASE COMPLETE (from and to the VCC UE)

The VMSC release the call toward the VCC UE; steps 6 to 8 are identical to step 16 to 18 from subclause A.7.3. The cause used in the DISCONNECT is mapped from the CAMEL release cause received by the VMSC.

There is no specific cause for VCC in the DISCONNECT.

The call in the IM CN subsystem for which the domain transfer has been requested continues unchanged in the IM CN subsystem.

Annex B (informative):
Example of filter criteria