A.8 Signalling flows for PS-PS access transfer in conjunction with PS-CS 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.8.1 Introduction

The signalling flows for PS-PS access transfer conjunction with PS-CS 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.8.2 shows an example when a multimedia session is transferred from one IP-CAN to a new IP-CAN and the CS bearer respectively ; and

– subclause A.8.3 shows an example when a multimedia session is transferred from one IP-CAN and CS bearer to a new IP-CAN.

A.8.2 PS – PS in conjunction with PS – CS Access Transfer: PS to CS

In this example, SC UE A has an ongoing multimedia session with remote UE B over IP-CAN#1 before access transfer. When SC UE connects to a new IP-CAN#2, it decides to transfer the multimedia session over the new IP-CAN#2 and the CS bearer respectively.

Figure A.8.2-1: Signalling flow for PS – PS in conjunction with PS – CS Access Transfer: PS to CS

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

1. SC UE A has an ongoing multimedia session with remote UE B

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. The call leg over old IP-CAN is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To tag=774321". The UE A and UE B exchange media over the old IP-CAN, which is maintained while the SC UE A initiates the handover procedure.

Table A.8.2-1 shows an example of the SDP offer from SC UE A to remote UE B.

NOTE 2: To later show how the media is transferred to the new IP-CAN and CS bearer, only the SDP offer is shown in table A.8.2-1.

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

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

Via:

Max-Forwards:

Route:

P-Asserted-Identity:

P-Charging-Vector:

P-Access-Network-Info:

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Require:

Proxy-Require:

Security-Verify:

Contact:

Allow:

Accept:

Content-Type:

Content-Length: (…)

v=0

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

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

m=message 7654 TCP/MSRP 98

a=accept-types:text/plain

2. SC UE A connects to a new IP-CAN#2:

The SC UE A decides to transfer the multimedia session over the new IP-CAN and CS bearer respectively. The UE A obtains an IP address that it will use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using multiple registrations procedure. Depending on the UE A configuration, the discovery of the P-CSCF in the new IP-CAN can be needed. Based on the UE A and new IP-CAN capabilities, the UE A decides to use the same codec that was used over the old IP-CAN. The UE A 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.

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

The SC UE A sends an initial SIP INVITE request with a STI and a new SDP offer to the UE B 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 a new contact address that will be used for non-realtime media over the new IP-CAN. Upon sending the initial SIP INVITE request, the UE A 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 SC UE are receiving the SIP 200 (OK) response for the initial SIP INVITE request.

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

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

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:fff]: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: <tel:+1-237-555-2222>

Call-ID: cb03a0s09a2sdfglkj490237

Cseq: 127 INVITE

Supported: 100rel; precondition

Require: sec-agree

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>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="principal";

Target-Dialog:me03a0s09a2sdfgjkl491777; to-tag=774321; from-tag=64727891

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:fff

t=0 0

m=audio 0 RTP/AVP 97 96

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

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=message 7654 TCP/MSRP 98

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

a=accept-types:text/plain

4. Evaluation of initial filter criteria

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request towards the SCC AS.

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

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC.

6. Remote Leg Update

The SCC AS identifies the session to be transferred using the STI. The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE.

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.8.2-7

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 A (Step 3).

Table A.8.2-7: 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: "John Doe" <sip:user1_public1@home1.net>, <tel:+1-237-555-1111>

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

Privacy: none

P-Charging-Vector: ####

P-Charging-Function-Addresses:

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

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

Call-ID: dc14b1t10b3teghmlk5013237

Cseq: 111 INVITE

Supported: precondition, 100rel

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"

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

Accept: application/sdp

Content-Type: application/sdp

Content-Length: (…)

v=0

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

s=t=0 0

m=audio 0 RTP/AVP 97 96

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

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=message 7654 TCP/MSRP 98

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

a=accept-types:text/plain

8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B)

The intermediate IM CN subsystem entities forwards the SIP re-INVITE request to remote UE B.

9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities)

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS.

11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities)

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B.

13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities)

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A.

15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities)

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS

17. Media paths between UE A and UE B

The non-realtime media is using the new IP-CAN while the realtime media path is still over the old IP-CAN.

18. CC SETUP message (SC UE A to Interworking entities)

The SC UE sends the CC SETUP message with the STN as the called party number.

NOTE 3: STN is a PSI DN used by the UE to request a session transfer towards the SCC AS.

19. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in Table A.8.2-19

Table A.8.2-19: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities)

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

Via: SIP/2.0/UDP msc1.home1.net; branch=z9hG4bKnashds7

Max-Forwards: 70

Route: <sip:icscf1.home1.net:7531;lr;comp=sigcomp>

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

P-Charging-Vector: ####

Privacy: none

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition

Require: sec-agree

Proxy-Require: sec-agree

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

Contact: <sip:mgcf2.home2.net;gr>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

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

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

Content-Type: application/sdp

Content-Length: (…)

v=0

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

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

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: contains the IMRN, as obtained from CS networks signalling.

SDP: The SDP contains preconfigured set of codecs supported by the MGW.

20. Evaluation of initial filter criteria

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request towards the SCC AS.

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

22. Remote Leg Update

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE.

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

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE request and the information previously stored against this session and routes it towards UE B via the intermediate IM CN subsystem entities. In this example the SCC AS includes the contents of the Contact header field from the received SIP INVITE request.

Table A.8.2-23: 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 sccas1.home1.net;branch=z9hG4bKnas34r5

Max-Forwards: 67

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

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

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

P-Charging-Vector: ####

Privacy: none

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

To: <tel:+1-237-555-2222>; tag=26545

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition

Require: sec-agree

Proxy-Require: sec-agree

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

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"

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

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

Content-Type: application/sdp

Content-Length: (…)

v=0

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

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=message 7654 TCP/MSRP 98

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

a=accept-types:text/plain

24. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B)

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B.

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

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B 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.

26. 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 SIP re-INVITE request to the SCC AS in the originating network.

27-28. SIP ACK request (SCC AS to UE B via IM CN subsystem entities)

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request to the remote UE B.

29-30. SIP 200 (OK) response (SCC AS to interworking entities via IM CN subsystem entities)

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) response to the interworking entities.

31. CC CONNECT message (interworking entities to SC UE A)

32-33. SIP ACK request (interworking entities to SCC AS via IM CN subsystem entities)

The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC AS.

34. CC CONNECT ACKNOWLEDGEMENT message (SC UE A to interworking entities)

35-36: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities)

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

37-38. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities)

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

39. Media paths between SC UE A and UE B

Finally, the non-realtime media path is over the new IP-CAN and the realtime media is using the CS bearer.

A.8.3 PS – PS in conjunction with PS – CS Access Transfer: CS to PS

In this example, SC UE A has an ongoing multimedia session with remote UE B over IP-CAN#1 and CS bearer before access transfer. When SC UE connects to a new IP-CAN#2, it decides to transfer all the multimedia session over the new IP-CAN#2.

Figure A.8.3-1: Signalling flow for PS – PS in conjunction with PS – CS Access Transfer: CS to PS

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

1. SC UE A has an ongoing multimedia session with remote UE B

The non realmedia path is over old IP-CAN#1 and the realtime media path is over the CS bearer. The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. The call leg over old IP-CAN#1 is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To tag=774321". The UE A and UE B exchange media over the old IP-CAN, which is maintained while the SC UE A initiates the handover procedure.

2. SC UE A connects to a new IP-CAN#2

The SC UE A decides to transfer the multimedia session over the new IP-CAN#2. The UE A obtains an IP address that it will use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using multiple registrations procedure. Depending on the UE A configuration, the discovery of the P-CSCF in the new IP-CAN can precede this. Based on the UE A and new IP-CAN capabilities, the UE A decides to use the same codec that was used over the old IP-CAN. The UE A 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.

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

Upon sending the initial SIP INVITE request, the UE A 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 SC UE are receiving the SIP 200 (OK) response for the initial SIP INVITE request.

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

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

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:fff]: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: <tel:+1-237-555-2222>

Call-ID: cb03a0s09a2sdfglkj490237

Cseq: 127 INVITE

Supported: 100rel; precondition, gruu, 199

Require: sec-agree, replaces

Proxy-Require: sec-agree

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

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

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>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="principal";

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

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:fff

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

t=0 0

m=audio 3456 RTP/AVP 97 96a=tcap:1 RTP/AVPF

a=pcfg:1 t=1

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=message 7654 TCP/MSRP 98

a=accept-types: text/plain

Request-URI: Contains the static STI.

4. Evaluation of initial filter criteria

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request towards the SCC AS.

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

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC.

6. Remote Leg Update

The SCC AS identifies the session to be transferred using the STI. The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE.

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

Table A.8.2-7: 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: "John Doe" <sip:user1_public1@home1.net>, <tel:+1-237-555-1111>

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

Privacy: none

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

P-Charging-Function-Addresses:

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

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

Call-ID: dc14b1t10b3teghmlk5013237

Cseq: 111 INVITE

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"

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

Content-Type: application/sdp

Content-Length: (…)

v=0

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

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

t=0 0

m=audio 3456 RTP/AVPF 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

m=message 7654 TCP/MSRP 98

a=accept-types: text/plain

8. SIP re–INVITE request (Intermediate IM CN subsystem entities to UE B)

The intermediate IM CN subsystem entities forwards the SIP re-INVITE request to remote UE B.

9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities)

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS.

11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities)

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B.

13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities)

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A.

15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities)

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS

17. Media paths between UE A and UE B

The multimedia is using the new IP-CAN. Resources used for signalling on the old IP-CAN#1 and CS bearer are not released.

18-19. SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities)

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

20-21. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities)

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

22-23. SIP BYE request (SCC AS to interworking entities via intermediate IM CN subsystem entities)

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a SIP BYE request.

24, 27-28. CC DISCONNECT message (interworking entities to SC UE A)

Upon receiving the CC DISCONNECT message, the SC UE A relinquishes all resources pertaining to the CS bearer.

25-26. SIP 200 (OK) response (Interworking entities to SCC AS via intermediate IM CN subsystem entities)

29. Media paths between UE A and UE B

The multimedia session is using the new IP-CAN#2.