A.3 Signalling flows for registration

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.3.1 Introduction

When using CS access for media and to make use of the ISC procedures, the SC UE is registered in IM CN subsystem and the signalling flows are defined in 3GPP TS 24.292 [4] clause A.2.

When initiating a CS call, the SC UE can be registered in the CS domain as defined in 3GPP TS 24.008 [8].

Whenever the UE acquires IP connectivity via an IP-CAN, the signalling flows for registration in the IM CN subsystem are defined in 3GPP TS 24.228 [3].

A.3.2 Signalling flows for multiple registration for service continuity

The signalling flows shown in figure A.3.2-1 gives an example when a UE connects to different IP-CAN respectively and performs multiple registrations. In this example the UE also supports the Controller UE procedures for IUT transfer. In this example the SCC AS receives the registration state information that it needs to implement SCC specific requirements from the third-party SIP REGISTER request.

Figure A.3.2-1 Signalling flows for multiple registrations

1. SIP REGISTER request (UE to P-CSCF#1)-See example in table A.3.2-1

UE sends the SIP REGISTER request via the IP-CAN#1.

NOTE 1: For clarity, the unprotected SIP REGISTER request via the IP-CAN#1 is not shown in this example.

Table A.3.2-1SIP REGISTER request (UE to P-CSCF#1)

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

Max-Forwards: 70

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

From: <sip:user1_public1@home1.net>;tag=4fa3

To: <sip:user1_public1@home1.net>

Contact: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp>; reg-id=1; +sip.instance="< urn:gsma:imei:90420156-025763-0 >";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="principal";+g.3gpp.accesstype="cellular1";expires=600000

Call-ID: apb03a0s09dkjdfglkj49111

Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net", nonce=base64(RAND + AUTN + server specific data), algorithm=AKAv1-MD5, uri="sip:registrar.home1.net", response="6629fae49393a05397450978507c4ef1"

Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=2468; port-s=1357

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

Require: sec-agree

Proxy-Require: sec-agree

CSeq: 2 REGISTER

Supported: path, outbound, gruu

Content-Length: 0

2. SIP REGISTER request (P-CSCF#1 to I-CSCF)-See example in table A.3.2-2

After performing the DNS query, the P-CSCF#1 forwards the SIP REGISTER request towards I-CSCF. The P-CSCF adds a Path header field with a flow token and includes the ‘ob’ parameter.

Table A.3.2-2 SIP REGISTER request (P-CSCF#1 to I-CSCF)

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

Max-Forwards: 69

P-Access-Network-Info:

Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@pcscf1.visited1.net;lr;ob>

Require: path

P-Visited-Network-ID: "Visited Network Number 1"

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"

From:

To:

Contact:

Call-ID:

CSeq:

Supported:

Content-Length:

3. SIP REGISTER request (I-CSCF to S-CSCF)

The I-CSCF forwards the SIP REGISTER request to the S-CSCF.

4. SIP 200 (OK) response (S-CSCF to I-CSCF)-See example in table A.3.2-4

The S-CSCF sends a SIP 200 (OK) response to the I-CSCF indicating that Registration was successful. AS the URI in the first Path header field has an "ob" URI parameter, it include a Require header field with the option-tag "outbound".

Table A.3.2-4: SIP 200 (OK) response (S-CSCF to I-CSCF)

SIP/2.0 200 OK

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

Path: <sip:term@pcscf1.visited1.net;lr;ob>

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

From:

To:

Call-ID:

Contact: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp>;
pub-gruu=" sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu="sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr"
;+sip.instance="< urn:gsma:imei:90420156-025763-0 >"+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="principal";+g.3gpp.accesstype="cellular1"
;expires=600000

CSeq:

Supported: path, outbound

Require: outbound

Date: Wed, 11 July 2001 08:49:37 GMT

P-Associated-URI: <sip:user1_public2@home1.net>, <sip:user1_public3@home1.net>, <sip:+1-212-555-1111@home1.net;user=phone>

Content-Length:

5-6. SIP 200 (OK) response (I-CSCF to UE)

The I-CSCF forwards the SIP 200 (OK) response to the UE via P-CSCF#1.

7. SIP REGISTER request (S-CSCF to SCC AS)-See example in table A.3.2-7

After UE successfully registered in the IM CN subsystem, the S-CSCF sends a third party SIP REGISTER request to the SCC AS based on the initial filter criteria it received.

Table A.3.2-7: SIP REGISTER request (S-CSCF to SCC AS)

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

Max-Forwards: 70

From: <sip:scscf1.home1.net>; tag=538ya

To: <sip:user1_public1@home1.net>

Call-ID: 1asdaddlrfjflslj40a222

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

Contact: <sip:scscf1.home1.net>; expires=600000

CSeq: 87 REGISTER

Content-Type: multipart/mixed;boundary="boundary1"

Content-Length: (…)

–boundary1

Content-Type: message/sip

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

Max-Forwards: 69

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

Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@pcscf1.visited1.net;lr;ob>

Require: path

P-Visited-Network-ID: "Visited Network Number 1"

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"

From: <sip:user1_public1@home1.net>;tag=4fa3

To: <sip:user1_public1@home1.net>

Contact: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp>; reg-id=1; +sip.instance="< urn:gsma:imei:90420156-025763-0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="principal";+g.3gpp.accesstype="cellular1";expires=600000

Call-ID: apb03a0s09dkjdfglkj49111

CSeq: 2 REGISTER

Supported: path, outbound, gruu

Content-Length: 0

–boundary1

Content-Type: message/sip

SIP/2.0 200 OK

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

Path: <sip:term@pcscf1.visited1.net;lr;ob>

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

From: <sip:user1_public1@home1.net>;tag=4fa3

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

Call-ID: apb03a0s09dkjdfglkj49111

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

pub-gruu="sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

;temp-gruu="sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr"

;+sip.instance="< urn:gsma:imei:90420156-025763-0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="principal"+g.3gpp.accesstype="cellular1"

;expires=600000

Supported: path, outbound

Require: outbound

Date: Wed, 11 July 2001 08:49:37 GMT

P-Associated-URI: <sip:user1_public2@home1.net>, <sip:user1_public3@home1.net>, <sip:+1-212-555-1111@home1.net;user=phone>

CSeq: 2 REGISTER

Content-Length: 0

–boundary1–

8. SIP 200 (OK) response (SCC AS to S-CSCF)

The SCC AS generates the SIP 200 (OK) response to the third party SIP REGISTER request.

9. UE connects to a new IP-CAN

The UE connects to a new IP-CAN and will perform the registration via the new IP-CAN.

10. SIP REGISTER request (UE to P-CSCF#2)- See example in table A.3.2-10

UE sends the unprotected SIP REGISTER request via the new IP-CAN to P-CSCF+2 which in this example is a different one with previous registration.

Table A.3.2-10: SIP REGISTER request (UE to P-CSCF#2)

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:eee];comp=sigcomp;branch=z9hG4bKnasiuen8

Max-Forwards: 70

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

From: <sip:user1_public1@home1.net>;tag=2hiue

To: <sip:user1_public1@home1.net>

Contact: <sip:[5555::aaa:bbb:ccc:eee];comp=sigcomp>; reg-id=2; +sip.instance="< urn:gsma:imei:90420156-025763-0>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="principal";+g.3gpp.accesstype="wlan2";expires=600000

Call-ID: E05133BD26DD

Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net", nonce="", uri="sip:registrar.home1.net", response=""

Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=1234; port-s=5678

Require: sec-agree

Proxy-Require: sec-agree

CSeq: 1 REGISTER

Supported: path, outbound, gruu

Content-Length: 0

11-12. SIP REGISTER request (P-CSCF#2 to S-CSCF)

The P-CSCF forwards the SIP REGISTER request towards S-CSCF via I-CSCF. Likewise in message #2, P-CSCF#2 adds a Path header field with flow token and ‘ob’ parameter.

13-15. SIP 401 (Unauthorized) response (S-CSCF to UE)

The authentication challenge is sent in the SIP 401 (Unauthorized) response towards the UE.

16-18. SIP REGISTER request (UE to S-CSCF)

The UE sends the protected SIP REGISTER request towards S-CSCF using contact#2.

19-21. SIP 200 (OK) response (S-CSCF to UE)

The S-CSCF sends a SIP 200 (OK) response towards the UE indicating that registration was successful.

22. SIP REGISTER request (S-CSCF to SCC AS)

The S-CSCF sends a third party SIP REGISTER request to the SCC AS based on the initial filter criteria it received.

Table A.3.2-22: SIP REGISTER request (S-CSCF to SCC AS)

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

Max-Forwards: 70

From: <sip:scscf1.home1.net>; tag=538ya

To: <sip:user1_public1@home1.net>

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

Call-ID: 1asdaddlrfjflslj40a222

Contact: <sip:scscf1.home1.net>; expires=600000

CSeq: 87 REGISTER

Content-Type: multipart/mixed;boundary="boundary1"

Content-Length: (…)

–boundary1

Content-Type: message/sip

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:eee]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 69

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

Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@pcscf1.visited1.net;lr;ob>

Require: path

P-Visited-Network-ID: "Visited Network Number 1"

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"

From: <sip:user1_public1@home1.net>;tag=2hiue

To: <sip:user1_public1@home1.net>

Contact: <sip:[5555::aaa:bbb:ccc:eee];comp=sigcomp>;reg-id=2;+sip.instance="< urn:gsma:imei:90420156-025763-0>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="principal";+g.3gpp.accesstype ="wlan2";expires=600000

Call-ID: apb03a0s09dkjdfglkj49111

CSeq: 3 REGISTER

Supported: path, outbound, gruu

Content-Length: 0

–boundary1

Content-Type: message/sip

SIP/2.0 200 OK

Via: SIP/2.0/UDP icscf1_p.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:eee]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Path: <sip:term@pcscf1.visited1.net;lr;ob>

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

From: <sip:user1_public1@home1.net>;tag=2hiue

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

Call-ID: apb03a0s09dkjdfglkj49111

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

pub-gruu="sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

;temp-gruu="sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr"

;+sip.instance="<urn:gsma:imei:90420156-025763-0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="principal";+g.3gpp.accesstype="wlan2"

;expires=600000

Supported: path, outbound

Require: outbound

Date: Wed, 11 July 2001 08:49:37 GMT

P-Associated-URI: <sip:user1_public2@home1.net>, <sip:user1_public3@home1.net>, <sip:+1-212-555-1111@home1.net;user=phone>

CSeq: 3 REGISTER

Content-Length: 0

–boundary1–

23. SIP 200 (OK) response (SCC AS to S-CSCF)

The SCC AS generates the SIP 200 (OK) response to the third-party SIP REGISTER request.

A.3.3 Signalling flows for registration with SRVCC enhancements

The signalling flows shown in figure A.3.3-1 gives an example flow for UE registration when ATCF is invoked.

Figure A.3.3-1 registration with SRVCC enhancements

1. SIP REGISTER request (UE to P-CSCF) – see example in table A.3.3-1

UE sends the unprotected SIP REGISTER request to P-CSCF.

Table A.3.3-1: SIP REGISTER request (UE to P-CSCF)

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:eee];comp=sigcomp;branch=z9hG4bKnasiuen8

Max-Forwards: 70

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

From: <sip:user1_public1@home1.net>;tag=2hiue

To: <sip:user1_public1@home1.net>

Contact: <sip:[5555::aaa:bbb:ccc:eee];comp=sigcomp>;+sip.instance="<urn:gsma:imei:90420156-025763-0>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

Call-ID: E05133BD26DD

Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net", nonce="", uri="sip:home1.net", response=""

Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=1234; port-s=5678

Require: sec-agree

Proxy-Require: sec-agree

CSeq: 1 REGISTER

Supported: path, gruu

Content-Length: 0

2. SIP REGISTER request (P-CSCF to ATCF) – see example in table A.3.3-2

The P-CSCF forwards the SIP REGISTER request towards ATCF.

Table A.3.3-2: SIP REGISTER request (P-CSCF to ATCF)

Path: <sip:aga2gfgf@pcscf1.visited2.net:5070;ob>

Route: <sip:reg@atcf.visited2.net;lr>

P-Visited-Network-ID: "Visited Network Number 1"

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

Via: SIP/2.0/UDP pcscf1.visited2.net:5060;branch=z9hG4bKnas56565, SIP/2.0/UDP [5555::aaa:bbb:ccc:eee];comp=sigcomp;branch=z9hG4bKnasiuen8;rport=5060;received=5555::aaa:bbb:ccc:eee

Max-Forwards: 69

P-Access-Network-Info:

From:

To:

Contact:

Call-ID:

Authorization:

Require:

Proxy-Require:

CSeq:

Supported:

Content-Length:

Route: ATCF URI for originating requests (as configured in P-CSCF).

3.-4. SIP REGISTER request (ATCF towards S-CSCF) – see example in table A.3.3-3

The ATCF decides to include itself for sessions created using this registration and forwards the SIP REGISTER request along the Route header fields.

Table A.3.3-3: SIP REGISTER request (ATCF towards S-CSCF)

Feature-Caps: *;+g.3gpp.atcf="<tel:+1-237-888-9999>"; +g.3gpp.atcf-mgmt-uri = "<sip:atcf.visited2.net>";+g.3gpp.atcf-path="<sip:termsdgfdfwe@atcf.visited2.net>";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting

Path: <sip:termsdgfdfwe@atcf.visited2.net>,<sip:aga2gfgf@pcscf1.visited2.net:5070;ob>

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

P-Visited-Network-ID:

P-Charging-Vector:

Via: SIP/2.0/UDP atcf.visited2.net:5060;branch=z9hG4bKnas5889; SIP/2.0/UDP pcscf1.visited2.net:5060;branch=z9hG4bKnas56565, SIP/2.0/UDP [5555::aaa:bbb:ccc:eee];comp=sigcomp;branch=z9hG4bKnasiuen8;rport=5060;received=5555::aaa:bbb:ccc:eee

Max-Forwards: 68

P-Access-Network-Info:

From:

To:

Contact:

Call-ID:

Authorization:

Require:

Proxy-Require:

CSeq:

Supported:

Content-Length:

Path: ATCF URI for terminating requests followed by P-CSCF URI for terminating requests. ATCF URI for terminating requests uniquely identifies registration path (or registration flow, if multiple registration mechanism is used).

Feature-Caps: The header field contains:

– g.3gpp.atcf feature-capability indicator indicating that the ATCF role is supported by this URI;

– g.3gpp.atcf-mgmt-uri feature-capability indicator indicating the management URI of the ATCF for receiving SIP MESSAGE requests containing SRVCC related information and the g.3gpp.atcf-path feature-capability indicator. The value of the g.3gpp.atcf feature-capability indicator contains the STN-SR allocated by ATCF. The value of the g.3gpp.atcf-mgmt-uri feature-capability indicator contains the ATCF management URI. The value of the g.3gpp.atcf-path feature-capability indicator is the ATCF URI for terminating requests;

– g.3gpp.mid-call indicating that all MSC servers, which can be involved in the SRVCC procedures and which are in the same network as the ATCF, support the MSC server assisted mid-call feature; and

– g.3gpp.srvcc-alerting indicating that all MSC servers, which can be involved in the SRVCC procedures and which are in the same network as the ATCF, support the PS to CS SRVCC for calls in alerting phase.

Route: URI of the entry point of the home network of the UE.

5-8. SIP 401 (Unauthorized) response (S-CSCF to UE)

The authentication challenge is sent in the SIP 401 (Unauthorized) response towards the UE.

9. SIP REGISTER request (UE to P-CSCF) – see example in table A.3.3-9

UE sends the protected SIP REGISTER request to P-CSCF.

Table A.3.3-9: SIP REGISTER request (UE to P-CSCF)

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:eee];comp=sigcomp;branch=z9hG4bKnasiuen8

Max-Forwards: 70

P-Access-Network-Info:

From:

To:

Contact:

Call-ID:

Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net", nonce=base64(RAND + AUTN + server specific data), algorithm=AKAv1-MD5, uri="sip:home1.net", response="6629fae49393a05397450978507c4ef1"

Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=1234; port-s=5678

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

Require:

Proxy-Require:

CSeq: 2 REGISTER

Supported:

Content-Length:

10. SIP REGISTER request (P-CSCF to ATCF) – see example in table A.3.3-10

The P-CSCF forwards the SIP REGISTER request towards ATCF.

Table A.3.3-10: SIP REGISTER request (P-CSCF to ATCF)

Path: <sip:aga2gfgf@pcscf1.visited2.net:5070;ob>

Route: <sip:reg@atcf.visited2.net;lr>

P-Visited-Network-ID: "Visited Network Number 1"

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

Via: SIP/2.0/UDP pcscf1.visited2.net:5060;branch=z9hG4bKnas56565, SIP/2.0/UDP [5555::aaa:bbb:ccc:eee];comp=sigcomp;branch=z9hG4bKnasiuen8;rport=5060;received=5555::aaa:bbb:ccc:eee

Max-Forwards: 69

P-Access-Network-Info:

From:

To:

Contact:

Call-ID:

Authorization:

Require:

Proxy-Require:

CSeq:

Supported:

Content-Length:

Route: ATCF URI for originating requests (as configured in P-CSCF).

11-12. SIP REGISTER request (ATCF towards S-CSCF) – see example in table A.3.3-11

The ATCF decides to include itself for sessions created using this registration and forwards the SIP REGISTER request.

Table A.3.3-11: SIP REGISTER request (ATCF towards S-CSCF)

Feature-Caps: *;+g.3gpp.atcf="<tel:+1-237-888-9999>" ;+g.3gpp.atcf-mgmt-uri= "<sip:atcf.visited2.net>";+g.3gpp.atcf-path="<sip:termsdgfdfwe@atcf.visited2.net>";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting

Path: <sip:termsdgfdfwe@atcf.visited2.net>,<sip:aga2gfgf@pcscf1.visited2.net:5070;ob>

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

P-Visited-Network-ID:

P-Charging-Vector:

Max-Forwards: 68

P-Access-Network-Info:

From:

To:

Contact:

Call-ID:

Authorization:

Require:

Proxy-Require:

CSeq:

Supported:

Content-Length:

Feature-Caps: The header field contains

– g.3gpp.atcf feature-capability indicator indicating that the ATCF role is supported by this URI;

– g.3gpp.mid-call indicating that all MSC servers, which can be involved in the SRVCC procedures and which are in the same network as the ATCF, support the MSC server assisted mid-call feature.

Route: URI of the entry point of the home network of the UE.

13.-14. SIP 200 (OK) response (S-CSCF to ATCF)

The S-CSCF sends a SIP 200 (OK) response towards the UE indicating that registration was successful.

15.-16. SIP 200 (OK) response (ATCF to UE)

The ATCF sends a SIP 200 (OK) response towards the UE indicating that registration was successful.

Table A.3.3-15: SIP 200 (OK) response to the REGISTER request (ATCF towards UE)

SIP/2.0 200 OK

Feature-Caps: *;+g.3gpp.atcf="<tel:+1-237-888-9999>"

Path: <sip:termsdgfdfwe@atcf.visited2.net>,<sip:aga2gfgf@pcscf1.visited2.net:5070;ob>

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

P-Charging-Vector:

Max-Forwards: 66

From:

To:

Contact:

Call-ID:

Authorization:

CSeq:

Supported:

Content-Length:

Feature-Caps: The header field contains g.3gpp.atcf feature-capability indicator indicating that the ATCF role is supported.

17. SIP REGISTER request (S-CSCF to SCC AS) – see example in table A.3.3-17

The S-CSCF sends a third party SIP REGISTER request to the SCC AS based on the initial filter criteria it received.

Table A.3.3-17: SIP REGISTER request (S-CSCF to SCC AS)

Via: SIP/2.0/TCP scscf1.home1.net;branch=z9hG499ffhy

Max-Forwards: 70

From: <sip:scscf1.home1.net>; tag=538ya

To: <sip:user1_public1@home1.net>

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

Call-ID: 1asdaddlrfjflslj40a222

Contact: <sip:scscf1.home1.net>; expires=600000

CSeq: 87 REGISTER

Content-Type: multipart/mixed;boundary="boundary1"

Content-Length: (…)

–boundary1

Content-Type: message/sip

Feature-Caps: *;+g.3gpp.atcf="<tel:+1-237-888-9999>" ;+g.3gpp.atcf-mgmt-uri= "<sip:atcf.visited2.net>";+g.3gpp.atcf-path="<sip:termsdgfdfwe@atcf.visited2.net>";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting

Path: <sip:termsdgfdfwe@atcf.visited2.net>,<sip:aga2gfgf@pcscf1.visited2.net:5070;ob>

P-Visited-Network-ID: "Visited Network Number 1"

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

Via: SIP/2.0/UDP icscf.visited2.net:5060;branch=z9hG4bKnas8866; SIP/2.0/UDP atcf.visited2.net:5060;branch=z9hG4bKnas5889; SIP/2.0/UDP pcscf1.visited2.net:5060;branch=z9hG4bKnas56565, SIP/2.0/UDP [5555::aaa:bbb:ccc:eee];comp=sigcomp;branch=z9hG4bKnasiuen8;rport=5060;received=5555::aaa:bbb:ccc:eee

Max-Forwards: 66

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

From: <sip:user1_public1@home1.net>;tag=2hiue

To: <sip:user1_public1@home1.net>

Contact: <sip:[5555::aaa:bbb:ccc:eee];comp=sigcomp>;+sip.instance="<urn:gsma:imei:90420156-025763-0>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

Call-ID: E05133BD26DD

Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net", nonce="", uri="sip:home1.net", response=""

Require: sec-agree

Proxy-Require: sec-agree

CSeq: 2 REGISTER

Supported: path, gruu

Content-Length: 0

–boundary1

Content-Type: message/sip

SIP/2.0 200 OK

Path: <sip:termsdgfdfwe@atcf.visited2.net>,<sip:aga2gfgf@pcscf1.visited2.net:5070;ob>

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

From: <sip:user1_public1@home1.net>;tag=2hiue

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

Call-ID: E05133BD26DD

Contact: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp>;+sip.instance="<urn:gsma:imei:90420156-025763-0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

;pub-gruu="sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

;temp-gruu="sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr";expires=600000

Supported: path, gruu

P-Associated-URI: <sip:user1_public2@home1.net>, <sip:user1_public3@home1.net>, <sip:+1-212-555-1111@home1.net;user=phone>

CSeq: 2 REGISTER

Content-Length: 0

–boundary1–

18. SIP 200 (OK) response (SCC AS to S-CSCF)

The SCC AS generates the SIP 200 (OK) response to the third-party SIP REGISTER request.

19.-20. SIP MESSAGE request with SRVCC related information (SCC AS to ATCF)

The SCC AS sends the SIP MESSAGE request with SRVCC related information towards the ATCF serving the registered UE.

Table A.3.3-19: SIP MESSAGE request (SCC AS towards ATCF)

MESSAGE sip:atcf.visited2.net SIP/2.0

Via: SIP/2.0/UDP sccas1.home1.net:5060;branch=z9hG4bKnas588339

Max-Forwards: 70

From: <sip:sccas1.home1.net>;tag=aassd

To: sip:atcf.visited2.net

Call-ID: sdvasdfgfasdf

CSeq: 56561 MESSAGE

Content-Length: …

P-Asserted-Identity: sip:sccas1.home1.net

Content-Type: application/vnd.3gpp.SRVCC-info+xml

<?xml version="1.0" encoding="UTF-8"?>

<SRVCC-infos>

<SRVCC-info ATCF-Path-URI="sip:termsdgfdfwe@atcf.visited2.net">

<ATU-STI>sip:sccas1.home1.net</ATU-STI>

<C-MSISDN>tel:+1-237-555-1111</C-MSISDN>

</SRVCC-info>

</SRVCC-infos>

Request-URI: ATCF management URI

P-Asserted-Identity: SCC AS URI

body: SRVCC related information

21.-22. SIP 200 (OK) response (ATCF to SCC AS)

The ATCF generates the SIP 200 (OK) response to the SIP MESSAGE request.

23. Store STN-SR in HSS (SCC AS to HSS)

SCC AS provides the received STN-SR into the HSS to replace the STN-SR pointing to the SCC AS or the previously stored STN-SR pointing to other ATCF.

NOTE: step 23 can be started in parallel to step 19.

24. Notify MME that STN-SR was changed (HSS to MME)

HSS provides the STN-SR to the MME because of the change of the subscription data.

A.3.4 Signalling flows for registration with SRVCC enhancements from UE supporting CS to PS SRVCC

The signalling flows shown in figure A.3.4-1 gives an example flow for UE registration when ATCF is invoked. UE and ATCF are also enhanced for CS to PS SRVCC.

Figure A.3.4-1 registration with CS to PS SRVCC enhancements

1. SIP REGISTER request (UE to P-CSCF) – see example in table A.3.4-1

UE sends the unprotected SIP REGISTER request to P-CSCF.

Table A.3.4-1: SIP REGISTER request (UE to P-CSCF)

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

Max-Forwards: 70

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

From: <sip:user1_public1@home1.net>;tag=2hiue

To: <sip:user1_public1@home1.net>

Contact: <sip:[5555::aaa:bbb:ccc:ddd]:5432;comp=sigcomp>;+sip.instance="<urn:gsma:imei:90420156-025763-0>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.cs2ps-srvcc;+g.3gpp.cs2ps-srvcc-alerting

Call-ID: E05133BD26DD

Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net", nonce="", uri="sip:home1.net", response=""

Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=1234; port-s=5678

Require: sec-agree

Proxy-Require: sec-agree

CSeq: 1 REGISTER

Supported: path, gruu

Content-Length: 0

Contact header field: media feature tag g.3gpp.cs2ps-srvcc indicates support of the CS to PS SRVCC in the UE; and media feature tag +g.3gpp.cs2ps-srvcc-alerting indicates support of the CS to PS SRVCC of calls in alerting phase in the UE.

2. SIP REGISTER request (P-CSCF to ATCF) – see example in table A.3.4-2

The P-CSCF forwards the SIP REGISTER request towards ATCF.

Table A.3.4-2: SIP REGISTER request (P-CSCF to ATCF)

Path: <sip:aga2gfgf@pcscf1.visited2.net:5070;ob>

Route: <sip:reg@atcf.visited2.net;lr>, <sip:icscf.home1.net;lr>

P-Visited-Network-ID: "Visited Network Number 1"

P-Charging-Vector: ####

Via: SIP/2.0/UDP pcscf1.visited2.net:5060;branch=z9hG4bKnas56565, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnasiuen8;rport=5060;received=5555::aaa:bbb:ccc:ddd

Max-Forwards: 69

P-Access-Network-Info:

From:

To:

Contact:

Call-ID:

Authorization:

Require:

Proxy-Require:

CSeq:

Supported:

Content-Length:

Route: ATCF URI for originating requests (as configured in P-CSCF) followed by URI of the entry point of the home network of the UE.

3.-4. SIP REGISTER request (ATCF towards S-CSCF) – see example in table A.3.4-3

The ATCF decides to include itself for sessions created using this registration and forwards the SIP REGISTER request along the Route header fields.

Table A.3.4-3: SIP REGISTER request (ATCF towards S-CSCF)

Feature-Caps: *;+g.3gpp.atcf="<tel:+1-237-888-9999>"; +g.3gpp.atcf-mgmt-uri= "<sip:atcf.visited2.net>";+g.3gpp.atcf-path="<sip:termsdgfdfwe@atcf.visited2.net>"; +g.3gpp.cs2ps-srvcc="<sip:sti-sr@atcf.visited2.net>"

Path: <sip:termsdgfdfwe@atcf.visited2.net>,<sip:aga2gfgf@pcscf1.visited2.net:5070;ob>

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

P-Visited-Network-ID:

P-Charging-Vector:

Via: SIP/2.0/UDP atcf.visited2.net:5060;branch=z9hG4bKnas5889; SIP/2.0/UDP pcscf1.visited2.net:5060;branch=z9hG4bKnas56565, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnasiuen8;rport=5060;received=5555::aaa:bbb:ccc:ddd

Max-Forwards: 68

P-Access-Network-Info:

From:

To:

Contact:

Call-ID:

Authorization:

Require:

Proxy-Require:

CSeq:

Supported:

Content-Length:

Path: ATCF URI for terminating requests followed by P-CSCF URI for terminating requests. ATCF URI for terminating requests uniquely identifies registration (or registration flow, if multiple registration mechanism is used).

Feature-Caps: The header field contains:

– g.3gpp.atcf feature-capability indicator with value containing the STN-SR allocated by ATCF;

– g.3gpp.atcf-mgmt-uri feature-capability indicator with value containing the ATCF management URI;

– g.3gpp.atcf-path feature-capability indicator with value containing the ATCF URI for terminating requests; and

– g.3gpp.cs2ps-srvcc feature-capability indicator with value containing the STI-rSR allocated by ATCF.

Route: URI of the entry point of the home network of the UE.

5-8. SIP 401 (Unauthorized) response (S-CSCF to UE)

The authentication challenge is sent in the SIP 401 (Unauthorized) response towards the UE.

9. SIP REGISTER request (UE to P-CSCF) – see example in table A.3.4-9

UE sends the protected SIP REGISTER request to P-CSCF.

Table A.3.4-9: SIP REGISTER request (UE to P-CSCF)

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

Max-Forwards: 70

P-Access-Network-Info:

From:

To:

Call-ID:

Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net", nonce=base64(RAND + AUTN + server specific data), algorithm=AKAv1-MD5, uri="sip:home1.net", response="6629fae49393a05397450978507c4ef1"

Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=1234; port-s=5678

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

Require:

Proxy-Require:

CSeq: 2 REGISTER

Supported:

Content-Length: 0

10. SIP REGISTER request (P-CSCF to ATCF) – see example in table A.3.4-10

The P-CSCF forwards the SIP REGISTER request towards ATCF.

Table A.3.4-10: SIP REGISTER request (P-CSCF to ATCF)

Path: <sip:aga2gfgf@pcscf1.visited2.net:5070;ob>

Route: <sip:reg@atcf.visited2.net;lr>, <sip:icscf.home1.net;lr>

P-Visited-Network-ID: "Visited Network Number 1"

P-Charging-Vector: ####

Via: SIP/2.0/UDP pcscf1.visited2.net:5060;branch=z9hG4bKnas56565, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnasiuen8;rport=5060;received=5555::aaa:bbb:ccc:ddd

Max-Forwards: 69

P-Access-Network-Info:

From:

To:

Contact:

Call-ID:

Authorization:

Require:

Proxy-Require:

CSeq:

Supported:

Content-Length:

Route: ATCF URI for originating requests (as configured in P-CSCF) followed by URI of the entry point of the home network of the UE.

11-12. SIP REGISTER request (ATCF towards S-CSCF) – see example in table A.3.4-11

The ATCF decides to include itself for sessions created using this registration and forwards the SIP REGISTER request.

Table A.3.4-11: SIP REGISTER request (ATCF towards S-CSCF)

Feature-Caps: *;+g.3gpp.atcf="<tel:+1-237-888-9999>"; +g.3gpp.atcf-mgmt-uri= "<sip:atcf.visited2.net>";+g.3gpp.atcf-path="<sip:termsdgfdfwe@atcf.visited2.net>"; +g.3gpp.cs2ps-srvcc="<sip:sti-sr@atcf.visited2.net>"

Path: <sip:termsdgfdfwe@atcf.visited2.net>,<sip:aga2gfgf@pcscf1.visited2.net:5070;ob>

Route: <sip:sdvfasdgf34t4@pcscf1.visited2.net:5080>

P-Visited-Network-ID:

P-Charging-Vector:

Max-Forwards: 68

P-Access-Network-Info:

From:

To:

Contact:

Call-ID:

Authorization:

Require:

Proxy-Require:

CSeq:

Supported:

Content-Length:

Feature-Caps: The header field contains:

– g.3gpp.atcf feature-capability indicator with value containing the STN-SR allocated by ATCF;

– g.3gpp.atcf-mgmt-uri feature-capability indicator with value containing the ATCF management URI;

– g.3gpp.atcf-path feature-capability indicator with value containing the ATCF URI for terminating requests; and

– g.3gpp.cs2ps-srvcc feature-capability indicator with value containing the STI-rSR allocated by ATCF.

Route: URI of the entry point of the home network of the UE.

13.-14. SIP 200 (OK) response (S-CSCF towards ATCF)

The S-CSCF sends a SIP 200 (OK) response towards the UE indicating that registration was successful.

15.-16. SIP 200 (OK) response (ATCF towards UE)- see example in table A.3.4-15

The ATCF sends a SIP 200 (OK) response towards the P-CSCF indicating that registration was successful.

Table A.3.4-15: SIP 200 (OK) response to the SIP REGISTER request (ATCF towards UE)

SIP/2.0 200 OK

Feature-Caps: *;+g.3gpp.atcf="<tel:+1-237-888-9999>";+g.3gpp.cs2ps-srvcc="<sip:sti-sr@atcf.visited2.net>"

Path: <sip:termsdgfdfwe@atcf.visited2.net>,<sip:aga2gfgf@pcscf1.visited2.net:5070;ob>

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

P-Charging-Vector:

Max-Forwards: 66

From:

To:

Contact:

Call-ID:

Authorization:

CSeq:

Supported:

Content-Length:

Feature-Caps: The header field contains:

– g.3gpp.atcf feature-capability indicator with value containing the STN-SR allocated by ATCF; and

– g.3gpp.cs2ps-srvcc feature-capability indicator with value containing the STI-rSR allocated by ATCF.

17. SIP REGISTER request (S-CSCF to SCC AS)

The S-CSCF sends a third party SIP REGISTER request to the SCC AS based on the initial filter criteria it received.

18. SIP 200 (OK) response (SCC AS to S-CSCF)

The SCC AS generates the SIP 200 (OK) response to the third-party SIP REGISTER request.

19.-20. SIP MESSAGE request with SRVCC related information (SCC AS towards ATCF) – see example in table A.3.4-19

The SCC AS sends the SIP MESSAGE request with SRVCC related information towards the ATCF serving the registered UE.

Table A.3.4-19: SIP MESSAGE request (SCC AS towards ATCF)

MESSAGE sip:atcf.visited2.net SIP/2.0

Via: SIP/2.0/UDP sccas1.home1.net:5060;branch=z9hG4bKnas588339

Max-Forwards: 70

From: <sip:sccas1.home1.net>;tag=aassd

To: sip:atcf.visited2.net

Call-ID: sdvasdfgfasdf

CSeq: 56561 MESSAGE

Content-Length: …

P-Asserted-Identity: sip:sccas1.home1.net

Content-Type: application/vnd.3gpp.SRVCC-info+xml

<?xml version="1.0"?>

<SRVCC-infos>

<SRVCC-info ATCF-Path-URI="sip:termsdgfdfwe@atcf.visited2.net">

<ATU-STI>sip:sccas1.home1.net</ATU-STI>

<C-MSISDN>tel:+1-237-555-1111</C-MSISDN>

<CS2PS-ATU-STI>sip:cs2ps@sccas1.home1.net</CS2PS-ATU-STI>

</anyExt>

</SRVCC-info>

</SRVCC-infos>

Request-URI: ATCF management URI

P-Asserted-Identity: SCC AS URI

body: SRVCC related information. The CS2PS-ATU-STI element contains the ATU-STI to be used in CS to PS SRVCC.

21.-22. SIP 200 (OK) response (ATCF towards SCC AS)

The ATCF generates the SIP 200 (OK) response to the SIP MESSAGE request.

23. Store STN-SR in HSS (SCC AS to HSS)

SCC AS provides the received STN-SR into the HSS to replace the STN-SR pointing to the SCC AS or the previously stored STN-SR pointing to other ATCF.

NOTE: step 23 can be started in parallel to step 19.

24. Notify MME that STN-SR was changed (HSS to MME)

HSS provides the STN-SR to the MME because of the change of the subscription data.

25.-26. SIP MESSAGE request with ATGW information for CS to PS SRVCC (ATCF towards UE) – see example in table A.3.4-25

Table A.3.4-25: SIP MESSAGE request (ATCF towards UE)

MESSAGE sip:[5555::aaa:bbb:ccc:ddd]:5432;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP atcf.visited2.net:5060;branch=z9hG4bKnas66

Max-Forwards: 70

Route: <sip:aga2gfgf@pcscf1.visited2.net:5070;ob>

P-Asserted-Identity: sip:sti-sr@atcf.visited2.net

From: sip:sti-sr@atcf.visited2.net;tag=aaa5234

To: sip:[5555::aaa:bbb:ccc:ddd]:5432

Call-ID: asgag34t34543

CSeq: 1000034

Content-Type:

Content-Length: (…)

Content-Disposition: render

P-Charging-Vector: ####

v=0

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

s=-

c=IN IP6 dfgrrgr.invalid

t=0 0

m=audio 9 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: contact address of the UE

Route: P-CSCF path header field

application/sdp MIME body: SDP describing the set of media streams and codecs the ATGW wishes to use receive the media in session transferred in any later CS to PS SRVCC access transfer. The IP addresses and ports can contain any value as the ATGW IP address and port are selected during the later CS to PS SRVCC access transfer.

27.-28. SIP 200 (OK) response (UE towards ATCF)

The UE generates the SIP 200 (OK) response to the SIP MESSAGE request.

29. SIP MESSAGE request with UE information for CS to PS SRVCC (UE to P-CSCF) – see example in table A.3.4-29

The UE sends the SIP MESSAGE request with UE information for CS to PS SRVCC towards the ATCF.

Table A.3.4-29: SIP MESSAGE request (UE to P-CSCF)

MESSAGE sip:sti-sr@atcf.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:orig@scscf1.home1.net;lr>

P-Preferred-Identity: "John Doe" <sip:user1_public1@home1.net>

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

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

To: sip:sti-sr@atcf.visited2.net

Call-ID: cb03a0s09a2sdfglkj49033333

CSeq: 56561 MESSAGE

Require: sec-agree

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

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

Content-Type: application/sdp

Content-Length: (…)

Content-Disposition: render

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: the STI-rSR allocated by ATCF received in message 16

application/sdp MIME body: SDP describing the set of media streams and codecs the UE wishes to use, along with the IP addresses and ports the UE would like to use to receive the media in session transferred in any later CS to PS SRVCC access transfer.

30. SIP MESSAGE request with UE information for CS to PS SRVCC (P-CSCF to ATCF) – see example in table A.3.4-30

Table A.3.4-30: SIP MESSAGE request (P-CSCF to ATCF)

MESSAGE sip:sti-sr@atcf.visited2.net SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited2.net:5060;branch=z9hG4bKnas5656544, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards:

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

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>

P-Access-Network-Info:

From:

To:

Call-ID:

CSeq:

Require:

Supported:

Proxy-Require:

Security-Verify:

Allow:

Content-Type:

Content-Length: (…)

Content-Disposition:

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: the STI-rSR allocated by ATCF

Route: ATCF URI for originating requests (as configured in P-CSCF).

31.-32. SIP 200 (OK) response (ATCF towards UE)

The ATCF generates the SIP 200 (OK) response to the SIP MESSAGE request.

A.3.5 Signalling flows for UE attaching to CS domain when MSC server is enhanced for ICS and for CS to PS SRVCC and when UE is not registered with IMS in PS access network yet

This signalling flow shown at figure A.3.5-1 describes the scenario of UE attaching to CS domain when the used MSC server is enhanced for ICS and for CS to PS SRVCC and when the UE is not registered with IMS in PS access network yet.

Figure A.3.5-1 MSC Server enhanced for ICS performs registration on behalf of the UE

The details of the signalling flows are as follows:

1. CS attach (UE to MSC)

UE performs CS attachment procedure as specified in 3GPP TS 24.008 [8]. UE indicates support of CS to PS SRVCC in the CS attachment procedure.

3. CS attach accept (MSC enhanced for ICS to UE)

The CS attach request is accepted by the network and an accept message is sent to the MS.

3-4. SIP REGISTER request (MSC Server enhanced for ICS to S-CSCF) – see example in table A.3.5-3

Table A.3.5-3: SIP REGISTER request (MSC Server enhanced for ICS to I-CSCF)

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

Max-Forwards: 70

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

P-Visited-Network-ID: "Visited Network Number 1 for MSC Server"

P-Charging-Vector: ####

Path: <sip:termpdfjkghlj@msc123.visited2.net;lr>

From: <sip:234150999999999@ics.mnc015.mcc234.3gppnetwork.org>;tag=4fa3

To: <sip:234150999999999@ics.mnc015.mcc234.3gppnetwork.org>

Contact: <sip:[5555::aaa:bbb:ccc:ddd]>;expires=600000;+sip.instance="<urn:gsma:imei:90420156-025763-0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server"; +g.3gpp.cs2ps-srvcc; +g.3gpp.path="<sip:termpdfjkghlj@msc123.visited2.net;lr>"

Call-ID: apb03a0s09dkjdfglkj49111

Authorization: Digest username="234150999999999@ics.mnc015.mcc234.3gppnetwork.org", realm=" ics.mnc015.mcc234.3gppnetwork.org", nonce="", integrity-protected=auth-done, uri="sip: ics.mnc015.mcc234.3gppnetwork.org", response=""

CSeq: 1 REGISTER

Supported: gruu

Require: path

Content-Length: 0

Contact: The header field contains:

– g.3gpp.icsi-ref media feature tag with value of ICSI of IMS multimedia telephony communication service;

– g.3gpp.ics media feature tag with value indicating that the resource is a network node which is ICS capable;

– g.3gpp.cs2ps-srvcc indicating support for CS to PS SRVCC; and

– g.3gpp.path media feature tag with value containing the MSC URI for terminating requests;

5-6. SIP 200 (OK) response (S-CSCF to MSC server enhanced for ICS)

The S-CSCF sends a SIP 200 (OK) response to the MSC server enhanced for ICS.

7. SIP REGISTER request (S-CSCF to SCC AS)

The S-CSCF sends a third party SIP REGISTER request containing in the body the incoming SIP REGISTER request from the PN UE and the SIP 200 (OK) response to the incoming REGISTER request to the SCC AS.

8. SIP 200 (OK) response (SCC AS to S-CSCF)

The SCC AS sends a SIP 200 (OK) response to the S-CSCF indicating the third party SIP REGISTER was successful.

A.3.6 Signalling flows for UE attaching to CS domain when MSC server is enhanced for ICS and for CS to PS SRVCC and when UE is already registered with IMS in PS access network

The signalling flow shown at figure A.3.6-1 describes the scenario of UE attaching to CS domain when MSC server is enhanced for ICS after the UE has already registered with IMS in PS access network. The scenario expects that UE, MSC server enhanced for ICS, ATCF and SCC AS are enhanced for CS to PS SRVCC.

Figure A.3.6-1 registration with SRVCC enhancements

1. SC UE attempts to registers with IMS in PS access network. The signalling flow described in subclause A.3.4 is performed.

2. SC UE attempts to attach to CS domain. MSC server enhanced for ICS registers with IMS without knowing the STN-SR of the ATCF selected during the registration of UE with IMS using PS domain. The signalling flow described in subclause A.3.5 is performed.

3.-4. SIP MESSAGE request with CS to PS SRVCC information (SCC AS to MSC server) – see example in table A.3.6-3

The SCC AS detects that the UE has a registration path over a PS domain where ATCF is included and therefore the SCC AS provides information about the registration path of the UE over a PS domain to the MSC server.

Table A.3.6-3: SIP MESSAGE request (SCC AS towards MSC server)

MESSAGE sip:msc123.visited2.net SIP/2.0

Via: SIP/2.0/UDP sccas1.home1.net:5060;branch=z9hG4bKnas588339

Max-Forwards: 70

From: <sip:sccas1.home1.net>;tag=aassd

To: sip:msc123.visited2.net

Call-ID: sdvasdfgfasdfsdfwefw

CSeq: 44561 MESSAGE

Content-Length: …

P-Asserted-Identity: sip:sccas1.home1.net

Accept-Contact: *;g.3gpp.path="<sip:termpdfjkghlj@msc123.visited2.net;lr>";explicit;require

Content-Type: application/vnd.3gpp.srvcc-ext+xml

<?xml version="1.0"?>

<srvcc-ext>

<PS-reg-info Path="sip:termpdfjkghlj@msc123.visited2.net;lr">

<ATCF-Management-URI>sip:atcf.visited2.net</ATCF-Management-URI>

<C-MSISDN>tel:+1-237-555-1111</C-MSISDN>

<cs2ps-srvcc-alerting>true</cs2ps-srvcc-alerting>

</PS-reg-info>

</srvcc-ext>

Request-URI: public user identity registered by the MSC server as provided in the step 2

P-Asserted-Identity: SCC AS URI

Accept-Contact: g.3gpp.path media feature tag containing the MSC URI for terminating requests provided in the SIP REGISTER request in the step 2.

body: CS to PS SRVCC information informing the MSC server about the ATCF used in the registration path of the UE over a PS domain. Path attribute contains the MSC URI for terminating requests provided in the SIP REGISTER request in the step 2. ATCF-Management-URI element contains the ATCF management URI of the ATCF, the C-MSISDN element contains the C-MSISDN of the UE, and the cs2ps-srvcc-alerting element shows the support of CS to PS SRVCC in alerting phase.

5.-6. SIP 200 (OK) response (MSC server to SCC AS)

The MSC server generates the SIP 200 (OK) response to the SIP MESSAGE request.