A.15 Signalling flows for MSC server assisted mid-call feature

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

The signalling flows in the subclause demonstrate how full duplex session on hold can be transferred together with active full duplex session when the MSC server assisted mid-call feature is used. The following signalling flows are included:

– subclause A.15.2 shows an example of CS to PS access transfer with the MSC server assisted mid-call feature.

– subclause A.15.3 shows an example of PS to CS access transfer with the MSC server assisted mid-call feature.

subclause A.15.4 shows an example of PS to CS access transfer with MSC server assisted mid-call feature with an incoming waiting call in alerting phase

The examples assume that:

– the SC UE, the MSC server enhanced for ICS and the SCC AS support the MSC server assisted mid-call feature;

– the SC UE does not use ICS procedures; and

– the SCC AS is allowed to use the MSC server assisted mid-call feature according to operator policy.

A.15.2 CS to PS access transfer with MSC server assisted mid-call feature

In the example flow at the figure A.15.2-1, SC UE A has two ongoing sessions over CS bearer which are anchored at SCC AS. The active session X is with UE B, the held session Y is with UE C. The session X and session Y are two party sessions. The session Y contains rejected video stream and accepted speech media component. When the SC UE connects to an IP-CAN, it decides to transfer the sessions over the IP-CAN.

Figure A.15.2-1: Signalling flow for 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 active session X with remote UE B and a held session Y with remote UE C

The calls have been anchored at the SCC AS which is in the HPLMN of originating SC UE A.

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

The SC UE A decides to transfer the sessions over the new IP-CAN. 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 standard registration procedure and reserves resources in the new IP-CAN.

3. SIP INVITE request transferring the active session X (SC UE A to intermediate IM CN subsystem entities) – see example in table A.15.2-3

The SC UE A sends an initial SIP INVITE request to request the new call replaces the existing call X.

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

INVITE sip:domain.xfer@sccas.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>, <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, 199, gruu, norefersub

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.mid-call

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

Accept: application/sdp, application/3gpp-ims+xml, application/vnd.3gpp.mid-call+xml

Content-Type: application/sdp

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

a=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

Contact: contains the g.3gpp.mid-call media feature tag as defined in annex C indicating the support for the MSC server assisted mid-call feature.

Accept: contains the MSC Server assisted mid-call feature MIME type.

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 performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg.

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

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

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

The intermediate IM CN subsystem entities forward 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 media path of session X is using the new IP-CAN but the media path of the session Y is still using the CS bearer.

18-19. SIP BYE request (SCC AS to MSC Server 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.

20-22. 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.

NOTE: Steps 20-22 are performed only if signalling over CS domain is possible after the CS-PS access transfer is completed; otherwise, the SC UE A and the network release the source access leg of session X locally, without any signalling between the SC UE and the network.

23-24. SIP 200 (OK) response (MSC Server to SCC AS via intermediate IM CN subsystem entities)

Upon receiving the SIP BYE request over the old IP-CAN, the MSC Server sends a SIP 200 (OK) response over the old IP-CAN to the SCC AS.

25: SIP REFER request (SCC AS to Intermediate IM CN subsystem entities) -see example in table A.15.2-25

The SCC AS sends SIP REFER request towards UE A inside the dialog created by the message 13.

Table A.15.2-25: SIP REFER request (SCC AS to IM CN subsystem entities)

REFER sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0

Via: SIP/2.0/UDP sip:sccas1.home1.net;branch=z9hG4bk731b8a

Max-Forwards: 70

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

From: <tel:+1-237-555-2222>; tag=aasdfgaag

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

Call-ID: cb03a0s09a2sdfglkj490237

Cseq: 55998 REFER

Content-Length: …

Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.home1.net:7531;lr>

Contact: <sip:sccas1.home1.net;gr>

Refer-Sub: false

Supported: norefersub, gruu

Refer-To: <sip:additional.session.xfer@sccas.home1.net?Target-Dialog=a84b4c76e66710%3Bremote-tag=654364735%3Blocal-tag=1928301774&Require=tdialog&From=tel:+1-237-555-1111&To=tel:+1-987-654-3210&Content-Type=application%2Fsdp&body=v%3D0%0D%0Ao%3D-%202987933623%202987933623%20IN%20IP6%205555::ggg:fff:aaa:bbb%0D%0As%3D-%0D%0Ac%3DIN%20IP6%205555::ggg:fff:aaa:bbb%0D%0At%3D0%200%0D%0Am%3Dvideo%200%20RTP%2FAVP%2098%0D%0Am%3Daudio%203456%20RTP%2FAVP%2097%2096%0D%0Ab%3DAS:25.4%0D%0Aa%3Drtpmap:97%20AMR%0D%0Aa%3Dfmtp:97%20mode-set%3D0%2C2%2C5%2C7%3B%20mode-change-period%3D2%0D%0Aa%3Dmaxptime:20%0D%0A>

Content-Type: application/vnd.3gpp.mid-call+xml

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

<mid-call/>

Refer-To: contains the additional transferred session SCC AS URI and the following URI header fields:

Target-Dialog: the dialog identifier of the source access leg.

Require: containing "tdialog" option tag

From: contains the public user identity of the UE A

To: contains the public user identity of the UE C

Content-Type: containing "application/sdp" MIME type of the "body" URI header field

body: SDP describing the media used in the session

26. SIP REFER request (intermediate IM CN subsystem entities to UE A)

The SIP REFER request is forwarded towards the UE A.

27-28. SIP 200 (OK) response (UE A to SCC AS via intermediate IM CN subsystem entities)

Upon receiving the SIP REFER request, the UE A sends a SIP 200 (OK) response.

29. SIP INVITE request transferring the held session Y (SC UE A to intermediate IM CN subsystem entities) – see example in table A.15.2-29

The SC UE A sends an initial SIP INVITE request to request the new call replacing the existing call Y.

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

INVITE sip:additional.session.xfer@sccas.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>, <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: <tel:+1-237-555-1111>; tag=171828

To: <tel:+1-987-654-3210>

Call-ID: asdfqweasas

Cseq: 127 INVITE

Supported: 100rel, precondition, 199, gruu

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.mid-call

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

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

Target-Dialog: a84b4c76e66710;remote-tag=654364735;local-tag=1928301774

Content-Type: application/sdp

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=video 0 RTP/AVP 98

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos loca

a=tcap:1 RTP/AVPF

a=pcfg:1 t=1l 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

a=sendonly

Request-URI: contains the additional transferred session SCC AS URI as received in the Refer-To URI in the SIP REFER request.

Target-Dialog: contains the dialog identifier as received in the Refer-To URI in the SIP REFER request.

Contact: contains the g.3gpp.mid-call media feature tag as defined in annex C indicating the support for the MSC server assisted mid-call feature.

SDP: All the media are offered with the sendonly directionality.

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

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

32. Remote Leg Update

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

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

34. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE C)

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

35-36: SIP 200 (OK) response (UE C to SCC AS via Intermediate IM CN subsystem entities)

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

37-38: SIP ACK request (SCC AS to UE C 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 C.

39: SIP 200 (OK) response (SCC AS to 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.

40: SIP 200 (OK) response (Intermediate IM CN subsystem entities to UE A)

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

41-42: 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

43. Media paths between UE A and UE B

The media paths of session X and session Y are using the new IP-CAN but the the CS bearer is still not released.

44-45. SIP BYE request (SCC AS to MSC Server 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.

46, 49-50. 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.

NOTE: Steps 46-48 are performed only if signalling over CS domain is possible after the CS-PS access transfer is completed; otherwise, the SC UE and the network release the source access leg of session Y locally, without any signalling between the SC UE and the network.

47-48. SIP 200 (OK) response (MSC Server to SCC AS via intermediate IM CN subsystem entities)

51. Media paths between UE A and UE B

The media paths of session X and session Y are using the new IP-CAN.

A.15.3 PS to CS access transfer with MSC server assisted mid-call feature

In the example flow at the figure A.15.3-1, SC UE A has two ongoing sessions over PS bearer which are anchored at SCC AS. When both sessions were established the SC UE and the SCC AS included the g.3gpp.mid-call media feature tag as specified in annex C into the Contact header fields. The active session X is with UE B, the held session Y is with UE C. The session X and session Y are two party sessions. The session Y contains a rejected video stream and an accepted speech media component. When the SC UE attaches to the CS domain, it decides to transfer the sessions over the CS bearer without using the ICS capability.

Figure A.15.3-1: Signalling flow for PS-CS access transfer: PS-CS

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

1. SC UE A is on an active session X with UE B and a held session Y with UE C:

There is an ongoing IP bearer between the SC UE and the remote UE B and another IP bearer between the SC UE and the remote UE C. Both sessions are anchored at SCC AS.

2. SC UE A attaches to the CS domain

The SC UE attaches to the CS domain and decides to transfer the sessions over the CS bearer.

3. CC SETUP messages

Transaction Identifier: 3

4. SIP INVITE request transferring the active session X (MSC Server to Intermediate IM CN subsystem entities) -see example in table A.15.3-4

Upon receiving the CC SETUP message the MSC Server sends a SIP INVITE request and associates the transaction identifier 3 with the SIP INVITE request.

Table A.15.3-4: SIP INVITE request (MSC Server to intermediate IM CN subsystem entities)

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

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

Max-Forwards: 70

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

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

Privacy: none

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu, 199, norefersub

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

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

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="server";+g.3gpp.mid-call

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

Content-Type: application/sdp

Content-Length: (…)

Accept: application/sdp, application/3gpp-ims+xml, application/vnd.3gpp.mid-call+xml

Recv-Info: g.3gpp.mid-call

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

a=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

Request-URI: contains the IMRN, as obtained from CS networks signalling.

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

Contact: contains the g.3gpp.mid-call media feature tag as defined in annex C indicating the support for the MSC server assisted mid-call feature.

Accept: contains the MSC Server assisted mid-call feature MIME type.

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

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

7. Remote Leg Update

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

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

The SCC AS acting as a routing B2BUA generates a SIP re-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.

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

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

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

12-13. 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.

14-15. SIP 200 (OK) response (SCC AS to MSC Server 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 towards the MSC Server.

16. CC CONNECT message (MSC Server to SC UE A)

17-18. SIP ACK request (MSC Server to SCC AS via IM CN subsystem entities)

The MSC Server generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the SCC AS.

19. CC CONNECT ACKNOWLEDGEMENT message (SC UE A to MSC server)

20. Media paths between SC UE A and UE B:

The CS bearer is setup while the PS bearers are still existing.

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

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

23-24. 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.

NOTE: Steps 22-23 are performed only if SC UE A is using Gm after the PS-CS access transfer is completed; otherwise, the SC UE A and the network release the source access leg of session X locally, without any signalling between the SC UE A and the network.

25. Media paths between SC UE A and UE B

The session X is transferred from PS bearer to CS bearer, but the session Y is still at the PS bearer.

26. SIP REFER request (SCC AS to IM CN subsystem entities) -see example in table A.15.3-26

The SCC AS sends SIP REFER request towards MSC Server inside the dialog created by the the message 14.

Table A.15.3-26: SIP REFER request (SCC AS to IM CN subsystem entities)

REFER sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0

Via: SIP/2.0/UDP sip:sccas1.home1.net;branch=z9hG4bk731b8a

Max-Forwards: 70

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

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

From: <tel:+1-237-555-3333>;tag=sdfsdf

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 55998 REFER

Content-Length: 125

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

Refer-Sub: false

Supported: norefersub, gruu

Contact: sip:sccas1.home1.net

Refer-To: <additional.session.xfer@sccas.home1.net?Target-Dialog=ksdjfhwrklf%3Bremote-tag=676723565%3Blocal-tag=45418454&Require=tdialog&From=tel:+1-237-555-1111&To=tel:+1-987-654-3210&Content-Type=application%2Fsdp&body=v%3D0%0D%0Ao%3D-%202987933623%202987933623%20IN%20IP6%205555::ggg:fff:aaa:bbb%0D%0As%3D-%0D%0Ac%3DIN%20IP6%205555::ggg:fff:aaa:bbb%0D%0At%3D0%200%0D%0Am%3Dvideo%200%20RTP%2FAVP%2098%0D%0Am%3Daudio%203456%20RTP%2FAVP%2097%2096%0D%0Ab%3DAS:25.4%0D%0Aa%3Drtpmap:97%20AMR%0D%0Aa%3Dfmtp:97%20mode-set%3D0%2C2%2C5%2C7%3B%20mode-change-period%3D2%0D%0Aa%3Dmaxptime:20%0D%0A>

Content-Type: application/vnd.3gpp.mid-call+xml

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

<mid-call/>

Refer-To: contains the additional transferred session SCC AS URI and the following URI header fields:

Target-Dialog: the dialog identifier of the source access leg.

Require: containing "tdialog" option tag

From: contains the public user identity of the UE A

To: contains the public user identity of the UE C

Content-Type: containing "application/sdp" MIME type of the "body" URI header field

body: SDP describing the media used in the session

27. SIP REFER request (intermediate IM CN subsystem entities to MSC Server)

The SIP REFER request is forwarded towards the MSC Server.

28-29. SIP 200 (OK) response (MSC Server to SCC AS via intermediate IM CN subsystem entities)

Upon receiving the SIP REFER request, the MSC Server sends a SIP 200 (OK) response.

30. SIP INVITE request for the held session Y (MSC Server to Intermediate IM CN subsystem entities) -see example in table A.15.3-30

Upon receiving the SIP REFER request the MSC Server sends a SIP INVITE request and associates the transaction identifier 4 with the SIP INVITE request.

Table A.15.3-30: SIP INVITE request (MSC Server to intermediate IM CN subsystem entities)

INVITE

sip:additional.session.xfer@sccas.home1.net SIP/2.0

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

Max-Forwards: 70

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

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

Privacy: none

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

To: <tel:+1-987-654-3210>

Call-ID: asdfgqwerq

Cseq: 1275 INVITE

Supported: 100rel, precondition, 199, gruu

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

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

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="server";+g.3gpp.mid-call

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

Content-Type: application/sdp

Target-Dialog: ksdjfhwrklf;remote-tag=676723565;local-tag=45418454

Require: tdialog

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=video 0 RTP/AVP 98

m=audio 3456 RTP/AVP 97 96

a=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

a=sendonly

Request-URI: contains the additional transferred session SCC AS URI as received in the Refer-To URI in the SIP REFER request.

Target-Dialog: contains the dialog identifier as received in the Refer-To URI in the SIP REFER request.

Contact: contains the g.3gpp.mid-call media feature tag as defined in annex C indicating the support for the MSC server assisted mid-call feature.

SDP: The SDP contains preconfigured set of codecs supported by the MSC Server. All the media are offered with the sendonly directionality.

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

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

33. Remote Leg Update

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

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

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 C via the intermediate IM CN subsystem entities. 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.

35. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE C)

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

36. SIP 200 (OK) response (UE C to intermediate IM CN subsystem entities)

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

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

38-39. SIP ACK request (SCC AS to UE C 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 C.

40. SIP 200 (OK) response (SCC AS to 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 towards the MSC Server.

41. SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC Server)

Intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP INVITE request to MSC Server.

42-43. SIP ACK request (MSC Server to SCC AS via IM CN subsystem entities)

The MSC Server generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the SCC AS.

44. Media paths between SC UE A and UE B:

The CS bearer and PS bearers for both the sessions are established but there is still the original IP bearer for the held session Y.

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

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

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

NOTE: Steps 46-47 are performed only if the SC UE A uses Gm after the PS-CS access transfer is completed; otherwise, the SC UE A and the network release the source access leg locally, without any signalling between the SC UE A and the network.

49. Media paths between SC UE A and UE B

Both sessions X and Y are transferred from PS bearer to CS bearer.

A.15.4 PS to CS access transfer with MSC server assisted mid-call feature with an incoming waiting call in alerting phase

In the example flow at the figure A.15.4-1, SC UE A has an ongoing sessions with speech media component and an incoming waiting session with speech media component which are anchored at SCC AS. The incoming waiting call is in alerting phase. The ongoing session X is with UE B, the incoming waiting session Y is with UE C. The session X and session Y are two party sessions. Based upon measurement reports sent from the UE to E-UTRAN, the source E-UTRAN decides to trigger a PS to CS SRVCC procedure to CS access.

Figure A.15.4-1: Signalling flow for PS to CS access transfer with MSC server assisted mid-call feature with an incoming waiting call in alerting phase

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

NOTE 2: For transferring the incoming waiting call in alerting phase, the feature of PS to CS SRVCC in alerting phase needs to be supported, but the MSC server assisted mid-call feature is not necessary.

1. SC UE A is on an active session X with UE B and an incoming waiting session Y with UE C:

There is an ongoing PS bearer between the SC UE and the remote UE B and another PS bearer between the SC UE and the remote UE C. Both sessions are anchored at SCC AS.

2. SC UE A sends the measurement reports to E-UTRAN

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an PS to CS SRVCC handover to CS access. The MSC server initiates the session transfer with the STN-SR, refer to 3GPP TS 23.237 [9].

3-24. Access transfer for the active session X

The procedure for transfering the active session X is the same as step 4 to step 15 and step 18 to step 24 described in subclause A.15.3.

25. Media paths between SC UE A and UE B

The session X is transferred from PS bearer to CS bearer, but the session Y is still at the PS bearer.

26. SIP REFER request (SCC AS to IM CN subsystem entities) -see example in table A.15.4-26

The SCC AS sends SIP REFER request towards MSC server inside the dialog created by the the message 14, and it also contain the state-and-event-info XML body to indicate that the additional session is an incoming session in alerting phase.

Table A.15.4-26: SIP REFER request (SCC AS to IM CN subsystem entities)

REFER sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0

Via: SIP/2.0/UDP sip:sccas1.home1.net;branch=z9hG4bk731b8a

Max-Forwards: 70

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

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

From: <tel:+1-237-555-3333>;tag=sdfsdf

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 55998 REFER

Content-Length: 125

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

Refer-Sub: false

Supported: norefersub, gruu

Contact: sip:sccas1.home1.net

Refer-To: <additional.session.xfer@sccas.home1.net?Target-Dialog=ksdjfhwrklf%3Bremote-tag=676723565%3Blocal-tag=45418454&Require=tdialog&From=tel:+1-237-555-1111&To=tel:+1-987-654-3210&Content-Type=application%2Fsdp&body=v%3D0%0D%0Ao%3D-%202987933623%202987933623%20IN%20IP6%205555::ggg:fff:aaa:bbb%0D%0As%3D-%0D%0Ac%3DIN%20IP6%205555::ggg:fff:aaa:bbb%0D%0At%3D0%200%0D%0Aaudio%203456%20RTP%2FAVP%2097%2096%0D%0Ab%3DAS:25.4%0D%0Aa%3Drtpmap:97%20AMR%0D%0Aa%3Dfmtp:97%20mode-set%3D0%2C2%2C5%2C7%3B%20mode-change-period%3D2%0D%0Aa%3Dmaxptime:20%0D%0A>

Content-Type: application/vnd.3gpp.state-and-event-info+xml

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

<state-and-event-info>

<state-info>early</state-info>

<direction>receiver</direction>

</state-and-event-info>

Refer-To: contains the additional transferred session SCC AS URI and the following URI header fields:

Target-Dialog: the dialog identifier of the source access leg.

Require: containing "tdialog" option tag

From: contains the public user identity of the UE A

To: contains the public user identity of the UE C

Content-Type: containing "application/sdp" MIME type of the "body" URI header field

body: SDP describing the media used in the session.

XML Schema: contain the session state information that the additional session is an incoming session in alerting phase.

27. SIP REFER request (intermediate IM CN subsystem entities to MSC server)

The SIP REFER request is forwarded towards the MSC server.

28-29. SIP 200 (OK) response (MSC server to SCC AS via intermediate IM CN subsystem entities)

Upon receiving the SIP REFER request, the MSC server sends a SIP 200 (OK) response.

30. SIP INVITE request for the held session Y (MSC server to Intermediate IM CN subsystem entities) -see example in table A.15.4-30

Upon receiving the SIP REFER request which contain the session state information to indicate that the additional session in an incoming session in alerting phase, the MSC server moves to Call Received state as described in the SIP REFER request but does not generate an in-band ring tone to the calling party, and sends a SIP INVITE request and associates the transaction identifier with the SIP INVITE request.

Table A.15.4-30: SIP INVITE request (MSC server to intermediate IM CN subsystem entities)

INVITE

sip:additional.session.xfer@sccas.home1.net SIP/2.0

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

Max-Forwards: 70

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

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

Privacy: none

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

To: <tel:+1-987-654-3210>

Call-ID: asdfgqwerq

Cseq: 1275 INVITE

Supported: 100rel, precondition, 199, gruu

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

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

Contact: <sip:msc1@home1.net> ;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel" ;+g.3gpp.ics="server";+g.3gpp.mid-call

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

Content-Type: application/sdp

Target-Dialog: ksdjfhwrklf;remote-tag=676723565;local-tag=45418454

Require: tdialog

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

a=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

Request-URI: contains the additional transferred session SCC AS URI as received in the Refer-To URI in the SIP REFER request.

Target-Dialog: contains the dialog identifier as received in the Refer-To URI in the SIP REFER request.

Contact: contains the g.3gpp.mid-call media feature tag as defined in annex C indicating the support for the MSC server assisted mid-call feature.

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

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

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

33. Remote Leg Update

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

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

The SCC AS acting as a routing B2BUA generates a SIP UPDATE request based upon the received SIP INVITE request and the information previously stored against this session and routes it towards UE C via the intermediate IM CN subsystem entities. 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 UE A.

35. SIP UPDATE request (Intermediate IM CN subsystem entities to UE C)

Intermediate IM CN subsystem entities forward the SIP UPDATE request to remote UE C.

36. SIP 200 (OK) response (UE C to intermediate IM CN subsystem entities)

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

37. 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 UPDATE request to the SCC AS in the originating network.

38-39. SIP 183 (Session Progress) response (SCC AS to MSC server via IM CN subsystem entities)

The SCC AS sends a 183 (Session Progress) containing the SDP answer as received from the UE C. The SDP answer indicates that resources are available

40. SIP PRACK request (MSC Server to Intermediate IM CN subsystem entities)

The MSC server acknowledges the receipt of the 183 Session Progress.

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

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

42-43. SIP 200 (OK) response (SCC AS to MSC server via IM CN subsystem entities)

The SCC AS acknowledges the SIP PRACK request with a SIP 200 (OK) response to the MSC server.

44. CC HOLD Message (SC UE to MSC server)

The SC UE A put the active session on hold.

45. SIP re-INVITE request (MSC server to intermediate IM CN subsystem entities)

Upon receiving the CS HOLD Message from the UE, MSC server sends a SIP re-INVITE request towords session X, which put session X on hold.The SDP in this SIP re-INVITE request is based on the last SDP offer/answer negotiation for the active session transfer form step 3 to 24, but for each media streams set the SDP attribute to "sendonly".

46. SIP re-INVITE request (Intermediate IM CN subsystem entities to SCC AS)

The SIP re-INVITE request is forwarded to the SCC AS.

47-48. SIP re-INVITE request (SCC AS to UE B)

SCC AS sends SIP re-INVITE request to UE B, The SIP re-INVITE request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the SIP re-INVITE request from the MSC server.

49-50. SIP 200 (OK) response (UE B to SCC AS)

Upon receiving the SIP re-INVITE request containing the SDP offer which contain the SDP attribute for each media streams to "sendonly", UE B response the SIP re-INVITE request with a SIP 200 (OK), which set the SDP attribute for each media streams to "receonly".

51-52. SIP ACK request (SCC AS to UE B)

53-54. SIP 200 (OK) response (SCC AS to MSC server via intermediate IM CN subsystem entities )

The SCC AS sends SIP 200 (OK) to indicate the succesful activity to the MSC server that put session X on hold.

55. CC HOLD ACKNOWLEDGE Message (MSC server to SC UE A)

56-57. SIP ACK request (MSC server to SCC AS via intermediate IM CN subsystem entities)

MSC server acknowledges the SIP 200 (OK) received from SCC AS.

58. CC CONNECT message from SC UE A to MSC server

The SC UE A accepts the call and sends CC CONNECT message.

59. CC CONNECT ACKNOWLEDGE (MSC server to SC UE A)

60. SIP INFO request (MSC server to intermediate IM CN subsystem entities) – see example in table A.15.4-60

A.15.4-60: INFO (SCC AS to intermediate IM CN subsystem entities)

INFO sip:sccas1.home1.net;gr SIP/2.0

Via: SIP/2.0/UDP msc1.visit1.net;branch=z9hG4bk731b87

Max-Forwards: 68

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

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

To: <tel: +1-237-555-3333>;tag=171828

Call-ID: cb03a0s09a2sdfglkj490334

Cseq: 130 INFO

Info-Package: g.3gpp.state-and-event

Content-Disposition: Info-Package

Content-Type: application/vnd.3gpp.state-and-event-info+xml

Content-Length:

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

<state-and-event-info>

<event>call-accepted</event>

</state-and-event-info>

XML Schema: contain the session state information indicating that the remote party has answered the call.

61. SIP INFO request (Intermediate IM CN subsystem entities to SCC AS)

The intermediate IM CN subsystem entities forward the SIP INFO request to the SCC AS. The SCC AS gets informed that the SC UE A has accepted the call.

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

The SCC AS acknowledges the receipt of the SIP INFO request indicating that the SC UE A has accepted the call

63. SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC server)

The SIP 200 (OK)response is forwarded to the MSC server.

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

The SCC AS sends SIP 200 (OK) response to indicate to the far end that the SC UE A has accepted the call.

65. SIP 200 (OK) response (Intermediate IM CN subsystem entities to far end)

The SIP 200 (OK) response is forwarded to the far end)

66. SIP ACK request (far end to intermediate IM CN subsystem entities)

The far end UE acknowledges the SIP 200 (OK) response received from the SCC AS

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

The SIP ACK request is forwarded to the SCC AS.

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

The SCC AS sends SIP 200 (OK) response to indicate the succesfull access transfer to the MSC server.

69. SIP 200 (OK) response (Intermdiate IM CN subsystem entities to far end)

The SIP 200 (OK) response is forwarded to the MSC server.

70. SIP ACK request (MSC server to intermediate IM CN subsystem entities)

MSC server acknowledges the SIP 200 (OK) response received from SCC AS.

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

The SIP ACK request is forwarded to the SCC AS.

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

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

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

NOTE 3: Steps 73-74 are performed only if the SC UE A uses Gm after the PS-CS access transfer is completed; otherwise, the SC UE A and the network release the source access leg of session Y locally, without any signalling between the SC UE A and the network.

76. Media paths between SC UE A and UE B

Both sessions X and Y are transferred from PS bearer to CS bearer.