A.6 Signalling flows for supplementary service invocation for ICS

24.2923GPPIP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS)Release 17Stage 3TS

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

A.6.1 Communication Hold/Resume with Announcement

Figure A.6.1-1 provides the example flow for ICS Communication Hold/Resume with Announcement over Gm reference point for the ICS UE. The SCC AS shown together with MRF is for the purpose of simplifying the signalling flow.

Figure A.6.1-1: ICS Communication Hold/Resume with Announcement over Gm reference point

The details of the signalling flows are as follows:

1. Session establishment

It is assumed that as a result of ICS UE origination procedure defined in subclause A.4.2 .ICS UE A establish a multimedia session with UE B.

2. SIP re-INVITE request (ICS UE A to intermediate IM CN subsystem entities) – see example in table A.6.1-2.

UE-A sends a re- INVITE request to UE-B to hold the session. Hold is done by changing the SDP attribute:

"a=sendonly", if the stream was previously a sendrecv media stream;

"a=inactive", if the stream was previously a recvonly media stream.

Table A.6.1-2: SIP re-INVITE request (ICS UE A to intermediate IM CN subsystem entities)

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

Via: SIP/2.0/UDP [4444::ccc:ddd:ccc:eee]:1357;comp=sigcomp;branch=z9hG4bKnashds8

Max-Forwards: 70

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

Privacy: none

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

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

Call-ID: cb03a0s09a2sdfgKlkj490334

Cseq: 127 INVITE

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

Content-Type: application/sdp

Content-Length: (…)

NOTE 1: Table A.6.1-2 does not show SDP offer.

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

The intermediate IM CN subsystem entities forwards the re-INVITE request to SCC AS/TAS based upon initial filter criterion.

4-5. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- see example in table A.6.1-4.

SCC AS will generate the re-INVITE request containing IMS media and forward it towards UE B. The MGW-SDP is obtained during ICS UE A originating procedure..

Table A.6.1-4: SIP re-INVITE request (SCC AS/TAS to intermediate IM CN subsystem entities)

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

Via: SIP/2.0/UDP sccas.home1.net;branch=z1hG4bKnashds8;SIP/2.0/UDP [4444::ccc:ddd:ccc:eee]:1357;comp=sigcomp;branch=z9hG4bKnashds8

Max-Forwards: 70

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

Privacy: none

From: <sip:user2_public1@home1.net>;tag=276859

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

Call-ID: cb03a0s09a2sdfgKlkj490334

Cseq: 127 INVITE

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

Content-Type: application/sdp

Content-Length: (…)

v=0

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

s=-

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

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

a=sendonly

6. The UE B acknowledge the re-INVITE request with 200 (OK) response to S-CSCF with recvonly attribute- see example in table A.6.1-6

Table A.6.1-6: 200 (OK) response (UE B to intermediate IM CN subsystem entities)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=zlhG4bKnashds8;SIP/2.0/UDP sccas@home1.net;branch=z1hG4bKnashds8;SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

From:

To:

Call-ID:

CSeq:

Contact: <sip:user1_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74>

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 3333::ccc:ddd:ccc:eee

s=-

c=IN IP6 3333::ccc:ddd: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; maxframes=2

a=rtpmap:96 telephone-event

a=recvonly

7. SIP 200 (OK) response

The intermediate IM CN subsystem entities forward the 200 (OK) response to SCC AS according to standard IMS procedure.

After the SCC AS receive the 200 (OK) response, it will indicate MRF to play Announcement to UE-B in order to indicate Communication HOLD.

8. SIP UPDATE request (SCC AS/TAS/MRF to intermediate IM CN subsystem entities) – see example in table A.6.1-8

The SCC AS generates SIP UPDATE request with SDP offer obtained from MRF in order to negotiate the media with inactive attribute.

Table A.6.1-8: UPDATE request (SCC AS to IM CN subsystem entities)

UPDATE sip:mgcf@home1.net SIP/2.0

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

Max-Forwards: 70

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

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

To: <sip:+358-50-4821437@home1.net;user=phone>;tag=314159

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 129 UPDATE

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 3333::ccc:ddd:ccc:eee

s=-

c=IN IP6 3333::ccc:ddd:ccc:eee

t=0 0

m=audio 3466 RTP/AVP 97 96

b=AS:25.4

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

a=inactive

NOTE 2: Alternatively, unspecified connection address and/or zero bandwidth in SDP in step 4 and step 8 could be used in order to control RTCP and RTP data between the MGCF and UE-B.

9. SIP UPDATE request

The intermediate IM CN subsystem entities forward the UPDATE request to MGCF according to standard IMS procedure.

10-11. SIP 200 (OK) response (MGCF to SCC AS)

In response to the SIP UPDATE request a SIP 200 (OK) response is sent from MGCF to SCC AS.

12-13. SIP 200 (OK) response

The SCC AS will send a SIP 200 (OK) response to ICS UE A according to normal IMS procedure.

14-17. ACK request

The SIP ACK request is sent from the ICS UE A to UE B according to standard IMS procedure.

18. SIP re-INVITE request (ICS UE A to intermediate IM CN subsystem entities) – see example in table A.6.1-18.

UE A sends a SIP re-INVITE request to UE B to resume the session. Resume is done by changing the SDP attribute:

Table A.6.1-18: SIP re-INVITE request (ICS UE A to intermediate IM CN subsystem entities)

INVITE sip:user1_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74SIP/2.0

Via: SIP/2.0/UDP [4444::ccc:ddd:ccc:eee]:1357;comp=sigcomp;branch=z9hG4bKnashds8

Max-Forwards: 68

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

Privacy: none

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

To: <sip:+358-50-4821437@home1.net;user=phone>;tag=184483

Call-ID: cb03a0s09a2sdfgKlkj490334

Cseq: 127 INVITE

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

Content-Type: application/sdp

Content-Length: (…)

NOTE 3: Table A.6.1-18 does not show SDP offer.

19. SIP re-INVITE request

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

As SCC AS receives the SIP re-INVITE request, it will indicate MRF to stop Announcement.

20. SIP re-INVITE request (SCC AS to Intermediate IM CN subsystem entities) – see example in table A.6.1-20.

In order to re-connect the CS bearer and IMS bearer, SCC AS will generate the SIP re-INVITE request towards MGCF with no SDP according to standard 3PCC procedure.

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

INVITE sip:mgcf@home1.net SIP/2.0

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

Max-Forwards: 70

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

Privacy: none

From: <tel:+123456>;tag=171829

To: <sip:user2_public1@home1.net>;tag=184483

Call-ID: cb03a0s09a2sdfgKlkj490334

Cseq: 127 INVITE

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

Content-Length:0

21. SIP re-INVITE request

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to MGCF according to standard IMS procedure.

22. The MGCF acknowledge the re-INVITE request with SIP 200 (OK) to ICS UE A with sendrecv attribute- see example in table A.6.1-22

Table A.6.1-22: SIP 200 (OK) response (MGCF to intermediate IM CN subsystem entities)

SIP/2.0 200 OK

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

sccas.home1.net;branch=z9hG4bK23d244.1, SIP/2.0/UDP

Privacy: none

From:

To:

Call-ID:

Cseq:

Contact: <sip:mgcf@home1.net>;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"

Content-Type:application/SDP

Content-Length:(…)

v=0

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

s=-

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

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

a=sendrecv

NOTE 4: It is assumed that MGCF will respond to the SIP re-INVITE request with the SDP offer containing "sendrecv" attribute.

23. 200 (OK) response

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

24. SIP re-INVITE request (SCC AS to Intermediate IM CN subsystem entities) – see example in table A.6.1-24.

SCC AS generates a SIP re-INVITE request containing the SDP offer from MGW and forward it to UE B.

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

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

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

Max-Forwards: 70

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

Privacy: none

From: <tel:+123456>;tag=171829

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

Call-ID: cb03a0s09a2sdfgKlkj490334

Cseq: 127 INVITE

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

Content-Length:(…)

v=0

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

s=-

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

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

a=sendrecv

25. SIP Re-INVITE request

The intermediate IM CN subsystem entities forward the Re-INVITE request to UE B according to standard IMS procedure.

26. The UE B acknowledge the Re-INVITE request with 200 OK to ICS UE A with sendrecv attribute- see example in table A.6.1-26

Table A.6.1-26: 200 (OK) response (UE B to intermediate IM CN subsystem entities)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf1.home1.net;branch=z1hG4bK23436s.1

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

sccas.home1.net;branch=z9jG4bK23d244.1,

P-Access-Network-Info:

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

From:

To:

Call-ID:

CSeq:

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

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 3333::ccc:ddd:ccc:eee

s=-

c=IN IP6 3333::ccc:ddd: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; maxframes=2

a=rtpmap:96 telephone-event

a=sendrecv

27. 200 (OK) response

The intermediate IM CN subsystem entities forward the 200 OK response to SCC AS according to standard IMS procedure.

28-29. The SCC AS acknowledge the 200 OK from MGCF with ACK request

SCC AS send ACK request with the SDP answer from UE B to MGCF according to standard IMS procedure.

30-31. 200 OK response

SCC AS send 200 OK response to UE A according to standard IMS procedure.

32-33. ACK request

UE A acknowledge the 200 OK response with ACK request according to standard IMS procedure.

34-35. ACK request

The SIP ACK request is sent from the SCC AS to UE B according to standard IMS procedure thus completing session RESUME procedure.

A.6.2 Explicit Communication Transfer using Gm reference point, ICS UE as transfer recipient

Figure A.6.2-1 describes how IMS consultative ECT is performed when ICS UE is playing the role of transfer recipient using Gm reference point. The UE A has a held call with UE C and a held call with ICS UE B before transfer.

Figure A.6.2-1: IMS Consultative ECT via Gm for ICS UE (transfer recipient)

The details of the signalling flows are as follows:

1. Session establishment and Communication HOLD

It is assumed that as a result of ICS UE origination procedure defined in subclause A.4.2 , ICS UE B establish a multimedia session with UE A and session between UE A and UE C on HOLD according to the procedure specified in subclause A.6.1.

2. SIP REFER request (UE A to intermediate IM CN subsystem entities) – see example in table A.6.2-2.

UE A initiates transfer of ICS UE B to UE C by sending a REFER request to ICS UE B as specified in 3GPP TS 24.173 [9]

It contains following parameters.

Request-URI: contains the public GRUU of ICS UE B.

Refer-To: contains the GRUU of UE C.

Referred-By: contains the public user identity of the referring user. As in this example, the referring user UE A has decided to indicate its own identity to the referred user.

Target-Dialog: contains the dialog parameters of the dialog between UE-A and UE B.

Table A.6.2-2: SIP REFER request (UE A to intermediate IM CN subsystem entities)

REFER sip:icsueb_public1@home1.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74 SIP/2.0

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

Max-Forwards: 70

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

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

Privacy: none

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

To: <sip:icsueb_public1@home1.net>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 REFER

Refer-To: <sip:uec_public1@home1.net;gr=urn:uuid:e763c4acb-8-may-12b1-c678-12b1c88c6fa2;method=INVITE>?Replaces=cb03a0s09a2sdfhlij490444;from-tag=165343;to-taq=236717&Require=replaces

Target-Dialog: b03a0s09a2sdfgclkj490333,local-tag=kkaz,remote-tag=6544

Referred-By: <sip:user1_public1@home1.net >

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

Content-Length:0

3. SIP REFER request (intermediate IM CN subsystem entities to SCC AS) – see example in table A.6.2-3

The intermediate IM CN subsystem entities forward the REFER request to SCC AS via Transferor AS, the Transferor AS will change the Refer-To header field value to ECT Session Identifier that is shown as private-URI in the flow, according to 3GPP TS 24.629 [19].

Table A.6.2-3: SIP REFER request (intermediate IM CN subsystem entities to SCC AS)

REFER sip:icsueb_public1@home1.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74 SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9pG4bK392b23.1,SIP/2.0/UDP ectas.home1.net;branch=z9hG3bK382b23.1, SIP/2.0/UDP scscf1.home1.net;branch=z9pG4bK392b25.1,SIP/2.0/UDP pcscf1.home1.net;branch=z9aK4bK292b20.3, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 66

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

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

Privacy:

From:

To: <sip:icsueb_public1@home1.net>; tag=26876

Call-ID:

Cseq:

Refer-To: <sip:12345@ectas.home1.net>

Target-Dialog:

Referred-By:

Contact:

Content-Length:

4-5. SIP REFER request

The SCC AS forwards the REFER request to ICS UE B according to normal IMS procedure.

6. SIP 202 (Accepted) response (ICS UE B to intermediate IM CN subsystem entities) – see example in table A.6.2-6

Table A.6.2-6: SIP 202 (Accepted) response (ICS UE B to intermediate IM CN subsystem entities)

SIP/2.0 202 Accepted

Via: SIP/2.0/UDP pcscf2.home1.net;branch=z9aK4bK292b2x.3,SIP/2.0/UDP scscf1.home1.net;branch=z9pG4bK392b23.1,SIP/2.0/UDP ectas.home1.net;branch=z9hG3bK382b23.1, SIP/2.0/UDP scscf1.home1.net;branch=z9pG4bK392b25.1,SIP/2.0/UDP pcscf1.home1.net;branch=z9aK4bK292b20.3, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Privacy:

From:

To: To: <sip:icsueb_public1@home1.net>; tag=26876

Call-ID:

CSeq:

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

Content-Length:0

7-9. SIP 202 (Accepted) response

The intermediate IM CN subsystem entities forward the SIP 202 (Accepted) response to UE A according to normal IMS procedure

10. SIP INVITE request (ICS UE B to intermediate IM CN subsystem entities) – see example in table A.6.2-10.

The ICS UE B initiates session establishment towards private-URI set in the Refer-To header field by initiating an INVITE request.

Table A.6.2-10: SIP INVITE request (ICS UE B to intermediate IM CN subsystem entities)

INVITE sip:12345@ectas.home1.net SIP/2.0

Via: SIP/2.0/UDP [3333::ccc:ddd:ccc:eee]:1357;comp=sigcomp;branch=z9hG4bKnashds8

Max-Forwards: 70

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

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

Privacy: none

From: <sip:icsueb_public1@home1.net>;tag=276589

To: <sip:12345@ectas.home1.net>

Call-ID: cb03a0s09a2sdfgKlkj490334

Cseq: 127 INVITE

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

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

Content-Type: application/sdp

Content-Length: (…)

NOTE 1: Table A.6.2-10 does not show SDP offer.

11. SIP 100 (Trying) response (intermediate IM CN subsystem entities to ICS UE B)

The intermediate IM CN subsystem entities respond to the ICS UE B with a SIP 100 (Trying) response

There is no ICS specific content in this response.

12-13. SIP INVITE request / SIP 100 (Trying) response

The intermediate IM CN subsystem entities forward the SIP INVITE request to SCC AS and SCC AS respond with SIP 100 (Trying) response according to normal IMS procedure.

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

SCC AS initiates SIP re-INVITE request containing no SDP and sends it towards the MGCF according to standard 3PCC procedure.

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

INVITE sip:mgcf@home1.net SIP/2.0

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

Max-Forwards: 70

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

P-Asserted-Identity: <sip:uea@home1.net>

Privacy: none

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

To: <sip:icsueb_public1@home1.net>;tag=184483

Call-ID: cb03a0s09a2sdfgKlkj490334

Cseq: 127 INVITE

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

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

Intermediate IM CN subsystem entity forwards the SIP re-INVITE request to MGCF according to normal IM CN subsystem procedure.

16. SIP 200 (OK) response containing SDP-MGW (MGCF to intermediate IM CN subsystem entities) – see example in table A.6.2-16

Table A.6.2-16: SIP 200 (OK) response (MGCF to intermediate IM CN subsystem entities)

SIP/2.0 200 OK

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

sccas.home1.net;branch=z9hG4bK23d244.1, SIP/2.0/UDP

Privacy: none

From:

To:

Call-ID:

Cseq:

Contact: <sip:mgcf@home1.net>;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"

Content-Type:application/sdp

Content-Length:(…)

v=0

o=- 2987933615 2987933615 IN IP6 ffff::adf:333:ccc:ddd

s=-

c=IN IP6 ffff::adf:333:ccc:ddd

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

17. SIP 200 (OK) response

Intermediate IM CN subsystem entities forward the SIP 200 (OK) response towards SCC AS.

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

SCC AS sends a SIP INVITE request containing SDP-MGW as a SDP offer towards the private-URI.

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

INVITE sip:12345@ectas.home1.net SIP/2.0

Via: SIP/2.0/UDP sccas.home1.net;comp=sigcomp;branch=z9hG4bGnashds6

Max-Forwards: 70

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

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

Privacy: none

From: <sip:icsueb_public1@home1.net>;;tag=171838

To: <sip:12345@ectas.home1.net>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

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

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

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 ffff::adf:333:ccc:ddd

s=-

c=IN IP6 ffff::adf:333:ccc:ddd

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

19. SIP 100 (Trying) response

The intermediate intermediate IM CN subsystem entnties respond to the SCC AS with a SIP 100 (Trying) response

There is no ICS specific content in this response.

20-21. SIP INVITE request / SIP 100 (Trying) response

The intermediate IM CN subsystem entities forward the SIP INVITE request to private-URI, which will arrived at Transferor AS, and Transferor AS will add Replaces header field in the SIP INVITE request and send to UE C according to 3GPP TS 24.629 [19].

22. SIP 183 (Session Progress) provisional response (UE C to intermediate IM CN subsystem entities) – see example in table A.6.2-22

UE C sends a SIP 183 (Session Progress) provisional response containing SDP-C as a SDP answer towards SCC AS via Transferor AS, according to normal IM CN subsystem procedure.

Table A.6.2-22: 183 (Session Progress) (UE C to intermediate IM CN subsystem entities)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK23G36a.0, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK23436s.1, SIP/2.0/UDP ectas.home1.net;branch=z9hG3bK382b2a.1, SIP/2.0/UDP scscf1.home1.net;branch=z9pG4bK392b2x.1,SIP/2.0/UDP sccas.home1.net;comp=sigcomp;branch=z9hG4bGnashds6

Privacy: none

From:

To:

Call-ID:

Cseq:

Contact: <sip:uec_public1@home1.net;gr=urn:uuid:e763c4acb-8-may-12b1-c678-12b1c88c6fa2>;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"

Content-Type:application/sdp

Content-Length:(…)

v=0

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

s=-

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

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

23. SIP 183 (Session Progress) provisional response

The intermediate IM CN subsystem entities forward the SIP 183 (Session Progress) provisional response to SCC AS via Transferor AS, according to normal IMS procedure.

24-25. SIP ACK request

The SCC AS acknowledges the SIP 200 (OK) response from MGCF with an ACK request containing SDP-C according to standard 3PCC procedure.

26-27. SIP 200 (OK) response

UE C answers the call and sends a SIP 200 (OK) response towards SCC AS according to normal IMS procedure.

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

The SCC AS response to the SIP INVITE request from ICS UE B with a SIP 200 (OK) response according to normal IM CN subsystem procedure.

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

SIP/2.0 200 OK

Via: SIP/2.0/UDP sccas.home1.net;branch=z9hG4bGnashds8,SIP/2.0/UDP scscf1.home1.net;branch=z9pG4bK392b3o.1,SIP/2.0/UDP pcscf2.home1.net;branch=z9hG4bK23G36b.0,SIP/2.0/UDP [3333::ccc:ddd:ccc:eee]:1357;comp=sigcomp;branch=z9hG4bKnashds8

Privacy: none

From:

To:

Call-ID:

Cseq:

Contact: <sip:uec_public1@home1.net;gr=urn:uuid:e763c4acb-8-may-12b1-c678-12b1c88c6fa2>;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"Content-Type:application/sdp

Content-Length: (…)

NOTE 2: Table A.6.2-28 does not show SDP answer.

29. SIP 200 (OK) response

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to ICS UE B according to normal IM CN subystem procedure.

30-31. SIP ACK request

The ICS UE B acknowledges the SIP 200 (OK) from SCC AS with an ACK request according to normal IM CN subsystem procedure.

32-33. SIP ACK request

The SCC AS acknowledges the SIP 200 (OK) from UE C with an ACK request according to normal IM CN subsystem procedure.

34. Session establishment

A session is established between ICS UE B and UE C.

35-38. SIP NOTIFY request / SIP 200 (OK) response

The ICS UE B provides indication that the communication transfer is completed by sending a SIP NOTIFY request as specified in 3GPP TS 24.173 [9].

39. Session Release

After communication transfer is completed the UE A releases the session with ICS UE B, and UE C releases the session with UE A according to the Replaces header field value.

A.6.3 Communication Waiting

A.6.3.1 Communication Waiting when using Gm

Figure A.6.3.1-1 illustrates the signalling flows for the Communication Waiting service when using Gm service control. This example shows an active session between the UE C and the ICS UE B with CS media bearer. The waiting session between UE A and the ICS UE B reuses CS media bearer. There can be other cases where the active session uses an IP media bearer and the waiting session uses a CS bearer and thus the CS bearer needs to be established. Alternatively the active session can use a CS bearer and T-ADS decision for the waiting call can result in deciding to use an IP media bearer.

Figure A.6.3.1-1: Signalling flows for Communication Wait using Gm service control

The details of the signalling flows are as follows:

1. Active session between UE C and ICS UE using CS bearers for media

An active session exists between UE C and ICS UE. The ICS UE uses CS bearers for the audio media.

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

UE A originates a SIP INVITE request in order to establish a session with ICS UE, and thus the SIP INVITE request is forwarded towards the intermediate IM CN subsystem entities in the terminating network.

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

INVITE sip:user2_public2@home2.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;lr>, <sip:scscf1.home1.net;lr>

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

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

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

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

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

Privacy: none

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

To: < sip:user2_public2@home2.net >

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu, 199

Contact: <sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>; +g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-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:ddd

s=-

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

t=0 0

m=video 3400 RTP/AVP 98 99

b=AS:75

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=inactive

a=rtpmap:98 H263

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

a=rtpmap:99 MP4V-ES

m=audio 3456 RTP/AVP 97 0 96

b=AS:25.4

a=curr:qos local none

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

3. SIP INVITE request (Intermediate IM CN subsystem entities to TAS with CW)

As a result of filter criteria evaulation at the terminating S-CSCF, the SIP INVITE request is forwarded to the TAS with CW.

4. CW detection at the TAS with CW (Network determined user busy)

The AS detects the CW condition and inserts a CW indication into the SIP INVITE request as described in 3GPP TS 24.615 [18].

5. SIP INVITE request (TAS with CW to Intermediate IM CN subsystem entities) – see example in Table A.6.3.1-5

Table A.6.3.1-5: SIP INVITE request (TAS WITH CW to intermediate IM CN subsystem entities)

INVITE sip:user2_public2@home2.net SIP/2.0

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

Max-Forwards: 70

Route: <sip:cwas2.home2.net;lr>, <sip:cb03a0s09a2sdfglkj490333@scscf2.home2.net;lr>;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"

Record-Route: <sip:scscf2.home2.net;lr>, <sip:scscf1.home1.net;lr>, <sip:pcscf1.home1.net;lr>

P-Access-Network-Info:

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

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

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

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

Privacy: none

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

To: <sip:user2_public2@home2.net >

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu, 199

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

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

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

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

Content-Length: (…)

–boundary1

Content-Type: application/sdp

v=0

o=-

s=-

–boundary1

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

<?xml version="1.0"?>

<ims-cw xmlns="urn:3gpp:ns:cw:1.0">

<communication-waiting-indication/>

</ims-cw>

–boundary1–

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

As a result of further iFC evaluation, the SIP INVITE request is routed towards the SCC AS.

7. T-ADS

The SCC AS performs T-ADS and selects Gm service control to be used with CS media bearers.

8-9. SIP INVITE request (SCC AS to ICS UE B via Intermediate IM CN subsystem entities)

The SIP INVITE request is routed towards the ICS UE B.

10-11. SIP 180 (Ringing) response (ICS UE B to Intermediate IM CN subsystem entities)

ICS UE B responds with a SIP 180 (Ringing) response with an Alert-Info header field set to "urn:alert:service:call-waiting" according to IETF RFC 7462 [38], which is routed towards the SCC AS through the intermediate IM CN subsystem entities.

12. Hold/resume call between UE C and ICS UE B

[out of scope: user B uses the Call Hold service as specified in subclause 12.2.4 or releases a call]

13-14. SIP 180 (Ringing) response (SCC AS to TAS WITH CW via IM CN subsystem entities)

The SCC AS sends the SIP 180 (Ringing) response with an Alert-Info header field set to "urn:alert:service:call-waiting" according to IETF RFC 7462 [38], towards the TAS WITH CW.

15-16. SIP 180 (Ringing) response (TAS WITH CW to UE A via IM CN subsystem entities)

The SIP 180 (Ringing) response is forwarded through the intermediate IM CN subsystem entities and the originating IM CN subsystem towards UE A.

A.6.3.2 Communication Waiting via the MSC Server enhanced for ICS

Figure A.6.3.2-1 illustrates the signalling flows for the Communication Waiting service via the MSC Server enhanced for ICS. This example shows an active session between a UE and the CS UE with CS media bearer. The waiting session between a UE C and the ICS UE reuses CS media bearer.

Figure A.6.3.2-1: Communication Waiting via the MSC Server enhanced for ICS

The details of the signalling flows are as follows:

1a. Active session between a UE and CS UE using CS bearers for media

An active session exists between a UE and CS UE. The CS UE uses CS bearers for the audio media.

1b. SIP INVITE request (originating IM CN subsystem entities to intermediate IM CN subsystem entities) – see example in table A.6.3.2-1b.

A SIP INVITE request is forwarded towards the intermediate IM CN subsystem entities in the terminating network in order to establish a session with the CS UE.

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

INVITE sip:user2_public2@home2.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;lr>, <sip:scscf1.home1.net;lr>

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

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

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

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

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

Privacy: none

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

To: < sip:user2_public2@home2.net >

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu, 199

Contact: <sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>; +g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-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:ddd

s=-

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

t=0 0

m=video 3400 RTP/AVP 98 99

b=AS:75

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=inactive

a=rtpmap:98 H263

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

a=rtpmap:99 MP4V-ES

m=audio 3456 RTP/AVP 97 0 96

a=tcap:1 RTP/AVPF

a=pcfg:1 t=1

b=AS:25.4

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=inactive

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

4. SIP INVITE request (Intermediate IM CN subsystem entities to TAS with CW)

As a result of filter criteria evaulation at the terminating S-CSCF, the SIP INVITE request is forwarded to the TAS with CW.

6. CW detection at the TAS with CW (Network determined user busy)

The AS detects the CW condition and inserts a CW indication into the SIP INVITE request as described in 3GPP TS 24.615 [18].

7. SIP INVITE request (TAS with CW to Intermediate IM CN subsystem entities) – see example in table A.6.3.2-7

Table A.6.3.2-7: SIP INVITE request (TAS with CW to intermediate IM CN subsystem entities)

INVITE sip:user2_public2@home2.net SIP/2.0

Max-Forwards:

Route: <sip:cwas2.home2.net;lr>, <sip:cb03a0s09a2sdfglkj490333@scscf2.home2.net;lr>;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"

Record-Route: <sip:scscf2.home2.net;lr>, <sip:scscf1.home1.net;lr>, <sip:pcscf1.home1.net;lr>

P-Access-Network-Info:

P-Asserted-Identity:

P-Charging-Vector:

P-Asserted-Service:

Accept-Contact:

Privacy:

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

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

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

Content-Length: (…)

–boundary1

Content-Type: application/sdp

v=0

o=-

s=-

–boundary1

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

<?xml version="1.0"?>

<ims-cw xmlns="urn:3gpp:ns:cw:1.0">

<communication-waiting-indication/>

</ims-cw>

–boundary1–

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

As a result of further iFC evaluation, the SIP INVITE request is routed towards the SCC AS.

12-13. SIP INVITE request (SCC AS to the MSC Server enhanced for ICS via Intermediate IM CN subsystem entities)

The SCC AS selects the MSC Server enhanced for ICS.The SIP INVITE request is routed towards the CS UE.

16. SIP 180 (Ringing) response (CS UE and MSC Server enhanced for ICS)

MSC Server enhanced for ICS and the CS UE signal according to 3GPP TS 24.083 [26].

17-22. SIP 180 (Ringing) response (CS UE to Intermediate IM CN subsystem entities)

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