A.20 Signalling flows for CS to PS Access Transfer: using CS to PS SRVCC

24.2373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuityRelease 17Stage 3TS

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

A.20.1 Introduction

The signalling flows in the subclause demonstrate the CS to PS access SRVCC transfer. The following signalling flows are included:

– subclause A.20.2 shows an example of CS to PS access transfer for SRVCC when CS to PS SRVCC occurs during an ongoing call for which media are anchored in ATGW.

– subclause A.20.3 shows an example of CS to PS access transfer for SRVCC when CS to PS SRVCC occurs during an ongoing call for which media are not anchored in ATGW.

A.20.2 Signalling flows for CS to PS Access Transfer: CS to PS SRVCC occurs during an active call

The signalling flow shown in figure A.20.2-1 gives an example for CS to PS access transfer when using CS to PS SRVCC. The call is established, contains active speech media component and has been anchored in ATGW during the establishment of the call.

The call may have been established either via the MSC server or as the result of the CS to PS SRVCC procedure.

NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow.

Figure A.20.2-1 Signalling flows for CS to PS Access Transfer: CS to PS SRVCC occurs during a call.

1+2. The UE A has an session with active speech media component with UE B

There is one CS bearer between the UE A and the MSC server, one PS bearer between the MSC server and the ATGW and one PS bearer between the ATGW and the remote end UE B. The CS call has the transaction identifier 88 (decimal) and was originated by UE B and accepted by UE A.

3. The UE A sends the measurement reports to UTRAN/GERAN that decides to trigger a CS to PS SRVCC handover to the E-UTRAN access.

4. CS to PS request

The MSC server receives a CS to PS request indicating that a CS to PS SRVCC access transfer is initiated.

5. SIP INFO request (MSC server to ATCF) – see example in table A.20.1-5

The MSC Server initiates the CS to PS SRVCC by means of a SIP INFO request sent towards the ATCF. The SIP INFO includes a session transfer notification request. The session transfer notification request is an indication to prepare for the transfer of media to PS.

Table A.20.2-5: SIP INFO request (MSC server to ATCF)

INFO sip:user2_public1@home2.net SIP/2.0

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

Max-Forwards: 70

Route: <sip:atcf.visited.net;lr>, <sip:scscf.home1.net;lr>, <sip:icscf.home1.net;lr>, <sip:sccas.home1.net;lr>

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 130 INFO

Info-Package: g.3gpp.access-transfer-events

Content-Disposition: Info-Package

Content-Type: application/vnd.3gpp.access-transfer-events+xml

Content-Length: (…)

<?xml version="1.0"?>

</events>

application/vnd.3gpp.access-transfer-events+xml: Contains the value 1 indicating that the MSC server sends the session transfer notification request to the ATCF.

6 SIP 200 (OK) response (ATCF to MSC server)

The ATCF acknowledge the SIP INFO request.

7. ATCF reserves resources in ATGW

The ATCF reserves resources in ATGW towards UE A and the ATGW provides the SDP answer to the SDP which the UE A provided during the registration (see subclase A.3.4). Apart from the IP address and port, the SDP answer contains the same media pararameters as provided to the UE A after PS registration (see subclause A.3.4).

8. SIP INFO request (ATCF to MSC server) – see example in table A.20.1-8

The ATCF sends a SIP INFO request containing the session transfer notification response contains the parameters required for the transfer, including IP address and media port allocated in the ATGW.

Table A.20.2-8: SIP INFO request (ATCF to MSC server)

INFO sip:user1_public1@visited2.net SIP/2.0

Via:

Max-Forwards:

Record-Route:

From:

To:

Call-ID:

Cseq:

Content-Disposition: Info-Package

Info-Package: g.3gpp.access-transfer-events

Contact:

Content-Type: application/vnd.3gpp.access-transfer-events+xml

Content-Length: (…)

<?xml version="1.0"?>

<STNResp-params>

<transfer-details>AVL0IrgAAAAAAAAAbwDeAU0BvA==</transfer-details>

<redirect-speech>false</redirect-speech>

</STNResp-params>

</event>

</events>

application/vnd.3gpp.access-transfer-events+xml: Contains the IPv6 address and port number of the ATGW. With the following <transfer-details>: ATGW-IPv6-address = 8888::111:222:333:444, ATGW-audio-UDP-port = 21236. Also indicates that the ATCF does not require the MSC server to redirect the speech media component of the session transferred by the CS to PS SRVCC access transfer.

Info-Package: Indicates that the SIP INFO request contains the g.3gpp.access-transfer-events info package.

9. SIP 200 (OK) response (MSC server to ATCF)

The MSC server acknowledge the SIP INFO request.

10. The MSC server starts the preparation for the access transfer.

11. When access transfer is prepared, the MSC server sends CS to PS handover command to the UE using access stratum signalling.

12. SIP INFO request (MSC server to ATCF) – see example in table A.20.1-12

The MSC server sends a SIP INFO request containing a session transfer preparation to the ATCF to instruct the ATCF that media should be switched to the target access.

Table A.20.2-12: SIP INFO request (MSC server to ATCF)

INFO sip:user2_public1@home2.net SIP/2.0

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

Max-Forwards: 70

Route: <sip:atcf.visited.net;lr>, <sip:scscf.home1.net;lr>, <sip:icscf.home1.net;lr>, <sip:sccas.home1.net;lr>

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 130 INFO

Content-Disposition: Info-Package

Info-Package: g.3gpp.access-transfer-events

Content-Type: application/vnd.3gpp.access-transfer-events+xml

Content-Length: (…)

<?xml version="1.0"?>

</events>

application/vnd.3gpp.access-transfer-events+xml: Contains the event 3 indicating that MSC server requests ATCF to perform the CS to PS SRVCC access transfer, i.e. start sending media towards the UE instead of towards the MSC server.

13. SIP 200 (OK) response (ATCF to MSC server)

The ATCF acknowledge the SIP INFO request by means of a SIP 200 (OK) response.

14. ATCF configures resources in ATGW

The ATCF configures resources in the ATGW to start sending and receiving media towards the UE A instead of the MSC server.

15. The media path is now reconfigured. The audio is sent between the UE A and ATGW using IMS signalling bearer.

16-17. SIP INVITE request (UE A to ATCF) – see example in table A.20.1-16

When the UE A receives the CS to PS handover command the UE A sends an SIP INVITE request towards the ATCF.

Table A.20.2-16: SIP INVITE request (UE A to ATCF)

INVITE sip:sti-rsr@atcf1.visited2.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.visited2.net:7531;lr;comp=sigcomp>,<sip:atcf.visited.net;lr, <sip:orig@scscf1.home1.net;lr>

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

P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11

Privacy: none

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Require: sec-agree

Supported: 100rel, gruu

Proxy-Require: sec-agree

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:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;comp=sigcomp>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

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

Content-Type: application/sdp

Content-Length: (…)

Accept: application/sdp,application/3gpp-ims+xml

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=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

Request-URI: contains the STI-rSR associated with the transferred call.

SDP offer: The media parameters of the speech media component are the same as the UE A sent to ATCF during registraton (see subclause A.3.4).

18. SIP 200 (OK) response (ATCF to P-CSCF)- see example in table A.20.1-18

The ATCF sends the SIP 200 (OK) response towards the UE A with the media information allocated by the ATGW.

Table A.20.2-18: SIP 200 (OK) response (ATCF to P-CSCF)

SIP/2.0 200 OK

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

Max-Forwards: 70

Record-Route: <sip:pcscf1.visited2.net:7531;lr;comp=sigcomp>,<sip:atcf.visited.net;lr>

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

Privacy: none

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

To: <tel:+1-212-555-2222>;tag=aaaa

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Contact: <sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;comp=sigcomp>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

Feature-Caps: *;+g.3gpp.ti="70D8"

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=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

Feature-Caps: g.3gpp.ti feature-capability indicator with value containing the transaction identifier specified in figure 11.9 and table 11.3 of 3GPP TS 24.007 [75] encoded by hexadecimal digit. In this example, the transaction identifier 88 (decimal) and the transaction identifier flag as sent by the MSC server in CS signalling of the terminating CS call are shown.

19. Bearer resource reservation

P-CSCF initiates bearer resource reservation based on the SDP answer received in the SIP 200 (OK) response.

20. SIP 200 (OK) response (P-CSCF to UE A)

The P-CSCF forwards the SIP 200 (OK) response to the UE A. The UE A associates the dialog established by the SIP 200 (OK) response with the CS call where the transaction identifier sent by MSC server were equal to the value of the g.3gpp.ti feature-capability indicator in the Feature-Caps header field of the SIP 200 (OK) response.

21-22. SIP ACK request (UE A to ATCF)

The UE A acknowledges the reception of the SIP 200 (OK) response.

23. The media path is now reconfigured. The audio is sent between the UE A and ATGW using a dedicated bearer.

24-25. SIP INVITE request (ATCF to SCC AS) – see example in table A.20.1-25

Table A.20.2-25: SIP INVITE request (ATCF to SCC AS)

INVITE sip:cs2ps@sccas1.home1.net SIP/2.0

Record-Route: <sip:atcf2.visited2.net;lr>

Via: SIP/2.0/UDP atcf.visited2.net:5060;branch=z9hG4bKnas55889, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;;branch=z9hG4bKnashds7

Max-Forwards: 69

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

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

P-Charging-Vector: icid-value="1234bc9876e";icid-generated-at"5555::aaa:bbb:ccc:ddd";orig-ioi=visited2.net

P-Preferred-Service:

P-Access-Network-Info:

Privacy:

From:

To:

Call-ID:

Cseq:

Require:

Supported:

Proxy-Require:

Contact:

Accept-Contact:

Allow:

Content-Type:

Content-Length:

Accept:

v=0

o=- 22 333 IN IP6 8888::111:222:333:444

s=-

c=IN IP6 8888::111:222:333:444

t=0 0

m=audio 8899 RTP/AVP 97 96

b=AS:25.4

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

Request-URI: contains the ATU-STI for CS to PS SRVCC associated with the transferred call.

SDP: The SDP contains the SDP used at ATGW towards the remote UE B.

P-Asserted-Identity: the C-MSISDN of the served UE.

26-27. SIP 200 (OK) response (SCC AS to ATCF)

Since there is no update in the session description, no remote end update will be performed. The SCC AS sends confirmation response to the ATCF which contains the SDP answer that the SCC AS stored during the original session establishment procedure.

28-29. SIP ACK request (ATCF to SCC AS)

30-32. SIP BYE request (SCC AS to MSC server)

The SCC AS initiates the release of the source access leg.

33-35. SIP 200 (OK) response (MSC server to UE A)

36. The MSC server clears the call

The MSC server locally clears the call.

37. The UA A clears the call

The UA locally clears the call.

A.20.3 Signalling flows for CS to PS Access Transfer without CS media anchored in ATGW: CS to PS SRVCC occurs during an active call

The signalling flow shown in figure A.20.3-1 gives an example for CS to PS access transfer when using CS to PS SRVCC. The call is established, contains active speech media component and has not been anchored in ATGW during the establishment of the call.

The call may have been established either via the MSC server or as the result of the CS to PS SRVCC procedure.

NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow.

Figure A.20.3-1 Signalling flows for CS to PS Access Transfer: CS to PS SRVCC occurs during a call.

1+2. The UE A has an session with active speech media component with UE B

There is one CS bearer between the UE A and the MSC server, one PS bearer between the MSC server and the remote end UE B. The CS call has the transaction identifier 88 (decimal) and was originated by UE B and accepted by UE A.

3. The UE A sends the measurement reports to UTRAN/GERAN that decides to trigger a CS to PS SRVCC handover to the E-UTRAN access.

4. CS to PS request

The MSC server receives a CS to PS request indicating that a CS to PS SRVCC access transfer is initiated.

5. SIP INFO request (MSC server to ATCF) – see example in table A.20.3-5

Table A.20.3-5: SIP INFO request (MSC server to ATCF)

INFO sip:user2_public1@home2.net SIP/2.0

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

Max-Forwards: 70

Route: <sip:atcf.visited.net;lr>, <sip:scscf.home1.net;lr>, <sip:icscf.home1.net;lr>, <sip:sccas.home1.net;lr>

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 130 INFO

Content-Disposition: Info-Package

Info-Package: g.3gpp.access-transfer-events

Content-Type: application/vnd.3gpp.access-transfer-events+xml

Content-Length: (…)

<?xml version="1.0"?>

</events>

application/vnd.3gpp.access-transfer-events+xml: Contains the value 1 indicating that the MSC server sends the session transfer notification request to the ATCF.

6 SIP 200 (OK) response (ATCF to MSC server)

The ATCF acknowledge the SIP INFO request.

7. ATCF reserves resources in ATGW

8. SIP INFO request (ATCF to MSC server) – see example in table A.20.3-8

The ATCF sends a SIP INFO request containing the session transfer notification response contains the parameters required for the transfer, including IP address and media port allocated in the ATGW.

Table A.20.3-8: SIP INFO request (ATCF to MSC server)

INFO sip:user1_public1@visited2.net SIP/2.0

Via:

Max-Forwards:

Record-Route:

From:

To:

Call-ID:

Cseq:

Content-Disposition: Info-Package

Info-Package: g.3gpp.access-transfer-events

Contact:

Content-Type: application/vnd.3gpp.access-transfer-events+xml

Content-Length: (…)

<?xml version="1.0"?>

<STNResp-params>

<transfer-details>AVL0IrgAAAAAAAAAbwDeAU0BvA==</transfer-details>

<redirect-speech>true</redirect-speech>

</STNResp-params>

</event>

</events>

application/vnd.3gpp.access-transfer-events+xml: Contains the IPv6 address and port number of the ATGW. With the following <transfer-details>: ATGW-IPv6-address = 8888::111:222:333:444, ATGW-audio-UDP-port = 21236. Also indicates that the ATCF requires the MSC server to redirect the speech media component of the session transferred by the CS to PS SRVCC access transfer.

Info-Package: Indicates that the SIP INFO request contains the g.3gpp.access-transfer-events info package.

9. SIP 200 (OK) response (MSC server to ATCF)

The MSC server acknowledge the SIP INFO request.

10. The MSC server starts the preparation for the access transfer.

11. SIP INVITE request (MSC server to ATCF) – see example in table A.20.3-11

The MSC sends a SIP INVITE request to the ATCF to instruct the ATCF to establish the media bearer between MGW and ATGW.

Table A.20.3-11: SIP INVITE request (MSC server to ATCF)

INVITE sip:user2_public1@home2.net SIP/2.0

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

Max-Forwards: 70

Route: <sip:atcf.visited.net;lr>, <sip:scscf.home1.net;lr>, <sip:icscf.home1.net;lr>, <sip:sccas.home1.net;lr>

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

To: <sip:user1_public1@home1.net>;

Call-ID: cb03a0s09a2sdfglkj490333

Contact: <sip:msc1.home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

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

Cseq: 1 INVITE

Content-Type: application/sdp

Content-Length: (…)

…

12. SIP 200 (OK) response (ATCF to MSC server)

The ATCF acknowledge the SIP INVITE request by means of a SIP 200 (OK) response.

13. SIP ACK request (MSC Server to ATCF)

The MSC Server acknowledges the reception of the SIP 200 (OK) response.

14. When access transfer is prepared, the MSC server sends CS to PS handover command to the UE using access stratum signalling.

15. The MSC Server instructs the MGW to switch the media path from the source access to the target access.

16. SIP INFO request (MSC server to ATCF) – see example in table A.20.3-16

The MSC server sends a SIP INFO request containing a session transfer preparation to the ATCF to instruct the ATCF that media should be switched to the target access.

Table A.20.3-16: SIP INFO request (MSC server to ATCF)

INFO sip:user2_public1@home2.net SIP/2.0

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

Max-Forwards: 70

Route: <sip:atcf.visited.net;lr>, <sip:scscf.home1.net;lr>, <sip:icscf.home1.net;lr>, <sip:sccas.home1.net;lr>

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 130 INFO

Content-Disposition: Info-Package

Info-Package: g.3gpp.access-transfer-events

Content-Type: application/vnd.3gpp.access-transfer-events+xml

Content-Length: (…)

<?xml version="1.0"?>

</events>

17. SIP 200 (OK) response (ATCF to MSC server)

The ATCF acknowledge the SIP INFO request by means of a SIP 200 (OK) response.

18. ATCF configures resources in ATGW

The ATCF configures resources in the ATGW to start sending and receiving media towards the UE A instead of the MSC server.

19. The media path is now reconfigured.

20-21. SIP INVITE request (UE A to ATCF) – see example in table A.20.3-20

When the UE A receives the CS to PS handover command the UE A sends an SIP INVITE request towards the ATCF.

Table A.20.3-20: SIP INVITE request (UE A to ATCF)

INVITE sip:sti-rsr@atcf1.visited2.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.visited2.net:7531;lr;comp=sigcomp>,<sip:atcf.visited.net;lr, <sip:orig@scscf1.home1.net;lr>

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

P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11

Privacy: none

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Require: sec-agree

Supported: 100rel, gruu

Proxy-Require: sec-agree

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:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;comp=sigcomp>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

Accept: application/sdp, application/3gpp-ims+xml

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

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=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

Request-URI: contains the STI-rSR associated with the transferred call.

SDP offer: The media parameters of the speech media component are the same as the UE A sent to ATCF during registration (see subclause A.3.4).

22. SIP 200 (OK) response (ATCF to P-CSCF) – see example in table A.20.3-22

The ATCF sends the SIP 200 (OK) response towards the UE A with the media information allocated by the ATGW.

Table A.20.3-22: SIP 200 (OK) response (ATCF to P-CSCF)

SIP/2.0 200 OK

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

Max-Forwards: 70

Record-Route: <sip:pcscf1.visited2.net:7531;lr;comp=sigcomp>,<sip:atcf.visited.net;lr>

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

Privacy: none

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

To: <tel:+1-212-555-2222>;tag=aaaa

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Contact: <sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;comp=sigcomp>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

Feature-Caps: *;+g.3gpp.ti="70D8"

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=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

23. Bearer resource reservation

P-CSCF initiates bearer resource reservation based on the SDP answer received in the SIP 200 (OK) response.

24. SIP 200 (OK) response (P-CSCF to UE A)

25-26. SIP ACK request (UE A to ATCF)

The UE A acknowledges the reception of the SIP 200 (OK) response.

25. The media path is now reconfigured. The audio is sent between the UE A and ATGW using a dedicated bearer.

27-28. SIP INVITE request (ATCF to SCC AS) – see example in table A.20.3-27

Table A.20.3-27: SIP INVITE request (ATCF to SCC AS)

INVITE sip:cs2ps@sccas1.home1.net SIP/2.0

Record-Route: <sip:atcf2.visited2.net;lr>

Via: SIP/2.0/UDP atcf.visited2.net:5060;branch=z9hG4bKnas55889, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;;branch=z9hG4bKnashds7

Max-Forwards: 69

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

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

P-Charging-Vector: icid-value="1234bc9876e";icid-generated-at"5555::aaa:bbb:ccc:ddd";orig-ioi=visited2.net

P-Preferred-Service:

P-Access-Network-Info:

Privacy:

From:

To:

Call-ID:

Cseq:

Require:

Supported:

Proxy-Require:

Contact:

Accept:

Accept-Contact:

Allow:

Content-Type:

Content-Length:

v=0

o=- 22 333 IN IP6 8888::111:222:333:444

s=-

c=IN IP6 8888::111:222:333:444

t=0 0

m=audio 8899 RTP/AVP 97 96

b=AS:25.4

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

Request-URI: contains the ATU-STI for CS to PS SRVCC associated with the transferred call.

SDP: The SDP contains the SDP used at ATGW towards the remote UE B.

P-Asserted-Identity: the C-MSISDN of the served UE.

29-30. SIP 200 (OK) response (SCC AS to ATCF)

Since there is update in the session description, remote end update will be performed. The SCC AS sends confirmation response to the ATCF which contain the SDP answer that the SCC AS recevied during remote end update procedure.

31-32. SIP ACK request (ATCF to SCC AS)

33. SIP BYE request (ATCF to MSC Server)

Upon receiving the SIP 200 (OK) response from SCC AS, the ATCF sends a SIP BYE request to MSC Server to release the session established by SIP INVITE requet in step 11.

34. SIP 200 (OK) response (MSC Server to ATCF)

MSC server sends the SIP 200 (OK) response to the ATCF.

35-37. SIP BYE request (SCC AS to MSC server)

The SCC AS initiates the release of the source access leg.

38-40. SIP 200 (OK) response (MSC server to UE A)

41. The audio is sent between the UE A and ATGW using a dedicated PS bearer.

42. The MSC server clears the call

The MSC server locally clears the call.

43. The UA A clears the call

The UA locally clears the call.

Annex B (informative):
Void

Annex C (normative):
Media feature tags and feature-capability indicators defined within the current document