A.7 Signalling flows for PS-PS access transfer

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

The signalling flows for PS-PS access transfer demonstrate how a multimedia session is transferred from Source Access Leg to the Target Access Leg. The following signalling flows are included:

– subclause A.7.2 shows an example when all media of an ongoing communication session and the associated signalling are transferred from Source Access Leg to the Target Access Leg; and

– subclause A.7.3 shows an example when not all media of an ongoing communication session are transferred from the Source Access Leg to the Target Access Leg.

A.7.2 PS-PS access transfer with full media transfer

The signalling flows shown in figure A.7.2-1 describes the PS-PS access transfer procedure when all media of an ongoing communication session and the associated signalling are transferred from one contact address of an UE to a different contact address of the same UE. No lower-level mechanism to support the access transfer is assumed or needed.

In this example the UE-1 is on an active multimedia session with the UE-2 via one IP-CAN. After changing to a new IP‑CAN, obtaining a new IP address, and discovering a P-CSCF, the UE-1 reserves resources in new IP-CAN prior to initiating the PS-PS access transfer procedure. When the PS-PS access transfer procedure is completed, the UE-1 continues the multimedia session with the UE-2 on the new IP-CAN. In this example, when attaching to the new IP-CAN, it is irrelevant whether the UE-1 uses the same P-CSCF or a new P-CSCF.

NOTE 1: This scenario requires that the UE-1 and the IM CN subsystem support simultaneous multiple registrations and requires that the UE-1 supports dual mode operation.

NOTE 2: In this example flow, each call leg is uniquely identified with a respective dialog identifier consisting of the Call-ID, From tag, and To tag.

Figure A.7.2-1: Signalling flow for session handover

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

1. UE–1 is on an active session with UE–2

The UE-1 is in an active session with the UE-2. The call is anchored in the SCC AS. It is irrelevant which endpoint initiated the call. Each call leg is uniquely identified with a respective dialog identifier. The call leg over old IP-CAN is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To tag=774321". The UE-1 and UE-2 exchange media over the old IP-CAN, which is maintained while the UE-1 initiates the handover procedure.

2. UE-1 connects to new IP–CAN

The UE-1 determines that a handover of the session is required. The UE-1 connects to the new IP-CAN. The UE-1 obtains an IP address that it will use for the signalling and media.

3. UE-1 registers with intermediate IM CN subsystem entities over new IP-CAN

The UE-1 registers with the S-CSCF over the new IP-CAN using the standard multiple registrations procedure. Depending on the UE-1 configuration, the discovery of the P-CSCF in the new IP-CAN can precede this.

4. UE-1 acquires resources in new IP-CAN

Based on the UE-1 and new IP-CAN capabilities, the UE-1 decides to use the same codec that was used over the old IP-CAN. The UE-1 reserves resources (e.g. QoS) in the new IP-CAN that will be needed for the signalling and transferred media, prior to sending the initial SIP INVITE request.

5. SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) – see example in table A.7.2-5

The UE-1 sends an initial SIP INVITE request with the PS to PS STI and a new SDP offer to the UE-2 that indicates that the new call replaces the existing call. The initial SIP INVITE request establishes a dialog for signalling and specifies in the SDP the new contact address that will be used for media over the new IP-CAN. Upon sending the initial SIP INVITE request, the UE-1 is ready to receive the RTP packets either over the new IP-CAN or the old IP-CAN. The RTP packets can arrive over the new IP-CAN prior to the UE-1 receiving the SIP 200 (OK) response for the initial SIP INVITE request.

Table A.7.2-5: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities)

INVITE sip:pstops.transfer@sccas1.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:orig@scscf1.home1.net;lr>

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

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

Privacy: none

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

To: <sip:pstops.transfer@sccas1.home1.net>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu, outbound

Require: sec-agree; replaces

Replaces: me03a0s09a2sdfgjkl491777; to-tag=774321; from-tag=64727891

Proxy-Require: sec-agree

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port1=7531

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

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

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

Content-Type: application/sdp

Content-Length: (…)

v=0

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

s=-

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

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

a=maxptime:20

Request-URI: the PS to PS STI configured in the SC UE or the URI contained in the Contact header field returned at the creation of the dialog on the Source Access Leg.

Require: the "replaces" option tag indicate that the support for Replace header field is required.

Replaces: specifies the existing call that will be replaced with the new call.

SDP: specifies the new IP address that the UE-1 has acquired in the new IP-CAN, and indicates that the resources in the new IP-CAN have been acquired.

6. Evaluation of initial filter criteria

Upon the evaluation of the initial filter criteria, as this is an originating initial SIP INVITE request for a registered user, the S-CSCF routes the initial SIP INVITE request to the SCC AS.

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

The initial SIP INVITE request is forwarded from intermediate IM CN subsystem entities in the home network to the SCC AS. The P-CSCF added a Record-Route header field with a flow token to ensure that mid-dialog SIP requests are forwarded to the UE-1 over the correct flow. The SCC AS acts as a routeing B2BUA as specified in 3GPP TS 24.229 [2]. The SCC AS includes the contents of the Contact header field from the received SIP INVITE request.

Table A.7.2-7: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS)

INVITE sip:pstops.transfer@sccas1.home1.net SIP/2.0

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

Max-Forwards: 67

Route: <sip:sccas.home1.net;lr>; <sip:cb03a0s09a2sdfglkj490333@scscf1.home1.net;lr>;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"

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

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>, <tel:+1-212-555-1111>

P-Access-Network-Info:Privacy:Require: replaces

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

P-Charging-Function-Addresses: ####

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

To: <sip:pstops.transfer@sccas1.home1.net >

Call-ID:

Cseq:

Supported:

Replaces:

Contact:

Allow:

Accept:

Content-Type:

Content-Length: (…)

P-Early-Media: supported

t=0 0

8. Remote leg update

The SCC AS based on the content of the Replaces header field correlates the initial SIP INVITE request to the existing local and remote call legs of the existing concatenated end to end session between the UE-1 and UE-2. The SCC AS updates the remote call leg by sending a SIP re-INVITE request to the UE-2 containing the new SDP offer that it has received from the UE-1.

9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) – see example in table A.7.2-9

The UE-2 is informed of the change in access leg by the SCC AS sending a SIP re-INVITE request to the S-CSCF.

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from the UE-1 (Step 5).

Table A.7.2-9: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)

INVITE < sip:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74> SIP/2.0

Via: SIP/2.0/UDP sccas.home1.net; branch=z9hG4bK332b33.3;

Max-Forwards: 67

Route: <scscf1.home1.net;lr>,<sip:scscf2.home2.net;lr>,<sip:pcscf2.visited2.net;lr>

P-Asserted-Identity:P-Access-Network-Info:Privacy:P-Charging-Vector: icid-value="BzyretyU0dm+6O2IrT5tAFrbHLso=023551034 "

P-Charging-Function-Addresses:

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

To: <tel:+1-212-555-2222>, tag=4321

Call-ID: dc14b1t10b3teghmlk5013333

Cseq: 111 INVITE

Supported:

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

Allow:

Accept: application/sdp

Content-Type:

Content-Length: (…)

v=0

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

s=-

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

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a= curr:qos local sendrecv

a= curr:qos remote none

a= des:qos mandatory local sendrecv

a= des:qos none remote sendrecv

a= rtpmap:97 AMR

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

a= rtpmap:96 telephone-event

a= maxptime:20

Route: The SIP re-INVITE request contains the saved list of Route header fields that the SCC AS has saved for the remote leg of the call.

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

In the originating network, the intermediate IM CN subsystem entities forward the SIP re-INVITE request to the intermediate IM CN subsystem entities in the terminating network.

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

INVITE < sip:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74> SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP sccas.home1.net; branch=z9hG4bK332b33.3;

Max-Forwards: 66

Route: <sip:scscf2.home2.net;lr>, <sip:pcscf2.visited2.net;lr>

P-Asserted-Identity:

Privacy: none

From:

To:

Call-ID:

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

Contact:

Allow:

Accept:

Content-TypeContent-Length:

s=-

11. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-2)

In the terminating network, the SIP re-INVITE request is forwarded towards the UE-2 by the intermediate IM CN subsystem entities.

12. Media paths between UE-1 and UE-2

The UE-2 receives the SIP re-INVITE request containing the SDP offer that indicates that the UE-1 is ready to receive the same media on a different contact address. Since the UE-2 has resources already available, it starts to send the media to the UE-1’s contact address specified in the SDP offer immediately.

The UE-1 will be receiving the RTP packets over new IP-CAN. However, the UE-1 can receive some out-of-sequence RTP packets over the old IP-CAN. The RTP packets are delivered to the codec in sequence. Once the UE-1 determine that no media will be received over the old IP-CAN (e.g. by examining the sequence numbers in the RTP headers), it can relinquish the resources that it has been using for incoming media on the old IP-CAN.

The UE-1 sends the media to the UE-2 over the old IP-CAN.

Resources used for signalling on the old IP-CAN are not released.

13. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities)

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE-2 has all resources available, it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The SDP answer indicates that the resources are available.

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

In the terminating network, the intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to the intermediate IM CN subsystem entities in the originating network.

15. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS)

The intermediate IM CN subsystem entities in the originating network forward the SIP 200 (OK) response to the SIP re-INVITE request to the SCC AS.

16. SIP ACK request (SCC AS to intermediate IM CN subsystem entities)

The SCC AS acting as a B2BUA acknowledges the receipt of the SIP 200 (OK) response to the SIP re-INVITE request by forwards a SIP ACK request to the intermediate IM CN subsystem entities.

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

In the originating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the intermediate IM CN subsystem entities in the terminating network.

18. SIP ACK request (intermediate IM CN subsystem entities to UE-2)

In the terminating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the UE-2.

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

The SCC AS forwards the SIP 200 (OK) response to the initial SIP INVITE request to the intermediate IM CN subsystem entities, using the content of the Via header field that was received in the initial SIP INVITE request (step 5).

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID header fields from one side of the B2BUA to the other. The SIP 200 (OK) response to the initial SIP INVITE request contains the SDP answer that is identical to the SDP answer that the SCC AS has received in the SIP 200 (OK) response to SIP re-INVITE request from the UE-2 (Step 13).

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

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

21. Media paths between UE-1 and UE-2

The UE-1 receives the SIP 200 (OK) response containing the SDP answer that indicates that the UE-2 is ready to receive media. Since the UE-1 has already resources available, it starts to send media over new IP-CAN to the UE-2’s contact address specified in the SDP answer immediately.

The UE-1 can relinquish the resources that it has been using for outgoing media on the old IP-CAN.

Resources used for signalling on the old IP-CAN are not released.

22. SIP ACK request (UE-1 to intermediate IM CN subsystem entities)

The UE-1 completes the new call leg creation with a SIP ACK request sent to the intermediate IM CN subsystem entities.

23. SIP ACK request (-intermediate IM CN subsystem entities to SCC AS)

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

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

The SCC AS terminates the replaced call leg- that was using the old IP-CAN, by sending a SIP BYE request to the UE-1.

25. SIP BYE request (intermediate IM CN subsystem entities to UE-1)

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

26. SIP 200 (OK) response (UE-1 to intermediate IM CN subsystem entities)

Upon receiving the SIP BYE request over the old IP-CAN, the UE-1 sends a SIP 200 (OK) response over the old IP-CAN. Subsequently, the UE-1 relinquishes all resources pertaining to the old IP-CAN.

27. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS)

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

Since both the old contact address and the new contact address were registered using multiple registrations procedure with different reg-id values, then upon transferring the dialog from the old contact address to the new contact address, the UE-1 is still registered with the old contact address and the UE-1 subscription dialog to its reg-event using the old contact address is intact.

A.7.3 PS-PS access transfer with partial media transfer

The signalling flows shown in figure A.7.3-1 describes the PS-PS access transfer procedure when not all media of an ongoing communication session are transferred from the Source Access Leg to the Target Access Leg. No lower-level mechanism to support the access transfer is assumed or needed.

In this example, UE‑1 is on an active multimedia session with UE‑2 via one IP‑CAN. After connecting to an additional IP‑CAN, obtaining an additional IP address, discovering a P-CSCF, and performing registration in the IM CN subsystem, UE-1 reserves resources in the new IP‑CAN prior to initiating the PS-PS access transfer procedure. When the PS-PS access transfer procedure is completed, UE‑1 continues the multimedia session with UE‑2 on both the old and the new IP‑CANs. In this example, when attaching to the new IP‑CAN, it is irrelevant whether the UE‑1 uses the same P‑CSCF or a new P‑CSCF.

NOTE 1: This scenario requires that UE-1 and the IM CN subsystem support simultaneous multiple registrations and requires that UE-1 supports dual mode operation.

Figure A.7.3-1: Signalling flow for PS-PS session transfer with partial media transfer

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

1. UE‑1 is on an active session with UE‑2

UE-1 is in an active session with UE-2. The call is anchored in the SCC AS. It is irrelevant which endpoint initiated the call. Each call leg is uniquely identified with a respective dialog identifier. The call leg over IP-CAN #1 is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To tag=774321". UE-1 and UE-2 exchange media over the IP-CAN #1, which is maintained while the UE-1 initiates the session transfer procedure.

2. UE‑1 connects to IP-CAN #2

UE-1 connects to the new IP-CAN and obtains an IP address that it will use for the signalling and media.

3. UE‑1 registers with intermediate IM CN subsystem entities over IP-CAN #2

UE-1 registers with the S-CSCF over the IP-CAN #2 using the standard multiple registrations procedure. The P-CSCF in the signalling path of this registration can be distinct from the one used in the signalling path over IP-CAN #1.

4. UE‑1 acquires resources in IP-CAN #2

UE-1 decides to perform partial media transfer to the IP-CAN #2. Based on UE-1 and IP-CAN #2 capabilities, the UE-1 decides to use the same codec that was used over the IP-CAN #1 for the media components to be transferred. UE-1 ensures that the resources (e.g. QoS) in IP-CAN #2 that will be needed for the signalling and transferred media are available, prior to sending the initial SIP INVITE request.

5. SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) – see example in table A.7.3-5

UE‑1 sends initial SIP INVITE request with the PS to PS STI and a new SDP offer to UE‑2 and indicates that the video component is to be transferred to IP-CAN #2. The initial SIP INVITE request establishes a dialog for signalling and specifies in the SDP new contact address that will be used for media over IP-CAN #2. Upon sending the initial SIP INVITE request, UE-1 is ready to receive the RTP packets over both IP-CAN #1 and IP-CAN #2.

Table A.7.3-5: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities)

INVITE sip:pstops.transfer@sccas1.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:orig@scscf1.home1.net;lr>

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

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

Privacy: none

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

To: <sip:pstops.transfer@sccas1.home1.net>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu, outbound

Require: sec-agree; tdialog

Target-Dialog: me03a0s09a2sdfgjkl491777; remote-tag=774321; local-tag=64727891

Proxy-Require: sec-agree

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port1=7531

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

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

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

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 0 RTP/AVP 97 96

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

m=video 3400 RTP/AVP 98 99

b=AS:75

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

Request-URI: the PS to PS STI configured in the SC UE or the URI contained in the Contact header field returned at the creation of the dialog on the Source Access Leg .

Require: the "tdialog" option tag indicate that the support for Target-Dialog header field is required.

Target-Dialog: specifies the existing call that will be transferred.

SDP: specifies the new IP address that the UE-1 has acquired in the new IP-CAN, and indicates that only the video component will be transferred and the resources in the new IP-CAN have been reserved.

6. Evaluation of initial filter criteria

Upon the evaluation of the initial filter criteria, as this is an originating initial SIP INVITE request for a registered user, the S-CSCF routes the initial SIP INVITE request to the SCC AS.

7. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS)

The initial SIP INVITE request is forwarded from intermediate IM CN subsystem entities in the home network to the SCC AS. The P-CSCF added a Record-Route header with a flow token to ensure that mid-dialog SIP requests are forwarded to the UE-1 over the correct flow. The SCC AS acts as a routeing B2BUA as specified in 3GPP TS 24.229 [2].

8. Remote leg update

Based on the content of the Target-Dialog header field, the SCC AS correlates the SIP INVITE request for session transfer to the existing local and remote call legs of the existing concatenated end to end session between UE-1 and UE-2. The SCC AS updates the remote call leg by sending a SIP re-INVITE request to the remote UE-2 containing the new SDP offer based on the partial media transfer request received from UE-1 and the negotiated SDP for the original session.

9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) – see example in table A.7.3-9

UE-2 is informed of the change in access leg by the SCC AS sending a re-INVITE request to the S-CSCF.

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE request contains the SDP offer that is based on original SDP offer and the SDP offer that the SCC AS received in the initial SIP INVITE request from the UE-1 (Step 7).

Table A.7.3-9: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)

INVITE < sip:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74> SIP/2.0>

Via: SIP/2.0/UDP sccas.home1.net; branch=z9hG4bK332b33.3;

Max-Forwards: 70

Route: <scscf1.home1.net;lr>, <sip:scscf2.home2.net;lr>, <sip:pcscf2.visited2.net;lr>

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>, <tel:+1-212-555-1111>

Privacy: none

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

P-Charging-Function-Addresses:

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

To: <tel:+1-212-555-2222>, tag=4321

Call-ID: dc14b1t10b3teghmlk5013333

Cseq: 111 INVITE

Supported: precondition, 100rel

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

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

Accept: application/sdp

Content-Type: application/sdp

Content-Length: (…)

v=0

o=2987933100 2987933101 IN IP6 5555::aaa:bbb:ccc:eee

s=-

t=0 0

m=audio 3456 RTP/AVP 97 96

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

b=AS:25.4

a= curr:qos local sendrecv

a= curr:qos remote none

a= des:qos mandatory local sendrecv

a= des:qos none remote sendrecv

a= rtpmap:97 AMR

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

a= rtpmap:96 telephone-event

a= maxptime:20

m=video 3400 RTP/AVP 98 99

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

b=AS:75

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

Route: The SIP re-INVITE request contains the saved list of Route header fields that the SCC AS has saved for the remote leg of the call.

SDP: specifies the new IP address and ports used for the media components. In this case, the audio component is still using the original address and port while the video component is using the new IP address and new port allocated.

10. SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities)

In the originating network, the intermediate IM CN subsystem entities forward the SIP re-INVITE request to the intermediate IM CN subsystem entities in the terminating network.

11. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-2)

In the terminating network, the SIP re-INVITE request is forwarded towards UE-2 by the intermediate IM CN subsystem entities.

UE-2 receives the SIP re-INVITE request containing the SDP offer that indicates that UE-1 is ready to receive video media on a different contact address. Since UE-2 has resources already available, it starts to send the media to UE-1’s contact address specified in the SDP offer immediately.

UE-1 starts receiving the video RTP packets over IP-CAN #2. However, UE-1 can receive some out-of-sequence video RTP packets over IP-CAN #1. The video RTP packets are delivered to the codec in sequence. Once UE-1 determine that no video will be received over IP-CAN #1 (e.g. by examining the sequence numbers in the RTP headers), it can relinquish the resources that it has been using for incoming video media on IP-CAN #1.

At the same time, UE-1 still sends both the audio and video media to UE-2 over IP-CAN #1.

Resources used for signalling on IP-CAN #1 are not released.

12. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) – see example in table A.7.3-12

Upon receiving the SIP re-INVITE request containing the SDP offer, since UE-2 has all resources available, it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The SDP answer indicates that the resources are available.

Table A.7.3-12: SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK361k21.1,

SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1,

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

SIP/2.0/UDP sccas.home1.net;branch=z9hG4bK332b33.3

Record-Route: <sip:pcscf2.visited2.net:5088;lr;comp=sigcomp>, <sip:scscf2.home2.net;lr>, <sip:scscf1.home1.net;lr>

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

Privacy: none

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

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

Call-ID: dc14b1t10b3teghmlk5013333

CSeq: 111 INVITE

Supported: precondition, 100rel

Contact: <sip:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74>;+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=- 2987933623 2987933624 IN IP6 5555::eee:fff:aaa:bbb

s=-

c=IN IP6 5555::eee:fff:aaa:bbb

t=0 0

m=audio 6544 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote sendrecv

a=des:qos mandatory local sendrecv

a=des:qos mandatory 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

m=video 10001 RTP/AVP 98 99

b=AS:75

a=curr:qos local sendrecv

a=curr:qos remote sendrecv

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

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

14. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS)

The intermediate IM CN subsystem entities in the originating network forward the SIP 200 (OK) response to the SIP re-INVITE request to the SCC AS.

15. SIP ACK request (SCC AS to intermediate IM CN subsystem entities)

The SCC AS acting as a B2BUA acknowledges the receipt of the SIP 200 (OK) response to the SIP re-INVITE request by forwards a SIP ACK request to the intermediate IM CN subsystem entities.

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

In the originating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the intermediate IM CN subsystem entities in the terminating network.

17. SIP ACK request (intermediate IM CN subsystem entities to UE-2)

In the terminating network, the intermediate IM CN subsystem entities forward the SIP ACK request to UE-2.

18. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) – see example in table A.7.3-18

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS includes the contents of the Contact header field from the received SIP 200 (OK) response. The SIP 200 (OK) response to the initial SIP INVITE request contains the SDP answer derived from the SDP answer that the SCC AS has received in the SIP 200 (OK) response to SIP re-INVITE request from UE-2 (Step 14).

Table A.7.3-18: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities)

SIP/2.0 200 OK

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

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

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

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

Privacy: none

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

To: <sip:pstops.transfer@sccas1.home1.net>;tag=8009

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu, outbound

Contact: < sip:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

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

Accept: application/sdp

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933300 2987933300 IN IP6 5555::eee:fff:aaa:bbb

s=-

c=IN IP6 5555::eee:fff:aaa:bbb

t=0 0

m=audio 0 RTP/AVP 97 96

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

m=video 10001 RTP/AVP 98 99

b=AS:75

a=curr:qos local sendrecv

a=curr:qos remote sendrecv

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

19. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1)

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

UE-1 receives the SIP 200 (OK) response containing the SDP answer indicating that UE-2 is ready to receive media. Since UE-1 has already resources available, it starts to send video media over IP-CAN #2 to UE-2’s contact address specified in the SDP answer immediately.

The UE-1 can relinquish the resources that it has been using for outgoing video media on IP-CAN #1.

Resources used for signalling and audio media on IP-CAN #1 are not released.

20. SIP ACK request (UE-1 to intermediate IM CN subsystem entities)

UE-1 completes the new call leg creation with a SIP ACK request sent to the intermediate IM CN subsystem entities.

21. SIP ACK request ( intermediate IM CN subsystem entities to SCC AS)

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

22. SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) – see example in table A.7.3-22

UE-1 updates the old call leg on IP-CAN #1 by sending a SIP re-INVITE request to the intermediate IM CN subsystem entities.

Table A.7.3-22: SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities)

INVITE <sip:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74> SIP/2.0

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

Max-Forwards: 70

Route: sip:XopDDDsn0oFFFXRdV9BAXpT3coNuiGKV@pcscf1.home1.net:8765;lr;comp=sigcomp>, <sip:orig@scscf1.home1.net;lr>

P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=123456ABCDE22

Privacy: none

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

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

Call-ID: me03a0s09a2sdfgjkl491777

Cseq: 101 INVITE

Supported: 100rel; precondition; tdialog

Require: sec-agree;

Proxy-Require: sec-agree

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=12345678; port1=2468

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

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

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

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933000 2987933001 IN IP6 5555::aaa:bbb:ccc:eee

s=-

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

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

m=video 0 RTP/AVP 98 99

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

23. SIP re-INVITE request (intermediate IM CN subsystem entities to SCC AS)

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the SCC AS.

24. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) – see example in table A.7.3-24

The SCC AS updates the old call leg based on the SIP re-INVITE request and sends the SIP 200 (OK) response to the SIP re-INVITE request to the intermediate IM CN subsystem entities, using the content of the Via header field that was received in the SIP re-INVITE request (step 23). In this example the SCC AS includes the contents of the Contact header field from the received SIP 200 (OK) response. The SIP 200 (OK) response to the SIP re-INVITE request contains the SDP answer derived from the SDP answer that the SCC AS previously received from UE-2 (Step 14).

Table A.7.3-24: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK345b32.2,

SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK568f35.1,

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

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

Privacy: none

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

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

Call-ID: me03a0s09a2sdfgjkl491777

Cseq: 101 INVITE

Supported: 100rel; precondition

Contact: < sip:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

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

Accept: application/sdp

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933800 2987933801 IN IP6 5555::eee:fff:aaa:bbb

s=-

c=IN IP6 5555::eee:fff:aaa:bbb

t=0 0

m=audio 6544 RTP/AVP 97 96

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

m=video 0 RTP/AVP 98 99

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

25. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1)

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

26. SIP ACK request (UE-1 to intermediate IM CN subsystem entities)

UE-1 completes the old call leg update with a SIP ACK request sent to the intermediate IM CN subsystem entities.

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

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

A.7.4 PS-PS Access Transfer with full media transfer for an outgoing call in alerting phase

The signalling flows shown in figure A.7.4-1 describes the PS-to-PS access transfer procedure when an early dialog originated by the SC UE A, is transferred from one contact address of a SC UE A (using an old IP-CAN) to a different contact address of the same SC UE A (using a different IP-CAN). In this example flow, the SC UE A is attached to old IP‑CAN, and is in the process of establishing a dialog on its Source Access Leg via this IP‑CAN, with the UE B. While the dialog on the Source Access Leg is in the alerting phase, the SC UE A decides (e.g. based on the measurement reports) to transfer this dialog to the Target Access Leg that will be established over the new IP‑CAN. Both, the SCC AS and the SC UA A support the PS-to-PS access transfer for the dialogs in early dialog phase.

NOTE 1: This scenario requires that the SC UE A supports dual mode operation and multiple registration procedure.

NOTE 2: In this example flow, each call leg is uniquely identified with a respective dialog identifier consisting of the Call-ID, From tag, and To tag.

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

Figure A.7.4-1: Signalling flow for an outgoing call in the alert phase

1. SC UE A has sent an INVITE request and subsequently has received a SIP 180 (Ringing) response and it is ringing

The SC UE A initiated call toward the UE B by sending an initial SIP INVITE request on the Source Access Leg, and subsequently it has received a SIP 180 (Ringing) response, and it is providing ring-back. The call has been anchored at the SCC AS of the SC UE A.

The dialog on the Source Access Leg is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To tag=774321".

2. SC UE A attaches to different IP-CAN

The SC UE A determines that a handover of the dialog on the Source Access Leg to a Target Access Leg is required while this dialog is in the alerting phase. The SC UE A connects to different IP-CAN and obtains a new IP address that it will use for the subsequent signalling and media. The SC UE A registers with the S-CSCF over the new IP-CAN using the standard multiple registration procedure. If needed, prior to sending the initial SIP INVITE request over the new IP-CAN, the SC UE A reserves resources in the new IP-CAN that will be needed for the signalling and the media.

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) – see example in table A.7.5-3

The SC UE A sends an initial SIP INVITE request over the new IP-CAN with a new SDP offer to the UE B that indicates that the new dialog on the Target Access Leg will replace the existing dialog on the Source Access Leg. The SDP offer in the initial SIP INVITE request sent on the Target Access Leg specifies the new contact address on the new IP-CAN that will be used for the media.

Table A.7.5-3: SIP INVITE request (SC UE A to intermediate IM CN subsystem entities)

INVITE tel:+1-212-555-2222 SIP/2.0

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

Max-Forwards: 70

Route: <sip:pcscf1.home1.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:IEEE-802.11b

Privacy: none

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu, outbound

Require: sec-agree; replaces

Replaces: me03a0s09a2sdfgjkl491777; to-tag=774321; from-tag=64727891

Proxy-Require: sec-agree

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port1=7531

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

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

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

Content-Type: application/sdp

Content-Length: (…)

v=0

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

s=-

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

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

a=maxptime:20

Request-URI: the tel-URI of the destination, i.e. the UE-B.

Require: the "replaces" option tag indicate that the support for Replace header field is required.

Replaces: identifies the dialog on the Source Access that will be replaced with the new dialog on the Target Access Leg.

SDP: specifies the new IP address for media that the SC UE A has acquired in the new IP-CAN, and also indicates that the resources in the new IP-CAN have been acquired.

4. SIP INVITE request transferring the session (intermediate IM CN subsystem entities to SCC AS)

Based on the initial filter criteria in the S-CSCF, the initial SIP INVITE request is routed towards the SCC AS.

4a Remote Leg Update

The SCC AS correlates the initial SIP INVITE request received on the Target Access Leg to the dialog on the Source Access Leg and to the remote call leg. The SCC AS acting as a B2BUA generates a SIP UPDATE request, based on the information in the initial SIP INVITE request received on the Target Access Leg, and the information previously stored against these dialogs. The SIP UPDATE request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from the SC UE A on the Target Access Leg.

5. SIP UPDATE request (SCC AS to intermediate IM CN subsystem entities)

The SCC AS performs the remote call leg update by sending the SIP UPDATE request towards the UE B.

6. SIP UPDATE request (Intermediate IM CN subsystem entities to UE B)

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

7. SIP 200 (OK) response (UE B to Intermediate IM CN subsystem entities)

Upon receiving the SIP UPDATE request containing the SDP offer, the remote UE B sends a SIP 200 (OK) response. The SIP 200 (OK) response contains the SDP answer. The SDP answer indicates that the resources are available.

8. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS)

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

9. SIP 183 (Session Progress) response (SCC AS to Intermediate IM CN subsystem entities)

The SCC AS sends a 183 (Session Progress) response on the Target Access Leg that contains the SDP answer as received from the remote UE B. The SDP answer indicates that the resources at the UE B are available.

10. SIP 183 (Session Progress) response (Intermediate IM CN subsystem entities to SC UE A)

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

11. SIP PRACK request (SC UE A to Intermediate IM CN subsystem entities)

The SC UE A acknowledges the receipt of the 183 Session Progress response.

12. SIP PRACK request (Intermediate IM CN subsystem entities to SCC AS)

The intermediate IM CN subsystem entities forward the SIP PRACK request to the SCC AS.

13. SIP 200 (OK) response (SCC AS to Intermediate IM CN subsystem entities)

The SCC AS acknowledges the receipt of the SIP PRACK request.

14. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SC UE A)

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SC UE A. Upon successful exchange of the SIP 183 (Session Progress) response and the SIP PRACK request on the Target Access Leg, the early dialog and associated media has been transferred from the Source Access Leg to the Target Access Leg. Since the resources for media on the Source Access Leg are not used any more, the SC UE A releases the resources that the SC UE A was using for media on the Source Access Leg. In spite of releasing the resources, the early dialog on the Source Access Leg is still in the alerting phase.

NOTE 4: For clarity, the exchange of the SIP messages and associated SDPs on the Source Access Leg, to release the resources that the SC UE A was using for media on the Source Access Leg, is not shown in the signalling flow.

15. Remote user answers the call

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

The UE B accepts the call and sends a SIP 200 (OK) response to the initial INVITE request received from the SC UE A..

17. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS)

The SIP 200 (OK) response is forwarded to the SCC AS.

18. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities)

The SCC AS acting as a B2BUA generates the SIP 200 (OK) response to initial SIP INVITE request that it has received on the Target Access Leg , that indicate that the remote UE B has accepted the call.

19. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SC UE A)

The SIP 200 (OK) response is forwarded to the SC UE A.

20. SIP ACK request (SC UE A to intermediate IM CN subsystem entities)

The SC UE A acknowledges the SIP 200 (OK) response received from the SCC AS

21. SIP ACK request (Intermediate IM CN subsystem entities to SCC AS)

The SIP ACK request is forwarded to the SCC AS.

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

The SCC AS acknowledges the SIP 200 (OK) response received from the UE B.

23 SIP ACK request (Intermediate IM CN subsystem entities to UE B)

The SIP ACK request is forwarded towards the UE B.

24-31 SIP CANCEL Processing

The SC UE A cancels the SIP INVITE request sent on the Source Access Leg towards the SCC AS.

A.7.5 PS-PS Access Transfer with full media transfer for an incoming call in alerting phase

The signalling flows shown in the figure A.7.5-1 describes the PS-to-PS access transfer procedure when an incoming dialog that is in alerting phase is transferred from one contact address of the SC UE A (using the old IP-CAN) to a different contact address of the same SC UE A (using a different IP-CAN). In this example flow the SC UE A has an incoming dialog which is anchored at the SCC AS. While the dialog on the Source Access Leg (using the old IP-CAN) is in the alerting phase, the SC UE A decides (e.g. based on the measurement reports) to transfer this dialog to the Target Access Leg that will be established over the new IP‑CAN. The the SCC AS and SC UA A support the PS-to-PS access transfer for the dialogs in early dialog phase.

NOTE 1: This scenario requires that the SC UE A supports dual mode operation and multiple registration procedure.

NOTE 2: In this example flow, each call leg is uniquely identified with a respective dialog identifier consisting of the Call-ID, From tag, and To tag.

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

Figure A.7.5-1: Signalling flow for an incoming dialog in the alert phase

1. SC UE A has received an incoming call and is in Ringing State

The incoming call has been anchored at the SCC AS of the SC UE A. If needed, both ends have reserved the resources, and the SC UE A has sent a SIP 180 (Ringing) response to the initial SIP INVITE request received on the Source Access Leg.

The dialog on the Source Access Leg is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To tag=774321".

2. SC UE A attaches to different IP–CAN

The SC UE A determines that a handover of the dialog on the Source Access Leg to a Target Access Leg is required while this dialog is in the alerting phase. The SC UE A connects to different IP-CAN and obtains new IP address that it will use for the subsequent signalling and media. The SC UE A registers with the S-CSCF over the new IP-CAN using the standard multiple registration procedure. If needed, prior to sending the initial SIP INVITE request over the new IP-CAN, the SC UE A reserves resources in the new IP-CAN that will be needed for the signalling and media.

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) – see example in table A.7.5-3

The SC UE A sends an initial SIP INVITE request on the Target Access Leg with a new SDP offer toward the UE B and indicates that the new dialog on the Target Access Leg will replace the existing early dialog on the Source Access Leg. The SDP offer in the initial SIP INVITE request sent on the Target Access Leg specifies the new contact address that will be used for the media over the new IP-CAN.

Table A.7.5-3: SIP INVITE request (SC UE A to intermediate IM CN subsystem entities)

INVITE tel:+1-212-555-2222 SIP/2.0

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

Max-Forwards: 70

Route: <sip:pcscf1.home1.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:IEEE-802.11b

Privacy: none

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu, outbound

Require: sec-agree; replaces

Replaces: me03a0s09a2sdfgjkl491777; to-tag=774321; from-tag=64727891

Proxy-Require: sec-agree

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port1=7531

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

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

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

Content-Type: application/sdp

Content-Length: (…)

v=0

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

s=-

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

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

a=maxptime:20

Request-URI: the tel-URI of the destination, i.e. the UE-B.

Require: the "replaces" option tag indicate that the support for Replace header field is required.

Replaces: that identifies the dialog on the Source Access Leg that will be replaced with the new dialog on the Target Access Leg.

SDP: specifies the new IP address for media that the SC UE A has acquired in the new IP-CAN, and also indicates that the resources in the new IP-CAN have been acquired.

4. SIP INVITE request transferring the session (intermediate IM CN subsystem entities to SCC AS)

Based on the initial filter criteria in the S-CSCF, the initial SIP INVITE request is routed towards the SCC AS.

4a. Remote Leg Update

The SCC AS correlates the initial SIP INVITE request received on the Target Access Leg to the dialog on the Source Access Leg, and to the remote call leg. The SCC AS acting as a B2BUA generates a SIP UPDATE request, based on the information received in the initial SIP INVITE request on the Target Access Leg, and the information previously stored against these dialogs. The SIP UPDATE request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from the SC UE A on the Target Access Leg.