A.6 Signalling flows for supplementary service invocation for ICS
24.2923GPPIP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS)Release 17Stage 3TS
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=-
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
–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
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:
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=-
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
m=
a=
a=
b=
a=
a=
a=
a=
a=
a=
a=
a=
a=
–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)
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.
Annex B (normative):
Media feature tags and feature-capability indicators defined within the current document