IP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS)

3GPP TS 24.292 V9.19.0 (2016-09)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals;
IP Multimedia (IM) Core Network (CN) subsystem
Centralized Services (ICS);
Stage 3
(Release 9)
	
The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.	
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.	
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.


Keywords
Circuit Switched, IMS, Supplementary Services, LTE

3GPP
Postal address

3GPP support office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org

Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© 2016, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.

UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association
Contents
 TOC \o "1-9" 1	Scope	 PAGEREF _Toc462929106 \h 8
2	References	 PAGEREF _Toc462929107 \h 8
3	Definitions and abbreviations	 PAGEREF _Toc462929108 \h 10
3.1	Definitions	 PAGEREF _Toc462929109 \h 10
3.2	Abbreviations	 PAGEREF _Toc462929110 \h 11
4	Overview of IP Multimedia (IM) Core Network (CN) subsystem centralized services (ICS)	 PAGEREF _Toc462929111 \h 12
4.1	General	 PAGEREF _Toc462929112 \h 12
4.2	Underlying network capabilities	 PAGEREF _Toc462929113 \h 13
4.3	URI and address assignments	 PAGEREF _Toc462929114 \h 13
5	Functional entities	 PAGEREF _Toc462929115 \h 14
5.1	Introduction	 PAGEREF _Toc462929116 \h 14
5.2	User Equipment (UE)	 PAGEREF _Toc462929117 \h 14
5.3	MSC Server enhanced for ICS	 PAGEREF _Toc462929118 \h 14
5.4	Application Server (AS)	 PAGEREF _Toc462929119 \h 14
6	Roles for registration in the IM CN subsystem	 PAGEREF _Toc462929120 \h 15
6.1	Introduction	 PAGEREF _Toc462929121 \h 15
6.2	ICS UE	 PAGEREF _Toc462929122 \h 15
6.3	MSC Server enhanced for ICS	 PAGEREF _Toc462929123 \h 15
6.3.1	General	 PAGEREF _Toc462929124 \h 15
6.3.2	Initial registration	 PAGEREF _Toc462929125 \h 16
6.3.3	Sending the REGISTER request	 PAGEREF _Toc462929126 \h 18
6.3.4	Subscription to the registration-state event package	 PAGEREF _Toc462929127 \h 18
6.3.5	Reregistration	 PAGEREF _Toc462929128 \h 19
6.3.6	Deregistration	 PAGEREF _Toc462929129 \h 20
6.3.6.1	S-CSCF initiated deregistration	 PAGEREF _Toc462929130 \h 20
6.3.6.2	MSC Server enhanced for ICS initiated deregistration	 PAGEREF _Toc462929131 \h 20
6.4	SCC AS	 PAGEREF _Toc462929132 \h 21
7	Roles for call origination	 PAGEREF _Toc462929133 \h 21
7.1	Introduction	 PAGEREF _Toc462929134 \h 21
7.2	ICS UE	 PAGEREF _Toc462929135 \h 21
7.2.1	General	 PAGEREF _Toc462929136 \h 21
7.2.2	ICS UE using Gm	 PAGEREF _Toc462929137 \h 21
7.2.3	ICS UE using CS	 PAGEREF _Toc462929138 \h 22
7.2.4	ICS UE using I1	 PAGEREF _Toc462929139 \h 22
7.3	MSC Server enhanced for ICS	 PAGEREF _Toc462929140 \h 23
7.4	SCC AS	 PAGEREF _Toc462929141 \h 23
7.4.1	General	 PAGEREF _Toc462929142 \h 23
7.4.2	SCC AS for service control over Gm	 PAGEREF _Toc462929143 \h 23
7.4.2.1	CS bearer is requested by the ICS UE	 PAGEREF _Toc462929144 \h 23
7.4.2.2	Non CS bearer is requested by the ICS UE	 PAGEREF _Toc462929145 \h 25
7.4.3	SCC AS for service control over CS	 PAGEREF _Toc462929146 \h 25
7.4.4	SCC AS for service control over I1	 PAGEREF _Toc462929147 \h 26
7.4.4.1	General	 PAGEREF _Toc462929148 \h 26
7.4.4.2	Failure handling	 PAGEREF _Toc462929149 \h 27
8	Roles for call modifcation initiated from the ICS UE	 PAGEREF _Toc462929150 \h 27
8.1	Introduction	 PAGEREF _Toc462929151 \h 27
8.2	ICS UE	 PAGEREF _Toc462929152 \h 27
8.2.1	General	 PAGEREF _Toc462929153 \h 27
8.2.2	ICS UE is using Gm	 PAGEREF _Toc462929154 \h 27
8.2.2.1	General	 PAGEREF _Toc462929155 \h 27
8.2.2.2	ICS UE adds a CS bearer	 PAGEREF _Toc462929156 \h 27
8.2.2.3	ICS UE adds media in PS domain	 PAGEREF _Toc462929157 \h 27
8.2.2.5	ICS UE removes a CS bearer	 PAGEREF _Toc462929158 \h 28
8.2.2.6	ICS UE removes PS media	 PAGEREF _Toc462929159 \h 28
8.2.2.7	ICS UE add/remove CS video media	 PAGEREF _Toc462929160 \h 28
8.3	MSC server enhanced for ICS	 PAGEREF _Toc462929161 \h 28
8.4	SCC AS	 PAGEREF _Toc462929162 \h 28
8.4.1	General	 PAGEREF _Toc462929163 \h 28
8.4.2	SCC AS actions when UE adds a CS bearer	 PAGEREF _Toc462929164 \h 28
8.4.3	SCC AS adds media in the PS domain	 PAGEREF _Toc462929165 \h 29
9	Roles for call modifcation initiated towards an ICS UE	 PAGEREF _Toc462929166 \h 30
9.1	Introduction	 PAGEREF _Toc462929167 \h 30
9.2	ICS UE	 PAGEREF _Toc462929168 \h 30
9.2.1	General	 PAGEREF _Toc462929169 \h 30
9.2.2	ICS UE using Gm	 PAGEREF _Toc462929170 \h 30
9.2.2.1	General	 PAGEREF _Toc462929171 \h 30
9.2.2.2	 ICS UE is offered a CS bearer	 PAGEREF _Toc462929172 \h 30
9.2.2.3	ICS UE is offered PS media	 PAGEREF _Toc462929173 \h 31
9.2.2.4	ICS UE is offered media both in CS and PS domain	 PAGEREF _Toc462929174 \h 31
9.2.2.5	SCC AS removes a CS bearer	 PAGEREF _Toc462929175 \h 31
9.2.2.6	SCC AS removes PS media	 PAGEREF _Toc462929176 \h 31
9.3	MSC server enhanced for ICS	 PAGEREF _Toc462929177 \h 31
9.4	SCC AS	 PAGEREF _Toc462929178 \h 31
9.4.1	Terminating Access domain selection	 PAGEREF _Toc462929179 \h 31
9.4.2	SCC AS adds a CS bearer	 PAGEREF _Toc462929180 \h 31
9.4.3	SCC AS adds PS media	 PAGEREF _Toc462929181 \h 32
9.4.4	SCC AS removes a CS bearer	 PAGEREF _Toc462929182 \h 33
9.4.5	SCC AS add/remove CS video media	 PAGEREF _Toc462929183 \h 33
10	Roles for call termination	 PAGEREF _Toc462929184 \h 33
10.1	Introduction	 PAGEREF _Toc462929185 \h 33
10.2	ICS UE	 PAGEREF _Toc462929186 \h 33
10.2.1	General	 PAGEREF _Toc462929187 \h 33
10.2.2	ICS UE using Gm	 PAGEREF _Toc462929188 \h 33
10.2.2.1	General	 PAGEREF _Toc462929189 \h 33
10.2.2.2	Call control over Gm and all media over IP bearer	 PAGEREF _Toc462929190 \h 33
10.2.2.3	Call control over Gm and voice or voice and video over CS bearer	 PAGEREF _Toc462929191 \h 34
10.2.2.4	Call control over Gm and T-ADS executed by the UE	 PAGEREF _Toc462929192 \h 35
10.2.3	ICS UE using CS	 PAGEREF _Toc462929193 \h 37
10.2.4	CS fallback	 PAGEREF _Toc462929194 \h 37
10.2.5	ICS UE using I1	 PAGEREF _Toc462929195 \h 38
10.2.5.1	Call control over I1 and media over CS bearer	 PAGEREF _Toc462929196 \h 38
10.3	MSC Server enhanced for ICS	 PAGEREF _Toc462929197 \h 38
10.4	SCC AS	 PAGEREF _Toc462929198 \h 38
10.4.1	General	 PAGEREF _Toc462929199 \h 38
10.4.2	Terminating Access Domain Selection	 PAGEREF _Toc462929200 \h 38
10.4.3	SCC AS for call termination in IM CN	 PAGEREF _Toc462929201 \h 39
10.4.4	SCC AS for call control over Gm and voice or voice and video over CS	 PAGEREF _Toc462929202 \h 40
10.4.5	SCC AS for call termination to CS network via MSC Server enhanced for ICS	 PAGEREF _Toc462929203 \h 42
10.4.6	SCC AS allowing UE to execute T-ADS	 PAGEREF _Toc462929204 \h 42
10.4.7	SCC AS for call termination over CS	 PAGEREF _Toc462929205 \h 44
10.4.8	SCC AS for call control over I1 and media over CS	 PAGEREF _Toc462929206 \h 44
10.4.8.0	SCC AS sends I1 Invite message	 PAGEREF _Toc462929207 \h 44
10.4.8.1	SCC AS receives a I1 Bye message	 PAGEREF _Toc462929208 \h 45
10.4.8.2	SCC AS receives a SIP Bye message from the CS domain	 PAGEREF _Toc462929209 \h 45
10.4.8.3	SCC AS receives a SIP BYE message from a remote ICS UE	 PAGEREF _Toc462929210 \h 45
10.4.8.4	SCC AS receives SIP error from remote UE	 PAGEREF _Toc462929211 \h 46
11	Roles for session release	 PAGEREF _Toc462929212 \h 46
11.1	Introduction	 PAGEREF _Toc462929213 \h 46
11.2	ICS UE	 PAGEREF _Toc462929214 \h 46
11.2.1	General	 PAGEREF _Toc462929215 \h 46
11.2.2	ICS UE using Gm	 PAGEREF _Toc462929216 \h 46
11.2.3	ICS UE using CS	 PAGEREF _Toc462929217 \h 46
11.2.4	ICS UE using I1	 PAGEREF _Toc462929218 \h 46
11.3	MSC Server enhanced for ICS	 PAGEREF _Toc462929219 \h 46
11.4	SCC AS	 PAGEREF _Toc462929220 \h 47
11.4.1	General	 PAGEREF _Toc462929221 \h 47
11.4.2	SCC AS for service control over Gm	 PAGEREF _Toc462929222 \h 47
11.4.3	SCC AS procedure upon loss of Gm service control	 PAGEREF _Toc462929223 \h 47
11.4.4	SCC AS for service control over I1	 PAGEREF _Toc462929224 \h 47
12	Supplementary service invocation for ICS	 PAGEREF _Toc462929225 \h 48
12.1	Supplementary service invocation for an ICS UE with IMS sessions using CS bearer	 PAGEREF _Toc462929226 \h 48
12.1.1	Overview	 PAGEREF _Toc462929227 \h 48
12.1.2	Use of Gm reference point	 PAGEREF _Toc462929228 \h 48
12.1.2.1	Line ID Services (OIP, OIR, TIP, TIR)	 PAGEREF _Toc462929229 \h 48
12.1.2.2	 Communication Diversion Services	 PAGEREF _Toc462929230 \h 48
12.1.2.3	Communication Barring	 PAGEREF _Toc462929231 \h 48
12.1.2.4	Communication Hold/Resume	 PAGEREF _Toc462929232 \h 48
12.1.2.5	Explicit Communication Transfer	 PAGEREF _Toc462929233 \h 49
12.1.2.6	Conferencing	 PAGEREF _Toc462929234 \h 49
12.1.2.7	Communication Waiting	 PAGEREF _Toc462929235 \h 49
12.1.4	When use of Gm reference point is not possible due to VPLMN limitations	 PAGEREF _Toc462929236 \h 49
12.1.4.1	When attached to an MSC Server enhanced for ICS	 PAGEREF _Toc462929237 \h 49
12.1.4.2	When attached to an MSC Server not enhanced for ICS	 PAGEREF _Toc462929238 \h 49
12.2	Supplementary service invocation using the MSC Server enhanced for ICS	 PAGEREF _Toc462929239 \h 49
12.2.1	Line ID Services (OIP, OIR, TIP, TIR)	 PAGEREF _Toc462929240 \h 49
12.2.2	Communication Diversion (CDIV) Services	 PAGEREF _Toc462929241 \h 50
12.2.2.1	General	 PAGEREF _Toc462929242 \h 50
12.2.2.2	Communication Forwarding Unconditional (CFU)	 PAGEREF _Toc462929243 \h 50
12.2.2.3	Communication Forwarding Busy (CFB)	 PAGEREF _Toc462929244 \h 50
12.2.2.4	Communication Forwarding No Reply (CFNR)	 PAGEREF _Toc462929245 \h 50
12.2.2.5	Communication Forwarding on Not Logged-in (CFNL)	 PAGEREF _Toc462929246 \h 50
12.2.2.6	Communication Deflection (CD)	 PAGEREF _Toc462929247 \h 50
12.2.2.7	Communication Forwarding on Subscriber Not Reachable (CFNRc)	 PAGEREF _Toc462929248 \h 50
12.2.2.8	Void	 PAGEREF _Toc462929249 \h 50
12.2.2.9	Diversion notifications to originating users	 PAGEREF _Toc462929250 \h 50
12.2.3	Communication Barring (CB)	 PAGEREF _Toc462929251 \h 51
12.2.4	Communication Hold/Resume	 PAGEREF _Toc462929252 \h 51
12.2.5	Explicit Communication Transfer (ECT)	 PAGEREF _Toc462929253 \h 51
12.2.6	Conferencing	 PAGEREF _Toc462929254 \h 51
12.2.7	Communication Waiting (CW)	 PAGEREF _Toc462929255 \h 51
12.3	Supplementary service invocation for non ICS UE when attached to an MSC Server not enhanced for ICS	 PAGEREF _Toc462929256 \h 52
12.3.1	Line ID Services (OIP, OIR, TIP, TIR)	 PAGEREF _Toc462929257 \h 52
12.3.2	Communication Diversion services	 PAGEREF _Toc462929258 \h 52
12.3.2.1	Communication Diversion services; CFU, CFNL	 PAGEREF _Toc462929259 \h 52
12.3.2.2	Communication Diversion services; CFNR, CFB	 PAGEREF _Toc462929260 \h 52
12.3.2.3	Communication Diversion services; Communication Deflection	 PAGEREF _Toc462929261 \h 52
12.3.3	Communication Barring	 PAGEREF _Toc462929262 \h 52
12.3.4	Communication Hold/Resume	 PAGEREF _Toc462929263 \h 52
12.3.5	Explicit Communication Transfer	 PAGEREF _Toc462929264 \h 52
12.3.6	Conferencing	 PAGEREF _Toc462929265 \h 52
12.3.7	User configuration of supplementary services	 PAGEREF _Toc462929266 \h 52
13	Supplementary service configuration for ICS	 PAGEREF _Toc462929267 \h 53
13.1	General	 PAGEREF _Toc462929268 \h 53
13.2	ICS UE	 PAGEREF _Toc462929269 \h 53
13.3	MSC server enhanced for ICS	 PAGEREF _Toc462929270 \h 53
Annex A (informative):	Example signalling flows	 PAGEREF _Toc462929271 \h 54
A.1	Scope of signalling flows	 PAGEREF _Toc462929272 \h 54
A.2	Introduction	 PAGEREF _Toc462929273 \h 54
A.2.1	General	 PAGEREF _Toc462929274 \h 54
A.2.2	Key required to interpret signalling flows	 PAGEREF _Toc462929275 \h 54
A.3	Signalling flows for registration	 PAGEREF _Toc462929276 \h 55
A.3.1	Signalling flows for CS UE IMS registration when using an MSC Server enhanced for ICS	 PAGEREF _Toc462929277 \h 55
A.4	Signalling flows for call origination	 PAGEREF _Toc462929278 \h 62
A.4.1	Signalling flows for ICS UE origination with CS media using Gm reference point when using an MSC Server enhanced for ICS	 PAGEREF _Toc462929279 \h 62
A.4.2	Signalling flows for ICS UE origination with CS media using Gm reference point when using an MSC Server not enhanced for ICS	 PAGEREF _Toc462929280 \h 71
A.4.3	Signalling flows for CS UE origination when using an MSC Server enhanced for ICS — multiple codecs used	 PAGEREF _Toc462929281 \h 75
A.4.4	Signalling flows for CS UE origination when using an MSC Server enhanced for ICS – one codec used	 PAGEREF _Toc462929282 \h 83
A.4.5	Signalling flows for CS UE origination when using an MSC Server not enhanced for ICS	 PAGEREF _Toc462929283 \h 88
A.4.6	Signalling flows for ICS UE origination when using I1 interface	 PAGEREF _Toc462929284 \h 95
A.5	Signalling flows for call termination	 PAGEREF _Toc462929285 \h 101
A.5.1	Signalling flows for termination to a CS UE registered in IMS using an MSC Server enhanced for ICS – multiple codecs used	 PAGEREF _Toc462929286 \h 101
A.5.2	Signalling flows for termination to a CS UE not registered in IMS	 PAGEREF _Toc462929287 \h 110
A.5.3	Signalling flows for termination to an ICS UE with CS media using Gm reference point when using an MSC server enhanced for ICS	 PAGEREF _Toc462929288 \h 114
A.5.4	Signalling flows for termination to an ICS UE with CS media using Gm reference point when using an MSC Server not enhanced for ICS	 PAGEREF _Toc462929289 \h 124
A.5.5	Signalling flows for termination to an ICS UE with CS media using Gm reference point when using an MSC Server enhanced for ICS and UE assisted T-ADS	 PAGEREF _Toc462929290 \h 128
A.5.6	Signalling flows for termination to an ICS UE with CS media using I1 reference point when using an MSC Server enhanced for ICS	 PAGEREF _Toc462929291 \h 136
A.5.7	Signalling flows for termination to an ICS UE with CS media using I1 reference point when using an MSC server enhanced for ICS and UE assisted T-ADS	 PAGEREF _Toc462929292 \h 143
A.6	Signalling flows for supplementary service invocation for ICS	 PAGEREF _Toc462929293 \h 149
A.6.1	Communication Hold/Resume with Announcement	 PAGEREF _Toc462929294 \h 149
A.6.2	Explicit Communication Transfer using Gm reference point, ICS UE as transfer recipient	 PAGEREF _Toc462929295 \h 155
A.6.3	Communication Waiting	 PAGEREF _Toc462929296 \h 162
A.6.3.1	Communication Waiting when using Gm	 PAGEREF _Toc462929297 \h 162
A.6.3.2	Communication Waiting via the MSC Server enhanced for ICS	 PAGEREF _Toc462929298 \h 166
Annex B (normative):	Media feature tags defined within the current document	 PAGEREF _Toc462929299 \h 171
B.1	General	 PAGEREF _Toc462929300 \h 171
B.2	Definition of media feature tag g.3gpp.ics	 PAGEREF _Toc462929301 \h 171
B.3	Definition of media feature tag g.3gpp.accesstype	 PAGEREF _Toc462929302 \h 171
Annex C (informative):	Change history	 PAGEREF _Toc462929303 \h 173

Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x	the first digit:
1	presented to TSG for information;
2	presented to TSG for approval;
3	or greater indicates TSG approved document under change control.
y	the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc.
z	the third digit is incremented when editorial only changes have been incorporated in the document.
1	Scope
IP Multimedia (IM) Core Network (CN) subsystem centralized services (ICS) allow for the delivery of consistent IMS services to the user regardless of the attached access type (e.g. CS domain access or IP-CAN).
The present document provides the protocol details for the realization of ICS based on the Session Initiation protocol (SIP), the Session Description Protocol (SDP), the I1 protocol, and the protocols of the 3GPP Circuit-Switched (CS) domain (e.g. CAP, MAP, ISUP, BICC and the NAS call control protocol for the CS access).
This document makes no ICS specific enhancements to SIP or SDP beyond those specified in 3GPP TS 24.229 [11].
The present document is applicable to User Equipment (UEs), MSC Servers and Application Servers (AS) providing ICS capabilities.
2	References
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non‑specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]	3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2]	3GPP TS 22.173: "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services".
[3]	3GPP TS 23.002: "Network architecture".
[4]	3GPP TS 23.003: "Numbering, addressing and identification".
[4A]	3GPP TS 23.153: "Out of band transcoder control; Stage 2".
[5]	3GPP TS 23.228: "IP multimedia subsystem; Stage 2".
[6]	3GPP TS 23.292: "IP Multimedia Subsystem (IMS) Centralized Services; Stage 2".
[7]	3GPP TS 24.008: "Mobile radio interface layer 3 specification; Core Network protocols; Stage 3".
[8]	3GPP TS 24.147: "Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3".
[8A]	3GPP TS 24.167: "3GPP IMS Management Object (MO); Stage 3".
[9]	3GPP TS 24.173: "IMS Multimedia telephony service and supplementary services; Stage 3".
[10]	3GPP TS 24.228 Release 5: "Signalling flows for the IP multimedia call control based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
[11]	3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
[11A]	3GPP TS 24.301: "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3".
[11B]	3GPP TS 24.294: "IMS Centralized Services (ICS) Protocol via I1 Interface; Stage 3".
[12]	3GPP TS 24.604: "Communication Diversion (CDIV) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification".
[13]	3GPP TS 24.605: "Conference (CONF) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification".
[14]	3GPP TS 24.607: "Originating Identification Presentation (OIP) and Originating Identification Restriction (OIR) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification".
[15]	3GPP TS 24.608: "Terminating Identification Presentation (TIP) and Terminating Identification Restriction (TIR) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification".
[16]	3GPP TS 24.610: "Communication HOLD (HOLD) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification".
[17]	3GPP TS 24.611: "Anonymous Communication Rejection (ACR) and Communication Barring (CB); using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification".
[18]	3GPP TS 24.615: "Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol Specification".
[19]	3GPP TS 24.629: "Explicit Communication Transfer (ECT) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification".
[20]	3GPP TS 29.002: "Mobile Application Part (MAP) specification".
[21]	3GPP TS 29.078: "Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4; CAMEL Application Part (CAP) specification".
[22]	3GPP TS 29.163: "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks".
[23]	3GPP TS 29.228: "IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling flows and message contents".
[24]	3GPP TS 29.292: "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and MSC Server for IMS Centralized Services (ICS)".
[25]	3GPP TS 29.328: "IP Multimedia Subsystem (IMS) Sh interface; Signalling flows and message contents".
[26]	3GPP TS 29.329: "Sh interface based on the Diameter protocol; Protocol details".
[27]	3GPP TS 32.260: "Telecommunication management; Charging management; IP Multimedia Subsystem (IMS) charging".
[28]	ITU-T Recommendations Q.761 to Q.764 (2000): "Specifications of Signalling System No.7 ISDN User Part (ISUP)".
[29]	ITU-T Recommendations Q.1902.1 to Q.1902.6 (07/2001): "Bearer Independent Call Control".
[30]	IETF RFC 3263 (June 2002): " Session Initiation Protocol (SIP): Locating SIP Servers".
[31]	IETF RFC 3264 (June 2002): "An Offer/Answer Model with Session Description Protocol (SDP)". 
[32]	IETF RFC 3265 (June 2002): "Session Initiation Protocol (SIP) Specific Event Notification".
[33]	IETF RFC 3680 (March 2004): "A Session Initiation Protocol (SIP) Event Package for Registrations".
[34]	IETF RFC 3840 (August 2004): "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)".
[35]	IETF RFC 5628 (October 2009): "Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)".
[35A]	IETF RFC 3841 (August 2004): "Caller Preferences for the Session Initiation Protocol (SIP)".
[36]	IETF RFC 7195 (May 2014): "Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)".
[37]	3GPP2 C.S0001-D: "Introduction to cdma2000 Spread Spectrum Systems - Revision D".
[38]	IETF RFC 7462 (March 2015): "URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)".
[39]	IETF RFC 7006 (September 2013): "Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)".
[40]	IETF RFC 5939 (September 2010): "Session Description Protocol (SDP) Capability Negotiation".
[41]	IETF RFC 6871 (February 2013): "SDP media capabilities Negotiation".
[42]	IETF RFC 3966 (December 2004): "The tel URI for Telephone Numbers".
[43]	3GPP TS 24.286: "IP Multimedia (IM) Core Network (CN) subsystem Centralised Services(ICS); Management Object (MO)".
[44]	ITU-T Recommendation E.164: "The international public telecommunication numbering plan".
[45]	IETF RFC 3261 (June 2002): "SIP: Session Initiation Protocol".
[46]	3GPP TS 44.018: "Mobile radio interface layer 3 specification; Radio Resource Control (RRC) protocol".
3	Definitions and abbreviations
3.1	Definitions
For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP TR 21.905 [1].
CS call: A connection established via the circuit switched domain in accordance with the related procedures e.g. such as described in 3GPP TS 24.008 [7], 3GPP2 C.S0001-D [37] and of which the established bearer is only used within a CS connection but not used as a media stream for a related IM CN subsystem session.
CS media: A media stream established through CS signalling (e.g. 3GPP TS 24.008 [7], 3GPP2 C.S0001-D [37]) and transported through the PSTN with a session description defined by IETF RFC 7195 [36].
IMS Voice over PS Session (IMSVoPS) indicator: An indication from the network indicating that IMS voice over PS session(s) are or are not supported for a specific RAT. The indication is provided by the network to the UE at each NAS registration. When the UE is in S1-mode, the IMSVoPS indicator defined in 3GPP TS 24.301 [11A] applies. When the UE is in Iu-mode or A/Gb mode, the IMSVoPS indicator defined in 3GPP TS 24.008 [7] applies. 
NAS combined attach or combined TA update: A NAS attach procedure where the EPS attach type is set to combined EPS/IMSI attach or a NAS tracking area update procedure where the EPS update type is set to "combined TA/LA updating with IMSI attach" or "combined TA/LA updating". See also 3GPP TS 24.301 [11A].
Successful NAS combined attach or combined TA update: The successful outcome of a NAS combined attach procedure where for the NAS attach procedure the EPS attach result is "combined EPS/IMSI attach" without "SMS only" indication or where for the NAS tracking area update procedure the EPS update result is "combined TA/LA updated" or "combined TA/LA updated and ISR activated" without "SMS only" indication. See also 3GPP TS 24.301 [11A].
Failure to access the CS domain: In this specification, failure to access the CS domain includes not receiving a location updating area accept message as specified in 3GPP TS 24.008 [8]) and the NAS sublayer not receiving an indication of successful NAS combined attach or combined TA update.
PSI DN: Is a digit string that conforms to ITU-T Recommendation E.164 [44].
UE in S1-mode: In this specification, a UE in this mode perform an EPS attach procedure with a MME, as defined in 3GPP TS 24.301 [11A].
UE in Iu-mode or UE in A/Gb mode: In this specification, a UE in one of these modes performs a GPRS attach procedure with a SGSN, as defined in 3GPP TS 24.008 [7].
SCC AS enhanced for I1: SCC AS supporting I1 as defined in 3GPP TS 24.294 [11B].
For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.292 [6] apply:
ICS UE
Correlation MSISDN
MSC Server enhanced for ICS
SCC AS

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.629 [19] apply:
transferee
transferor
transfer target

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.228 [5] apply:
Public Service Identity (PSI)

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.003 [3] apply:
CS Domain Routeing Number (CSRN)
IP Multimedia Routeing Number (IMRN)

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.301 [11A] apply:
CS fallback capable UE
EPS attach result
EPS attach type
EPS update result
EPS update type
TA

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.008 [7] apply:
routing area (RA)

For the purposes of the present document, the following terms and definitions given in 3GPP TS 44.018 [44] apply:
dual transfer mode (DTM)
3.2	Abbreviations
For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 3GPP TR 21.905 [1].
ADS	Access Domain Selection
AS	Application Server
BICC	Bearer Independent Call Control
CAMEL	Customised Applications for Mobile network Enhanced Logic
CB	Communication Barring
CD	Communication Deflection
CDIV	Communication DIVersion
CFNL	Communication Forwarding on Not Logged-in
CFNR	Communication Forwarding No Reply
CFNRc	Communication Forwarding on subscriber Not Reachable
CFU	Communication Forwarding Unconditional
CN	Core Network
CSFB	CS Fall Back
CSRN	CS domain Routing Number
CW	Communication Waiting
DN	Directory Number
ECT	Explicit Communication Transfer
ICS	IMS Centralized Services
IMSVoPS	IMS Voice over PS Session
IUA	ICS User Agent
HLR	Home Location Register
HSS	Home Subscriber Server
IM	IP Multimedia
IMRN	IP Multimedia Routeing Number
MSC	Mobile Switching Center
NAS	Non Access Stratum
OIP	Originating Identification Presentation
OIR	Originating Identification Restriction
SCC AS	Service Centralization and Continuity Application Server
T-ADS	Terminating ADS
TA	Tracking Area
TIP	Terminating Identification Presentation
TIR	Terminating Identification Restriction
UA	User Agent
UE	User Equipment
URI	Universal Resource Identifier
4	Overview of IP Multimedia (IM) Core Network (CN) subsystem centralized services (ICS)
4.1	General
ICS allows for the delivery of consistent IMS services to the user regardless of the attached access type (e.g. CS domain access or IP-CAN). ICS provides communication services such that all services, and service control, are based on IM CN subsystem mechanisms and enablers. This includes enabling IM CN subsystem services when using CS access for the media bearer.
When using a CS access network, or when using a PS access networks that does not support the full duplex speech component of an IM CN subsystem service, the CS core network is utilized to establish a circuit switch access according to e.g. 3GPP TS 24.008 [7] or 3GPP2 C.S0001-D [37] for use as media for IM CN subsystem sessions.
If the PS access network does support the full duplex speech component of an IMS service then existing IM CN subsystem session procedures are used as specified in 3GPP TS 24.229 [11].
ICS provides mechanisms to support the use of CS media bearer for IM CN subsystem sessions. With ICS, IM CN subsystem sessions using CS media are treated as standard IM CN subsystem sessions for the purpose of service control.
Sessions originated by ICS subscribers in both the IM CN subsystem and in the CS domain are subject to anchoring in the IM CN subsystem. Similarly, voice calls terminated to ICS subscribers are anchored in the IM CN subsystem. When anchoring occurs, such sessions have a path to the SCC AS from either the CS access domain or the IM CN subsystem so that the SCC AS can be used to provide service centralization. 
In order for the above to occur, the following procedures are supplied within this specification:
-	procedures for call origination are specified in Clause 7;
-	procedures for call modification initiated from the ICS UE are specified in Clause 8;
-	procedures for call modification initiated towards an ICS UE are specified in Clause 9;
-	procedures for call termination are specified in Clause 10;
-	procedures for session release are specified in Clause 11; and
-	procedures for supplementary service invocation for ICS are specified in Clause 12.
4.2	Underlying network capabilities
ICS assumes the use of a number of underlying network capabilities:
1)	provision by the home network operator of an ICS specific AS on the IM CN subsystem, as specified in 3GPP TS 24.229 [11];
2)	signalling within the CS domain (both within the home network and between the home network and any visited network) supported using either ISUP (as defined in ITU-T Recommendations Q.761 to Q.764 [28]) or BICC (as defined in ITU-T Recommendations Q.1902.1 to Q.1902.6 [29]);
3)	provision of CAMEL Phase 2 or later (as specified in 3GPP TS 29.078 [21]) at the MSC Server;
4)	if the MSC Server is not enhanced for ICS, interworking between the CS domain and the IM CN subsystem is provided by an MGCF in accordance with 3GPP TS 29.163 [22]; and
5)	capability of the IP-CAN to support full duplex speech component, for example as used in IMS multimedia telephony.
4.3	URI and address assignments
In order to support ICS to a subscriber the following URI and address assignments are assumed:
a)	the ICS UE will be configured to be reachable in both the IM CN subsystem and the CS domain by one to many public telecommunication numbers which should be correlated between the CS domain and IM CN subsystem. The subscriber's IM CN subsystem profile will need to be provisioned with a tel URI, either as the default public user identity or associated with it, equivalent to a DN (e.g. MSISDN) in the subscriber's CS profile associated with speech/audio (e.g. TS11).
b)	void
c)	a PSI DN is assigned that can reach an ICS application that can support the ICS capabilities for that ICS UE. The PSI DNs can be dynamically allocated at the time that the call is rerouted to the IM CN subsystem for ICS purposes. The PSI DN is used specifically in the case of Gm or I1 service control for the purpose of CS bearer setup and does not apply to other procedures. The IM CN subsystem is configured to treat the PSI DN as a PSI;
d)	a non ICS UEs which are not registered in the IM CN subsystem might still be attached to the CS network at an MSC. In this scenario, a CSRN is assigned for routing the call to the CS domain;
e)	an MSC Server enhanced for ICS shall use a private user identity and public user identity specifically reserved for IM CN subsystem registrations from an MSC Server. This is to avoid conflicts in IM CN subsystem registration by a UE and an MSC Server registering on behalf of the same subscriber. The identities reserved for ICS identities are defined in 3GPP TS 23.003 [4]; and an MSC Server shall use only those public user identities representing E.164 numbers from the subscriber's IM CN subsystem profile to originate and terminate calls; 
f)	an MSC Server enhanced for ICS is provisioned with a string that identifies the visited network at the home network. The string needs to be different than the value provisioned to a P-CSCF, as specified in 3GPP TS 24.229 [11], in order to distinguish between a P-CSCF and an MSC Server enhanced for ICS; and
g)	an IMRN is assigned that can reach an ICS application that can support the ICS capabilities for that UE. IMRNs can be dynamically allocated. The IM CN subsystem is configured to treat the IMRN as a PSI.
h)	an MSC Server enhanced for ICS shall provide a home network domain name from the subscriber's IMSI as defined in 3GPP TS 23.003 [4].
5	Functional entities
5.1	Introduction
This clause associates the functional entities described for the IM CN subsystem and for the CS domain, with the ICS roles described in the stage 2 architecture document (see 3GPP TS 23.292 [6]).
5.2	User Equipment (UE)
A UE establishing the service control signalling path over Gm, that is compliant with this specification shall implement the role of ICS UE capabilities defined in: 
-	subclause 6.2;
-	subclause 7.2 apart from subclause 7.2.4;
-	subclause 8.2;
-	subclause 9.2;
-	subclause 10.2 apart from subclause 10.2.5; and
-	subclause 11.2 apart from subclause 11.2.4.
A UE that is compliant with this specification may support establishing the service control signalling path over I1. A UE that supports establishing the service control signalling path over I1 shall implement the role of ICS UE capabilities defined in: 
-	subclause 7.2.4;
-	subclause 10.2.5; and
-	subclause 11.2.4.
5.3	MSC Server enhanced for ICS
Where the MSC server is supporting I2, the MSC server is enhanced for ICS. The MSC Server enhanced for ICS shall provide the UA role as defined in Annex A of 3GPP TS 24.229 [11], with the exceptions and additional capabilities as described in subclauses 6.3, 7.3, 8.3, 9.3, 10.3 and 11.3.
5.4	Application Server (AS)
The ICS AS provides the following roles:
a)	ICS User Agent (IUA) as defined in 3GPP TS 23.292 [6] subclause 5.3.1;
b)	Terminating Access Domain Selection (T-ADS) as defined in 3GPP TS 23.292 [6] subclause 5.3.1;
An AS implementing the ICS application shall implement one or more of the roles IUA or T-ADS. Both roles can be co-located.
3GPP TS 24.294 [11B] defines mechanisms for the support of establishing the service control signalling path over I1. Support of such a mechanism is optional for the SCC AS.
6	Roles for registration in the IM CN subsystem
6.1	Introduction
This clause specifies procedures that are related to registration in the IM CN subsystem that are required for support of ICS. Both when the ICS UE generates the registration and when the MSC Server enhanced for ICS generates the registration is covered.
Subclause A.3 gives examples of signalling flows for registration.
6.2	ICS UE
In the present document, "ICS is enabled for the UE" refers to all of the following conditions:
-	the ICS MO ICS_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [43]) is set to enabled; and
-	the ability of simultaneous use of a CS bearer and use of PS for the service control signalling path.
Prior to performing IMS registration the ICS UE shall check that the ICS MO ICS_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [43]) is set to enabled for this ICS UE; otherwise ICS is disabled for this ICS UE and the ICS UE shall perform as in 3GPP TS 24.229 [11] and in 3GPP TS 24.008 [7].
If the ICS UE has an IMEI, prior to performing registration, the ICS UE shall generate an instance id based on its IMEI as defined in 3GPP TS 23.003 [4].
If ICS is enabled for the UE then the ICS UE registers to IM CN subsystem as specified in 3GPP TS 24.229 [11] and includes its capabilities in the Contact header field including the media feature-tag applicable for ICS. The ICS UE shall include in the Contact header field:
a)	a g.3gpp.ics media feature tag set to principal as specified in annex B.2;
b)	a g.3gpp.accesstype media feature tag set to one of the following text strings based on the access network technology being used by the UE to register, as follows:
-	"wlan": the UE is using WLAN access technology;
-	"cellular": the UE is using cellular access technology;
-	"docsis": the UE is using DOCSIS access technology;
-	"dsl": the UE is using DSL access technology;
-	"ethernet": the UE is using Ethernet access technology;
	Additionally to ensure that the text string is unique for that registration flow the UE shall append a unique numerical single digit value for each registration flow to the text string value above (e.g "wlan1"); and
c)	a sip.instance media feature tag containing the instance ID;
6.3	MSC Server enhanced for ICS
6.3.1	General
Prior to performing registration on behalf of a UE, the MSC Server enhanced for ICS shall generate 
-	a private user identity; 
-	an instance id;
-	a temporary public user identity; and
-	a home network domain name to address the REGISTER request to;
in accordance with the procedures as described in 3GPP TS 23.003 [4].
NOTE:	The condition when the MSC Server enhanced for ICS initiates registration on behalf of a UE is described in 3GPP TS 29.292 [24].
Prior to performing registration on behalf of a UE, the MSC Server enhanced for ICS shall obtain the IMEI of the UE using procedures as defined in 3GPP TS 24.008 [7]. The IMEI shall be used to create the instance id as defined in 3GPP TS 23.003 [4].
6.3.2	Initial registration
On sending a REGISTER request, the MSC Server enhanced for ICS shall:
1) 	set the Request-URI to the SIP URI of the domain name of the home network used to address the REGISTER request;
2)	set the From header field to the SIP URI that contains the temporary public user identity to be registered;
3)	set the To header field to the SIP URI that contains the temporary public user identity to be registered;
4)	populate an Authorization header field, with:
-	the username directive, set to the value of the private user identity;
-	the realm directive, set to the domain name of the home network; 
-	the integrity-protected directive, set to "auth-done";
-	the uri directive, set to the SIP URI of the domain name of the home network;
-	the nonce directive, set to an empty value; and
-	the response directive, set to an empty value;
5)	set the Contact header field to include the SIP URI containing the IP address or FQDN of the MSC Server enhanced for ICS in the hostport parameter. The MSC Server enhanced for ICS shall include a +sip.instance parameter containing the instance ID. The MSC Server enhanced for ICS shall include a 
a)	g.3gpp.icsi-ref media feature tag as specified in 3GPP TS 24.229 [11] the value for the IMS Multimedia Telephony Communication Service as specified in 3GPP TS 24.173 [9]; and
b)	g.3gpp.ics media feature tag set to server as specified in subclause annex B.
6)	set the Via header field to include the IP address or FQDN of the MSC Server enhanced for ICS in the sent-by field;
7)	set the Expires header field, or the expires parameter within the Contact header field, to the value of 600 000 seconds for the duration of the registration;
NOTE:	The registrar (S-CSCF) might decrease the duration of the registration in accordance with network policy. Registration attempts with a registration period of less than a predefined minimum value defined in the registrar will be rejected with a 423 (Interval Too Brief) response.
8)	populate the Supported header field with the option tag "gruu";
9)	populate the Require header field with the option tag "path";
10)	populate the Path header field with:
-	a SIP URI identifying the MSC Server enhanced for ICS;
-	an indication that requests routed in this direction of the path (i.e. from the S-CSCF towards the MSC Server enhanced for ICS) are expected to be treated as for the terminating case;
11)	populate the P-Charging-Vector header field with the icid parameter populated as specified in 3GPP TS 32.260 [18] and a type 1 orig-ioi parameter. The MSC Server enhanced for ICS shall set the type 1 orig-ioi parameter to a value that identifies the sending network of the request. The MSC Server enhanced for ICS shall not include the type 1 term-ioi parameter;
12)	populate the P-Visited-Network-ID header field with the value of a pre-provisioned string that identifies the visited network at the home network as specified in subclause 4.3; and
13)	forward the request as specified in subclause 6.3.3. If the MSC Server enhanced for ICS fails to forward the REGISTER request, the MSC Server enhanced for ICS shall abort the initial IMS registration attempt.
On receiving a 200 (OK) response to the REGISTER request, the MSC Server enhanced for ICS shall:
1)	store the expiration time of the registration for the public user identities found in the To header field value;
2)	store the list of Service-Route headers preserving the order, in order to build a proper preloaded Route header value for new dialogs and standalone transactions. The MSC Server enhanced for ICS shall store this list during the entire registration period of the respective public user identity;
3)	associate the Service-Route header list with the registered public user identity;
4)	store as the default public user identity the first URI in the list of URIs present in the P-Associated-URI header field;
5)	treat the identity under registration as a barred public user identity, if it is not included in the P-Associated-URI header field;
6)	find the Contact header field within the response that matches the one included in the REGISTER request. If this contains a "pub-gruu" parameter or a "temp-gruu" parameter or both, then store the value of those parameters as the GRUUs for the UE in association with the public user identity that was registered;
7)	store the values received in the P-Charging-Function-Addresses header field; and
8) 	if a term-IOI parameter is received in the P-Charging-Vector header field, store the value of the received term-IOI parameter.
On receiving a 423 (Interval Too Brief) response to the REGISTER request, the MSC Server enhanced for ICS shall:
send another REGISTER request populating the Expires header field or the expires parameter within the Contact header field with an expiration timer of at least the value received in the Min-Expires header field of the 423 (Interval Too Brief) response.
On receiving a 408 (Request Timeout) response or 500 (Server Internal Error) response or 504 (Server Time-Out) response to a REGISTER request, the MSC server enhanced for ICS shall perform the procedures for initial registration as described in this subclause.
On receiving a 3xx response or a 480 (Temporarily Unavailable) response or a 503 (Service Unavailable) response response to a REGISTER request, the MSC server enhanced for ICS shall:
1)	select a different exit or entry point as described in subclause 6.3.3; and
2)	perform the procedures for initial registration as described in this subclause.
When the timer F expires at the MSC Server enhanced for ICS, the MSC Server enhanced for ICS shall:
1)	select a different exit or entry point as described in subclause 6.3.3; and
2)	perform the procedures for initial registration as described in this subclause. 
After a maximum of 5 consecutive unsuccessful initial registration attempts, the MSC Server enhanced for ICS shall not automatically attempt any further initial registration for an implementation dependant time of at least:
a) 	the amount of time indicated in the Retry-After header field of the 4xx, 5xx or 6xx response received in response to the most recent registration request, if that header field was present; or
b)	30 minutes, if the Retry-After header field was not present and the initial registration was automatically performed as a consequence of a failed reregistration; or
c)	5 minutes, if the header field was not present and the initial registration was not performed as a consequence of a failed reregistration.
After an unsuccessful initial registration attempt, the MSC server can fall back to the procedures for non ICS UE attached to a legacy MSC for call establishment as described in 3GPP TS 23.292 [6], until a successful initial registration attempt is completed.
6.3.3	Sending the REGISTER request
The MSC Server enhanced for ICS shall send the REGISTER request as follows:
1)	if the MSC Server enhanced for ICS is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network, the MSC Server enhanced for ICS shall send the REGISTER request to an IBCF in the visited network.
NOTE 1:	The list of exit points can be either provisioned in the MSC Server enhanced for ICS or obtained as specified in IETF RFC 3263 [30].
NOTE 2:	If the MSC Server enhanced for ICS sends the request to an IBCF in the visited network, the IBCF can determine the entry point of the home network, using the same mechanisms as described in NOTE 1 above. In that case the MSC Server enhanced for ICS does not need to determine the entry point of the home network.
2)	determine the entry point of the home network and send the request to that entry point.
NOTE 3:	The list of  entry points can be either provisioned in the MSC Server enhanced for or obtained as specified in IETF RFC 3263 [30].
If the MSC Server enhanced for ICS fails to send the REGISTER request to any exit or entry point, the MSC Server enhanced for ICS shall abort the registration attempt.
6.3.4	Subscription to the registration-state event package
Upon receipt of a 200 (OK) response to the initial registration, the MSC Server enhanced for ICS shall generate a SUBSCRIBE request in accordance with IETF RFC 3680 [33], with the following elements:
- 	a Request-URI set to a SIP URI that contains the default public user identity received in the 200 (OK) response to the REGISTER request;
-	a From header field set to a SIP URI that contains the default public user identity received in the 200 (OK) response to the REGISTER request;
-	a To header field set to a SIP URI that contains the default public user identity received in the 200 (OK) response to the REGISTER request;
-	a Route header field set to values received in the Service-Route header field saved from the 200 (OK) response to the last registration. If the MSC Server enhanced for ICS is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network, select an IBCF in the visited network and add the URI of the selected IBCF to the topmost Route header field;
-	an Event header field set to the "reg" event package;
-	an Expires header field set to a value higher than the Expires header field indicated in the 200 (OK) response to the REGISTER request;
- 	a Contact header field set to the SIP URI of the MSC Server enhanced for ICS;
-	a P-Asserted-Identity header field set a SIP URI that contains the default public user identity received in the 200 (OK) response to the REGISTER request;
-	a P-Charging-Vector header field with the icid parameter populated as specified in 3GPP TS 32.260 [27]; and
-	a P-Access-Network-Info header field set as specified for the access network technology as specified in 3GPP TS 24.229 [11].
Upon receipt of a 2xx response to the SIP SUBSCRIBE request, the MSC Server enhanced for ICS shall store the information for the established dialog and the expiration time as indicated in the Expires header field of the received response.
The MSC Server enhanced for ICS shall automatically refresh the subscription for the reg event package for a previously registered public user identity for the period of time in which that registration remains active. The MSC Server enhanced for ICS shall refresh the subscription either 600 seconds before the expiration time if the initial subscription was for greater than 1200 seconds, or when half of the time has expired if the initial subscription was for 1200 seconds or less. If a SUBSCRIBE request to refresh a subscription fails with a non-481 response, the MSC Server enhanced for ICS shall still consider the original subscription valid for the duration of the most recently known "Expires" value according to IETF RFC 3265 [32]. Otherwise, the MSC Server enhanced for ICS shall consider the subscription invalid and start a new initial subscription according to IETF RFC 3265 [32].
Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package with a state attribute "active", i.e. registered is received for one or more public user identities, the MSC Server enhanced for ICS shall
1)	store the indicated public user identities as registered; and 
2)	for each public user identity indicated in the notification that contains a  element or a  element or both (as defined in IETF RFC 5628 [35]) store the value of those elements in association with the public user identity.
6.3.5	Reregistration
The MSC Server enhanced for ICS can perform the reregistration of a previously registered public user identity with its contact address at any time after the initial registration has been completed.
Unless the MSC Server enhanced for ICS has determined that a continued registration is not required, the MSC Server enhanced for ICS shall reregister an already registered public user identity if that subscriber is still registered to that VLR. The MSC Server enhanced for ICS shall register the already registered public user identity either 600 seconds before the expiration time if the previous registration was for greater than 1200 seconds, or when half of the time has expired if the previous registration was for 1200 seconds or less, or when the MSC Server enhanced for ICS intends to update its capabilities according to IETF RFC 3840 [34].
On sending the REGISTER request for reregistration, the MSC Server enhanced for ICS shall populate headers as described in subclause 6.3.2.
If the MSC Server enhanced for ICS fails to forward the REGISTER request, the MSC Server enhanced for ICS shall abort the reregistration attempt. 
NOTE:	This will not affect the UE's CS domain registration status at the MSC Server enhanced for ICS or HSS or HLR.
On receiving a 200 (OK) response to the REGISTER request, the MSC Server enhanced for ICS shall perform the actions defined for 200 (OK) response handling in subclause 6.3.2.
On receiving a 423 (Interval Too Brief) response to the REGISTER request, the MSC Server enhanced for ICS shall perform the actions defined for 423 (Interval Too Brief) response handling in subclause 6.3.2.
On receiving a 408 (Request Timeout) response or 500 (Server Internal Error) response or 504 (Server Time-Out) response for a reregistration, the MSC Server enhanced for ICS shall perform the procedures for initial registration as described in subclause 6.3.2.
On receiving a 3xx response response or a 480 (Temporarily Unavailable) response or a 503 (Service Unavailable) response for a reregistration, the MSC server enhanced for ICS shall: 
1)	select a different exit or entry point as described in subclause 6.3.3; and
2)	perform the procedures for initial registration as described in subclause 6.3.2.
When the timer F expires at the MSC Server enhanced for ICS, the MSC Server enhanced for ICS shall:
1)	select a different exit or entry point as described in subclause 6.3.3; and
2)	perform the procedures for initial registration as described in subclause 6.3.2. 
6.3.6	Deregistration
6.3.6.1	S-CSCF initiated deregistration
Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package on behalf of the UE, as described in subclause 6.3.4, including a  element which was registered by the MSC Server enhanced for ICS with either:
-	the state attribute set to "terminated" and the event attribute within the  element belonging to this UE set to "rejected" or "deactivated"; or
-	the state attribute set to "active" and the state attribute within the  element belonging to this UE set to "terminated", and the event attribute within the  element belonging to this UE set to "rejected" or "deactivated";
the MSC Server enhanced for ICS shall remove all stored information for these public user identities and remove these public user identities from the list of the public user identities that are registered for this user. In case of a "deactivated" event attribute, the MSC Server enhanced for ICS shall start the initial registration procedure as described in subclause 6.3.1. In case of a "rejected" event attribute, the MSC Server enhanced for ICS shall release all IMS dialogs related to those public user identities.
6.3.6.2	MSC Server enhanced for ICS initiated deregistration
The MSC Server enhanced for ICS initiated deregistration procedure consists of the MSC Server enhanced for ICS sending a REGISTER request on behalf of the UE upon receipt of any indication that the subscriber is no longer active at this MSC Server enhanced for ICS. On receiving Location Cancellation request, the MSC Server enhanced for ICS should delay sending the REGISTER request for deregistration for a specific time in order to ensure that the registration request from the target MSC Server arrives at the S‑CSCF prior to the deregistration request from the source MSC Server.
Prior to sending a REGISTER request for deregistration, the MSC Server enhanced for ICS shall release all IMS dialogs related to the public user identity that is going to be deregistered or to one of the implicitly registered public user identities.
On sending a REGISTER request for deregistration, the MSC Server enhanced for ICS shall:
1) 	set the Request-URI to the SIP URI of the domain name of the home network used to address the REGISTER request;
2)	set the From header field to the SIP URI that contains the public user identity to be deregistered;
3)	set the To header field to the SIP URI that contains the public user identity to be deregistered;
4)	set the Contact header field set to include the SIP URI containing the IP address or FQDN of the MSC Server enhanced for ICS in the hostport parameter. The MSC Server enhanced for ICS shall include a +sip.instance parameter containing the instance ID that was used during registration;
5)	set the Via header field to include the IP address or FQDN of the MSC Server enhanced for ICS in the sent-by field;
5A)	populate an Authorization header field, with:
-	the username directive, set to the value of the private user identity;
-	the realm directive, set to the domain name of the home network; 
-	the integrity-protected directive, set to "auth-done";
-	the uri directive, set to the SIP URI of the domain name of the home network;
-	the nonce directive, set to an empty value; and
-	the response directive, set to an empty value;
6)	set the Expires header field, or the expires parameter within the Contact header field, to the value of zero; and
7)	send the request as specified in subclause 6.3.3.
On receiving the 200 (OK) response to the REGISTER request, the MSC Server enhanced for ICS shall remove all registration details relating to this public user identity. 
NOTE:	Other final responses than 200 (OK) might  require the MSC Server enhanced for ICS to perform cleanup such as removing details related to that public user identity. The details of such actions are not specified in this version of the specification.
The MSC Server enhanced for ICS shall consider any existing subscription to the reg event package cancelled (i.e. as if the MSC Server had sent a SUBSCRIBE request with an Expires header field containing a value of zero).
6.4	SCC AS
The SCC AS can obtain registration state information that it needs to implement ICS specific requirements from:
a)	any received third-party REGISTER request (e.g. including information contained in the body of the third-party REGISTER request) as specified in 3GPP TS 24.229 [11];
b)	any received reg event package as specified in 3GPP TS 24.229 [11]; or
c)	the Sh interface as specified in 3GPP TS 29.328 [25] and 3GPP TS 29.329 [26].
NOTE:	Obtaining registration state information from HSS using Sh interface does not allow the SCC AS to know the capabilities supported by the user registered UE(s), including the used IP-CAN(s).
7	Roles for call origination
7.1	Introduction
This clause specifies the procedures for call origination for when an ICS UE originates a session, establishing the service control signalling path either over the Gm interface or the I1 interface, and when a non-ICS UE originates a session achieving IMS service control via an MSC server enhanced for ICS. The associated procedures for the SCC AS and MSC server enhanced for ICS are also specified in this clause.
Subclause A.4 provides examples of signalling flows for call origination.
7.2	ICS UE
7.2.1	General
This clause specifies the procedures for call origination by an ICS UE.
Annex A.4 gives examples of signalling flows for call origination.
7.2.2	ICS UE using Gm
There are no ICS specific requirements for the origination of calls that may be subject to ICS.
If ICS is enabled for the UE then when the ICS UE originates a call using Gm reference point, the ICS UE shall:
a)	send a SIP INVITE request towards the IM CN subsystems as specified in 3GPP TS 24.229 [11]. The ICS UE shall populate the SIP INVITE request as follows: 
i)	include in the Contact header field:
-	a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [11] if a GRUU was received at registration;
-	the feature tag g.3gpp.ics set to "principal";
ii)	the SDP payload proposing an audio stream over a circuit-switched bearer as described IETF RFC 7195 [36], as follows:
-	a "c=" line with the nettype portion set to "PSTN" and the addrtype portion and connection-address portions both set to "-";
-	a CS media "m=" line with the media portion set to "audio", port portion set to "9", proto portion set to "PSTN" and fmt portion set to "-";
-	an a=setup attribute set to "active";
--	an a=cs-correlation attribute set to "callerid" along with the MSISDN, of ICS UE in the CS domain, in international E.164 number format;
	an a=connection attribute set to "new";
-	an indication that the related local preconditions for QoS are not met as specified in 3GPP TS 24.229 [11]. In the same, the SDP payload may also be proposing a CS video stream;
b)	when the ICS UE receives a reliable SIP 1xx provisional response from the network including a PSI DN number, the ICS UE shall setup a CS call by sending a SETUP message in accordance with 3GPP TS 24.008 [7] for 3GPP systems. The UE shall populate the SETUP message for 3GPP systems as follows:
i)	the called party BCD number information element set to the SCC AS PSI DN received in the SDP body of the SIP 1xx provisional response, in the connection-address portion of the "c=" line, appended to the "PSTN" nettype portion as described in IETF RFC 7195 [36]; and
ii)	Type Of Number is set to "International" and Numbering Plan Indicator set to "E.164" in the Called Party BCD Number information element.
c)	when the CS resources are available to the UE, the ICS UE shall send an SDP offer including an indication that the related local preconditions for QoS for audio as met as specified in 3GPP TS 24.229 [11].
When the ICS UE originates a non-CS bearer call using Gm reference point, the ICS UE shall act in accordance with 3GPP TS 24.229 [11].
7.2.3	ICS UE using CS
The ICS UE shall implement the call origination towards SCC AS suitable for ICS via CS domain as specified in 3GPP TS 24.008 [7] for 3GPP systems.
7.2.4	ICS UE using I1
In the present document, "I1 is enabled for the ICS UE" refers to all of the following conditions:
-	the ICS MO ICS_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [43]) is set to enabled;
-	the UE is an ICS UE compliant with 3GPP TS 24.294 [11B];
-	the ICS MO I1_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [43]) indicates that IMS Centralised Services capabilities over I1 are enabled if simultaneous use of CS RAT and PS RAT is not supported; and
-	the inability of simultaneous use of a CS bearer and use of PS for the service control signalling path.
If the ICS MO I1_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [43]) indicates that IMS Centralised Services capabilities over I1 are disabled for this ICS UE or if the ICS MO I1_Capabilities_Enabled leaf node is absent, the ICS UE shall not follow procedures as defined in 3GPP TS 24.294 [11B].
If I1 is enabled for the ICS UE and the ICS UE originates an I1 session using the I1 reference point, the ICS UE shall:
1)	generate an I1 Invite message toward the SCC AS in accordance with subclause 6.2.1.2.1.2 in 3GPP TS 24.294 [11B]; and
2)	select the transport layer protocol depending on the access network type, and forward the I1 Invite message toward the SCC AS.
When the ICE UE receives an I1 Progress with progress reason set to Call progressing act in accordance with subclause 6.2.1.2.1.3 in 3GPP TS 24.294 [11B].
When the ICS UE receives an I1 Progress with progress reason set to ringing act in accordance with subclause 6.2.1.2.1.4 in 3GPP TS 24.294 [11B].
When the ICS UE receives an I1 Success message, the ICS UE shall act in accordance with subclause 6.2.1.2.1.5 in 3GPP TS 24.294 [11B]..
7.3	MSC Server enhanced for ICS
The MSC Server enhanced for ICS shall implement call origination towards the SCC AS as specified in 3GPP TS 29.292 [24] with the following addition:
-	the Contact header of the SIP INVITE request shall include the feature tag g.3gpp.ics set to "server".
7.4	SCC AS
7.4.1	General
The following subclauses describe the procedures at the SCC AS for call origination. In such scenarios, the SCC AS serves the originating ICS UE. The SCC AS shall follow procedures specified in 3GPP TS 24.229 [11] with the additional procedures described in this specification in subclauses 7.4.2 and 7.4.3. These subclauses describe the procedures for the SCC AS when using service control over Gm and CS, respectively.
7.4.2	SCC AS for service control over Gm
7.4.2.1	CS bearer is requested by the ICS UE
When the SCC AS receives an initial SIP INVITE request from the ICS UE due to initial filter criteria, the SCC AS shall:
1)	store the information received in the SIP INVITE request, including the Request-URI, P-Asserted-Identity header field, Accept header field, Call-ID header field, To and From header fields including tags, Contact header field including associated feature tags, Accept-Contact header field, the Record-Route header field(s), and the received non-audio SDP information;
1A)	construct a Route header field(s) from the Record-Route header field(s) that was received in the initial SIP INVITE request, and save the constructed Route header field(s) for inclusion in the subsequent in dialog requests sent towards the ICS UE;
2)	if the SDP contains:
i)	a "c=" line with nettype portion set to "PSTN" as described in IETF RFC 7195 [36];
ii)	a CS media "m=" line with media portion set to audio, port portion set to "9" and nettype portion set to "PSTN" as described in IETF RFC 7195 [36]; and
NOTE:	If both i) and ii) are true, the ICS UE is requesting that the media bearer is to be set up over the CS domain.
iii)	an a=setup attribute set to "active" and an a=connection attribute set to "new"; and
iv)	an a=cs-correlation attribute set to "callerid" along with the MSISDN, of the ICS UE in the CS domain, in international E.164 number format.
then the SCC AS shall send a SIP 183 (Session Progress) response towards the originating ICS UE in accordance with 3GPP TS 24.229 [11] with the following additions:
i)	an SDP answer, in accordance with IETF RFC 7195 [36], containing a "c=" line with the nettype portion set to "PSTN" and with the addrtype portion set to "E164" and the connection-address portion set to a SCC AS PSI DN, in international E.164 number format. The SCC AS PSI DN that identifies the stored information in step 1) and associated with the SCC AS;
ii)	an a=setup attribute set to "passive"
iii)	an a=connection attribute set to "new"; 
iv)	an a=cs-correlation attribute set to "callerid"; and
v)	indicate local preconditions not met;
3)	When the SCC AS receives an initial SIP INVITE request with the Request-URI containing a valid SCC AS PSI DN encoded as a tel URI (see IETF RFC 3966 [42]) or SIP URI with the "user" SIP URI parameter set to "phone", in accordance with 3GPP TS 23.003 [4], subclause 13.5 as allocated in the above step 2 and with the P-Asserted-Identity header field containing the E.164 number received in the a=cs-correlation attribute contained in the SDP offer in the SIP INVITE request received from the ICS UE then the SCC AS shall:
i)	use the SCC AS PSI DN that was allocated in step 2 and E.164 number received in the a=cs-correlation attribute contained in the SDP offer from the SIP INVITE request received from the ICS UE to correlate the previously stored information against this session with the incoming SIP INVITE request;
ii)	act as a routing B2BUA, and generate an initial SIP INVITE request toward the terminating UE and include the information received in the SIP INVITE received in step 1 with the following exceptions:
a)	if a Privacy type of "id" is received in the SIP INVITE request received initial SIP INVITE request with the Request-URI containing the SCC AS PSI DN then the Privacy type shall be set to type of "id";
b)	an SDP offer with the media that combines the stored SDP offer from the ICS UE received in the SIP INVITE request from the ICS UE and the SDP offer received from the received in SIP INVITE request with the Request-URI containing the SCC AS PSI DN in accordance with the rules of IETF RFC 3264 [31];
c)	replace the Record-Route header field(s) received in the initial SIP INVITE request with a new Record-Route header field that only contains a SIP URI pointing to the SCC AS; and
d)	set the Contact header field to include the contents of the Contact header received in the received initial SIP INVITE request, except the g.3gpp.ics media feature tag.
Upon receiving a SIP 18x response from the remote UE the SCC AS shall:
1)	 send a SIP 18x response on the leg with the ICS UE. If the receiving response includes an SDP answer, the SIP 18x response shall include an SDP answer, and use a different dialog from that of the first SIP 183(Session Progress) response sent by the SCC AS;
1A)	include in the SIP 18x response sent on the leg with the ICS UE the Contact header field that contains the contents of the Contact header received in the SIP 18x response from the terminating UE;
1B)	include in the SIP 18x response sent on the leg with the ICS UE the Record-Route header field(s) that was constructed by the SCC AS adding its SIP URI to the saved Record-Route header field(s) that was received in the initial SIP INVITE request; and
2)	send a SIP 18x response on the leg with the CS domain.
The SDP answers shall be in accordance with rules for SDP answer as specified in IETF RFC 3264 [31].
When the SCC AS is aware of that preconditions are met on all legs the SCC AS shall send a SIP UPDATE request towards the remote UE indicating that local preconditions are met.
Upon receiving a SIP 200 (OK) response from the remote UE, the SCC AS shall send a SIP 200 (OK) response on both the leg with the ICS UE and on the leg with the CS domain. If the response includes an SDP answer, the AS shall send an SDP answer on the leg with the ICS UE and on the leg with the CS domain. The SDP answers shall be in accordance with rules for SDP answer as specified in IETF RFC 3264 [31].
When the SCC AS has received a SIP ACK request on both the leg with the CS domain and on the leg with the ICS UE, the SCC AS shall respond to the initial SIP INVITE request with a final 200 (OK) response. on the same dialog on which the second 18x was sent to the ICS UE.
7.4.2.2	Non CS bearer is requested by the ICS UE
When the SCC AS receives an initial SIP INVITE request due to initial filter criteria, which does not include a request for CS media, the SCC AS shall act as a routing B2BUA as described in 3GPP TS 24.229 [11].
7.4.3	SCC AS for service control over CS
When the SCC AS receives SIP INVITE request due to originating IMRN, the SCC AS shall:
NOTE 1:	Allocation of the IMRN is outside the scope of this specification.
1)	operate as an application server providing 3rd party call control, and specifically as an initiating B2BUA, as specified in subclause 5.7.5 of 3GPP TS 24.229 [11] for this request and all future requests and responses in the same dialog;
2)	set the Request-URI of the outgoing initial SIP INVITE request to a tel-URI which represents the original called party number of the call as initiated in the CS domain. The tel-URI may be available from information associated with the received IMRN or from the History-Info header field;
3)	set the To header field of the outgoing initial SIP INVITE request to a tel-URI which represents the original called party number of the call as initiated in the CS domain. The tel-URI may be available from information associated with the received IMRN or from the History-Info header field;
4)	if the SCC AS has received a History-Info header field indicating only one diversion, not include the History-Info header field;
5)	append the orig parameter to the S-CSCF URI included in the Route header field of the outgoing initial SIP INVITE request; and
6)	set the P-Asserted-Identity header field of the outgoing SIP INVITE request and to a tel-URI which represents the calling party number of the call initiated in the CS domain. This is either available from information associated against the received IMRN or is the value as received in P-Asserted-Identity header field of the incoming SIP INVITE request.
NOTE 2:	It can happen that the P-Asserted-Identity header field is not included in the incoming SIP INVITE request.
The SCC AS should in the outgoing SIP requests and SIP responses include the same values as received in the incoming SIP requests and SIP responses in all other header fields with the exception given in this subclause and in subclause 5.7.5 of 3GPP TS 24.229 [8].
The SCC AS will handle the Privacy header field in the outgoing SIP INVITE request in the following way. The SCC AS shall either:
-	if a Privacy header field is received in the incoming INVITE request, include  the Privacy header field as received in the incoming INVITE request; or
-	if a value is associated to IMRN and indicates that the presentation of the calling party number is restricted in the CS domain, include a Privacy header field with the value set to "id".
On completion of the above procedure, the call is anchored in the SCC AS.
NOTE 3:	After completion of anchoring the call in SCC AS, the allocated IMRN is available for reuse.
7.4.4	SCC AS for service control over I1
7.4.4.1	General
When the SCC AS receives an initial I1 Invite message from the ICS UE via the I1interface, the SCC AS shall:
1)	perform the procedures in accordance with subclause 6.2.1.3.1.2 in 3GPP TS 24.294 [11B];
2)	allocate the SCC AS PSI DN which is specified as an E.164 number, and shall identify the stored information in step 1) and associate with the SCC AS PSI DN;
3)	generate and send an I1 Progress message, in accordance with subclause 6.2.1.3.1.3 in 3GPP TS 24.294 [11B] towards the originating UE over the transport layer connection over which the I1 Invite message was received.
Subsequently, the SCC AS will wait for an initial SIP INVITE request from the CS domain (via MGCF) with the Request-URI set to the allocated SCC AS PSI DN, upon receiving the initial SIP INVITE request from the CS domain the SCC AS shall: 
0)	check that the Request URI is
i)	set to a valid SCC AS PSI DN as allocated in the above step 2, and
ii)	the SCC AS PSI DN is encoded as a tel URI (see IETF RFC 3966 [42]) or SIP URI with the "user" SIP URI parameter set to "phone", in accordance with 3GPP TS 23.003 [4], subclause 13.5;
If the SCC AS PSI DN is valid. , the SCC AS shall:
1)	and if Timer(s) as specified in 3GPP TS 24.294 [11B] subclause 7.5.3.2.1.2.2 has not expired use the received SCC AS PSI DN and correlate it with the information saved in step 1 above and the SCC AS PSI DN that was allocated in step 2 above;
2)	act as a routing B2BUA, and generate an initial SIP INVITE request toward the remote UE. The SIP INVITE request shall include:
i)	the information received in the initial I1 Invite message including the following additional information if the SCC AS received an I1 Invite containing:
a)	an Accept Contact information element as specified in subclause 7.3.2.9 in 3GPP TS 24.294 [11B] insert the media feature tags as received into the Accept Contact header field of the outgoing SIP INVITErequest;
b)	a ER Accept Contact information element as specified in subclause 7.3.2.10 in 3GPP TS 24.294 [11B] insert the media feature tags as received into the Accept Contact header field of the outgoing SIP INVITE request with the addition that:
-	if the E bit was set to "1" the SCC AS shall qualify the media feature tag with the preference "explicit"; and
-	if the R bit was set to "1" the SCC AS shall qualify the media feature tag with the preference "require"; and
c)	a Reject Accept information element as specified in subclause 7.3.2.11 in 3GPP TS 24.294 [11B] insert the feature tags as received into the Reject Contact header field of the outgoing SIP INVITE request;
d)	if a Privacy type of "id" is received in the SIP INVITE request from the CS domain then the Privacy type shall be set to type of "id"; and
ii)	an SDP offer with the media received in the SDP offer conveyed to the SCC AS in the SIP INVITE request received from the CS domain; and
3)	send the generated initial SIP INVITE request toward the remote UE as specified in 3GPP TS 24.229 [11].
Upon receiving a SIP 18x response from the remote UE, the SCC AS shall send the SIP 18x response toward the CS domain. The response includes an SDP answer received from the remote UE.
If the SCC AS receives a SIP 180 (Ringing) response from the remote UE, the SCC AS shall send the SIP 180 (Ringing) response towards the CS domain. In addition, the SCC AS may send an I1 Progress message with Reason set to 180 "Ringing" toward the ICS UE over the I1 interface, in accordance with subclause 6.2.1.3.1.4 in 3GPP TS 24.294 [11B].
Upon receiving a SIP 200 (OK) response from the remote UE, the SCC AS shall send the SIP 200 (OK) response towards the CS domain. If the SIP 200 (OK) response includes an SDP answer, the SCC AS shall include the SDP answer in the SIP 200 (OK) response sent towards the CS domain. 
Upon receving a SIP ACK request (indicating receipt of CONNECT ACKNOWLEDGEMENT in the CS domain) from the CS domain, the SCC AS shall send: 
1)	an I1 Success message in accordance with subclause 6.2.1.3.1.5 in 3GPP TS 24.294 [11B] toward the UE; and
2)	a SIP ACK request towards the remote UE.
7.4.4.2	Failure handling
If the SCC AS receives a status line as specified in subclause 7.2 of IETF RFC 3261[45] with status code value 3xx to 6xx as specified in subclause 21.3-21.6 of IETF RFC 3261 [45], the SCC AS shall:
a)	send an I1 Failure message in accordance with subclause 6.2.1.4 in 3GPP TS 24.294 [11B] toward the UE.
8	Roles for call modifcation initiated from the ICS UE
8.1	Introduction
This clause specifies call modification procedures initiated by an ICS UE for a call using a service control signalling path over Gm. The associated procedures for the ICS UE and the SCC AS are also specified in this clause; specifically, the procedure when a CS bearer is added or removed is specified. If a CS bearer is already used for the session, the ICS UE can add or remove video media to/from the existing CS bearer by applying the procedures in accordance with 3GPP TS 24.229 [11] and the CS SDP as described in IETF RFC 7195 [36].
8.2	ICS UE
8.2.1	General
This clause specifies the procedures for a UE when the call modification is initiated by an ICS UE.
8.2.2	ICS UE is using Gm
8.2.2.1	General
This subclause specifies call modification procedure when a session is modified from an ICS UE using a service control signalling path over Gm; specifically, the procedure when a CS bearer is added or removed is specified.
8.2.2.2	ICS UE adds a CS bearer
If the UE decides to add a CS bearer to an existing session, the ICS UE shall act in accordance with subclause 7.2.2, except that a SIP re-INVITE request and its related responses shall be used instead of an initial SIP INVITE request.
8.2.2.3	ICS UE adds media in PS domain
If the ICS UE decides to add a media using the PS domain, the ICS UE shall apply the procedure in accordance with 3GPP TS 24.229 [11].
8.2.2.5	ICS UE removes a CS bearer
When an ICS UE wants to remove a CS bearer the ICS UE shall:
a)	send a SIP re-INVITE request or SIP UPDATE request towards the IM CN subsystems as specified in 3GPP TS 24.229 [11]. The ICS UE shall populate the SIP INVITE request or SIP UPDATE request as follows:
i)	the request URI set to the contact address earlier received from the SCC AS;
ii)	include in the Contact header field:
-	a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [11] if a GRUU was received at registration;
-	the feature tag g.3gpp.ics set to principal;
b)	set the CS bearer to not be used any longer by setting the port number to zero for the CS media "m=" line with the proto portion set to "PSTN" as described in IETF RFC 7195 [36]; and
c)	when the ICS UE receives a reliable 1xx provisional response from the IM CN subsystem, the ICS UE shall release the resources in accordance with 3GPP TS 24.008 [8].
8.2.2.6	ICS UE removes PS media
If the ICS UE decides to remove any media using the PS domain the ICS UE shall apply the procedure in accordance with 3GPP TS 24.229 [11].
8.2.2.7	ICS UE add/remove CS video media
In case that a CS bearer is already used for the session and that the ICS UE decides to add or remove CS video media to/from the existing CS bearer, the ICS UE shall apply the procedures in accordance with 3GPP TS 24.229 [11] and the CS SDP as described in IETF RFC 7195 [36].
In the CS domain, the ICS UE shall apply in-call modification procedure (i.e., speech to/from UDI/RDI multimedia mode) as specified in 3GPP TS 24.008 [8] if it is possible, otherwise, the ICS UE shall apply Redial method as specified in 3GPP TS 24.008 [8].
8.3	MSC server enhanced for ICS
No special procedure is required for call modification procedure at the MSC Server enhanced for ICS.
8.4	SCC AS
8.4.1	General
This subclause specifies call modification procedure when a session is modified from an SCC AS using a service control signalling path over Gm; specifically, the procedure when a CS bearer is added or removed is specified.
8.4.2	SCC AS actions when UE adds a CS bearer
When the SCC AS receives a SIP re-INVITE request from the ICS UE indicating the addition of a CS bearer on an existing session, the SCC AS shall:
1)	if the SDP offer in the received SIP INVITE request contains:
i)	a "c=" line with nettype portion set to "PSTN" as described in IETF RFC 7195 [36];
ii)	a CS media "m=" line with media portion set to audio, port portion set to "9" and nettype portion set to "PSTN" as described in IETF RFC 7195 [36]; 
NOTE:	If both i) and ii) are true, the ICS UE is requesting that the media bearer is to be set up over the CS domain.
iii)	an a=cs-correlation attribute set to "callerid" along with the MSISDN, of the ICS UE, in international E.164 number format; and 
iv)	an a=setup attribute set to "active" and an a=connection attribute set to "new"
then the SCC AS shall send a SIP 183 (Session Progress) response towards the ICS UE in accordance with 3GPP TS 24.229 [11] with the following additions:
a)	include an SDP answer, in accordance with IETF RFC 7195 [36], containing a "c=" line with the nettype portion set to "PSTN" and with the addrtype portion set to "E164" and the connection-address portion set to a SCC AS PSI DN, in international E.164 number format. The SCC AS PSI DN is associated with the SCC AS and identifies the existing session; 
b)	an a=setup attribute set to "passive"
c)	an a=connection attribute set to "new"; 
d)	an a=cs-correlation attribute set to "callerid"; 
e)	indicate local preconditions not met for the media over CS bearer; and
2)	When the SCC AS receives an initial SIP INVITE request with the Request-URI containing a valid SCC AS PSI DN encoded as a tel URI (see IETF RFC 3966 [42]) or SIP URI with the "user" SIP URI parameter set to "phone", in accordance with 3GPP TS 23.003 [4], subclause 13.5 as allocated in the above step 1 and with the P-Asserted-Identity header field containing the E.164 number received in the a=cs-correlation attribute contained in the SDP offer in the SIP INVITE request received from the ICS UE then the SCC AS shall:
a)	use the SCC AS PSI DN that was allocated to associate SCC-AS-PDN with the existing session and E.164 number received in the a=cs-correlation attribute contained in the SDP offer from the SIP INVITE request received from the ICS UE to correlate the SCC AS PSI DN with the existing session with the remote UE and acting as a routing B2BUA generate a SIP INVITE request and include the following information:
i)	a Request-URI set to the contact address of the remote UE; and
ii)	in the SDP add the SDP offer received from the received initial SIP INVITE request with the Request-URI containing the SCC AS PSI DN in accordance with the rules of IETF RFC 3264 [31].
Upon receiving a SIP 18x response from the remote UE the SCC AS shall send a SIP 18x response on both the leg with the ICS UE and on the leg with the CS domain. If the response from the remote UE includes an SDP answer, the SCC AS shall send an SDP answer on the leg with the ICS UE and on the leg with the CS domain. The SDP answers shall be in accordance with rules for SDP answer as specified in IETF RFC 3264 [31].
When the SCC AS is aware that preconditions are met on all legs, the SCC AS shall send a SIP UPDATE request on the leg with the remote UE indicating that local preconditions are met.
Upon receiving a SIP 200 (OK) response from the remote UE, the SCC AS shall send a SIP 200 (OK) response on both the leg with the ICS UE and on the leg with the CS domain. If the SIP 200 (OK) response includes an SDP answer, the SCC AS shall send an SDP answer on the leg with the ICS UE and on the leg with the CS domain. The SDP answers shall be in accordance with rules for SDP answer as specified in IETF RFC 3264 [31].
When the SCC AS has received a SIP ACK request on both the leg with the CS domain and on the leg with the ICS UE, the SCC AS shall send a SIP ACK request to the remote UE .
8.4.3	SCC AS adds media in the PS domain
The SCC AS shall apply the procedure in accordance with 3GPP TS 24.229 [11].
9	Roles for call modifcation initiated towards an ICS UE
9.1	Introduction
This clause specifies call modification procedures initiated towards an ICS UE for a call using a service control signalling path over Gm. The associated procedures for the ICS UE and the SCC AS are also specified in this clause; specifically, the procedure when a CS bearer is added or removed is specified. If a CS bearer is already used for the session, the ICS UE can add or remove video media to/from the existing CS bearer by applying the procedure in accordance with 3GPP TS 24.229 [11] and the CS SDP as described in IETF RFC 7195 [36].
9.2	ICS UE
9.2.1	General
This clause specifies the procedures for a UE when the call modification is initiated towards an ICS UE.
9.2.2	ICS UE using Gm
9.2.2.1	General
This subclause specifies call modification procedure when a session is modified towards an ICS UE using a service control signalling path over Gm; specifically, the procedure when a CS bearer is added or removed is specified.
9.2.2.2		ICS UE is offered a CS bearer
When the ICS UE receives a SIP INVITE request on an existing session containing request for establishment of a CS bearer as described in by IETF RFC 7195 [36], the ICS UE shall: 
a)	send a reliable SIP 183 (Session Progress) response  towards the IM CN subsystems as specified in 3GPP TS 24.229 [11]. The ICS UE shall populate the SIP 183 (Session Progress) response as follows: 
i)	include in the Contact header field:
-	a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [11] if a GRUU was received at registration;
-	the feature tag g.3gpp.ics set to "principal"; and
ii)	the SDP answer accepting an audio stream over a circuit-switched bearer as described by IETF RFC 7195 [36], as follows:
-	a "c=" line with the nettype portion set to "PSTN" and the addrtype portion and connection-address portions both set to "-";
-	a CS media "m=" line with the media portion set to "audio", port portion set to "9", proto portion set to "PSTN" and fmt portion set to "-";
-	an a=setup attribute set to "active";
-	an a=cs-correlation attribute set to "callerid" along with the MSISDN, of the ICS UE in the CS domain, in international E.164 number format;
-	an a=connection attribute set to "new"; and
-	an indication that the related local preconditions for QoS are not met as specified in 3GPP TS 24.229 [11];
b)	shall setup a CS call by sending a CC SETUP message in accordance with 3GPP TS 24.008 [7] for 3GPP systems. The UE shall populate the CC SETUP message for 3GPP systems as follows:
i)	the called party BCD number information element set to the SCC AS PSI DN received in the SDP body of the SIP INVITE request, in the connection-address portion of the "c=" line, appended to the "PSTN" nettype portion as described in IETF RFC 7195 [36]; and
c)	when the CS resources are available to the UE, the ICS UE shall send an SDP offer including an indication that the related local preconditions for QoS for audio as met as specified in 3GPP TS 24.229 [11].
When the ICS UE originates a non-CS bearer call using Gm reference point, the ICS UE shall act in accordance with 3GPP TS 24.229 [11].
9.2.2.3	ICS UE is offered PS media
If the ICS UE is offered media in the PS domain using Gm reference point, the ICS UE shall act as specified in 3GPP TS 24.229 [11].
9.2.2.4	ICS UE is offered media both in CS and PS domain
If the ICS UE is offered media both in the PS domain using Gm reference point and the CS domain using a service control signalling path over Gm, the ICS UE shall act as specified in subclause 10.2.2.4.
9.2.2.5	SCC AS removes a CS bearer
When the ICS UE receives a SIP INVITE request from the network containing SDP with an indication that the CS bearer will not be used any longer with the port number set to zero for the CS media "m=" line with nettype portion set to "PSTN" as described in IETF RFC 7195 [36], the ICS UE shall release the CS bearer resources in accordance with 3GPP TS 24.008 [8].
9.2.2.6	SCC AS removes PS media
If the ICS UE is instructed to remove a media stream in the PS domain using Gm reference point, the ICS UE shall remove the media stream as specified in 3GPP TS 24.229 [11].
9.3	MSC server enhanced for ICS
No special procedure is required for call modification procedure at the MSC server enhanced for ICS.
9.4	SCC AS
9.4.1	Terminating Access domain selection
When the SCC AS receives on an existing session a SIP re-INVITE request or a SIP UPDATE request to add media stream(s) towards the ICS UE the SCC AS shall 
-	perform Terminating Access Domain Selection (T-ADS) based upon criteria described in 3GPP TS 23.292 [6];
-	if T-ADS results in choosing to deliver all media in the PS domain, skip the following steps and continue with call termination in the IM CN subsystem as specified in subclause 9.4.3; and
-	if T-ADS results in choosing to deliver media in the CS domain, and using Gm for service control, acting as a B2BUA, the SCC AS shall act in accordance with subclause 9.4.2.
9.4.2	SCC AS adds a CS bearer
When the SCC AS receives on an existing session a SIP re-INVITE request to add media stream(s) towards the ICS UE the SCC AS shall:
1)	allocate an SCC AS PSI DN associated with the SCC AS and the INVITE request from the originating UE;
2)	create a SIP INVITE request based upon the request from the originating UE and include the following:
i)	the Request URI set to the earlier received contact address 
ii)	an SDP offer based on the received SDP offer from the originator and including the following:
-	in the SDP offer include additional CS media "m=" line with media portion set to audio, port portion set to "9", proto portion set to "PSTN" and fmt portion set to"-" as described in IETF RFC 7195 [36];
-	in the SDP offer include, a "c=" line with the nettype portion set to "PSTN" and with the addrtype portion set to "E164" and the connection-address portion set to the SCC AS PSI DN allocated in step 1), in international E.164 number format, in accordance with IETF RFC 7195 [36];
	an a=setup attribute set to "passive";
-	an a=connection attribute set to "new";
-	an a=cs-correlation attribute set to "callerid";
-	an indication that preconditions are not met; and
3)	route the created SIP INVITE request towards the terminating ICS UE.
When the SCC AS has received the 18x response containing the SDP answer accepting an audio stream over a circuit-switched bearer from the ICS UE and receives the initial SIP INVITE request with the Request-URI containing a valid SCC AS PSI DN encoded as a tel URI (see IETF RFC 3966 [42]) or SIP URI with the "user" SIP URI parameter set to "phone", in accordance with 3GPP TS 23.003 [4], subclause 13.5 as allocated in the above step 1 and with the P-Asserted-Identity header field containing the E.164 number received in the a=cs-correlation attribute contained in the SDP answer in the response to the SIP INVITE request received from the ICS UE then the SCC AS shall:
NOTE:	The SCC AS could receive the SIP INVITE request before the SIP 18x response. IETF RFC 7195 [36] provides guidance on handling this situation.
1)	use the SCC AS PSI DN and E.164 number received in the a=cs-correlation attribute contained in the SDP answer from the response to the SIP INVITE request received from the ICS UE to correlate the SCC AS PSI DN against the incoming SIP INVITE request from the remote UE.
2)	send a response to the initial SIP INVITE request with the Request-URI containing the SCC AS PSI DN in accordance with 3GGP TS 24.229 [11], indicating local preconditions met.
When the SCC AS has received the 18x response containing the SDP answer accepting an audio stream over a circuit-switched bearer from the ICS UE and the SIP INVITE request with the Request-URI containing the SCC AS PSI DN number, the SCC AS shall prepare an SDP answer to be sent to the remote UE. The SDP answer shall be based on the SDP answer received from the ICS UE and the SDP offer received from the CS domain. If the "m=" line of the SDP offer from the CS domain includes more than one codecs the SCC AS shall delete the lowest priority codecs. The status line in the response sent to the remote UE shall be the same as received in the 18x response from the ICS UE. The SDP answer sent to the remote UE shall be in accordance with IETF RFC 3264 [31].
When the SCC AS gets aware that the remote precondition is fulfilled on the leg towards the remote UE and on the leg with the CS domain, the SCC AS shall send a SIP UPDATE request to the ICS UE indicating that precondition is met.
When the SCC AS receives precondition is met on the leg with the CS domain the SCC AS shall:
1)	send a SIP 200 (OK) for the SIP UPDATE request on the leg with the CS domain and
2)	send a SIP 200 (OK) for the SIP INVITE request on the leg with the CS domain.
9.4.3	SCC AS adds PS media
When the SCC AS receives an SDP offer on an existing session a request to add or modify a non-voice stream towards the ICS UE the SCC AS shall act in routing AS in accordance with 3GPP TS 24.229 [11].
9.4.4	SCC AS removes a CS bearer
If the SCC AS receives an SDP offer from the originating UE that indicates that all the CS media streams are removed, the SCC AS shall send a SIP INVITE request towards the IM CN subsystems as specified in 3GPP TS 24.229 [11]. The SCC AS shall populate the SIP INVITE request as follows:
-	the Request URI set to the contact address of the terminating ICS UE; and
-	an indication that the CS bearer will not be used any longer by setting the port number to zero for the CS media "m=" line with nettype portion set to "PSTN" as described in IETF RFC 7195 [36].
9.4.5	SCC AS add/remove CS video media
In case of a CS bearer with video media already used for the session and the SCC AS decides to add or remove CS video media to/from the existing CS bearer, the SCC AS shall apply the procedure in accordance with 3GPP TS 24.229 [11] and the CS SDP as described in IETF RFC 7195 [36].
10	Roles for call termination
10.1	Introduction
This clause specifies the procedures for call termination to an ICS UE and a non-ICS UE. The following procedures describe Terminating Access Domain Selection at both the SCC AS and terminating ICS UE, to decide the service control type for the terminating side of the session. Service control signalling path over Gm for an ICS UE and IMS service control for a non ICS UE via an MSC server enhanced for ICS are specified. Procedures specific to the SCC AS and MSC server enhanced for ICS are also described.
Subclause A.5 provides examples of signalling flows for call termination.
10.2	ICS UE
10.2.1	General
This clause specifies the procedures for call termination by an ICS UE.
Subclause A.5 gives examples of signalling flows for call termination.
10.2.2	ICS UE using Gm
10.2.2.1	General
Subclause 10.2.2 describes the behaviour of the terminating ICS UE.
10.2.2.2	Call control over Gm and all media over IP bearer
When the ICS UE receives a SIP INVITE request containing SDP for establishing a session using just an IP bearer or if the ICS UE decides to use an IP bearer as determined by the procedures in subclause 10.2.2.4, then the ICS UE shall establish this session  in accordance with 3GPP TS 24.229 [11] with the following clarification:
-	if the SIP INVITE request contains a Target-Dialog header field containing dialog parameters that correspond to an existing dialog (or a dialog in the process of being established) between the ICS UE and SCC AS the ICS UE shall treat the SIP INVITE request as another dialog that is part of the same session as the dialog identified by the dialog parameters contained in the Target-Dialog header field;
-	if the SIP INVITE request does not contain a Target-Dialog header field but there is an existing dialog (or a dialog in the process of being established) between the ICS UE and SCC AS the SCC AS shall check if the dialog parameters for this request correspond to the dialog parameters received in a Target-Dialog header field received on an existing dialog (or a dialog in the process of being established) between the ICS UE and SCC AS and if so then the ICS UE shall treat the SIP INVITE request as another dialog that is part of the same session as the dialog that the Target-Dialog header field was received on.
NOTE:	The second case is to cover the possibility that requests can arrive out of the order that they were sent
10.2.2.3	Call control over Gm and voice or voice and video over CS bearer
When:
1)	the ICS UE receives a SIP INVITE request containing an SDP offer to establish a CS bearer according to IETF RFC 7195 [36] and if the SIP response to the SIP INVITE request is to be sent:
a)	using I-WLAN or UTRAN; or
b)	using GERAN and both UE and network support dual transfer mode; or
NOTE:	Indication that network supports dual transfer mode is specified in 3GPP TS 44.018 [46].
2)	the ICS UE has decided to terminate a CS call using the Gm reference point after execution of the procedures in subclause 10.2.2.4;
then the ICS UE shall:
-	send a SIP reliable 183 (Session Progress) response towards the IM CN subsystems as specified in 3GPP TS 24.229 [11]. The UE shall populate the SIP 183 (Session Progress) response as follows:
a)	the SDP payload proposing an audio stream over a circuit-switched bearer as described by IETF RFC 7195 [36] ], as follows:
-	a"c=" line with the nettype portion to "PSTN" and the addrtype portion and connection-address portions both set to "-";
-	a CS media "m=" line's with the media portion set to "audio", port portion set to "9", proto portion to "PSTN" and fmt portion set to "-", as described in IETF RFC 7195 [36];
-	an a=setup attribute set to "active";
-	an a=cs-correlation attribute set to "callerid" along with the MSISDN, of ICS UE in the CS domain, in international E.164 number format;
-	an a=connection attribute set to "new";
and may also be proposing a CS video stream, and;
b)	an indication that the local preconditions for QoS are not met as specified in 3GPP TS 24.229 [11];
-	setup a CS call by sending a SETUP message in accordance with 3GPP TS 24.008 [7] for 3GPP systems. The UE shall populate the SETUP message for 3GPP systems as follows:
a)	the called party BCD number information element set to the E.164 number obtained from the connection-address portion of the "c=" line with the nettype portion set to "PSTN" of the audio media, as described in IETF RFC 7195 [36] received in the SDP body of the SIP INVITE request and the selected codec; and
b)	Type Of Number is set to "International" and Numbering Plan Indicator set to "E.164".in the Called Party BCD Number information element.
-	when the resources are available to the UE, and if the UE has already received an indication from the origination side that related local preconditions for QoS as met on the originating side, shall send a SIP 180 (Ringing) response and continue the call setup as specified in 3GPP TS 24.229 [11].
10.2.2.4	Call control over Gm and T-ADS executed by the UE
When the ICS UE receives, within an initial SIP INVITE request, an SDP offer which allows the UE to select between using an RTP-based IP bearer or a CS bearer for audio media or audio and video media of a session, i.e. in which for the media descriptions ("m=") the following is set:
-	the transport protocol within the "m=" line to RTP-based IP bearer;
-	the related connection line to an IP address;
-	additional a-lines as defined in IETF RFC 5939 [40], IETF RFC 7006 [39], IETF RFC 7195 [36] and IETF RFC 6871 [41] indicating the following:
a)	the media capability attribute "omcap" with a "-" for the  ;
b)	the transport protocol capability attribute "tcap" set to "PSTN"; and
c)	the connection data capability attribute "ccap" with nettype set to "PSTN", indicating "E.164" as address type and the connection-address set to the SCC AS PSI DN, in international E.164 number format;
and the ICS UE supports T-ADS execution:
1)	if the UE in the response to the INVITE request includes a P-Access-Network-Info header field including an access-type field set to one of "3GPP-E-UTRAN-FDD" or "3GPP-E-UTRAN-TDD", the UE is a CS fallback capable UE, and the UE is not responding with a SIP 3xx response, then the following applies, if the Voice_Domain_Preference_E_UTRAN leaf of the 3GPP IMS Management Object (see 3GPP TS 24.167 [8A]) is configured and is: 
a)	set to "1" (i.e. "CS Voice only") and the NAS sublayer has indicated a successful NAS combined attach or combined TA update then the UE shall send back a SIP 488 (Not Acceptable Here) response without SDP body;
b)	set to "1" and the UE fails to access the CS domain , the UE shall send back a SIP 606 (Not Acceptable) response;
c)	set to "2" (i.e. "CS Voice preferred, IMS PS Voice secondary") and the NAS sublayer has indicated a successful NAS combined attach or combined TA update then the UE shall send back a SIP 488 (Not Acceptable Here) response without SDP body;
d)	set to "2" and the NAS sublayer has not indicated a successful NAS combined attach or combined TA update and the IMSVoPS indicator indicates voice is supported, then the UE shall use a RTP-based PS bearer for the related audio media stream;
e)	set to "2" and the UE fails to access the CS domain  and the IMSVoPS indicator indicates voice is not supported, then the UE shall send back a SIP 606 (Not Acceptable) response;
f)	set to "3" (i.e. "IMS PS Voice preferred, CS Voice secondary") and the IMSVoPS indicator indicates voice is supported, then the UE shall use a RTP-based PS bearer for the related audio media stream;
g)	set to "3" and the IMSVoPS indicator indicates voice is not supported and the NAS sublayer has indicated a successful NAS combined attach or combined TA update, then the UE send back a SIP 488 (Not Acceptable Here) response without SDP body;
h)	set to "3" and the IMSVoPS indicator indicates voice is not supported and the UE fails to access the CS domain , then the UE shall send back a SIP 606 (Not Acceptable) response;
i)	set to "4" (i.e. "PS Voice only") and the IMSVoPS indicator indicates voice is supported, then the UE shall use a RTP-based PS bearer for the related audio media stream or;
j)	set to "4" and the IMSVoPS indicator indicates voice is not supported, then the UE shall send back a SIP 606 (Not Acceptable) response;
2)	if the UE in the response to the INVITE request includes a P-Access-Network-Info header field including an access-type field set to one of "3GPP-UTRAN-FDD" or "3GPP-UTRAN-TDD", and the UE is not responding with a SIP 3xx response, then the following applies, if the Voice_Domain_Preference_UTRAN leaf of the 3GPP IMS Management Object (see 3GPP TS 24.167 [8A]) is configured and is:
a)	set to "1" (i.e. "CS Voice only"), then the UE shall use the CS bearer for the related audio media stream;
b)	set to "2" (i.e. "CS Voice preferred, IMS PS Voice secondary") and the IMSVoPS indicator indicates voice is not supported, then the UE shall use the CS bearer for the related audio media stream;
c)	set to "2" (i.e. "CS Voice preferred, IMS PS Voice secondary") and the IMSVoPS indicator indicates voice is supported, then the UE should use the CS bearer for the related audio media stream or may use a RTP-based PS bearer for the related audio media stream;
d)	set to "3" (i.e. "IMS PS Voice preferred, CS Voice secondary") and the IMSVoPS indicator indicates voice is supported, then the UE should use a RTP-based PS bearer for the related audio media stream or may use the CS bearer for the related audio media stream; or
e)	set to "3" and the IMSVoPS indicator indicates voice is not supported, then the UE shall use CS bearer for the related audio media stream.
3)	if the UE in the response to the INVITE request includes a P-Access-Network-Info header field including an access-type field set to one of "3GPP-E-UTRAN-FDD" or "3GPP-E-UTRAN-TDD", and the Voice_Domain_Preference_E_UTRAN leaf of the 3GPP IMS Management Object (see 3GPP TS 24.167 [8A]) is not configured:
a)	if the IMSVoPS indicator indicates voice is supported, then the UE can use a RTP-based PS bearer for the related audio media stream; and
b)	if the IMSVoPS indicator indicates voice is not supported, then the UE shall send back a SIP 488 (Not Acceptable Here) response without SDP body;
4)	if the UE in the response to the INVITE request includes a P-Access-Network header field including an access-type field set to one of "3GPP-UTRAN-FDD" or "3GPP-UTRAN-TDD", and the Voice_Domain_Preference_UTRAN leaf of the 3GPP IMS Management Object (see 3GPP TS 24.167 [8A]) is not configured:
NOTE 1:	The UE decides based on local configuration and network conditions whether to use for the related audio media stream an IP connection, RTP-based IP bearer or a CS bearer.
a)	if the IMSVoPS indicator indicates voice is supported, then the UE can use a RTP-based PS bearer for the related audio media stream;
b)	if the IMSVoPS indicator indicates voice is not supported, then the UE shall:
I)	not use this access technology for a RTP-based PS bearer for the related audio media stream (e.g. using a SIP 3xx response); or
II)	send back a SIP 606 (Not Acceptable) response;
5)	if the UE in the response to the INVITE request includes a P-Access-Network-Info header field including an access-type field set to "3GPP-GERAN":
NOTE 2:	The UE decides based on local configuration and network conditions whether to use for the related audio media stream an IP connection, RTP-based IP bearer or a CS bearer.
a)	if both the UE and the network support dual transfer mode, then the UE shall use a CS bearer for the related audio media stream; and
NOTE 3:	Indication that network supports dual transfer mode is specified in 3GPP TS 44.018 [46].
b)	if the UE, network or both do not support dual transfer mode, then the UE shall send back a SIP 488 (Not Acceptable Here) response without SDP body; and
6)	if the UE in the response to the INVITE request includes a P-Access-Network-Info header field including an access-type field not set to one of "3GPP-GERAN", "3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP-E-UTRAN-FDD", or "3GPP-E-UTRAN-TDD", based on local configuration and network conditions, decide whether to use for the related audio media stream an IP connection RTP-based IP bearer or a CS bearer.
If the ICS UE decides to use a IP connection or RTP-based IP bearer, the ICS UE shall proceed as described in subclause 10.2.2.2 and in addition indicate that the IP connection or RTP-based IP bearer is used within the SDP answer in accordance with RFC 5939 [40].
If the ICS UE decides to use a CS bearer- then the ICS UE shall:
1)	send a reliable SIP 1xx provisional response towards the IM CN subsystems as specified in 3GPP TS 24.229 [11]. The UE shall populate the SIP 1xx provisional response as follows:
a)	the SDP answer proposing an audio stream over a circuit-switched bearer as described by IETF RFC 7195 [36], as follows:
-	a "c=" line with the nettype portion to "PSTN" and the addrtype portion and connection-address portions both set to "-";
-	a CS media "m=" line with the media portion set to "audio", port portion set to "9", proto portion to "PSTN" and connection-address portion set to "-" as described in IETF RFC 7195 [36];
-	an a=setup attribute set to "active";
-	an a=connection attribute set to "new"; and
-	an a=cs-correlation attribute set to "callerid" along with the MSISDN, of ICS UE in the CS domain, in international E.164 number format;
b)	indicate within the SDP answer that the CS bearer is used in accordance with RFC 5939 [40]; and
c)	indicate that the local preconditions for QoS are not met as specified in 3GPP TS 24.229 [11];
2)	setup a CS call by sending  a CC SETUP message in accordance with 3GPP TS 24.008 [7] for 3GPP systems. The UE shall populate the CC SETUP message for 3GPP systems as follows:
a)	the called party BCD number information element set to the E.164  number obtained from the connection data capability attribute "ccap" received in the SDP body of the SIP INVITE request; and
b)	Type Of Number is set to "International" and Numbering Plan Indicator set to "E.164".in the Called Party BCD Number information element.
3)	when the resources are available to the UE, and if the UE has already received an indication from the origination side that related local preconditions for QoS as met on the originating side, shall send a SIP 180 (Ringing) response and continue the CS call setup as specified in 3GPP TS 24.229 [11]; and
4)	if the UE fails to access the CS domain the UE shall send back a SIP 606 (Not Acceptable) response.
10.2.3	ICS UE using CS
An ICS UE shall implement the call termination suitable for ICS via CS domain as specified in 3GPP TS 24.008 [7] for 3GPP systems.
10.2.4	CS fallback
On the reception of an SIP INVITE request:
-	if the SDP offer of the SIP INVITE request only includes audio media that can not be served via the current PS connectivity, the ICS UE shall send back a 488 (Not Acceptable Here) response without an SDP body;
NOTE:	As an example the UE responds with a 488 (Not Acceptable Here) response when the ICS UE is unable to support the full duplex speech component of a session using the attached PS network or the attached PS network does not support or allow the full duplex speech component of a session.
-	if the SDP offer of the SIP INVITE request includes audio media that cannot be served via the current PS connectivity but includes other media that can be served by the current PS connectivity, the ICS UE sends back a18x response including an SDP answer indicating rejection of the audio media and acceptance of the other media
10.2.5	ICS UE using I1
10.2.5.1	Call control over I1 and media over CS bearer
When the ICS UE receives an
a)	I1 Invite message from the SCC AS, and the ICS UE determines that it is a mobile Terminated I1 Invite as specified in subclause 7.3.1 in 3GPP TS 24.294 [11B], the ICS UE shall handle the setting up of the I1 session following the procedures specified in subclause 6.2.1.2.2 in 3GPP TS 24.294 [11B]; or
b)	I1 Invite (Augmentation) message from the SCC AS, and the ICS UE determines that no I1 session exists for the Call-Identifier value as specified in subclause 7.2.2.1.4 in 3GPP TS 24.294 [11B] received in the I1 Invite message, the ICS UE shall handle the setting up of the I1 session following the procedures specified in subclause 6.2.1.2.3 in 3GPP TS 24.294 [11B].
10.3	MSC Server enhanced for ICS
When the MSC Server enhanced for ICS receives an initial SIP INVITE request from the IM CN subsystem, the MSC Server enhanced for ICS shall return a 488 (Not Acceptable Here) response as described in 3GPP TS 24.229 [11] if the SIP INVITE request includes an SDP offer which does not contain an acceptable audio codec.
The MSC Server enhanced for ICS shall implement call termination as specified in 3GPP TS 29.292 [24].
10.4	SCC AS
10.4.1	General
The following subclauses describe the procedures at the SCC AS for call termination. In such scenarios, the SCC AS serves the terminating UE. The SCC AS shall follow procedures specified in 3GPP TS 24.229 [11] with the additional procedures described in the subsequent subclauses. These subclauses describe the procedures for the SCC AS when using service control over Gm, I1 and CS, respectively.
10.4.2	Terminating Access Domain Selection
When the SCC AS serving the terminating UE receives an initial SIP INVITE request due to initial filter criteria, the SCC AS may perform:
o)	the procedures as described in 3GPP TS 29.328 [25] to determine if IMS voice over PS session is supported or unknown over the  Radio Access Technology the UE is current on.
The SCC AS shall:
1)	if T-ADS functionality based upon criteria described in 3GPP TS 23.292 [6] results in choosing to deliver all media in the PS domain and to one or more registered contact(s) for the URI in the Request-URI of the SIP INVITE request:
a)	and the registered contact(s) contain(s) the g.3gpp.ics media feature tag set to "principal" then follow the SCC AS procedures as in subclause 10.4.3; and
b)	and the registered contact(s) do not contain the g.3gpp.ics media feature tag set to "principal" then insert the Reject-Contact header field set to the g.3gpp.ics media feature tag into the SIP INVITE request and forward the SIP INVITE request in accordance with 3GPP TS 24.229 [2];
NOTE: 	Where there is a mixture of contacts with or without the g.3gpp.ics media feature tag, the SCC AS can send more than one SIP INVITE request.
2)	if T-ADS functionality based upon criteria described in 3GPP TS 23.292 [6] results in choosing to deliver media in the CS domain, and using CS domain service control, the SCC AS:
a)	if for the related public user identity a registration from an MSC Server enhanced for ICS exists, then follow the SCC AS procedures as defined in subclause 10.4.5; and
b)	if for the related public user identity no registration from an MSC Server enhanced for ICS exists, then follow the SCC AS procedures as defined in subclause 10.4.7;
3)	if one or more registered contacts for the URI in the Request-URI of the SIP INVITE request contains the g.3gpp.ics media feature tag set to "principal", and if T-ADS functionality based upon criteria described in 3GPP TS 23.292 [6] results in choosing to deliver media in the CS domain, and using Gm for service control, then follow the SCC AS procedures defined in subclause 10.4.4;
3a)	if:
i)	one or more registered contacts for the URI in the Request-URI of the SIP INVITE request contains the g.3gpp.ics media feature tag set to "principal"or if local policy determines that the terminating UE is an ICS UE; and
ii)	if T-ADS functionality based upon criteria described in 3GPP TS 23.292 [6] results in choosing to deliver media in the CS domain, and using I1 as specified in 3GPP TS 24.294 [11b] for service control;
then follow the SCC AS procedures defined in subclause 10.4.8; and
4)	if one or more registered contacts for the URI in the Request-URI of the SIP INVITE request contains the g.3gpp.ics media feature tag set to "principal", and if T-ADS functionality based upon criteria described in 3GPP TS 23.292 [6] results in preferring the ICS UE to execute T-ADS to select an appropriate domain for the media bearer, the SCC AS shall create a SIP INVITE request based upon the incoming request including containing within the SDP offer with an RTP-based IP bearer and an alternative circuit-switched bearer as described in subclause 10.4.6 for the ICS UE to execute T-ADS.
10.4.3	SCC AS for call termination in IM CN
When the SCC AS serving the terminating ICS UE receives an initial SIP INVITE request due to initial filter criteria and the T-ADS results in choosing to deliver media in the PS domain, the SCC AS shall act as a B2BUA, and
if multiple contacts are registered in the PS domain and the T-ADS chooses to establish different media types using different IP-CANs, the SCC AS shall for each selected PS domain IP-CAN create a SIP INVITE request in accordance with 3GPP TS 24.229 [2] and shall include, in this request;
i)	an Accept-Contact header field containing the g.3gpp.accesstype media feature tag containing the value associated at registration with the selected PS domain IP-CAN and the media feature tag g.3gpp.ics containing the value "principal" along with the parameters "require" and "explicit";
NOTE 1: The SCC AS can determine which g.3gpp.accesstype media feature tag values to use by taking into account the access-type and  access-class of the P-Access-Network-Info header and the value of the media feature tag g.3gpp.accesstype . The values in the 3gpp.accesstype media feature tag does not necessarily always identify an IP-CAN.
NOTE 2:	It is possible that a handover between different IP-CANs can take place without a reregistration of the UE and corresponding update of access-type and access-class (e.g. from "3GPP-UTRAN" to "3GPP-E-UTRAN"). The SCC AS needs to take this possibility into account when determining the IP-CAN to use.
ii)	if an existing leg for this session already exists or is in the process of being established between the SCC AS and the ICS UE using a different IP-CAN then a Target-Dialog header field containing the dialog parameters for that existing dialog between the SCC AS and the ICS UE; and
NOTE 3:	The SCC AS includes a Target-Dialog header field in the SIP INVITE request so that the ICS UE can correlate different requests as part of the same session.
iii)	SDP for the media type(s) selected to be established using this IP-CAN.
-	if multiple contacts are registered in the PS domain and the T-ADS chooses to establish all the media types over the same IP-CAN, the SCC AS shall create a SIP INVITE request in accordance with 3GPP TS 24.229 [2] and shall include, in this request:
i)	an Accept-Contact header field containing the g.3gpp.accesstype media feature tag containing the value associated at registration with the selected PS domain IP-CAN and the media feature tag g.3gpp.ics containing the value "principal" along with the parameters "require" and "explicit";
NOTE 4:	The SCC AS can determine which g.3gpp.accesstype media feature tag values to use by taking into account the access-type and  access-class of the P-Access-Network-Info header and the value of the media feature tag g.3gpp.accesstype . The values in the 3gpp.accesstype media feature tag does not necessarily always identify an IP-CAN.
NOTE 5:	It is possible that a handover between different IP-CANs can take place without a reregistration of the UE and corresponding update of access-type and access-class (e.g. from "3GPP-UTRAN" to "3GPP-E-UTRAN"). The SCC AS needs to take this possibility into account when determining the IP-CAN to use.
ii)	if an existing leg for this session already exists or is in the process of being established between the SCC AS and the ICS UE using a different IP-CAN then a Target-Dialog header field containing the dialog parameters for that existing dialog between the SCC AS and the ICS UE; and
NOTE 6:	The SCC AS includes a Target-Dialog header field in the SIP INVITE request so that the ICS UE can correlate different requests as part of the same session.
iii)	SDP for all the media types contained in the initial SIP INVITE request.
-	if only a single contact is registered in the PS domain the SCC AS shall create a SIP INVITE request in accordance with 3GPP TS 24.229 [2] and shall include, in this request:
i)	an Accept-Contact header field containing the media feature tag g.3gpp.ics containing the value "principal" along with the parameters "require" and "explicit"; and
ii)	SDP for all the media types contained in the initial SIP INVITE request.
If the SCC AS receives a 488 (Not Acceptable Here) response, from:
-	a UE:
i.	not including any SDP body; or
ii.	including an SDP body:
a)	without a media description ("m=") indicating "audio";
b)	with a media description ("m=") only indicating "audio" with the  subfield set to "PSTN" and with a connection data line ("c=") with  set to "PSTN";
then, the SCC-AS may follow the procedures in: 
1)	subclause 10.4.5 if one or more registered contacts for the URI in the Request-URI of the initial SIP INVITE request contains the g.3gpp.ics media feature tag set to "server"; or
2)	subclause 10.4.7.
If the SCC AS receives a18x response including an SDP answer with a media description ("m=") set to "audio" and port portion set to "0", the SCC AS may follow the procedures in subclause 10.4.5 or subclause 10.4.7.
10.4.4	SCC AS for call control over Gm and voice or voice and video over CS
When the SCC AS serving the ICS UE receives an initial SIP INVITE request due to initial filter criteria and the T-ADS results in choosing to deliver media in the CS domain, the SCC AS shall act as a B2BUA, the SCC AS shall:
0)	store the information received in the initial SIP INVITE request received from the remote UE;
1)	allocate an SCC AS PSI DN which is specified as an E.164 number, and shall identify and be associated with the stored information in step 1) and associated with the SCC AS ;
2)	create a SIP INVITE request and include:
a)	a Request-URI set to the value of the Request-URI as received in the incoming SIP INVITE request;
b)	a dedicated Accept-Contact header field with a media feature tag with the value g.3gpp.ics set to principal and append "require" and "explicit";
NOTE 1:	Other feature tags can also be included in the dedicated Accept-Contact header field if the feature tags have the same requirements on the "explicit" and "require" parameter.
b1)	an Accept-Contact header field with the values received in the Accept-Contact header field in the incoming SIP INVITE except for any g.3gpp.ics media feature tags; and 
NOTE 2: 	According to IETF RFC 3841 [35A] when the value of the "explicit" and "require" parameters are different for feature tag values they will be placed in separate Accept-Contact header fields.
c)	an SDP offer based on the received SDP from the originator and including the following:
i)	in the SDP offer towards the terminating ICS UE, include an additional CS media "m=" line with media portion set to audio, port portion set to "9", proto portion set to "PSTN" and fmt portion set to "-", as described in IETF RFC 7195 [36] and may also include a CS video media stream according to the initial SIP INVITE received by the SCC AS;
ii)	a media level "c=" line, , with the nettype portion set to "PSTN" and with the addrtype portion set to "E164" and the connection-address portion set to the SCC AS PSI DN allocated in step 1), in international E.164 number format, in accordance with IETF RFC 7195 [36];
iii)	an a=setup attribute set to "passive"
iv)	an a=connection attribute set to "new"; 
v)	an a=cs-correlation attribute set to "callerid";
vi)	codecs based on local policy and the received SDP offer from the remote UE; and
vii)	an indication that preconditions are not met;
d)	a new Record-Route header field that contains only a SIP URI pointing to the SCC AS; and
e)	a Contact header field that includes the contents of the Contact header field received in the incoming initial SIP INVITE request; and
3)	route the created SIP INVITE request towards the ICS UE.
When the SCC AS has received the 18x response containing the SDP answer accepting an audio stream over a circuit-switched bearer from the ICS UE and receives a SIP INVITE request with the Request-URI a valid  SCC AS PSI DN as allocated in the above step 1and with the P-Asserted-Identity header field containing the E.164 number received in the a=cs-correlation attribute contained in the SDP answer from the response to the SIP INVITE request received from the ICS UE then  the SCC AS shall:
NOTE 3:	The SCC AS could receive the SIP INVITE request before the SIP 18x response. IETF RFC 7195 [36] provides guidance on handling this situation.
1)	check that the SCC AS PSN DN is encoded as a tel URI (see IETF RFC 3966 [42]) or SIP URI with the "user" SIP URI parameter set to "phone", in accordance with 3GPP TS 23.003 [4], subclause 13.5.
NOTE 3:	The SCC AS could receive the SIP INVITE request before the SIP 18x response. IETF RFC 7195 [36] provides guidance on handling this situation.
2)	use the SCC AS PSI DN and E.164 number received in the a=cs-correlation attribute contained in the SDP answer from the response to the SIP INVITE request received from the ICS UE to correlate the with the SIP INVITE request from the remote  UE; and
3)	send a response to the initial SIP INVITE request with the Request-URI containing the SCC AS PSI DN in accordance with 3GPP TS 24.229 [11], indicating local preconditions met.
When the SCC AS receives a 18x response containing the SDP answer accepting an audio stream over a circuit-switched bearer from the ICS UE and the SIP INVITE request with the Request-URI containing the SCC AS PSI DN number, the SCC AS shall generate a SIP 18x response toward the remote UE that includes the information received in the SIP 18x response with the following exceptions:
a)	prepare an SDP answer to be sent to the originating UE. The SDP answer shall be based on the SDP answer received from the ICS UE and the SDP offer received from the initial SIP INVITE request with the Request-URI containing the SCC AS PSI DN. If the "m=" lines of the SDP offer from the CS domain includes more than one codecs the SCC AS shall delete the lowest priority codecs. The status line in the response sent to the originating UE shall be the same as received in the 18x response from the ICS UE. The SDP answer sent to the remote UE shall be in accordance with IETF RFC 3264 [31];
b)	replace the Record-Route header field(s) received in the SIP 18x response with a new Record-Route header field that only contains a SIP URI pointing to the SCC AS; and
c)	set the Contact header field to include the contents of the Contact header received in the SIP 183 (Session Progress) response, except the g.3gpp.ics media feature tag.
When the SCC AS gets aware that the remote precondition is fulfilled on the leg with the remote UE and on the leg with the CS domain, the SCC AS shall send a SIP UPDATE request to the ICS UE indicating that precondition is met.
When the SCC AS receives preconditions are met on the leg with the CS domain the SCC AS shall:
1)	send a SIP 200 (OK) for the SIP UPDATE request on the leg with the CS domain; and
2)	send a SIP 200 (OK) for the SIP INVITE request on the leg with the CS domain.
10.4.5	SCC AS for call termination to CS network via MSC Server enhanced for ICS
The SCC AS shall act as a B2BUA, the SCC AS shall create a SIP INVITE request in accordance with 3GPP TS 24.229 [11] with the following information;
1)	shall set the Request-URI to the value of the Request-URI as received in the incoming SIP INVITE request; and
2)	 include in Accept-Contact header fields:
-	the values received in the Accept-Contact header field(s) in the incoming SIP INVITE request except for any g.3gpp.ics media feature tags 
-	a media feature tag with the value g.3gpp.ics set to server appended with the value "explicit" and "require".
NOTE:	According to IETF RFC 3841 [35A] when the value of the "explicit" and "require" parameters are different for feature tag values they will be placed in separate Accept-Contact header fields.
10.4.6	SCC AS allowing UE to execute T-ADS
When the SCC AS serving the terminating ICS UE receives an initial SIP INVITE request due to initial filter criteria and the T-ADS results in allowing the ICS UE to execute T-ADS, the SCC AS shall act as a B2BUA, the SCC AS shall:
1)	allocate an SCC AS PSI DN associated with the SCC AS and the SIP INVITE request from the originating UE;
2)	create a SIP INVITE request and include the following:
a)	set the Request-URI to the value as received in the Request-URI in the incoming SIP INVITE request;
b)	a dedicated Accept-Contact header field a media feature tag with the value g.3gpp.ics set to principal appended with the value "explicit" and "require";
NOTE 1:	Other feature tags can also be included in the dedicated Accept-Contact header field if the feature tags have the same requirements on the "explicit" and "require" parameter.
b1)		 an Accept-Contact header field with media feature tag  values received in the Accept-Contact header field(s) in the incoming SIP INVITE request except for any g.3gpp.ics media feature tags;  and
NOTE 2: 	According to IETF RFC 3841 [35A] when the value of the "explicit" and "require" parameters are different for feature tag values they will be placed in separate Accept-Contact header fields.
c)	within the SDP offer based on the received SDP from the originator, for every media line indicating audio set the following:
i)	transport protocol within the media line to RTP-based IP bearer;
ii)	related connection line to the value as received from the originator; and
iii)	additional a-lines as defined in IETF RFC 5939 [40], IETF RFC 7006 [39], IETF RFC 7195 [36] and IETF RFC 6871 [41] indicating that:
-	the required capability negotiation extensions attribute "creq" set to "med-v0", indicating that the SDP capability negotiation mechanism for negotiating media capabilities must be supported by the terminating UE in order to initiate T-ADS;
-	the media capability attribute "omcap" with a "-" for the  ;
-	the transport protocol capability attribute "tcap" set to "PSTN";
-	the connection data capability attribute "ccap" with nettype set to "PSTN", indicating "E.164" as address type and the  connection-address set to the SCC AS PSI DN allocated in step 1), in international E.164 number format. The SCC AS PSI DN identifies the stored information and is associated with the SCC AS;
-	the related preconditions of the originating side are not met as specified in 3GPP TS 24.229 [11]; and
NOTE 3:	In the case when the UE chooses to use the CS bearer, the resources are not available in the MGCF. Therefore, regardless on the current status of the resource reservation at the originating side, the SCC AS sets the preconditions to not met.
3)	route the created SIP INVITE request towards the ICS UE. 
Upon receipt of a SIP response to this SIP INVITE request, including an SDP answer indicating that the UE has chosen the RTP-based IP bearer, the SCC AS shall proceed in accordance with 3GPP TS 24.229 [11].
When the SCC AS receives a SIP INVITE request with the Request-URI containing a valid SCC AS PSI DN encoded as a tel URI (see IETF RFC 3966 [42]) or SIP URI with the "user" SIP URI parameter set to "phone", in accordance with 3GPP TS 23.003 [4], subclause 13.5 as allocated in the above step 1 then the SCC AS shall proceed as defined in subclause 10.4.4.
When the SCC AS has received the SIP 18x response containing the SDP answer accepting an audio stream over a circuit-switched bearer from the ICS UE;
a)	and the UE indicates that service control will be via I1, and I1 is supported on the SCC AS, the SCC AS shall generate an I1 Invite message to the terminating ICS UE as specified in subclause 6.2.1.3.2.1 with the additions in accordance to the procedures in 3GPP TS 24.294 [11]; or
b)	otherwise, the SCC AS shall proceed as defined in subclause 10.4.4.
If the SCC AS receives a SIP 488 (Not Acceptable Here) response, from a UE:
i.	not including any SDP body; or
ii.	including an SDP body:
a)	without a media description ("m=") indicating "audio";
b)	with a media description ("m=") only indicating "audio" with the  subfield set to "PSTN" and with a connection data line ("c=") with  set to "PSTN";
then, the SCC-AS may follow the procedures in:
1)	subclause 10.4.5 if one or more registered contacts for the URI in the Request-URI of the initial SIP INVITE request contains the g.3gpp.ics media feature tag set to "server"; or
2)	subclause 10.4.7.
If the SCC AS receives a SIP 18x response including an SDP answer with a media description ("m=") set to "audio" and port portion set to "0", the SCC AS may follow the procedures in subclause 10.4.5 or subclause 10.4.7.
10.4.7	SCC AS for call termination over CS
If the SCC AS receives:
-	an initial SIP INVITE request due to the initial filter criteria;
-	a 488 (Not acceptable Here) response from the UE:
i.	not including any SDP body;
ii.	including an SDP body:
a)	without a media description ("m=") indicating "audio";
b)	with a media description ("m=") only indicating "audio" with the  subfield set to "PSTN" and with a connection data line ("c=") with  set to "PSTN"; or
-	a18x response from the UE including an SDP answer with a media description ("m=") set to "audio" and port portion set to "0";
then the SCC AS may select to breakout to the CS domain
If the SCC AS selects to breakout to the CS domain, the SCC AS retrieves via procedures as defined in subclause 6.4 the correlation MSISDN associated with the private user identity associated with the public user identity which is the served party of the session. The SCC AS shall, based on the correlation MSISDN, fetch a CSRN for routing the call to the CS domain. To perform CS breakout, the SCC AS shall act as B2BUA and shall create the SIP INVITE in accordance to the procedures in 3GPP TS 24.229 [11] with the headers as follows;
1)	set the Request-URI of the outgoing SIP INVITE request to the CSRN; and
2)	set the To header field of the outgoing SIP INVITE request to the CSRN;
NOTE:	How the CSRN gets selected by the SCC AS is out of the scope of this specification.
10.4.8	SCC AS for call control over I1 and media over CS
10.4.8.0	SCC AS sends I1 Invite message
When the SCC AS receives an initial SIP INVITE request from the remote UE destined for the serving ICS UE, and if upon performing the T-ADS, the SCC AS selects to deliver the media via the CS domain using the I1 protocol, the SCC AS shall:
1)	store the information received in the initial SIP INVITE request received from the remote UE;
2)	allocate the SCC AS PSI DN which is specified as an E.164 number, and shall identify and be associated with the stored information in step 1); and
3)	use the information received in the initial SIP INVITE request to generate, store and forward an I1 Invite message toward the ICS UE in accordance with subclause 6.2.1.3.2.1 in 3GPP TS 24.294 [11B].
When the SCC AS receives a SIP INVITE request from the CS domain (via MGCF) with the Request-URI set to the allocated SCC AS PSI DN, the SCC AS shall: 
0)	check that the Request URI is
i)	set to a valid SCC AS PSI DN as allocated in the above step 2, and
ii)	the SCC AS PSI DN is encoded as a tel URI (see IETF RFC 3966 [42]) or SIP URI with the "user" SIP URI parameter set to "phone", in accordance with 3GPP TS 23.003 [4], subclause 13.5;
If the SCC AS PSI DN is valid and if the Timer(s) as specified in subclause 7.5.3.2.2.2 in 3GPP TS 24.294 [11B] has not expired, the SCC AS shall:
1)	correlate the received SCC AS PSI DN contained in the Request URI of the SIP INVITE request received from the CS domain with the information saved in step 2 above;
2)	send an 18x message that contains the SDP answer toward the remote UE. The SDP answer shall be based on the SDP offer received in the SIP INVITE request from the CS domain; and
3)	create a response towards the CS domain in accordance with 3GPP TS 24.229 [11]. The response towards the CS domain shall contain the SDP answer. The SDP answer sent towards the CS domain is based on the SDP offer received in the initial SIP INVITE request previously received from the remote the UE.
If the SCC AS receives an I1 Progress message (with Reason field set to either 180 "Ringing" or 183 "Call Progress") over the I1 interface prior to receiving the SIP INVITE request from the CS domain, the SCC AS shall use the I1 Progress message in accordance with subclause 6.2.1.3.2.2 in 3GPP TS 24.294 [11B] and wait until the SIP INVITE request from the CS domain is received.
When the SCC AS receives an indication from the CS domain that the media resources are available (e.g. the SCC AS receives a SIP message from the MGCF) and upon receiving an I1 Progress message with Reason field set to 180 "Ringing", the SCC AS shall forward a SIP 180 (Ringing) response to the remote UE.
Upon receiving an I1 Success message from the ICS UE, the SCC AS shall forward a SIP 200 (OK) response to the remote UE.
Upon receiving a SIP ACK request from the remote UE, the SCC AS shall send a SIP ACK request towards the CS domain.
10.4.8.1	SCC AS receives a I1 Bye message
When the SCC AS enhanced for I1 receives a binary I1 Bye message using the I1 session control channel:
a)	if there are no more I1 service control sessions using the CS bearer, then the SCC AS shall not transmit a I1 Success message using the I1 session control channel back to the ICS UE. If there are other I1 service control sessions using the CS bearer, then the SCC AS shall perform the procedures as in accordance with subclause 6.2.3.3.3 in 3GPP TS 24.294 [11B];
b)	based on the value of the Call-Id information element included in the I1 Bye message, the SCC AS shall transmit the following SIP requests:
-	if there are no more I1 service control sessions using the CS bearer associated with the value of the Call-Id information element, if a SIP BYE request from the CS domain has not been received, send a SIP BYE request to the CS domain; and
-	release the SIP session by sending a SIP BYE request towards the B-party associated with the value of the Call-ID information element.
10.4.8.2	SCC AS receives a SIP Bye message from the CS domain
When the SCC AS enhanced for I1 receives a SIP BYE from the CS domain for a CS bearer:
-	the CS bearer release timer shall be cleared, if set;
-	respond with a SIP 200 (OK) response to the SIP BYE request;
10.4.8.3	SCC AS receives a SIP BYE message from a remote ICS UE
When the SCC AS receives a SIP BYE request from a remote ICS UE, it shall:
-	respond with a SIP 200 (OK) response to the SIP BYE request;
-	release the I1 session using an I1 Bye message according to subclause 6.2.3.3.1 in 3GPP TS 24.294 [11B];
-	if there are no more I1 service control sessions using the CS bearer, set a CS bearer release timer value.
If the CS bearer release timer expires and no SIP BYE from the CS domain was released, the SCC AS shall release the CS bearer by sending a SIP BYE request to the CS domain. If the SCC AS receives an I1 Success act in accordance to subclause 6.2.3.3.2 in 3GPP TS 24.294 [11B].
10.4.8.4	SCC AS receives SIP error from remote UE
If the SCC AS receives a stastus line as specified in subclause 7.2 of IETF RFC 3261[45] with status code value 3xx to 6xx as specified in subclause 21.3-21.6 of IEFF RFC 3261 [45], the SCC AS shall:
a)	send an I1 Failure message in accordance with subclause 6.2.1.4 in 3GPP TS 24.294 [11B] toward the UE.
11	Roles for session release
11.1	Introduction
This clause specifies session release procedures for when an ICS UE releases a session using a service control signalling path over Gm and when a non-ICS UE has IMS service control via an MSC server enhanced for ICS. The associated procedures for the SCC AS are also specified in this clause; specifically, the CS bearer release procedures when using Gm are described. The clause also specifies the SCC AS procedures when it detects the loss of service control signalling path over Gm. The session release procedures specific to an MSC server enhanced for ICS are also described.
11.2	ICS UE
11.2.1	General
This clause specifies the procedures for session release by an ICS UE.
11.2.2	ICS UE using Gm
The ICS UE shall support session release suitable for ICS via Gm reference point as specified in 3GPP TS 24.229 [11].
If the ICS UE uses a CS bearer, the UE shall release the resources in accordance with 3GPP TS 24.008 [7] for 3GPP systems, to release the CS bearer.
NOTE:	The order of releasing the CS or PS resources is an implementation issue.
11.2.3	ICS UE using CS
The ICS UE shall implement the bearer release towards SCC AS suitable for ICS via CS domain in accordance with 3GPP TS 24.008 [7] for 3GPP systems.
11.2.4	ICS UE using I1
3GPP TS 24.294 [11B] specifies the session release procedures for an ICS UE using I1.
11.3	MSC Server enhanced for ICS
The MSC Server enhanced for ICS shall implement session release as specified in 3GPP TS 29.292 [24].
11.4	SCC AS
11.4.1	General
The following subclauses describe the procedures at the SCC AS for session release. In such scenarios, the SCC AS serves the terminating ICS UE. The SCC AS shall follow procedures specified in 3GPP TS 24.229 [11] with the additional procedures described in this specification in subclauses 11.4.2 and 11.4.3. These subclauses describe the procedures for the SCC AS when using service control over Gm and CS, respectively.
11.4.2	SCC AS for service control over Gm
When the SCC AS receives a SIP BYE request the SCC AS shall:
1)	determine if the SIP BYE request was originated due to release of a service control session or if the SIP BYE requested was originated in the CS domain as a result of ICS UE bearer release procedures; and
2)	if the SIP BYE request was received from an endpoint involved in the session to be released, this indicates a user's desire to release the service control session forward the SIP BYE request towards the other endpoint involved in the session. 
The SCC AS distinguishes the SIP BYE requests generated by the MGCF and the SIP BYE requests from the ICS UE by the associated dialog IDs. 
When the SCC AS receives a SIP BYE request from the ICS UE, the SCC AS shall:
-	forward the SIP BYE request towards the remote leg in accordance with the procedures defined in 3GPP TS 24.229 [11]; and
-	if the CS bearer is not used by any other session, send a SIP BYE request towards the MGCF, in accordance with the procedures defined in 3GPP TS 24.229 [11], to release the CS bearer.
When the SCC AS receives a SIP BYE request from the MGCF, the SCC AS shall do the following for every session associated with the ICS UE which has a CS bearer:
-	if the session includes other PS media in addition to the CS media, the SCC AS shall send a SIP re-INVITE or a SIP UPDATE request towards 
-	the access leg, removing the CS media by setting the port number to zero for the CS media "m=" line set to "PSTN" as described in IETF RFC 7195 [36]; and
-	the remote leg, removing the corresponding audio media by setting the port number to zero; and
-	if the session only contains CS media, the SCC AS shall send a SIP BYE request towards both the access and remote legs in accordance to the procedures defined in 3GPP TS 24.229 [11].
11.4.3	SCC AS procedure upon loss of Gm service control
If the SCC AS detects the ICS UE is not reachable over Gm service control, the SCC AS shall for every held session associated with the ICS UE send a SIP BYE request towards the other UE involved in the session in accordance with the procedures defined in 3GPP TS 24.229 [11].
NOTE:	The exact mechanism for detecting loss of Gm by SCC AS is implementation dependent.
11.4.4	SCC AS for service control over I1
3GPP TS 24.294 [11B] specifies the session release procedures for service control using I1.
12	Supplementary service invocation for ICS
12.1	Supplementary service invocation for an ICS UE with IMS sessions using CS bearer
12.1.1	Overview
When the CS bearer is used for the media of the IMS Multimedia Telephony service and service control is provided using Gm, see 3GPP TS 22.173 [2], the procedures specified in subclause 12.1 apply.
3GPP TS 24.294 [11B] specifies the supplementary service procedures for service control using I1.
12.1.2	Use of Gm reference point
12.1.2.1	Line ID Services (OIP, OIR, TIP, TIR)
The procedures as defined in 3GPP TS 24.607 [14] and 3GPP TS 24.608 [15] apply with the addition of the SCC AS combining the description of the CS bearer with the service control signalling communicated over the Gm reference point as specified in subclause 7.4.2.
12.1.2.2		Communication Diversion Services
The procedures as defined in 3GPP TS 24.604 [12] apply with the addition of the SCC AS combining the description of the CS bearer with the service control signalling communicated over the Gm reference point as specified in subclause 7.4.2.
12.1.2.3	Communication Barring
The procedures as defined in 3GPP TS 24.611 [17] apply with the addition of the SCC AS combining the description of the CS bearer with the service control signalling communicated over the Gm reference point as specified in subclause 7.4.2.
12.1.2.4	Communication Hold/Resume
Invocation of Communication HOLD service for ICS UE using Gm reference point shall be as described in 3GPP TS 24.610 [16].
Upon receiving the re-INVITE request describe in subclause 4.5.2.1 of 3GPP TS 24.610 [16], which indicates that media streams shall be held, the SCC AS shall:
1)	generate a new SDP offer that contains "inactive" attribute for the media streams that shall be put on held;
2)	send the  SDP offer in an UPDATE (or re-INVITE) request towards the MGCF or the MSC server enhanced for ICS in order to inactive RTP media;
Upon receiving the re-INVITE request describe in subclause 4.5.2.1 of 3GPP TS 24.610 [16], which indicates that media streams shall be resumed, the SCC AS shall:
1)	send a re-INVITE request without SDP towards the MGCF or the MSC server enhanced for ICS.
2)	after receiving a 200 (OK) response with SDP offer from the MGCFor the MSC server enhanced for ICS, send another re-INVITE request with the SDP offer to the held UE.
3)	after receiving a 200 (OK) response with SDP answer from the held UE, send an ACK request with the SDP answer to the MGCF or the MSC server enhanced for ICS.
12.1.2.5	Explicit Communication Transfer
Invocation of ECT service for ICS UE using Gm reference point shall be as described in 3GPP TS 24.629 [19] for a transferor UE, transferee UE, and transfer target UE.
In the case of ICS UE as transferee, upon receiving an INVITE request from the transferee, the SCC AS shall:
1)	send a re-INVITE request without SDP to MGCF;
2)	after receiving a 200 (OK) response with SDP offer from the MGCF;
3)	initiate an INVITE request with the SDP offer to the transfer target;
4)	if, within a specific time, a response with an SDP answer from the transfer target is not received, send an ACK request to the MGCF with an SDP answer and repeat steps 1) and 2). The SDP answer shall contain the same  media types as the SDP offer received from the MGCF;
5)	after receiving a response with SDP answer from the transfer target, send an ACK request with the SDP answer to the MGCF.
12.1.2.6	Conferencing
Invocation of conferencing service for ICS UE using Gm reference point shall be as described in 3GPP TS 24.147 [8].
12.1.2.7	Communication Waiting 
The procedures defined in 3GPP TS 24.615 [18] apply for invocation of Communication Waiting. The SCC AS shall update the session characteristics upon the existing session being put on hold or released, according to the procedures defined in subclauses 12.1.2.4 or 11.4.2, respectively. 
In the case that a CS bearer shall be established for the waiting session, procedures described in subclause 10.4 shall be applied to the session.
12.1.4	When use of Gm reference point is not possible due to VPLMN limitations
12.1.4.1	When attached to an MSC Server enhanced for ICS
Procedures specified in subclause 12.2 Supplementary service invocation for an ICS UE with IMS sessions using CS bearer apply.
12.1.4.2	When attached to an MSC Server not enhanced for ICS
Procedures specified in subclause 12.3 Supplementary service invocation for non ICS UE when attached to an MSC Server not enhanced for ICS apply.
12.2	Supplementary service invocation using the MSC Server enhanced for ICS
12.2.1	Line ID Services (OIP, OIR, TIP, TIR)
Invocation of line ID services at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.607 [14] and 3GPP TS 24.608 [15] for an originating UE and a terminating UE with the following exception:
-	the MSC Server enhanced for ICS shall also apply the interworking procedures as specified in 3GPP TS 29.292 [24] for line ID services.
12.2.2	Communication Diversion (CDIV) Services
12.2.2.1	General
The following exception applies to the invocation of all CDIV services at the MSC Server enhanced for ICS acting as a diverting UA on behalf of the UE:
-	the MSC Server enhanced for ICS shall not support the user subscription option of "served user receives indication that a communication has been forwarded (indication of communication diversion to the diverting user)".
12.2.2.2	Communication Forwarding Unconditional (CFU)
Invocation of CFU at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.604 [12] for an originating UA, diverted to UA and diverting UA.
12.2.2.3	Communication Forwarding Busy (CFB)
Invocation of CFB at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.604 [12] for an originating UA, diverted to UA and diverting UA with the following exception:
-	for user determined user busy, invocation of CFB at the MSC Server enhanced for ICS acting as a diverting UA shall also apply the interworking procedures as specified in 3GPP TS 29.292 [24] for CFB.
12.2.2.4	Communication Forwarding No Reply (CFNR)
Invocation of CFNR at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.604 [12] for an originating UA, diverted to UA and diverting UA.
12.2.2.5	Communication Forwarding on Not Logged-in (CFNL)
Invocation of CFNL at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.604 [12] for an originating UA, diverted to UA and diverting UA.
12.2.2.6	Communication Deflection (CD)
Invocation of CD at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.604 [12] for an originating UA, diverted to UA and diverting UA with the following exception:
-	invocation of CD at the MSC Server enhanced for ICS acting as a diverting UA shall also apply the interworking procedures as specified in 3GPP TS 29.292 [24] for CD.
12.2.2.7	Communication Forwarding on Subscriber Not Reachable (CFNRc)
Invocation of CFNRc at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.604 [12] for an originating UA, diverted to UA and diverting UA with the following exception:
-	invocation of CFNRc at the MSC Server enhanced for ICS acting as a diverting UA shall also apply the interworking procedures as specified in 3GPP TS 29.292 [24] for CFNRc.
12.2.2.8	Void
12.2.2.9	Diversion notifications to originating users
Diversion notifications to originating users shall be supported at the MSC Server enhanced for ICS as described in 3GPP TS 29.292 [24].
12.2.3	Communication Barring (CB)
Invocation of CB at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.611 [17] for an originating and destination UE with the following exception:
-	the MSC Server enhanced for ICS shall also apply interworking procedures as specified in 3GPP TS 29.292 [24] for CB.
12.2.4	Communication Hold/Resume
Invocation of Hold and Resume at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.610 [16] for an invoking and held UE with the following exception:
-	the MSC Server enhanced for ICS shall also apply interworking procedures as specified in 3GPP TS 29.292 [24] for Hold and Resume.
12.2.5	Explicit Communication Transfer (ECT)
Invocation of ECT at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.629 [19] for a transferor UE, transferee UE and transfer target UE with the following exceptions:
-	the MSC Server enhanced for ICS shall support the transferor role only when the MSC Server enhanced for ICS has a consultation communication with the transfer target (consultative transfer). The MSC Server enhanced for ICS shall not support the transferor role for blind or assured transfer.
-	the MSC Server enhanced for ICS shall also apply interworking procedures as specified in 3GPP TS 29.292 [24] for ECT.
12.2.6	Conferencing
Invocation of Conferencing at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.605 [13] for an originating UE and destination UE with the following exceptions:
-	a Conference Factory URI shall be derived as specified in 3GPP TS 23.003 [4];
-	conference creation by the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.147 [8] subclause 5.3.1.3.3;
-	the MSC Server enhanced for ICS shall invite other users to the conference using one of the REFER method procedures as specified in 3GPP TS 24.147 [8] subclause 5.3.1.5.2 and subclause 5.3.1.5.3;
-	the MSC Server enhanced for ICS shall not subscribe to the conference event package;
-	the MSC Server enhanced for ICS shall also apply the interworking procedures as specified in 3GPP TS 29.292 [24] for Conferencing.
12.2.7	Communication Waiting (CW)
Invocation of Communication Waiting at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.615 [18] with the following exception:
-	the MSC Server enhanced for ICS shall also apply interworking procedures as specified in 3GPP TS 29.292 [24] for Communication Waiting.
12.3	Supplementary service invocation for non ICS UE when attached to an MSC Server not enhanced for ICS
12.3.1	Line ID Services (OIP, OIR, TIP, TIR)
The service control for the Line ID services may be provided by the CS domain if they are provisioned in the CS domain.
12.3.2	Communication Diversion services
12.3.2.1	Communication Diversion services; CFU, CFNL
The procedures as defined in 3GPP TS 24.604 [12] apply with the addition of the SCC AS presenting the SIP UA behaviour toward IM CN subsystem on behalf of the non ICS UE.
12.3.2.2	Communication Diversion services; CFNR, CFB
The procedures as defined in 3GPP TS 24.604 [12] apply with the addition of the SCC AS presenting the SIP UA behaviour toward IM CN subsystem on behalf of the non ICS UE.
12.3.2.3	Communication Diversion services; Communication Deflection
The service control for the Call Deflection service may be provided by the CS domain if it is provisioned in the CS domain.
12.3.3	Communication Barring
The procedures as defined in 3GPP TS 24.611 [17] apply with the addition of the SCC AS presenting the SIP UA behaviour toward IM CN subsystem on behalf of the non ICS UE.
12.3.4	Communication Hold/Resume
The service control for the Call Hold and Retrieve services may be provided by the CS domain if they are provisioned in the CS domain.
12.3.5	Explicit Communication Transfer
The service control for the Explicit Call Transfer services may be provided by the CS domain if they are provisioned in the CS domain.
12.3.6	Conferencing
The service control for the Call Hold and Retrieve services may be provided by the CS domain if they are provisioned in the CS domain.
12.3.7	User configuration of supplementary services
There are no special procedures for user configuration of supplementary services.
13	Supplementary service configuration for ICS
13.1	General
For ICS, the multimedia telephony application server supports the following methods for supplementary service configuration: 
-	Supplementary service setting requests directly from the ICS UE as described in subclause 13.2; or
-	Supplementary service setting requests from the MSC Server enhanced for ICS as described in subclause 13.3.
The multimedia telephony application server shall allow only one method per ICS user. The multimedia telephony application server shall reject supplementary service configuration requests if the ICS user has chosen the not allowed method.
13.2	ICS UE
The procedures as defined in 3GPP TS 24.173 [9] apply for the ICS UE.
13.3	MSC server enhanced for ICS
The procedures as defined in 3GPP TS 29.292 [24] apply for the MSC Server enhanced for ICS.
Annex A (informative):
Example signalling flows
A.1	Scope of signalling flows
This annex includes signalling flows for ICS which provide examples of ICS specific behaviour. Therefore, signalling flows that would otherwise be identical to examples of normal behaviour without ICS are not included in this annex.
In many cases, the signalling flows in this annex expand on the overview information flows provided in 3GPP TS 23.292 [6].
A.2	Introduction
A.2.1	General
The signalling flows provided in this annex follow the methodology developed in 3GPP TS 24.228 [10]. The following additional considerations apply:
a)	3GPP TS 24.228 [10] shows separate signalling flows with no configuration hiding between networks, and with configuration hiding between networks. There is no ICS specific functionality associated with hiding, and therefore such separate signalling flows are not show in the present document; 
b)	3GPP TS 24.228 [10] does not show the functionality between the S-CSCF and the AS. As ICS can depend on the functionality provided by SCC AS, the signalling flows between S-CSCF and SCC AS are shown in the present document;
c)	3GPP TS 24.228 [10] breaks down the functionality of the various CSCFs. In the present document this is only shown for registration. For all other flows the CSCFs are collapsed into a single entity labelled "Intermediate IM CN subsystem entities"; 
NOTE:	3GPP TS 24.228 [10] is an informative specification that is no longer maintained and cannot be used for specifying ICS requirements. It is not intended that the reader refer to 3GPP TS 24.228 [10] beyond the subclause on methodology.
d)	where entities are combined as in c) above, and the signalling flow is directed to such a combined entity, the contents of the signalling flow represent the contents of the sending entity;
e)	where entities are combined as in c) above and the signalling flow originates at such a combined entity, the contents of the signalling flow represent the contents of the receiving entity; and
f)	ordering of headers within a table does not follow the conventions of 3GPP TS 24.228 [10].
A.2.2	Key required to interpret signalling flows
The key to interpret signalling flows specified in 3GPP TS 24.228 [10] subclauses 4.1 and 4.2 applies with the additions specified below:
-	sip:[email protected] represents the temporary public user ID used for registration.
-	sip:sccas.home1.net represents the address of the SCC AS on the originating side.
-	sip:sccas2.home2.net represents the address of the SCC AS on the terminating side.
Each signalling flow table contains descriptions for headers where the content of the header is new to that signalling flow, as is already performed in 3GPP TS 24.228 [10].
However, 3GPP TS 24.228 [10] includes extensive descriptions for the contents of various headers following each of the tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown in 3GPP TS 24.228 [10], then such text is not reproduced in the present document. 
Additional text can also be found on the contents of headers within 3GPP TS 24.228 [10] in addition to the material shown in the present document.
In order to differentiate between messages for SIP and media, the notation in figure A.2-1 is used.
 EMBED Visio.Drawing.6  
Figure A.2-1: Signalling flow notation
A.3	Signalling flows for registration
A.3.1	Signalling flows for CS UE IMS registration when using an MSC Server enhanced for ICS
Figure A.3.1-1 shows the registration in the IM CN subsystem performed by the MSC Server enhanced for ICS, on behalf of a UE. The registration is triggered upon a CS attach of the UE. In this example the MSC Server is enhanced for ICS and is capable of translating NAS signalling received from the UE to SIP and vice versa. In this example an IBCF is not used. 
 EMBED Visio.Drawing.11  
Figure A.3.1-1 MSC Server enhanced for ICS performs registraton on behalf of the UE
The details of the signalling flows are as follows:
1.	CS attach (UE A to MSC)
As a result of some stimulus, UE A performs CS attachment procedure as specified in 3GPP TS 24.008 [7].
2.	Authentication and Update Location (MSC/VLR to HLR/HSS)
	MSC/VLR retrieves authentication vectors for the received IMSI as specified in 3GPP TS 29.002 [20] and challenges UE A as specified in 3GPP TS 24.008 [7]. After successful authentication, the MSC/VLR sends update location to the HSS/HLR as specified in 3GPP TS 29.002 [20]. HSS/HLR returns subscriber data for the IMSI that was sent by the MSC/VLR.
3.	CS attach accept (MSC to UE A)
	The CS attach request is accepted by the network, an accept message is sent to the MS.
4.	IMS Registration evaluation
	The MSC Server enhanced for ICS evaluates whether it needs to perform registration with the IM CN subsystem. This can be based on subscriber data received from the HSS/HLR.
5.	IMS address discovery
	The MSC Server enhanced for ICS derives a home network domain name as described in 3GPP TS 23.003 [4]. The home network domain is used to perform DNS queries to locate the I-CSCF in the home network.
6.	REGISTER request (MSC Server enhanced for ICS to I-CSCF) – see example in table A.3.1-6
	The purpose of this request is to register a private user identity and a temporary public user identity derived from the subscriber’s IMSI on behalf of the user with an S-CSCF in the home network. This request is routed to the I-CSCF in the home network. In this example no IBCF is employed.
Table A.3.1-6: REGISTER request (MSC Server enhanced for ICS to I-CSCF)
REGISTER sip: ics.mnc015.mcc234.3gppnetwork.org SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];branch=z9hG4bKnashds7
Max-Forwards: 70
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
P-Visited-Network-ID: "Visited Network Number 1 for MSC Server"
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
Path: 
From: ;tag=4fa3
To: 
Contact: ;expires=600000;+sip.instance="";+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server"
Call-ID: apb03a0s09dkjdfglkj49111
Authorization: Digest username=" [email protected] ", realm=" ics.mnc015.mcc234.3gppnetwork.org ", nonce="", integrity-protected="auth-done", uri="sip: ics.mnc015.mcc234.3gppnetwork.org ", response=""
CSeq: 1 REGISTER
Supported: gruu
Require: path
Content-Length: 0

R-URI:	Contains the home network domain name that was derived from the subscribers IMSI as described in 3GPP TS 23.003 [4]. In the given example, the IMSI of the subscriber is 234150999999999.
From:		the temporary public user identity that was derived form the subscribers IMSI as described in 3GPP TS 23.003 [4]. In the given example, the IMSI of the subscriber is 234150999999999.
To:	the temporary public user identity that was derived form the subcribers IMSI as described in 3GPP TS 23.003 [4]. In the given example, the IMSI of the subscriber is 234150999999999.
Contact:	 The point-of-presence representing UE A, i.e. an IP address at the MSC Server enhanced for ICS allocated for  UE a. The Contact header field contains an instance ID and a feature tag indicating that the MSC Server is acting as an MSC Server enhanced for ICS services.
7.	Cx: User registration status query procedure
	The I-CSCF employs network domain security mechanisms to ensure that the REGISTER request was received from a trusted node. The I-CSCF makes a request for information related to the Subscriber registration status by sending the private user identity, public user identity and visited domain name to the HSS as specified in see 3GPP TS 29.228 [23]. The HSS returns the S-CSCF required capabilities and the I-CSCF uses this information to select a suitable S-CSCF.
8.	REGISTER request (I-CSCF to S-CSCF) – see example in table A.3.1-8
	I-CSCF forwards the REGISTER request to the selected S-CSCF.
Table A.3.1-8: REGISTER request (I-CSCF server to S-CSCF)
REGISTER sip:ics.mnc015.mcc234.3gppnetwork.org SIP/2.0
Via: SIP/2.0/UDP icscf.home1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]
Max-Forwards: 69
P-Access-Network-Info:
P-Visited-Network-ID:
P-Charging-Vector:
Path:
From:
To:
Contact:
Call-ID:
Authorization:
CSeq:
Supported:
Require
Content-Length:

9.	Cx: S-CSCF Registration Notification
	Based on configuration data, the S-CSCF knows that the subscriber has already been authenticated by the MSC Server enhanced for ICS. The S-CSCF informs the HSS that the user has been registered. Upon being requested by the S-CSCF, the HSS will also include the user profile in the response sent to the S-CSCF. For detailed message flows see 3GPP TS 29.228 [23].
10.	200 (OK) response (S-CSCF to I-CSCF) - see example in table A.3.1-10
	The S-CSCF sends a 200 (OK) response to the I-CSCF indicating that Registration was successful.
Table A.3.1-10: 200 (OK) response (S-CSCF to I-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP icscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357; branch=z9hG4bKnashds7
Path: 
Service-Route: 
From:
To:
Call-ID:
Contact: ; pub-gruu="sip: [email protected];gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6";temp-gruu="sip:[email protected];gr";+sip.instance="";+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server; expires=600000
CSeq:
P-Associated-URI: , 
Content-Length:

11.	200 (OK) response (I-CSCF to MSC Server enhanced for ICS) - see example in table A.3.1-11
	The I-CSCF forwards the 200 (OK) response to the MSC Server enhanced for ICS indicating that Registration was successful.
Table A.3.1-11: 200 (OK) response (I-CSCF to MSC Server enhanced for ICS)
SIP/2.0 200 OK
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357; branch=z9hG4bKnashds7
Path:
Service-Route:
From:
To:
Call-ID:
Contact:
CSeq:
P-Associated-URI:
Content-Length:

12.	iFC evaluation
	Select the filter criteria for originating session case and check the REGISTER request for the temporary public user identity against the initial filter criterion with the highest priority. In this example there is a match for the SCC AS and therefore the S-CSCF will send a third party REGISTER request to the SCC AS. In this example the filter criteria contains an Include Register Request XML element and an Include Register Response XML element.
13.	REGISTER request (S-CSCF to SCC AS) - see example in table A.3.1-13
	The S-CSCF sends a third party REGISTER request containing in the body the incoming REGISTER request from the PN UE and the 200 (OK) response to the incoming REGISTER request to the SCC AS.
Table A.3.1-13: REGISTER request (S-CSCF to SCC AS)
REGISTER sip:scc_as.home1.net SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]
Max-Forwards: 70
From: ;tag=21235
To: 
Contact: 
Call-ID:
Expires: 600000
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net
P-Charging-Function-Address: ccf=192.1.1.1; ecf=192.1.1.2
CSeq:
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: (…)

--boundary1
Content-Type: message/sip

REGISTER sip:ics.mnc015.mcc234.3gppnetwork.org SIP/2.0
Via: SIP/2.0/UDP icscf.home1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]
Max-Forwards: 69 
P-Visited-Network-ID: "Visited Network Number 1 for MSC Server"
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
From: ;tag=4fa3
To: 
Contact: ;expires=600000;+sip.instance="";+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server"
Call-ID: apb03a0s09dkjdfglkj49111
Authorization: Digest username="[email protected] ", realm=" ics.mnc015.mcc234.3gppnetwork.org ", nonce="", integrity-protected="auth-done", uri="sip: ics.mnc015.mcc234.3gppnetwork.org ", response=""
CSeq: 1 REGISTER
Supported: path, gruu
Content-Length: 0

--boundary1
Content-Type: message/sip

SIP/2.0 200 OK
Via: SIP/2.0/UDP icscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357; branch=z9hG4bKnashds7
Path: 
Service-Route: 
From: ;tag=4fa3
To: 
Call-ID: apb03a0s09dkjdfglkj49111
Contact: ; pub-gruu="sip: [email protected];gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6";temp-gruu="sip:[email protected];gr";+sip.instance="";+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server";expires=600000
CSeq: 1 REGISTER
P-Associated-URI: , 
Content-Length: 0

--boundary1--

14.	200 (OK) response (SCC AS to S-CSCF)
	The SCC AS sends a 200 (OK) response to the S-CSCF indicating the third party REGISTER was successful. 
15.	SCC AS can subscribe to reg-event
	The SCC AS can subscribe to the reg event package for the public user identity registered at the S-CSCF. Contents of the flows for subscription to reg-event from the SCC AS to the S-CSCF are similar as shown in messages 15) to 20).
16.	SUBSCRIBE request (MSC Server enhanced for ICS to S-CSCF) – see example in table A.3.1-16
	The MSC Server enhanced for ICS subscribes to the reg-event package.
Table A.3.1-16: SUBSCRIBE request (MSC Server enhanced to I-CSCF)
SUBSCRIBE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];branch=z9hG4bKnashds7
Max-Forwards: 70
P-Asserted-Identity: 
Privacy: none
From: ;tag=31415
To: 
Route: 
Call-ID: dre36d2v32gnlgiiomm72445
CSeq: 61 SUBSCRIBE
Event: reg
Expires: 600000
Accept: application/reginfo+xml
Contact:
Content-Length: 0

17.	200 (OK) response (S-CSCF to MSC Server enhanced for ICS) - see example in table A.3.1-17
	The S-CSCF sends a 200 (OK) response to the MSC Server enhanced for ICS indicating that the subscription is established.
Table A.3.1-17: 200 (OK) response (S-CSCF to MSC Server enhanced for ICS)
SIP/2.0 200 OK
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];branch=z9hG4bKnashds7
Max-Forwards: 70
P-Asserted-Identity: 
Privacy:
From:
To: ;tag=151170
Call-ID:
CSeq:
Contact: 
Expires:
Content-Length:

18.	NOTIFY request (S-CSCF to MSC Server enhanced for ICS) - see example in table A.3.1-18
	The S-CSCF sends a first NOTIFY request towards the MSC Server enhanced for ICS in order to inform about the registration status of the monitored user.
Table A.3.1-18: NOTIFY request (S-CSCF to MSC Server enhanced for ICS)
NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1
Max-Forwards: 70
From: ;tag=31415
To: ;tag=151170
Call-ID:
CSeq: 42 NOTIFY
Subscription-State: active;expires=600000
Event: reg
Content-Type: application/reginfo+xml
Contact: 
P-Charging-Info: icid=ee36d84688fe;orig-ioi=home1.net
Content-Length: (...)



     
         
             sip:[5555::aaa:bbb:ccc:ddd]

                  
     "<urn: gsma:imei:90420156-025763-0>"
     
                  <urn:urn-7:3gpp-service.ims.icsi.mmtel>” 
                  <server>” 
     
     
                  
     
     
                  
     
         
     
     
         
             sip:[5555::aaa:bbb:ccc:ddd]

         
     


	The message body in the NOTIFY request that carries the subscriber's registration state is formed as indicated in 3GPP TS 24.229 [11].
19.	200 (OK) response (MSC Server enhanced for ICS to S-CSCF) - see example in table A.3.1-19
Table A.3.1-19: 200 (OK) response (MSC Server enhanced for ICS to S-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];branch=z9hG4bKnashds7
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
From:
To:
Call-ID:
CSeq:
Content-Length: 0

A.4	Signalling flows for call origination
A.4.1	Signalling flows for ICS UE origination with CS media using Gm reference point when using an MSC Server enhanced for ICS
Figure A.4.1-1 shows the origination of a call from an ICS UE using CS bearers controlled through the IM CN subsystem. In this example the MSC Server is enhanced for ICS and is capable of translating NAS signalling received from the ICS UE to SIP and vice versa. If the MSC is not enhanced for ICS, translation of NAS signalling to ISUP is required before routing towards a MGCF for interworking with the IM CN subsystem, as shown in subclause A.4.2.
 EMBED Visio.Drawing.11  
Figure A.4.1-1: ICS UE Origination with CS media using Gm reference point when using an MSC Server enhanced for ICS
The details of the signalling flows are as follows:
1.	Determination of call establishment
As a result of some stimulus to establish a session with voice media, the ICS UE based on a combination of user policy, and access technology availability, decides to establish the service control signalling using the IM CN subsystem.
	The ICS UE initiates service control signalling in the IM CN subsystem towards the SCC AS by sending a SIP INVITE request to the intermediate IM CN subsystem entities.
2.	SIP INVITE request (ICS UE to intermediate IM CN subsystem entities) – see example in table A.4.1-2.
Table A.4.1-2: SIP INVITE request (ICS UE to intermediate IM CN subsystem entities) 
INVITE tel:+1-212-555-2222 SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: , 
P-Preferred-Identity: 
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCE11
Privacy: none
From: ;tag=171828
To: 
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Supported: 100rel, precondition, 199, gruu
Accept: application/sdp,application/3gpp-ims+xml
Require: sec-agree
Proxy-Require: sec-agree
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"
P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel 
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port=7531
Contact:  ;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="principal"
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=
c=PSTN - -
t=0 0
m=audio 9 PSTN -
a=setup:active
a=connection:new
a=cs-correlation:callerid:+358504821437
a=curr: qos local none
a=curr: qos remote none
a=des: qos mandatory local sendrcv
a=des: qos mandatory remote sendrcv
a=inactive

	Request-URI:	the SIP URI or tel URI of the called party. In this example the tel URI of the called party is included in the tel URI.
	The SDP included in this SIP INVITE request indicates that the session is to be setup using CS bearers as described in IETF RFC 7195 [36].
3.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to ICS UE)
	The intermediate IM CN subsystem entities respond to the ICS UE with a SIP 100 (Trying) response 
	There is no ICS specific content in this response. 
4.	Evaluation of initial filter criteria
	The S-CSCF evaluates initial filter criteria for the served ICS 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) – see example in table A.4.1-5.
Table A.4.1-5: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS)
INVITE tel:+1-212-555-2222 SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 68
Route: ,;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"
Record-Route: , 
P-Asserted-Identity: ,
P-Access-Network-Info:
Privacy:
From:
To:
Call-ID:
Cseq:
Supported:
Accept:
Require:
Proxy-Require: 
Accept-Contact: 
P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel
Security-Verify:
Contact:
Allow:
Content-Type:
Content-Length: (…)

v=0
o=
s=
c=
t=
m=
a=
a=
a=
a=
a=

6.	SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities)
	The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
7.	SCC AS allocates an SCC AS PSI DN to the ICS UE
	The SCC AS stores the information received in the initial INVITE request and associates an SCC AS PSI DN with this request. The SCC AS PSI DN is returned in a SIP to the ICS UE together with an inidcation that CS bearer establishment is to be initiated by the ICS UE. For this example the SCC AS PSI DN is chosen as +1212556666.
8.	SIP 183 (Session Progress) response (SCC AS to intermediate IM CN subsystem entities) – see example in table A.4.1-8
Table A.4.1-8: SIP 183 (Session Progress) response (SCC AS to intermediate IM CN subsystem entities) 
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route: , , 
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCE11
Privacy: none
From: ;tag=171828
To: 
Call-ID:
CSeq:
Require: 100rel, precondition
Contact:
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933622 2987933622 IN IP6 5555::eee:fff:aaa:bbb
s=-
c=PSTN E164 +12125556666
t=0 0
m=audio – PSTN -
a=setup:passive
a=connection:new
a=cs-correlation:callerid
a=curr: qos local none
a=curr: qos remote none
a=des: qos mandatory sendrcv
a=des: qos mandatory sendrcv
a=inactive

	The SCC AS PSI DN is returned in the SDP body using the mechanisms described in IETF RFC 7195 [36].
9.	SIP 183 (Session Progress) response (intermediate IM CN subsystem entities to ICS UE)
	The SIP 183 (Session Progress) response is routed towards the ICS UE from the intermediate IM CN subsystem entities.
10.	SIP PRACK request and SIP 200 (OK) response
	The ICS UE sends a SIP PRACK request towards the SCC AS via the intermediate IM CN subsystem entities as a result of receiving the reliably sent SIP 183 (Session Progress) response containing the SDP answer.
	Upon receipt of the SIP PRACK request, the SCC AS responds with a SIP 200 (OK) response towards the ICS UE via the intermediate IM CN subsystem entities.
	The is no ICS specific content in these SIP messages.
NOTE:	In the event that the SCC AS does not receive a PRACK request, the SCC AS is capable of handling a new SIP INVITE request sent from the ICS UE as per normal SIP procedures. In this case a new SCC AS PSI DN would be returned to the ICS UE in the SIP 183 (Session Progress) response.
11.	ICS UE proceeds to setup CS bearers
	Upon receipt of the SCC AS PSI DN, the ICS UE proceeds with setting up the call using CS bearers.
12.	SETUP message (ICS UE to MSC Server enhanced for ICS)
	The ICS UE initiates the call over CS bearers by sending a SETUP message to the MSC Server enhanced for ICS.
	Specifically for this signalling flow, the SETUP message includes:
-	Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits = 1212556666)] . The Called Party Number information element is set to the SCC AS PSI DN.
-	Bearer Capability information element = [(information transfer capability  = speech), (speech versions = FR AMR, GSM EFR, GSM FR)]
-	Supported Codec List information element = {[(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)]}
	The MSC Server enhanced for ICS knows the calling party number corresponding to the UE.
13.	CALL PROCEEDING message (MSC Server enhanced for ICS to ICS UE)
	Upon receipt of the SETUP message from the ICS UE, the MSC Server enhanced for ICSresponds with a CALL PROCEEDING message. There is no ICS specific content in this message.
14.	SIP INVITE request (MSC Server enhanced for ICS to intermediate IM CN subsystem entities) – see example in table A.4.1-14
	The MSC Server enhanced for ICS maps the received SETUP message to a SIP INVITE request which is addressed to the SCC AS PSI DN.
Table A.4.1-14: SIP INVITE request (MSC Server enhanced for ICS to intermediate IM CN subsystem entities)
INVITE tel:+1-212-555-6666 SIP/2.0
Via: SIP/2.0/UDP msc1.hom1.net;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: 
P-Asserted-Identity: ,
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net
P-Access-Network-Info: 
Privacy: none
From: ;tag=171828
To: 
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Cseq: 127 INVITE
Supported: 100rel, precondition, gruu, 199
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"
P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel 
Contact: ; +g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server"
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee
s=
c=IN IP6 5555::aaa:bbb:ccc:eee
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=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:	SCC AS PSI DN as received in the SETUP message
P-Asserted-Identity:	The MSC Server enhanced for ICS inserts the tel-URI containing the subscriber number, as received from the ICS UE
Accept-Contact: The MSC Server enhanced for ICS includes the mmtel feature tag in the INVITE request .
Contact:	The MSC Server enhanced for ICS includes the GRUU received at registration, the feature tag g.3gpp.icsi-ref set to "urn%3Aurn-7%3gpp-service.ims.icsi.mmtel" and the feature tag g.3gpp.ics set to "server".
SDP:	The SDP contains preconfigured set of codecs supported by the MGW.
15.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to enahanced MSC Server)
	The intermediate IM CN subsystem entities respond to the MSC Server enhanced for ICS with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
16.	SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) – see example in table A.4.1-16
	The SIP INVITE request is routed towards the SCC AS.
Table A.4.1-16: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS)
INVITE tel:+1-212-555-6666 SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf1.home1.net;branch=z9hG4bKdwe534, SIP/2.0/UDP msc1.hom1.net;branch=z9hG4bKnashds7
Max-Forwards: 68
Route: , ;orig-dialog-id="yuflsae80r3rb3fh31ondyr829cnyr381cn932YDWref0w0-wwtg374"
Record-Route: 
P-Asserted-Identity: ,
P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4ee]; ecf=[5555::6aa:7bb:8cc:9dd]
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi="type 3home1.net"; orig-ioi="home1.net"
P-Access-Network-Info:
Privacy: none
From: 
To: 
Call-ID:
Cseq: 
Supported:
Accept-Contact:
P-Asserted-Service:
Contact: Allow:
Content-Type:
Content-Length:

v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

17.	SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities)
	The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
18.	SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) – see example in table A.4.1-18
	The SCC AS acting as a routing B2BUA, generates a SIP INVITE request based upon the received SIP INVITE request and the information previously stored against this session and routes it towards UE B via the intermediate IM CN subsystem entities.
Table A.4.1-18: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities)
INVITE tel:+1-212-555-2222 SIP/2.0
Via: SIP/2.0/UDP sccas1.home1.net;branch=z9hG4bKnas34r5
Max-Forwards: 67
Route: ;orig-dialog-id="yuflsae80r3rb3fh31ondyr829cnyr381cn932YDWref0w0-wwtg374"
Record-Route: 
P-Asserted-Identity: ,
P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4ee]; ecf=[5555::6aa:7bb:8cc:9dd]
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi="type3home1.net"
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id=3gpp=234151D0FCE11
Privacy: none
From: ;tag=274890
To: 
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Cseq: 127 INVITE
Supported: 100rel, precondition, gruu, 199
Require: sec-agree
Proxy-Require: sec-agree
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"
P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port=7531
Contact:  ;+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 5555::aaa:bbb:ccc:eee
s=
c=IN IP6 5555::aaa:bbb:ccc:eee
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:96 telephone-event
a=maxptime:20

	Request-URI:	The SCC AS replaces the SCC AS PSI DN with the tel URI of the called party which was stored from the initial SIP INVITE request sent in step 2.
	Contact:	In this example the SCC AS includes the contents of the Contact header from the received SIP INVITE request except the g.3gpp.ics media feature tag which is removed by the SCC AS.
	Record-Route:	The SCC AS includes a Record-Route header field that contains its SIP URI and specifies the address where the SCC AS will receive subsequent in-dialog SIP requests originating from the UE B.
19.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to SCC AS)
 	The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
20.	SIP INVITE request (intermediate IM CN subsystem entities to UE B)
	The intermediate IM CN subsystem entities route the SIP INVITE request to UE B.
21.	SIP 100 (Trying) response (UE B to intermediate IM CN subsystem entities)
	UE B responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
22-23. SIP 180 (Ringing) response (UE B to SCC AS via intermediate IM CN subsystem entities)
	UE B responds to the received SIP INVITE request with a SIP 180 (Ringing) response. The response contains no SDP body and contains no ICS specific content.
24-25. SIP 180 (Ringing) response (SCC AS to ICS UE A via intermediate IM CN subsystem entities)
	Upon receiving the SIP 180 (Ringing) response from the terminating UE, the SCC AS sends a SIP 180 (Ringing) response to the ICS UE A via the intermediate IM CN subsystem entities. The response is associated with the SIP INVITE in step 2 and contains no ICS specific content. In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 180 (Ringing) response from the terminating side. Furthermore, the SIP 180 (Ringing) contains no SDP body.
26.	SIP 200 (OK) response (UE B to to intermediate IM CN subsystem entities) – see example in table A.4.1-26
	The terminating side sends an SDP answer in a SIP 200 (OK) response to the received SIP INVITE request.
Table A.4.1-26: SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities)
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK361k21.1, scscf2.home1.net;branch=z9hG4bK764z87.1, icscf1.home1.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP sccas1.home1.net;branch= z9hG4bKnas34r5
Record-Route: , , , 
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCE11
Privacy: none
From: ;tag=274890
To: ;tag=4fa328
Call-ID:
CSeq:
Require: 100rel, precondition
Contact: ; +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=- 2987933623 2987933623 IN IP6 5555::ggg:fff:aaa:bbb
s=-
c=IN IP6 5555::ggg:fff:aaa:bbb
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrcv
a=curr:qos remote sendrcv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=maxptime:20

27.	SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS)
	The SIP 200 (OK) response from UE is routed towards the SCC AS.
28-29. SIP 200 (OK) response (SCC AS to MSC Server enhanced for ICS via intermediate IM CN subsystem entities)
	The SDP answer received in the SIP 200 (OK) response is routed to the MSC Server enhanced for ICS via the intermediate IM CN subsystem entities. In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 200 (OK) response from the terminating side.
30. CONNECT message (MSC Server enhanced for ICS to ICS UE)
	The MSC Server enhanced for ICS maps the received SIP 200 (OK) response to a CONNECT message. There is no ICS specific content in this message.
31.	CONNECT ACKNOWLEDGMENT (ICS UE A to MSC Server enhanced for ICS)
	The ICS UE A sends a CONNECT ACKNOWLEDGMENT message upon receiving the CONNECT message.
32-33. SIP ACK request (MSC Server enhanced for ICS to SCC AS via intermediate IM CN subsystem entities)
	Upon receiving the CONNECT ACKNOWLEDGEMENT from the ICS UE A, the MSC Server enhanced for ICS forwards a SIP ACK request to the SCC AS via the intermediate IM CN Subsystem entities.
	There is no ICS specific content in this request.
34-35.	SIP 200 (OK) response (SCC AS to ICS UE A via intermediate IM CN subsystem entities)
	The SCC AS responds with a SIP 200 (OK) response to the initial INVITE request sent by the ICS UE A in the step 2. Since the SDP answer was previously sent in the SIP 183 (Session Progress) response, the SIP 200 (OK) response contains no SDP body. In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 200 (OK) response from the terminating side.
36-37.	SIP ACK request (ICS UE A to SCC AS via intermediate IM CN subsystem entities)
	The ICS UE A sends a SIP ACK request to the SCC AS via the intermediate IM CN subsystem entities. There is no ICS specific content in this response.
38-39.	SIP ACK request (SCC AS to UE B via intermediate IM CN subsystem entities)
	The SCC AS sends a SIP ACK request to UE B via the IM CN subsystem entities. There is no ICS specific content in this response. 
A.4.2	Signalling flows for ICS UE origination with CS media using Gm reference point when using an MSC Server not enhanced for ICS
Figure A.4.2-1 shows the origination of a call from an ICS UE using CS bearers controlled through the IM CN subsystem. In this example the MSC Server is not enhanced for ICS thus translation at the MGCF of ISUP message to SIP messages is required.
 EMBED Visio.Drawing.11  
Figure A.4.2-1: ICS UE Origination with CS media using Gm reference point when using an MSC Server not enhanced for ICS
The details of the signalling flows are as follows:
1-13:	These steps are identical to steps 1-13 described in subclause A.4.1.
14.	ISUP IAM (MSC Server not enhanced for ICS to MGCF)
	The MSC Server not enhanced for ICS maps the received SETUP message to an ISUP IAM message that is routed towards the MGCF.
	Specifically for this signalling flow, the IAM includes:
-	Called Party Number parameter = [Numbering plan identifier = ISDN/telephony numbering plan], (type of number = international number), (Number digits = 12125556666)]. The Called Party Number is set to the SCC AS PSI DN, as received in the SETUP message.
-	Calling Party Number parameter = [(Numbering plan identifier =  ISDN/telephony numbering plan), (type of number = international number), (Number digits = 12125551111)]
15.	SIP INVITE request (MGCF to intermediate IM CN subsystem entities) – see example in table A.4.2-15
	The MGCF interworks the received IAM message to a SIP INVITE request which is addressed to the SCC AS PSI DN.
Table A.4.2-15: SIP INVITE request (MGCF to intermediate IM CN subsystem entities)
INVITE tel:+1-212-555-6666 SIP/2.0
Via: SIP/2.0/UDP mgcf1.hom1.net;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: 
P-Asserted-Identity: 
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net
Privacy: none
From: ;tag=171828
To: 
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Cseq: 127 INVITE
Supported: 100rel, precondition, gruu, 199
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"
P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel 
Contact: ;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee
s=
c=IN IP6 5555::aaa:bbb:ccc:eee
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=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:	SCC AS PSI DN as received in the SETUP message
P-Asserted-Identity:	The MGCF inserts the tel-URI containing the subscriber number, as received from the ICS UE
SDP:	The SDP contains preconfigured set of codecs supported by the MGW.
16.	SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities)
	The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
17.	SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) – see example in table A.4.2-17
	The SIP INVITE request is routed towards the SCC AS.
Table A.4.2-17: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS)
INVITE tel:+1-212-555-6666 SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf1.home1.net;branch=z9hG4bKdwe534, SIP/2.0/UDP mgcf1.hom1.net;branch=z9hG4bKnashds7
Max-Forwards: 68
Route: , ;orig-dialog-id="yuflsae80r3rb3fh31ondyr829cnyr381cn932YDWref0w0-wwtg374"
Record-Route: 
P-Asserted-Identity: 
P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4ee]; ecf=[5555::6aa:7bb:8cc:9dd]
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi="type 3home1.net"; orig-ioi="home1.net"
P-Access-Network-Info:
Privacy: none
From: ;tag=171828
To: 
Call-ID: 
Cseq: 127 INVITE
Supported:
Require:
Proxy-Require: 
Accept-Contact:
P-Asserted-Service:
Security-Verify:
Contact: 
Allow:
Content-Type:
Content-Length:

v=0
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

18.	SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities)
	The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
19-28.	These steps are identical to steps 18-27 described in subclause A.4.1.
29-30.	SIP 200 (OK) response (SCC AS to MGCF via intermediate IM CN subsystem entities)
	The SDP answer received in the SIP 200 (OK) response is routed to the MGCF via the intermediate IM CN subsystem entities.
31.	ISUP ANM message (MGCF to MSC Server not enhanced for ICS)
	On receipt of the SIP 200 (OK) response, the MGCF generates an ISUP ANM message and sends this to the MSC Server not enhanced for ICS. 
	There is no ICS specific content in this message.
32-33.	These steps are identical to steps 30-31 described in subclause A.4.1.
34-35.	SIP ACK request (MGCF to SCC AS via intermediate IM CN subsystem entities)
	On receipt of the SIP 200 (OK) response, the MGCF sends a SIP ACK request to the SCC AS via the intermediate IM CN Subsystem entities.
	There is no ICS specific content in this request.
36-41.	These steps are identical to steps 34-39 described in subclause A.4.1.
A.4.3	Signalling flows for CS UE origination when using an MSC Server enhanced for ICS — multiple codecs used
Figure A.4.3-1 shows the origination of a call from a CS UE which uses NAS signalling towards the MSC Server enhanced for ICS. The CS UE is controlled by an MSC Server enhanced for ICS. In this example the CS UE supports more than one speech codec. The MSC Server enhanced for ICS is supporting codec negotiation. The MSC Server is enhanced for ICS and is capable of translating NAS signalling received from the CS UE to SIP and vice versa.
 EMBED Microsoft Visio Drawing 
Figure A.4.3-1: CS UE Origination with CS media when using an MSC Server enhanced for ICS – multiple codecs used
The details of the signalling flows are as follows:
1.	SETUP message (CS UE to MSC Server enhanced for ICS)
As a result of some stimulus to establish a session with voice media, the CS UE initiates service control signalling towards the MSC Server enhanced for ICS by sending a SETUP message.
	Specifically for this signalling flow, the SETUP message includes:
-	Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits =12125552222)]
-	Bearer Capability information element = [(information transfer capability  = speech), (speech versions = FR AMR, GSM EFR, GSM FR)]
-	Supported Codec List information element = {[(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)]}
	The MSC Server enhanced for ICS knows the calling party number corresponding to the CS UE
2.	Call proceeding message (MSC Server enhanced for ICS to CS UE)
	The MSC Server enhanced for ICS acknowledges the receipt of the SETUP message by sending a call proceeding message to the CS UE.
Provide IP addresses and RTP information
	The MSC Server enhanced for ICS provides the media gateway with the possible codecs. The MGW provides the MSC Server enhanced for ICS with media information eg IP information and RTP information.
5.	SIP INVITE request (MSC Server enhanced for ICS  to IM CN subsystem entities) – see example in table A.4.3-5.
Table A.4.3-5: SIP INVITE request (MSC Server enhanced for ICS to IMS CN subsystem entities) 
INVITE tel:+1-212-555-2222 SIP/2.0
Via: SIP/2.0/UDP emsc1.home1.net;branch=z9hG4bK332b23.1
Max-Forwards: 68
Route: sip:[email protected];lr>
P-Asserted-Identity: ,
P-Access-Network-Info:3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11;np
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
Privacy: none
From: ;tag=171828
To: 
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
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"
Supported: 100rel, precondition, gruu, 199
P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel 
Contact: ;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server"
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee
s=
c=IN IP6 5555::aaa:bbb:ccc:eee
t=0 0
m=audio 49152 RTP/AVP 97 98 99 100
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/8000/1
a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2
a=rtpmap:98 GSM-EFR/8000/1
a=rtpmap:99 GSM/8000/1
a=ptime:20
a=rtpmap:100 telephone-event
a=maxptime:240

Request-URI:	SCC AS PSI DN as received in the SETUP message
P-Asserted-Identity: The MSC Server enhanced for ICS enhanced for ICS inserts the tel-URI containing the subscriber number stored in the MSC.
Accept-Contact: The MSC Server enhanced for ICS includes the mmtel feature tag in the INVITE request .
P-Asserted -Service: The MSC Server enhanced for ICS includes the mmtel ICSI value in the INVITE request.
Contact:	The MSC Server enhanced for ICS includes the GRUU received at registration, the feature tag g.3gpp.icsi-ref set to "urn%3Aurn-7%3gpp-service.ims.icsi.mmtel" and the media 
SDP: 	The MSC Server enhanced for ICS includes the codecs and IP addresses and port address as received from the MGW.
6.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to MSC Server enhanced for ICS)
	The intermediate IM CN subsystem entities respond to the MSC Server enhanced for ICS with a SIP 100 (Trying) response 
	There is no ICS specific content in this response.
7.	Evaluation of initial filter criteria
	The S-CSCF evaluates initial filter criteria for the served CS user and as a result routes the SIP INVITE request towards the SCC AS.
8.	SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) – see example in table A.4.3-8
Table A.4.3-8: SIP INVITE request (IM CN subsystem entities to SCC AS)
INVITE tel:+1-212-555-2222 SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1,
SIP/2.0/UDP emsc1.home1.net;branch=z9hG4bK332b23.1
Max-Forwards: 67
Route: ,;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"
Record-Route: ,
P-Asserted-Identity:
P-Access-Network-Info:
P-Charging-Vector:
From:
To:
Call-ID:
Cseq:
P-Asserted-Service:
Accept-Contact:
Supported: 
Contact: 
Allow: 
Content-Type: 
Content-Length: (…)

v=0
o=
s=
c= 
t=
m
b
a
a
a
a
a
a
a
a
a
a
a

9.	SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities)
	The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
10 SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) – see example in table A.4.3-10
Table A.4.3-10: SIP INVITE request (SCC AS to IMS CN subsystem entities)
INVITE tel:+1-212-555-2222 SIP/2.0
Via: SIP/2.0/UDP SIP/2.0/UDP sccas1.home1.net;branch=z9hG4bKnas34r5,
SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1,
SIP/2.0/UDP emsc1.home1.net;branch=z9hG4bK332b23.1
Max-Forwards: 66
Route: ;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"
Record-Route:
P-Asserted-Identity:
P-Access-Network-Info:
P-Charging-Vector:
Privacy:
From: ;tag=274890
Call-ID:
Cseq: 
Supported:
Accept: 
Contact:;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"
P-Asserted-Service:
Accept-Contact:
Allow:
Content-Type:
Content-Length: (…)
v=0
o=
s=
c=
t=
m
b
a
a
a
a
a
a
a
a
a
a
a

11.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to SCC AS)
	The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
12.	SIP INVITE request (intermediate IM CN subsystem entities to IMS UE)
	The intermediate IM CN subsystem entities route the SIP INVITE request to IMS UE.
13.	SIP 100 (Trying) response (IMS UE to intermediate IM CN subsystem entities)
	IMS UE responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
14	SIP 183 (Session Progress) response (IMS UE to intermediate IM CN subsystem entities) – see example in table A.4.3-14
Table A.4.3-14: SIP 183 (Session Progress) response (IMS UE to intermediate IM CN subsystem entities) 
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP pcscf2.home1.net;branch=z9hG4bK240f34.1,
SIP/2.0/UDP scscf2.home1.net;branch=z9hG4bK332b23.1,
SIP/2.0/UDP SIP/2.0/UDP sccas1.home1.net;branch=z9hG4bKnas34r5,
SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1,
SIP/2.0/UDP emsc1.home1.net;branch=z9hG4bK332b23.1
Record-Route: ,,
,
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCE11
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
Privacy: none
From: < sip:[email protected] >;tag=274890
To: ;tag=4fa328
Call-ID:
CSeq:
Require: 100rel, precondition
Contact: ;+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=
s=-
c=
t=
m=audio 49152 RTP/AVP 97 100
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=conf:qos remote sendrecv
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2
a=rtpmap:100 telephone-event
a=maxptime:240

15-17.	SIP 183 (Session Progress) response (From IMS UE to MSC Server enhanced for ICS via IM-CN subsystem)
	The SIP 183 (Session Progress) response is routed towards the MSC Server enhanced for ICS via the intermediate IM CN subsystem entities.
18.	SIP PRACK request and SIP 200 (OK) response see example in table A.4.3-18.
	After the speech codec has been determined the MSC Server enhanced for ICS indicates that precondition is met.
Table A.4.3-18: PRACK request (from MSC Server enhanced for ICS to intermediate IM CN entities)
PRACK 
Via:SIP/2.0/UDP emsc1.home1.net;branch=z9hG4bK332b23.1
Max-Forwards: 70
P-Access-Network-Info: 
Route::,;  
From: 
To: 
Call-ID: 
Cseq:
Contact:;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server"
Content-Type: 
Content-Length: (…)

v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd 
t=0 0
m=audio 49152 RTP/AVP 97 100
a=curr:qos local sendrececv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=fmtp:97 mode-set=0,2,5,7; maxframes
a=rtpmap:100 telephone-event
a=maxptime:240

19-20	Setup radio bearer
	At the receipt of the SDP answer with the codec the MSC Server enhanced for ICS indicates the selected codec to the MGW. The MGW releases earlier booked codecs. In this scenario the bearer is set up to the CS UE.
21	RAB Assignment
	The MSC Server enhanced for ICS sets up the radio bearer. It indicates in the NAS synchronisation indicator bit the selected codec to the CS UE.
22-24.	SIP PRACK 200 (OK) (PRACK)
	The PRACK request and its corresponding 200 are sent between MSC Server enhanced for ICS and the IMS UE.
25-28. SIP 180 (Ringing) response (IMS UE to MSC Server enhanced for ICS via intermediate IM CN subsystem entities)
	IMS UE responds to the received SIP INVITE request with a SIP 180 (Ringing) response and alert UE 2.
	The response contains no SDP body and contains no ICS specific content.
	In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 180 (Ringing) response from the terminating side.
29-30.	Send ringing tone.
	At the receipt of the SIP 180 (Ringing) response the MSC Server enhanced for ICS orders the MGW to send a ringing tone towards CS UE.
31	Alerting (MSC Server enhanced for ICS to CS UE)
	The MSC Server enhanced for ICS sends an alerting message to the CS UE.
32-35	SIP 200 (OK) (INVITE) from IMS UE to MSC Server enhanced for ICS via intermediate IM CN subsystem entities
	When IMS UE answers the call the IMS UE sends a SIP 200 (OK) response to the received SIP INVITE request.
	In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 200 (OK) response from the terminating side.
36-39 SIP ACK request (from IMS UE to MSC Server enhanced for ICS via intermediate IM CN subsystem entities)
40-41.	Through connection in both directions
	At the receipt of the SIP 200 (OK) (INVITE) the MSC Server enhanced for ICS through connect in both direction.
42. CONNECT message (MSC Server enhanced for ICS to CS UE)
	The MSC Server enhanced for ICS maps the received SIP 200 (OK) response to a CONNECT message. 
	There is no ICS specific content in this message.
43.	CONNECT ACKNOWLEDGMENT (ICS UE A to MSC Server enhanced for ICS)
	The ICS UE A sends a CONNECT ACKNOWLEDGMENT message upon receiving the CONNECT message.
	There is no ICS specific content in this request.
A.4.4	Signalling flows for CS UE origination when using an MSC Server enhanced for ICS – one codec used
Figure A.4.4-1 shows the origination of a call from a CS UE which uses NAS signalling towards the MSC Server enhanced for ICS. The CS UE is controlled by an MSC Server enhanced for ICS. In this example the CS UE supports one speech codec. The MSC Server enhanced for ICS is not supporting codec negotiation. The MSC Server is enhanced for ICS and is capable of translating NAS signalling received from the CS UE to SIP and vice versa.
 EMBED Visio.Drawing.11  
Figure A.4.4-1: CS UE Origination with CS media using an MSC Server enhanced for ICS – one codec used
The details of the signalling flows are as follows:
1.	SETUP message (CS UE to MSC Server enhanced for ICS)
As a result of some stimulus to establish a session with voice media, The CS UE initiates service control signalling towards the MSC Server enhanced for ICS by sending a SETUP message.
	Specifically for this signalling flow, the SETUP message includes:
-	Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits =12125552222)]
-	Bearer Capability information element = [(information transfer capability  = speech)]
	The MSC Server enhanced for ICS knows the calling party number corresponding to the UE.
2.	Call proceeding message (MSC Server enhanced for ICS to CS UE)
	The MSC Server enhanced for ICS acknowledges the receipt of the SETUP message by sending a call proceeding message to the CS UE.
3-4.	Interaction with the MGW to get media information eg address and port information is performed.
5.	RAB Assignment(From MSC Server enhanced for ICS to the CS UE)
The MSC Server enhanced for ICS will send the selected codec to the CS UE in NAS synchronisation indicator bit in the RAB assignment message.
6.	SIP INVITE request (MSC Server enhanced for ICS to IM CN subsystem entities) for detailed description see table A.4.4.6
Table A.4.4-6: SIP INVITE request (MSC Server enhanced for ICS to IMS CN subsystem entities)
INVITE tel:+1-212-555-2222 SIP/2.0
Via: SIP/2.0/UDP emsc1.home1.net;branch=z9hG4bK332b23.1
Max-Forwards: 68
Route: 
P-Asserted-Identity: 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11;np
Privacy: none
From: ;tag=171828
To: 
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
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"
Supported: 100rel, precondition, gruu, 199
Contact: ;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server"
P-Access-Network-Info:3GPP-GERAN; utran-cell-id-3gpp=234151D0FCE11
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee
s=
c=IN IP6 5555::aaa:bbb:ccc:eee
t=0 0
m=audio 49152 RTP/AVP 97 100
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/8000/1
a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2
a=ptime:20
a=rtpmap:100 telephone-event
a=maxptime:240

Request-URI:	SCC AS PSI DN as received in the SETUP message.
P-Asserted-Identity: The MSC Server enhanced for ICS inserts the tel-URI containing the telephone number stored in the MSC.
Accept-Contact: The MSC Server enhanced for ICS includes the mmtel feature tag in the INVITE request.
P-Asserted-Service: The MSC Server enhanced for ICS includes the mmtel ICSI value in INVITE request.
Contact:	The MSC Server enhanced for ICS includes the GRUU received at registration, the media feature tag g.3gpp.icsi-ref set to "urn%3Aurn-7%3gpp-service.ims.icsi.mmtel" and the feature tag g.3gpp.ics set to "server".
SDP: 	The MSC Server enhanced for ICS includes the codec and IP addresses and port address as received from the MGW.
7.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to MSC Server enhanced for ICS)
	The intermediate IM CN subsystem entities respond to the MSC Server enhanced for ICS with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
8.	Evaluation of initial filter criteria
	The S-CSCF evaluates initial filter criteria for the served CS user and as a result routes the SIP INVITE request towards the SCC AS.
9.	SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) – see example in table A.4.4-9.
Table A.4.4-9: SIP INVITE request (IMS CN subsystem entities to SCC AS)
INVITE tel:+1-212-555-2222 SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1
SIP/2.0/UDP emsc1.home1.net;branch=z9hG4bK332b23.1,
Max-Forwards: 67
Route: ,;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"
Record-Route: 
P-Asserted-Identity:
P-Access-Network-Info:
Privacy:
From:
To:
Call-ID:
Cseq:
P-Asserted-Service:
Accept-Contact:
Supported:
Contact:
Allow:
P-Access-Network-Info:
P-Charging-Vector:
Content-Type:
Content-Length: (…)

v=0
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

10.	SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities)
	The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
11. SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) – see example in table A.4.4-11.
Table A.4.4-11: SIP INVITE request (SCC AS to IMS CN subsystem entities)
INVITE tel:+1-212-555-2222 SIP/2.0
Via: SIP/2.0/UDP SIP/2.0/UDP sccas1.home1.net;branch=z9hG4bKnas34r5,
SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1
SIP/2.0/UDP emsc1.home1.net;branch=z9hG4bK332b23.1
Max-Forwards: 66
Route: ;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"
Record-Route:
P-Asserted-Identity:
Privacy:
From: ;tag=274890
To:
Call-ID:
Cseq:
Supported:
Contact:;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"
P-Asserted- Service:
Accept-contact:
Allow:
P-Access-Network-Info:
P-Charging-Vector:
Content-Type:
Content-Length: (…)
v=0
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

12.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to SCC AS)
	The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
13.	SIP INVITE request (intermediate IM CN subsystem entities to IMS UE)
	The intermediate IM CN subsystem entities route the SIP INVITE request to IMS UE.
14.	SIP 100 (Trying) response (UE B to intermediate IM CN subsystem entities)
	UE B responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
15-18. SIP 180 (Ringing) response (UE B to MSC Server enhanced for ICS via intermediate IM CN subsystem entities)
	UE B responds to the received SIP INVITE request with a SIP 180 (Ringing) response and alerts IMS UE. The response contains no SDP body and contains no ICS specific content.
	In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 180 (Ringing) response from the terminating side. The SIP 180 (Ringing) response also includes the Record-Route header field(s) that was constructed by the SCC AS adding its SIP URI to the saved Record-Route header field(s) that was received in the initial SIP INVITE request in step 9.
19-20.	Send ringing tone.
	At the receipt of the SIP 180 (Ringing) response the MSC Server enhanced for ICS orders the MGW to send a ringing tone towards CS UE.
21.	Alerting (MSC Server enhanced for ICS to CS UE)
	The MSC Server enhanced for ICS sends an alerting message to the UE.
22-25	SIP 200 OK (INVITE) from MSC Server enhanced for ICS  to IMS UE via intermediate IM CN subsystem entities
	IMS UE sends a SIP 200 (OK) response to the received SIP INVITE request when IMS UE answers the call. The SIP 200 (OK) also include the SDP answer. 
	In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 200 (OK) response from the terminating side.
26-27-	Through connection in both directions
	At the receipt of the SIP 200 (OK) (INVITE) the MSC Server enhanced for ICS orders the MGW to through connects in both directions.
28. CONNECT message (MSC Server enhanced for ICS to CS UE)
	The MSC Server enhanced for ICS maps the received SIP 200 (OK) response to a CONNECT message. There is no ICS specific content in this message.
29.	CONNECT ACKNOWLEDGMENT (CS UE to MSC Server enhanced for ICS)
	The CS UE A sends a CONNECT ACKNOWLEDGMENT message upon receiving the CONNECT message.
30-33. SIP ACK request (MSC Server enhanced for ICS to IMS UE via intermediate IM CN subsystem entities)
	Upon receiving the CONNECT ACKNOWLEDGEMENT from the CS UE A, the MSC Server enhanced for ICS forwards a SIP ACK request to the SCC AS via the intermediate IM CN Subsystem entities.
	There is no ICS specific content in this request.
A.4.5	Signalling flows for CS UE origination when using an MSC Server not enhanced for ICS
Figure A.4.5-1 shows the origination of a call in the CS domain when using an MSC server not enhanced for ICS. The originating UE can be an ICS UE or can be a UE without ICS capabilities. 
 EMBED Visio.Drawing.6  
Figure A.4.5-1: CS UE origination when using an MSC Server not enhanced for ICS
The details of the signalling flows are as follows: 
1	Determination of call establishment domain
	As a result of some stimulus to establish a full-duplex, voice-only call, the UE based on a combination of user policy, and access technology availability, decides to establish the call using the CS domain.
2.	SETUP message (UE to VMSC)
	After establishment of the MM connection, the UE initiates the CS call towards the destination UE by sending out the SETUP message.
	Specifically for this signalling flow, the SETUP message includes:
-	Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits = 12125552222)]
-	Bearer Capability information element = [(information transfer capability  = speech), (speech versions = FR AMR, GSM EFR, GSM FR)]
-	Supported Codec List information element = {[(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)]}
	The VMSC knows the calling party number corresponding to the UE.
3.	Origination triggers
4.	Redirection to IM CN subsystem
	The call is redirected to the IM CN subsystem. The mechanism for redirection is out of scope of ICS requirements and can be based upon the use of an IP Multimedia Routing Number (IMRN) for redirecting the signalling towards the SCC AS. How an IMRN is retrieved is outside the scope of this specification.
5.	ISUP IAM (VMSC to MGCF)
	The VMSC initiates the CS call towards the MGCF by sending out the IAM message.
	Specifically for this signalling flow, the IAM includes:
-	Called Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits = 12415553333)]
-	Calling Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits = 12125551111)]
-	USI parameter = 3.1 kHz audio
	The Called Party Number parameter represents the IMRN allocated for this call.
6.	SIP INVITE request (MGCF to intermediate IM CN subsystem entities) – see example in table A.4.5-6
	The MGCF initiates a SIP INVITE request, containing an initial SDP to the intermediate IM CN subsystem entities.
Table A.4.5-6: SIP INVITE request (MGCF to intermediate IM CN subsystem entities)
INVITE tel:+1-241-555-3333 SIP/2.0
Via: SIP/2.0/UDP mgcf1.home1.net;branch=z9hG4bK779s24.0
Max-Forwards: 70
Route: 
P-Asserted-Identity: 
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net
Privacy: none
From: ;tag=171828
To: 
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE 
Supported: 100rel, precondition
Contact: ;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd 
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:96 telephone-event
a=maxptime:20

Request-URI:	Contains the IMRN, as obtained from CS Networks signalling.
P-Asserted-Identity:	The MGCF inserts the tel URL containing the subscriber number, as received from the CS network.
SDP:	The SDP contains a preconfigured set of codecs supported by the MGW based on what is received in the ISUP. The codecs selected are speech codecs. See table 10a of 3GPP TS 29.163 [10]
7.	SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) – see example in table A.4.5-7
	The IMRN is a PSI. The intermediate IM CN subsystem entities are configured to route this PSI to the SCC AS. In this particular case, the I-CSCF performs the routeing over the Ma interface. For this example, there is no IBCF before the I-CSCF and no intermediate entities Record-Route the request.
Table A.4.5-7: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS)
INVITE tel:+1-241-555-3333 SIP/2.0
Via: SIP/2.0/UDP mgcf1.home1.net;branch=z9hG4bK779s24.0, SIP/2.0/UDP icscf1_s.home1.net;branch=z9hG4bK312a32.1
Max-Forwards: 69
Route: 
P-Asserted-Identity:
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=type 3home1.net; orig-ioi=home1.net
Privacy:
From:
To:
Call-ID:
Cseq: 
Supported:
Contact:
Allow:
Content-Type:
Content-Length: (…)

v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

8.	SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities)
	There is no ICS specific content to this response.
	The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.
9.	Retrieve original calling and called party information
	The SCC AS acts as a routeing B2BUA. The SCC AS retrieves the original called party number and calling party number associated with the IMRN and places the called party number in the Request-URI and the To header field of the outgoing request.
	How to retrieve the original called party and calling party numbers associated with the IMRN are considered to be out of scope of this specification. 
10.	SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) – see example in table A.4.5-10
	The SCC AS forwards the SIP INVITE request to the S-CSCF serving the originating user within the IM CN subsystem. In this case it is assumed that the user is registered within the IM CN subsystem.
	In this example the SCC AS includes the contents of the Contact header from the received SIP INVITE request 	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.
Table A.4.5-10: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities)
INVITE tel:+1-212-555-2222 SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK312a32.1
Max-Forwards: 68
Route: 
Record-Route:
P-Asserted-Identity:
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=Type 3home1.net
Privacy:
From: ;tag=274890
To: 
Call-ID: dc14b1t10b3teghmlk501444
Cseq: 
Supported:
Contact:
Allow:
Content-Type:
Content-Length: (…)

v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

Contact:	In this example the SCC AS includes the contents of the Contact header from the received SIP INVITE request 
11.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to SCC AS)
	The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response.
	There is no ICS content to this response.
12.	SIP INVITE request (intermediate IM CN subsystem entities to terminating side processing) – see example in table A.4.5-12
	The intermediate IM CN subsystem entities route the SIP INVITE request to the terminating side processing. In this example, there is no intermediate IBCF and none of the intermediate entities Record-Route.
Table A.4.5-12: SIP INVITE request (intermediate IM CN subsystem entities to terminating side processing)
INVITE tel:+1-212-555-2222 SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK312a32.1
Max-Forwards: 68Record-Route:
P-Asserted-Identity:
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net
Privacy:
From:
To: 
Call-ID: 
Cseq: 
Supported:
Contact: 
Allow:
Content-Type:
Content-Length: (…)

v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

13.	SIP 100 (Trying) response (terminating side processing to intermediate IM CN subsystem entities)
	The terminating side processing responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.
	There is no ICS specific content to this response.
14.	SIP 180 (Ringing) response, ISUP ACM and ALERTING message (terminating side processing to VCC UE)
	The call is successfully delivered to the terminating UE, which begins alerting the user. Normal SIP, ISUP and access signalling messages are transferred to indicate this is occurring. At or before this time, completion of negotiation of the bearer (e.g. as indicated by SDP in SIP) occurs. There is no ICS specific actions associated with this step.
	The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID header fields from one side of the B2BUA to the other.
	In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 180 (Ringing) response from the terminating side.
15.	SIP 200 (OK) response (terminating side processing to intermediate IM CN subsystem entities)
	A SIP 200 (OK) response is received from the terminating side processing by the intermediate IM CN subsystem entities.
	There is no ICS specific content to this response.
16.	SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS)
	The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS.
	There is no ICS specific content to this response.
17.	SIP 200 (OK) response (SCC AS intermediate to IM CN subsystem entities)
	The SCC AS forwards the SIP (200) OK response back to the intermediate IM CN subsystem entities.
	The UE modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID header fields from one side of the B2BUA to the other.
	In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 200 (OK) response from the terminating side
	There is no ICS specific content to this response.
18.	SIP 200 (OK) response (intermediate IM CN subsystem entities to MGCF)
	The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the MGCF.
	There is no ICS specific content to this response.
19.	ISUP ANM (MGCF to VMSC)
	On receipt of the SIP 200 (OK) response, the MGCF generates an ISUP ANM message and sends this to the VMSC.
	There is no ICS specific content to this response.
20.	CONNECT message (VMSC to UE)
	The VMSC sends a CONNECT message to the UE.
	There is no ICS specific content to this response.
21.	CONNECT ACKNOWLEDGE message (UE to VMSC)
	The UE generates the CONNECT ACKNOWLEDGE message on receipt of the CONNECT message.
	There is no ICS specific content to this response.
22.	SIP ACK request (MGCF to intermediate IM CN subsystem entities)
	The MGCF generates a SIP ACK request on receipt of the SIP 200 (OK) response and sends it back to the intermediate IM CN subsystem entities.
	There is no ICS specific content to this response.
23.	H.248 interaction with the MGW
	The MGCF interacts with the MGW for the necessary resource allocation.
24.	SIP ACK request (intermediate IM CN subsystem entities to SCC AS)
	The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS.
	There is no ICS specific content to this response.
25.	SIP ACK request (SCC AS to intermediate IM CN subsystem entities)
	The SCC AS forwards the SIP ACK request back to the 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.
	There is no VCC specific content to this response.
26.	SIP ACK request (intermediate IM CN subsystem entities to terminating side processing)
	The intermediate IM CN subsystem entities forward the SIP ACK request to the terminating side processing.
	There is no ICS specific content to this response.
A.4.6	Signalling flows for ICS UE origination when using I1 interface
Figure A.4.6-1 shows ICS UE origination signalling flows using I1 when the MSC server. The MSC server can be enhanced for ICS but need not be.
 EMBED Visio.Drawing.11  
Figure A.4.6-1: ICS UE origination signalling flows
The details of the signalling flows are as follows:
1.	Determination of call establishment
As a result of some stimulus to establish a session with voice media, the ICS UE based on a combination of user policy, and access technology availability, decides to establish the service control signalling using the IM CN subsystem.
2.	I1 Invite message (ICS UE to intermediate IM CN subsystem entities).
	The ICS UE initiates service control signalling in the IM CN subsystem towards the SCC AS by sending an I1 Invite message.
	Specifically for this signalling flow, the I1 Invite message includes:
-	Protocol Information = 0x11
-	Message Type = I1 Invite
-	Reason = MO (0x000)
-	Call ID = (0x100)
-	Sequence-ID = (0x1)
-	To-id = [(international number), (12125556666)]
-	From-id = [(international number), (12125551111)]
7.	SCC AS allocates an IUA PSI DN to the ICS UE
	The SCC AS stores the information received in the initial I1 Invite message and associates an IUA PSI DN with this request. The IUA PSI DN is returned in a I1 Progress message to the ICS UE together with an indication that CS bearer establishment is to be initiated by the ICS UE. For this example the IUA PSI DN is chosen as +1212556666.
8.	I1 Progress message (SCC AS to ICS UE via I1 protocol)
	Specifically for this signalling flow, the I1 Progress message includes:
-	Protocol Information = 0x11
-	Message Type = I1 Progress
-	Reason = 0x0 183
-	Call ID = (0x100)
-	Sequence-ID = 0x1
-	SCC-AS-id information element = [(Code specific = E.164 number), (number digits = 1212556666)]. This is the allocated SCC AS PSI DN
-	Session-identifier information element = [(Code specific = E.164 number), (number digits = 1212557777)]. This is the allocated SCC AS STI
11.	ICS UE proceeds to setup CS bearers
	Upon receipt of the IUA PSI DN, the ICS UE proceeds with setting up the call using CS bearers.
12.	CC SETUP message (ICS UE to MSC server)
	The ICS UE initiates the call over CS bearers by sending a CC SETUP message to the MSC server.
	Specifically for this signalling flow, the CC SETUP message includes:
1)	Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits = 1212556666)]. The Called Party Number information element is set to the IUA PSI DN.
2)	Bearer Capability information element = [(information transfer capability  = speech), (speech versions = FR AMR, GSM EFR, GSM FR)]
3)	Supported Codec List information element = {[(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)]}
	The MSC server knows the calling party number corresponding to the UE.
13.	CC CALL PROCEEDING message (MSC server to ICS UE)
	Upon receipt of the CC SETUP message from the ICS UE, the MSC server responds with a CC CALL PROCEEDING message. There is no ICS specific content in this message.
14.	SIP INVITE request (MSC server to intermediate IM CN subsystem entities via MGCF) – see example in table A.4.6-14
	The MSC server maps the received CC SETUP message to an ISUP IAM. The MGCF maps the ISUP IAM to a SIP INVITE request which is addressed to the IUA PSI DN.
Table A.4.6-14: SIP INVITE request (MSC server to intermediate IM CN subsystem entities)
INVITE tel:+1-212-555-6666 SIP/2.0
Via: SIP/2.0/UDP mgcf1.home1.net;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: 
P-Asserted-Identity: 
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net
P-Access-Network-Info: 
Privacy: none
From: ;tag=171828
To: 
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Cseq: 127 INVITE
Supported: 100rel, precondition
Contact:
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee
s=
c=IN IP6 5555::aaa:bbb:ccc:eee
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=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:	UAI PSI DN as received in the SETUP message
P-Asserted-Identity:	The MSC server inserts the tel-URI containing the subscriber number, as received from the ICS UE
SDP:	The SDP contains preconfigured set of codecs supported by the MGW.
15.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to MGCF)
	The intermediate IM CN subsystem entities respond to the MGCF with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
16.	SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) – see example in table A.4.6-16
	The SIP INVITE request is routed towards the SCC AS.
Table A.4.6-16: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS)
INVITE tel:+1-212-555-6666 SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf1.home1.net;branch=z9hG4bKdwe534, SIP/2.0/UDP mgcf1.hom1.net;branch=z9hG4bKnashds7
Max-Forwards: 68
Route: , ;orig-dialog-id="yuflsae80r3rb3fh31ondyr829cnyr381cn932YDWref0w0-wwtg374"
Record-Route: 
P-Asserted-Identity: 
P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4ee]; ecf=[5555::6aa:7bb:8cc:9dd]
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi="type 3home1.net"; orig-ioi="home1.net"
P-Access-Network-Info:
Privacy: none
From: ;tag=171828
To: 
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Cseq: 127 INVITE
Supported:
Require:
Proxy-Require:
Security-Verify:
Contact: 
Allow:
Content-Type:
Content-Length:

v=0
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

17.	SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities)
	The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
18.	SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) – see example in table A.4.6-18
	The SCC AS acting as a routing B2BUA, generates a SIP INVITE request based upon the received SIP INVITE request and the information previously stored against this session and routes it towards UE B via the intermediate IM CN subsystem entities.
Table A.4.6-18: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities)
INVITE tel:+1-212-555-2222 SIP/2.0
Via: SIP/2.0/UDP sccas1.home1.net;branch=z9hG4bKnas34r5
Max-Forwards: 67
Route: 
P-Asserted-Identity: 
P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4ee]; ecf=[5555::6aa:7bb:8cc:9dd]
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi="type3home1.net"
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id=3gpp=234151D0FCE11
Privacy: none
From: ;tag=171828
To: 
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Cseq: 127 INVITE
Supported: 100rel, precondition
Require: sec-agree
Proxy-Require: sec-agree
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port=7531
Contact:
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee
s=
c=IN IP6 5555::aaa:bbb:ccc:eee
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:96 telephone-event
a=maxptime:20

	Request-URI:	The SCC AS replaces the IUA PSI DN with the tel URI of the called party which was stored from the initial SIP INVITE request sent in step 2.
19.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to SCC AS)
 	The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
20.	SIP INVITE request (intermediate IM CN subsystem entities to UE B)
	The intermediate IM CN subsystem entities route the SIP INVITE request to UE B.
21.	SIP 100 (Trying) response (UE B to intermediate IM CN subsystem entities)
	UE B responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.
	There is no ICS specific content in this response.
22-23.	SIP 180 (Ringing) response (UE B to SCC AS via intermediate IM CN subsystem entities)
	UE B responds to the received SIP INVITE request with a SIP 180 (Ringing) response. The response contains no SDP body and contains no ICS specific content.
24.	I1 Progress message (SCC AS to ICS UE A via using I1 protocol) – see example in table A.4.6-24
	Upon receiving the SIP 180 (Ringing) response from the terminating UE, the SCC AS sends an I1 Progress message to the ICS UE A using the I1 protocol. The response is associated with the SIP INVITE in step 2.
	Specifically for this signalling flow, the I1 Progress message includes:
-	Protocol Information = 0x11
-	Message Type = I1 Progress
-	Reason = 0x0 180
-	Call ID = (0x100)
-	Sequence-ID = 0x1
26.	SIP 200 (OK) response (UE B to to intermediate IM CN subsystem entities) – see example in table A.4.6-26
	The terminating side sends an SDP answer in a SIP 200 (OK) response to the received SIP INVITE request.
Table A.4.6-26: SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities)
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK361k21.1, scscf2.home1.net;branch=z9hG4bK764z87.1, icscf1.home1.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP sccas1.home1.net;branch= z9hG4bKnas34r5
Record-Route: , , 
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCE11
Privacy: none
From: ;tag=171828
To: 
Call-ID:
CSeq:
Require: 100rel, precondition
Contact:
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933623 2987933623 IN IP6 5555::ggg:fff:aaa:bbb
s=-
c=IN IP6 5555::ggg:fff:aaa:bbb
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrcv
a=curr:qos remote sendrcv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=maxptime:20

27.	SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS)
	The SIP 200 (OK) response from UE is routed towards the SCC AS.
28-29.	SIP 200 (OK) response (SCC AS to MSC server via intermediate IM CN subsystem entities and)
	The SDP answer received in the SIP 200 (OK) response is routed to the MSC server via the intermediate IM CN subsystem entities and MGCF. The MGCF maps the SIP 200 (OK) response into a ISUP ANM.
30.	CC CONNECT message (MSC server to ICS UE)
	The enhanced MSC server maps the received SIP 200 (OK) to a CC CONNECT message. There is no ICS specific content in this message.
31.	CC CONNECT ACKNOWLEDGMENT (ICS UE A to MSC Server)
	The ICS UE A sends a CC CONNECT ACKNOWLEDGMENT message upon receiving the CONNECT message.
32-33.	SIP ACK request (MGCF to SCC AS via intermediate IM CN subsystem entities)
	The MGCF forwards a SIP ACK request to the SCC AS via the intermediate IM CN Subsystem entities.
	There is no ICS specific content in this request.
34.	I1 Success message (SCC AS to ICS UE A via I1 protocol) – see example in table A.4.6-34
	The SCC AS responds with an I1 Success message to the initial I1 Invite message sent by the ICS UE A in the step 2.
	Specifically for this signalling flow, the I1 Success message includes:
-	Protocol Information = 0x11
-	Message Type = I1 Success
-	Reason = 0x0
-	Call ID = (0x100)
-	Sequence-ID = 0x3

35-36.	SIP ACK request (SCC AS to UE B via intermediate IM CN subsystem entities)
	The SCC AS sends a SIP ACK request to UE B via the IM CN subsystem entities. There is no ICS specific content in this response. 

A.5	Signalling flows for call termination
A.5.1	Signalling flows for termination to a CS UE registered in IMS using an MSC Server enhanced for ICS – multiple codecs used
Figure A.5.1-1 shows the termination of a call to a CS UE via the MSC Server enhanced for ICS. Codec negotiation is performed.
 EMBED Visio.Drawing.11  
Figure A.5.1-1: CS UE Termination with CS media using an MSC Server enhanced for ICS (with codec negotiation)
The details of the signalling flows are as follows:
1.	SIP INVITE request (from the originating IM CN subsystem to intermediate IM CN subsystem entities) - see example in table A.5.1-1
	The SIP INVITE request is sent by the originating IM CN subsystem to the intermediate IM CN subsystem entities.
Table A.5.1-1: SIP INVITE request (originating IM CN subsystem to intermediate IM CN subsystem entities)
INVITE sip:[email protected] SIP/2.0
Via: 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: 67
Route: 
Record-Route: , 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
P-Asserted-Identity: "John Doe" , 
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: ;tag=171828
To: 
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Supported: 100rel, precondition, gruu, 199
Accept: applicatiom/sdp,application/3gpp-ims+xml
Contact: ;+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 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

	Request-URI:	the SIP URI or tel URI of the called party. In this example the SIP  URI of the called party is included, which might have been translated from a tel URI by the S-CSCF in the originating IM CN subsystem.
	P-Asserted-Service and Contact:	the ICSI  defined for MMtel is included as this flow assumes a 3GPP R8 IMS UE originator. This for example purposes only, the ICSI might not be included for other originator types.
2.	SIP 100 (Trying) response (from intermediate IM CN subsystem entities to the originating IM CN subsystem)
	The intermediate IM CN subsystem entities respond to the originating IM CN subsystem with a SIP 100 (Trying) response. There is no ICS specific content in this response.
3.	Evaluation of initial filter criteria
	The S-CSCF evaluates initial filter criteria for the CS user and as a result routes the SIP INVITE request towards the SCC AS. 
4.	SIP INVITE request (from intermediate IM CN subsystem entities to SCC AS) – see example in table A.5.1-4.
	The intermediate IM CN subsystem entities route the SIP INVITE request to the SCC AS.
Table A.5.1-4: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS)
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b33.1, icscf1_s.home1.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.home2.net;branch=z9hG4bK431h23.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 66
Route: , ;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"
Record-Route: , , 
P-Access-Network-Info:
P-Asserted-Identity:
P-Charging-Vector:
P-Asserted-Service:
Accept-Contact:
Privacy:
From:
To:
Call-ID:
Cseq:
Supported:
Accept:
Contact:
Allow:
Content-Type:
Content-Length: (…)

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=

5.	SIP 100 (Trying) response (from SCC AS to intermediate IM CN subsystem entities)
The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is no ICS specific content in this response.
6.	SIP INVITE request (from SCC AS to intermediate IM CN subsystem entities) - see example in table A.5.1-6
	The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE request and sends it to the intermediate IM CN subsystem entities.
Table A.5.1-6: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities)
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP sccas.home1.net;branch=z9hG4bKnas34r5
Max-Forwards: 65
Route: ;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"Record-Route:
P-Access-Network-Info:
P-Asserted-Identity:
P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4ee]; ecf=[5555::6aa:7bb:8cc:9dd]
P-Charging-Vector:
P-Asserted-Service:
Accept-Contact:*;+g.3gpp.ics="server"
Privacy:
From:;tag=274890
To:
Call-ID:
Cseq:
Supported:
Accept:
Contact:
Allow:
Content-Type:
Content-Length: (…)

v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

	Via:	the SCC AS, acting as a B2BUA, replaces the Via header field with one containing only its own SIP URI.
	Contact:	In this example the SCC AS includes the contents of the Contact header from the received SIP INVITE request 	No more triggering is required in the initial filter criteria, the IM CN subsystem will route the SIP INVITE request to the terminating user.
7.	SIP 100 (Trying) response (from intermediate IM CN subsystem entities to SCC AS)
	The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response. There is no ICS specific content in this response.
8.	SIP INVITE request (from intermediate IM CN subsystem entities to MSC Server enhanced for ICS) - see example in table A.5.1-8
	The intermediate IM CN subsystem entities route the SIP INVITE request to the MSC Server enhanced for ICS.
Table A.5.1-8: SIP INVITE request (intermediate IM CN subsystem entities to MSC Server enhanced for ICS)
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK433b44.1, SIP/2.0/UDP sccas.home1.net;branch=z9hG4bKnas34r5
Max-Forwards: 64
Route: 
Record-Route: ,
P-Asserted-Identity: 
P-Charging-Function-Addresses:
P-Charging-Vector:
P-Asserted-Service:
P-Called-Party-ID: 
Accept-Contact:
Privacy:
From:
To:
Call-ID:
Cseq:
Supported:
Accept:
Contact:
Allow:
Content-Type:
Content-Length: (…)

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=

	Request-URI:	the S-CSCF replaces the Request-URI with the registered contact address by the MSC Server enhanced for ICS during registration.
9.	SIP 100 (Trying) response (from MSC Server enhanced for ICS to intermediate IM CN subsystem entities)
	The MSC Server enhanced for ICS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.  There is no ICS specific content in this response.
10.	SETUP message (from MSC Server enhanced for ICS to CS UE)
	The MSC Server enhanced for ICS identities the subscriber using the Request-URI and initiates the paging procedure towards the terminating CS UE. After the CS UE has successfully accessed the network, the MSC Server enhanced for ICS sends a SETUP message towards the CS UE according to 3GPP TS 24.008 [7], providing the interworking as described in 3GPP TS 29.292 [24].
	Specifically for this signalling flow, the SETUP message includes:
-	Calling Party BCD Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Presentation indicator=presentation allowed), (Screening indicator=network provided), (Number digits = 1212551111)]
-	Bearer Capability 1 information element = [(information transfer capability = speech)]
11.	CALL CONFIRMED message (from CS UE to MSC Server enhanced for ICS)
	The CS UE sends a CALL CONFIRMED message towards the MSC Server enhanced for ICS according to 3GPP TS 24.008 [7].  Specifically for this signalling flow, the CALL CONFIRMED message includes:
-	Supported Codec List information element = {[(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS AMR2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)]}
	In this example, no Bearer Capability 1 information element is returned.
As the node terminating the out of band transcoder control procedures as specified in 3GPP TS 23.153 [4A], the MSC Server enhanced for ICS selects a single selected codec.
12.	Reserve / Configure RTP (from MSC Server enhanced for ICS to CS-MGW)
	The MSC Server enhanced for ICS performs CS-MGW selection and requests the CS-MGW to prepare for network side bearer establishment. The MSC Server enhanced for ICS removes the video media description from the SDP offer and then requests reservation and configuration of a local RTP endpoint. The MSC Server enhanced for ICS also sends the selected speech codec and the remote user plane RTP information received from the SDP offer to the CS-MGW. The MSC Server enhanced for ICS receives the local RTP endpoint information from the CS-MGW.
13.	SIP 183 (Session Progress) response (from MSC Server enhanced for ICS to intermediate IM CN subsystem entities) - see example in table A.5.1-13
	The MSC Server enhanced for ICS returns an SDP answer. The video media description has been removed and only the audio media description is included.
Table A.5.1-13: SIP 183 (Session Progress) response (MSC Server enhanced for ICS to intermediate IM CN subsystem entities)
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK433b44.1, SIP/2.0/UDP sccas.home1.net;branch=z9hG4bKnas34r5
Record-Route: 
P-Asserted-Identity: 
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
From:
To: ;tag=314159
Call-ID:
Cseq:
Require: 100rel
Contact:;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server"
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER
Rseq: 9021
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933623 2987933623 IN IP6 5555::eee:fff:aaa:bbb
s=-
c=IN IP6 5555::eee:fff:aaa:bbb
t=0 0
m=video 0 RTP/AVP 98 99
m=audio 6544 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des: qos mandatory remote sendrecv
a=conf:qos 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

	P-Asserted-Identity: the value taken from the P-Called-Party-ID header field in the INVITE request.
	The SDP answer in the 183 (Session Progress) response contains a single selected codec and a request for confirmation of when remote preconditions are met.
14-16.	SIP 183 (Session Progress) response (from intermediate IM CN subsystem entities to SCC AS)
	The SIP 183 (Session Progress) response is routed to the originating IM CN subsystem via the SCC AS and intermediate IM CN subsystem entities. In this example the SCC AS includes the contents of the Contact header from the received SIP 183 (Session Progress) response except the g.3gpp.ics media feature tag which is removed by the SCC AS.
17-20.	SIP PRACK request and SIP 200 (OK) response
	The SIP PRACK request and its SIP 200 (OK) response are routed end-to-end between the originating IM CN subsystem, intermediate IM CN subsystem entities, SCC AS and MSC Server enhanced for ICS. There is no specific ICS content in these messages. In this example the SCC AS includes the contents of the Contact header from the received SIP PRACK request.
21-24.	SIP UPDATE request and SIP 200 (OK) response
	When the originating endpoint has completed its resource reservation, the intermediate IM CN subsystem entities receive an UPDATE request. The UPDATE request and its SIP 200 (OK) response are routed end-to-end between the originating IM CN subsystem, intermediate IM CN subsystem entities, SCC AS and MSC Server enhanced for ICS. There is no specific ICS content in these messages. In this example the SCC AS includes the contents of the Contact header from the received SIP UPDATE request.
25.	Assignment
	The MSC Server enhanced for ICS performs access bearer assignment.
For UTRAN access this involves invocation of the Prepare Bearer and Change Through Connection procedures with the CS-MGW, followed by sending a RAB ASSIGNMENT REQUEST message to the UTRAN. The NAS Synchronization Indicator information element is included to identify the selected codec and codec configuration.
	For GERAN access this involves invocation of the Reserve Circuit and Change Through Connection procedures with the CS-MGW, followed by sending a ASSIGNMENT REQUEST to the GERAN. 
26.	ALERTING message (from CS UE to MSC Server enhanced for ICS)
	The CS UE sends an ALERTING message to the MSC Server enhanced for ICS according to 3GPP TS 24.008 [7].
27.	Start tone (from MSC Server enhanced for ICS to CS-MGW)
	The MSC Server enhanced for ICS instructs the CS-MGW to start ringback tone. 
28.	SIP 180 (Ringing) response (from MSC Server enhanced for ICS to intermediate IM CN subsystem entities) - see example in table A.5.1-28
	The MSC Server enhanced for ICS does not include "100rel" in the Require header field as the 180 (Ringing) response does not contain SDP and therefore need not be sent reliably. 
Table A.5.1-28: SIP 180 (Ringing) response (MSC Server enhanced for ICS to intermediate IM CN subsystem entities)
SIP/2.0 180 Ringing	
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK433b44.1, SIP/2.0/UDP sccas2.home2.net;branch=z9hG4bKnas34r5
From: 
To: ;tag=314159
Call-ID: 
Cseq: 
Rseq: 9022
Content-Length: 0

29-31.	SIP 180 (Ringing) response (from intermediate IM CN subsystem entities to SCC AS)
	The SIP 180 (Ringing) response is routed to the originating IM CN subsystem via the SCC AS and intermediate IM CN subsystem entities.
32.	CONNECT message (from CS UE to MSC Server enhanced for ICS)
	The CS UE sends a CONNECT message to the MSC Server enhanced for ICS according to 3GPP TS 24.008 [7]. 
33.	Stop tone and through connect (from MSC Server enhanced for ICS to CS-MGW)
	The MSC Server enhanced for ICS instructs the CS-MGW to stop ringback tone and to through connect the bearer. 
34.	SIP 200 (OK) response (from MSC Server enhanced for ICS to intermediate IM CN subsystem entities) - see example in table A.5.1-34
Table A.5.1-34: SIP 200 (OK) response (MSC Server enhanced for ICS to intermediate IM CN subsystem entities)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK433b44.1, SIP/2.0/UDP sccas2.home2.net;branch=z9hG4bKnas34r5
From:
To: ;tag=314159
Call-ID:
Cseq:
Contact: <
sip:[email protected];gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server"
Content-Length: 0

	Contact:	the MSC Server enhanced for ICS includes the GRUU received at registration, the media feature tag g.3gpp.icsi-ref set to "urn%3Aurn-7%3gpp-service.ims.icsi.mmtel" and the media feature tag g.3gpp.ics set to "server".
35-37.	SIP 200 (OK) response
	The 200 (OK) response is routed to the originating IM CN subsystem via the SCC AS and intermediate IM CN subsystem entities. In this example the SCC AS includes the contents of the Contact header from the received SIP 200 (OK) response except the g.3gpp.ics media feature tag which is removed by the SCC AS.
38.	CONNECT ACK request (from MSC Server enhanced for ICS to CS UE)
	After through-connecting the traffic channel, the MSC Server enhanced for ICS sends a CONNECT ACKNOWLEDGEMENT message to the CS UE according to 3GPP TS 24.008 [7].
39-42.	SIP ACK request
	A SIP ACK request is routed end-to-end from the originating IM CN subsystem to the MSC Server enhanced for ICS. There is no ICS specific content in this message.
A.5.2	Signalling flows for termination to a CS UE not registered in IMS 
Figure A.5.2-1 shows the termination of a call to a CS UE not registered in the IM CN subsystem.
 EMBED Visio.Drawing.11  
Figure A.5.2-1: CS UE Termination to UE not registered in the IM CN subsystem
The details of the signalling flows are as follows:
Steps 1 through 5 are identical to the example is subclause A.5.1.
6.	Domain selection
	The SCC AS acting performs terminating access domain selection based on operator and user preferences, registration and call states; in this example, the user is not registered in the IM CN subsystem and the SCC AS selects breakout to the CS domain to terminate the call.
7.	CSRN retrieval
	The SCC AS determines the CS domain Routing Number (CSRN).
NOTE:	CSRN retrieval is implementation specific.
8.	SIP INVITE request (from SCC AS to intermediate IM CN subsystem entities) - see example in table A.5.2-8
	The SCC AS acting as a routing B2BUA generates a SIP INVITE request.
Table A.5.2-8: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities)
INVITE tel:+1-212-555-2222 SIP/2.0
Via: SIP/2.0/UDP sccas.home1.net;branch=z9hG4bKnas34r5
Max-Forwards: 65
Route: ;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"
Record-Route:
P-Access-Network-Info:
P-Asserted-Identity:
P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4ee]; ecf=[5555::6aa:7bb:8cc:9dd]
P-Charging-Vector:
P-Asserted-Service:
Accept-Contact:
Privacy:
From: ;tag=274890
To:
Call-ID:
Cseq:
Supported:
Accept:
Contact:
Allow:
Content-Type:
Content-Length: (…)

v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

	Request-URI: the CSRN.
	Via: the SCC AS, acting as a B2BUA, replaces the Via header field with one containing only its own SIP URI.
9.	SIP 100 (Trying) response (from intermediate IM CN subsystem entities to SCC AS)
	The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response. There is no ICS specific content in this response.
10.	SIP INVITE request (from intermediate IM CN subsystem entities to BGCF)
	The S-CSCF determines the destination is in the CS domain (e.g. after ENUM/DNS translation fails to translate the CSRN in tel URI format to a globally routeable SIP URI). The S-CSCF forwards the INVITE request to a BGCF in the local network. There is no ICS specific content in this request.
11.	SIP 100 (Trying) response (from BGCF to intermediate IM CN subsystem entities)
	The BGCF responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is no ICS specific content in this response.
12.	SIP INVITE request (from BGCF to MGCF)
	The BGCF analyzes the destination address and allocates a MGCF to handle the termination. The BGCF forwards the INVITE request to the MGCF. There is no ICS specific content in this request.
	In this example, the BGCF does not add itself to the Record-Route header field and will therefore not be in the session path of subsequent SIP requests.
13.	SIP 100 (Trying) response (from MGCF to BGCF)
	The MGCF responds to the MGCF with a SIP 100 (Trying) response. There is no ICS specific content in this response.
14-18.	SIP 183 (Session Progress) response
	The SIP 183 (Session Progress) response is routed to the originating IM CN subsystem via the SCC AS and intermediate IM CN subsystem entities. In this example the SCC AS includes the contents of the Contact header from the received SIP 183 (Session Progress) response.
19-22.	SIP PRACK request and SIP 200 (OK) response
	The SIP PRACK request and its SIP 200 (OK) response are routed end-to-end between the originating IM CN subsystem, intermediate IM CN subsystem entities, SCC AS and MGCF. There is no specific ICS content in these messages. In this example the SCC AS includes the contents of the Contact header from the received SIP PRACK request.
23-26.	SIP UPDATE request and SIP 200 (OK) response
	When the originating endpoint has completed its resource reservation, the intermediate IM CN subsystem entities receive an UPDATE request. The UPDATE request and its SIP 200 (OK) response are routed end-to-end between the originating IM CN subsystem, intermediate IM CN subsystem entities, SCC AS and MGCF. There is no specific ICS content in these messages. In this example the SCC AS includes the contents of the Contact header from the received SIP UPDATE request.
27-31.	SIP 180 (Ringing) response (from MGCF to intermediate IM CN subsystem entities)
	The SIP 180 (Ringing) response is routed to the originating IM CN subsystem via the SCC AS and intermediate IM CN subsystem entities. The MGCF does not include "100rel" in the Require header field as the 180 (Ringing) does not contain SDP and therefore need not be sent reliably.
32-36.	SIP 200 (OK) response
	The 200 (OK) response is routed to the originating IM CN subsystem via the SCC AS and intermediate IM CN subsystem entities.
37-41.	SIP ACK request
	A SIP ACK request is routed end-to-end from the originating IM CN subsystem to the MGCF. There is no ICS specific content in this message.
A.5.3	Signalling flows for termination to an ICS UE with CS media using Gm reference point when using an MSC server enhanced for ICS
Figure A.5.3-1 shows the termination of a call to an ICS UE using CS bearers controlled through the IM CN subsystem. In this example the MSC Server is enhanced for ICS and is capable of translating NAS signalling received from the ICS UE to SIP and vice versa. 
 EMBED Visio.Drawing.11  
Figure A.5.3-1:	ICS UE termination with CS media using Gm reference point when using an MSC Server enhanced for ICS
The details of the signalling flows are as follows:
1.	SIP INVITE request (originating IM CN subsystem to intermediate IM CN subsystem entities in terminating network) – see example in table A.5.3-1	In this example, the originating UE initiates a voice call though its home IM CN subsystem (home2) with a terminating UE which is ICS capable which is in a different network (home1). 
Table A.5.3-1:	SIP INVITE request (originating IM CN subsystem to intermediate IM CN subsystem entities in terminating network)
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP icscf1.home1.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited2.net;branch=z9hG4bK431h23.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 67
Route: 
Record-Route: , 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
P-Asserted-Identity: "John Doe" , 
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: ;tag=171828
To: 
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Supported: 100rel, precondition, gruu, 199
Contact: ;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel">
Accept: application/sdp,application/3gpp-ims+xml
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd 
t=0 0
m=audio 3456 RTP/AVP 97 0 96
b=AS:25.4
a=curr:qos local sendrcv
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

NOTE 1:	This example assumes the session was originated from a 3GPP Release 8 IMS UE and thus includes the ICSI value defined for MMTel in the Contact header field and Accept Contact header field. However, termination procedures for ICS do not rely upon the MMTel ICSI value being present in the incoming request. 
2.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to originating IM CN subsystem)
	The intermediate IM CN subsystem entities respond to the originating IM CN subsystem with a SIP 100 (Trying) response. There is no ICS specific content in this response. 
3.	Evaluation of initial filter criteria
	The S-CSCF evaluates initial filter criteria for the served ICS user and as a result routes the SIP INVITE request towards the SCC AS.
NOTE 2:	for terminating scenario, the SCC AS is configured as the last AS in the terminating iFC chain.
4.	SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) – see example in table A.5.3-4
	As a result of iFC evaluation, the S-CSCF routes the INVITE request to the SCC AS.
Table A.5.3-4:	SIP INVITE request (intermediate IM CN subsystem entities to SCC AS)
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b33.1,SIP/2.0/UDP  icscf1.home1.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited2.net;branch=z9hG4bK431h23.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 66
Route: , ;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"
Record-Route: , , 
P-Access-Network-Info:
P-Asserted-Identity:
P-Charging-Vector:
P-Asserted-Service:
Accept-Contact:
Privacy:
From:
To:
Call-ID:
Cseq:
Supported:
Accept:
Contact:
Allow:
Content-Type:
Content-Length:

v=0
o=-
s=-
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

5.	SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities)
	The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is no ICS specific content in this response.
6.	Terminating Access Domain Selection
	The SCC AS performs Terminating Access Domain Selection and chooses the CS domain for the setup of the media. 
7.	SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) – see example in Table A.5.3-7.
The SCC AS, acting as a routing B2BUA, generates a SIP INVITE request based upon the received SIP INVITE request and send it to the intermediate subsystem entities. The SDP indicates that the ICS UE B should establish a CS media bearer.
Table A.5.3-7:	SIP INVITE request (SCC AS to intermediate IM CN subsystem entities)
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP sccas2.home2.net;branch=z9hG4bKnas34r5
Max-Forwards: 65
Route: ;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"
Record-Route:
P-Access-Network-Info:
P-Asserted-Identity:
P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4ee]; ecf=[5555::6aa:7bb:8cc:9dd]
P-Charging-Vector:
P-Asserted-Service:
Accept-Contact*;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"
Accept-Contact:+*;g.3gpp.ics="principal";explicit;require
Privacy:
From:;tag=274890
To:
Call-ID:
Cseq:
Supported:
Accept:
Contact:
Allow:
Content-Type:
Content-Length:

v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=PSTN E164 +12125556666
t=0 0
m=audio 9 PSTN -
a=setup:passive
a=connection:new
a=cs-correlation:callerid
a=curr: qos local none
a=curr: qos remote none
a=des: qos mandatory local sendrcv
a=des: qos mandatory remote sendrcv
a=inactive

8.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to SCC AS)
	The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response. There is no ICS specific content in this response.
9.	SIP INVITE request (intermediate IM CN subsystem entties to ICS UE B) 
	The SIP INVITE request is routed towards the called party ICS UE B since further iFC evaluation is not necessary.
10.	SIP 100 (Trying) response (ICS UE B to intermediate IM CN subsystem entities)
	The ICS UE B responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is no ICS specific content in this response.
11	SIP 183 (Session Progress) response (ICS UE B to intermediate IM CN subsystem entities) – see example in table A.5.3-11
The ICS UE generates a SIP 183 (Session Progress) response based upon the received SIP INVITE request and indicates in the SDP that the CS media bearer is used.
Table A.5.3-11: SIP 183 (Session Progress) response (ICS UE to intermediate IM CN subsystem entities) 
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK240f34.1,
SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1,
SIP/2.0/UDP sccas.home1.net;branch=z9hG4bKnas34r5,
Record-Route: ;
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCE11
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
Privacy: none
From: ;tag=171828
To: ;tag=171820
Call-ID:
CSeq:
Require: 100rel
Contact: ;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="principal"
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)

v=0
o=2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=
t=0 0
m=audio 9 PSTN -
c=PSTN - -
a=setup:active
a=connection:new
a=cs-correlation:callerid:+12125552222
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv

12.	SIP 183 (Session Progress) response (intermediate IM CN subsystem entities to SCC AS)
	The SIP 183 (Session Progress) response is routed towards the SCC AS.
13.	SETUP message (ICS UE B to MSC Server enhanced for ICS)
	The ICS UE B inititates bearer setup in the CS domain by sending a SETUP message to the MSC Server enhanced for ICS.
	Specifically for this signalling flow, the SETUP message includes:
-	Called Party Number information element = = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits = 1212556666)].	The Called Party Number information element is set to the SCC AS PSI DN.
-	Bearer Capability information element = [(information transfer capability  = speech), (speech versions = FR AMR, GSM EFR, GSM FR)]
-	Supported Codec List information element = {[(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)]}
	The MSC Server enhanced for ICS knows the calling party number corresponding to the ICS UE B.
14.	CALL PROCEEDING message (MSC Server enhanced for ICS to ICS UE B)
	Upon receipt of the SETUP message from the ICS UE B, the MSC Server enhanced for ICS responds with a CALL PROCEEDING message. There is no ICS specific content in this message.
15.	SIP INVITE request (MSC Server enhanced for ICS to intermediate IM CN subsystem entities) – see example in table A.5.3-15.
	The MSC Server enhanced for ICS maps the received SETUP message to a SIP INVITE request which is routed towards the intermediate IM CN subsystem entities. The INVITE request is addressed to the SCC AS PSI DN in the Request-URI.
Table A.5.3-15: SIP INVITE request (MSC Server enhanced for ICS to intermediate IM CN subsystem entities)
INVITE tel:+1-212-555-6666 SIP/2.0
Via: SIP/2.0/UDP msc2.home1.net;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: 
P-Asserted-Identity: ,
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home2.net
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"
P-Access-Network-Info:
Privacy: none
From: ;tag=171828
To: 
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Cseq: 127 INVITE
Supported: 100rel, precondition, gruu, 199
Contact: ; +g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server"
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee
s=
c=IN IP6 5555::aaa:bbb:ccc:eee
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=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:	SCC AS PSI DN as received in the SETUP message.
	P-Asserted-Identity:	The MSC Server enhanced for ICS inserts the tel-URI containing the subscriber number, as received from the ICS UE B.
	Accept-Contact: The MSC Server enhanced for ICS includes the mmtel media feature tag in the INVITE request .
	Contact:	The MSC Server enhanced for ICS includes the GRUU received at registration, the media feature tag g.3gpp.icsi-ref set to "urn%3Aurn-7%3gpp-service.ims.icsi.mmtel" and the media feature tag g.3gpp.ics set to "server".
	SDP:	The SDP contains preconfigured set of codecs supported by the MGW.
16.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to MSC Server enhanced for ICS)
	The intermediate IM CN subsystem entities respond to the MSC Server enhanced for ICS with a SIP 100 (Trying) response. There is no ICS specific content in this response.
17.	SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) – see example in Table A.5.3-17
	The SIP INVITE request is sent to the SCC AS.
Table A.5.3-17: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS)
INVITE tel:+1-212-555-6666 SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b33.1,SIP/2.0/UDP  icscf1.home1.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP msc2.home1.net;branch=z9hG4bKnashds7
Max-Forwards: 68
Route: , ;orig-dialog-id="yuflsae80r3rb3fh31ondyr829cnyr381cn932YDWref0w0-wwtg374"
Record-Route: 
P-Asserted-Identity:
P-Charging-Vector:
P-Access-Network-Info:
Accept-Contact:
Privacy:
From:
To:
Call-ID:
Cseq:
Supported:
Require:
Proxy-Require:
Security-Verify:
Contact:
Allow:
Content-Type:
Content-Length: (…)

v=
o=-
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

18.	SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities)
	The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is no ICS specific content in this response.
19.	SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) – see example in table A.5.3-19.
	The SCC AS responds to the SIP INVITE request with a SIP 200 (OK) response that includes an SDP answer. 
Table A.5.3-19: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b33.1,SIP/2.0/UDP  icscf2.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP msc2.home2.net;branch=z9hG4bKnashds7
Record-Route: ,
P-Access-Network-Info:
Privacy: none
From: ;tag=171828
To: ;tag=378959
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
CSeq:
Require: 100rel, precondition
Contact: ;+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=- 2987933623 2987933623 IN IP6 5555::ggg:fff:aaa:bbb
s=-
c=IN IP6 5555::ggg:fff:aaa:bbb
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrcv
a=curr:qos remote sendrcv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=maxptime:20

20.	SIP 200 (OK) response (intermediate IM CN subsystem to MSC Server enhanced for ICS) 
	The intermediate IM CN subsystem entities route the SIP 200 (OK) response to the MSC Server enhanced for ICS. 
21.	CONNECT message (MSC Server enhanced for ICS to ICS UE B)
	The enhance MSC Server maps the received SIP 200 (OK) response to a CONNECT message. There is no ICS specific content in this message.
22.	CONNECT ACKNOWLEDGEMENT message (ICS UE B to MSC Server enhanced for ICS)
	The ICS UE A sends a CONNECT ACKNOWLEDGMENT message upon receiving the CONNECT message. There is no ICS specific content in this message. 
23-24.	SIP ACK request (MSC Server enhanced for ICS to SCC AS via intermediate IM CN subsystem entities)
	The MSC Server enhanced for ICS interworks the received CONNECT ACKNOWLEDGEMENT message to a SIP ACK request which is routed to the SCC AS via the intermediate IM CN subsystem entities. There is no ICS specific content in this response.
25-26.	SIP 180 (Ringing) response (ICS UE B to SCC AS via intermediate IM CN subsystem entities)
	The ICS UE B responds to the received SIP INVITE request with a SIP 180 (Ringing) response. The response contains no SDP body and contains no ICS specific content. The SIP 180 (Ringing) response is routed to the SCC AS.
27-28.	SIP 180 (Ringing) response (SCC AS to originating IM CN subsystem via intermediate IM CN subsystem entities)
	The SCC AS routes the received SIP 180 (Ringing) response towards the originating network and the calling party.
29. SIP 200 (OK) response (ICS UE B to intermediate IM CN subsystem entities) – see example in Table A.5.3-29
	The ICS UE B responds to the received initial SIP INVITE request with a SIP 200 (OK) response. This SIP 200 (OK) response includes an SDP answer from the ICS UE and indicates resources have been reserved and the dialog can be established.
Table A.5.3-29: SIP 200 (OK) response (ICS UE B to intermediate IM CN subsystem entities)
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcscf2.home2.net;branch=z9hG4bKfeh9083, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b44.1, SIP/2.0/UDP sccas2.home2.net;branch=z9hG4bKnas34r5
Record-Route: , 
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCE11
Privacy: none
From: ;tag=171828
To: 
Call-ID: cb03a0s09a2sdfglkj490333
CSeq:
Require: 100rel, precondition
Contact: 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933623 2987933623 IN IP6 5555::eee:fff:aaa:bbb
s=-
c=PSTN - - 
t=0 0
m=audio 9 PSTN -
a=setup:active
a=connection:new
a=cs-correlation:callerid:+358504821437
a=curr:qos local sendrcv
a=curr:qos remote sendrcv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv

30.	SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS)
	The SIP 200 (OK) response and final SDP answer from the ICS UE is routed towards the SCC AS.
31.	SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in Table A.5.3-31
	The SCC AS, acting as a B2BUA, generates a SIP 200 (OK) response based upon the SIP 200 (OK) response reeceived and is routed towards the intermediate IM CN subsystem entities. This SIP 200 (OK) response includes an answer SDP in response to the offer SDP that was received by the SCC AS in the original SIP INVITE request.  The answer SDP indicates the IP addressed and codecs of the MGW as received by the SCC AS during CS bearer setup. 
Table A.5.3-31: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities)
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcscf2.home2.net;branch=z9hG4bKfeh9083, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b44.1, SIP/2.0/UDP sccas2.home2.net;branch=z9hG4bKnas34r5
Record-Route: , 
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCE11
Privacy: none
From: ;tag=171828
To: 
Call-ID: cb03a0s09a2sdfglkj490333
CSeq:
Require: 100rel, precondition
Contact: 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933623 2987933623 IN IP6 5555::eee:fff:aaa:eee
s=-
c=IN IP6 5555::eee:fff:aaa:eee
t=0 0
m=audio 3456 RTP/AVP 97 96
a=curr:qos local sendrcv
a=curr:qos remote sendrcv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=maxptime:20

32.	SIP 200 (OK) response (intermediate IM CN subsystem entities to originating IM CN subsystem via)
	The SIP 200 (OK) response is routed towards the originating UE via the originating IM CN subsystem.
33-34.	SIP ACK request (originating IM CN subsystem to SCC AS via intermediate IM CN subsystem entities and SCC AS)
	The originating IM CN subsystem sends a SIP ACK request to the SCC AS via the intermediate IM CN subsystem entities. There is no ICS specific content in this response.
35-36.	SIP ACK request (SCC AS to ICS UE B via intermediate IM CN subsystem entities and SCC AS)
	The SCC AS sends a SIP ACK request to the ICS UE B via the intermediate IM CN subsystem entities. There is no ICS specific content in this response.
A.5.4	Signalling flows for termination to an ICS UE with CS media using Gm reference point when using an MSC Server not enhanced for ICS
Figure A.5.4-1 shows the termination of a call to an ICS UE using CS bearers controlled through the IM CN subsystem. In this example the MSC Server is not enhanced for ICS thus translation at the MGCF of ISUP message to SIP messages is required.
 EMBED Visio.Drawing.11  
Figure A.5.4-1:	ICS UE termination with CS media using Gm reference point when using an MSC Server not enhanced for ICS
The details of the signalling flows are as follows:
1-12.	These steps are identical to steps 1-12 described in subclause A.5.3 (Signalling flows for termination to an ICS UE with CS media using Gm reference point when using an MSC Server enhanced for ICS)
13. ISUP IAM message (MSC Server not enhanced for ICS to MGCF)
	The MSC Server not enhanced for ICS maps the received SETUP message to an ISUP IAM message that is routed towards the MGCF.
	Specifically for this signalling flow, the IAM includes:
-	Called Party Number parameter = [Numbering plan identifier = ISDN/telephony numbering plan], (type of number = international number), (Number digits = 12125556666)]. The Called Party Number is set to the SCC AS PSI DN, as received in the SETUP message.
-	Calling Party Number parameter = [(Numbering plan identifier =  ISDN/telephony numbering plan), (type of number = international number), (Number digits = 12125552222)]
14.	SIP INVITE request (MGCF to intermediate IM CN subsystem entities) – see example in Table A.5.4-14.
	The MGCF maps the received ISUP IAM message to a SIP INVITE request which is routed towards the intermediate IM CN subsystem entities. The INVITE request is addressed to the SCC AS PSI DN in the Request-URI.
Table A.5.4-14: SIP INVITE request (MGCF to intermediate IM CN subsystem entities)
INVITE tel:+1-212-555-6666 SIP/2.0
Via: SIP/2.0/UDP mgcf1.home1.net;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: 
P-Asserted-Identity: 
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home2.net
Privacy: none
From: ;tag=171828
To: 
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"
Cseq: 127 INVITE
Supported: 100rel, precondition
Contact:;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee
s=
c=IN IP6 5555::aaa:bbb:ccc:eee
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=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:	SCC AS PSI DN as received in the SETUP message.
	P-Asserted-Identity:	The MGCF inserts the tel-URI containing the subscriber number, as received from the ICS UE B. 
	SDP:	The SDP contains preconfigured set of codecs supported by the MGW. 
15.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to MSC Server not enhanced for ICS)
	The intermediate IM CN subsystem entities respond to the MSC Server not enhanced for ICS with a SIP 100 (Trying) response. There is no ICS specific content in this response.
16.	SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) – see example in Table A.5.4-16
	The SIP INVITE request is sent to the SCC AS.
Table A.5.4-16: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS)
INVITE tel:+1-212-555-6666 SIP/2.0
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b33.1,SIP/2.0/UDP  icscf1.home1.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP mgcf1.home1.net;branch=z9hG4bKnashds7
Max-Forwards: 68
Route: , ;orig-dialog-id="yuflsae80r3rb3fh31ondyr829cnyr381cn932YDWref0w0-wwtg374"
Record-Route: 
P-Asserted-Identity:
P-Charging-Vector:
Privacy:
From:
To:
Accept-Contact:
Call-ID:
Cseq:
Supported:
Contact:
Allow:
Content-Type:
Content-Length: (…)

v=
o=-
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

17.	SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities)
	The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is no ICS specific content in this response.
18.	SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) – see example in Table A.5.4-18
	The SCC AS responds to the SIP INVITE request with a SIP 200 (OK) response that includes an SDP answer.
Table A.5.4-18: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b33.1,SIP/2.0/UDP  icscf2.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP mgcf2.home2.net;branch=z9hG4bKnashds7
Record-Route: ,
P-Access-Network-Info:
Privacy: none
From: ;tag=171828
To: ;tag=1667452
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
CSeq:
Require: 100rel, precondition
Contact: ;+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=- 2987933623 2987933623 IN IP6 5555::ggg:fff:aaa:bbb
s=-
c=IN IP6 5555::ggg:fff:aaa:bbb
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrcv
a=curr:qos remote sendrcv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=maxptime:20

19.	SIP 200 (OK) response (intermediate IM CN subsystem to MGCF) 
	The intermediate IM CN subsystem entities route the SIP 200 (OK) response to the MSC Server not enhanced for ICS.
20.	ISUP ANM message (MGCF to MSC Server not enhanced for ICS)
	On receipt of the SIP 200 (OK) response, the MGCF generates an ISUP ANM message and sends this to the MSC Server not enhanced for ICS. 
	There is no ICS specific content in this message.
21-22.	These steps are identical to steps 19-20 described in subclause A.5.3.
23-24.	SIP ACK request (MGCF to SCC AS via intermediate IM CN subsystem entities)
	On receipt of the SIP 200 (OK) response, the MGCF sends a SIP ACK request which is routed to the SCC AS via the intermediate IM CN subsystem entities. There is no ICS specific content in this response.
25-36.	These steps are identical to steps 23-34 described in subclause A.5.3.
A.5.5	Signalling flows for termination to an ICS UE with CS media using Gm reference point when using an MSC Server enhanced for ICS and UE assisted T-ADS
Figure A.5.5-1 shows the termination of a call to an ICS UE using CS bearers controlled through the IM CN subsystem. In this example the MSC Server is enhanced for ICS and is capable of translating NAS signalling received from the ICS UE to SIP and vice versa. In this example, the UE supports UE assisted terminating access domain selection.
 EMBED Visio.Drawing.11  
Figure A.5.5-1:	ICS UE termination with CS media using Gm reference point when using an MSC Server enhanced for ICS – UE assisted T-ADS
The details of the signalling flows are as follows:
1-5:	These steps are identical to steps 1-5 described in subclause A.5.3.
The SDP shows that local preconditions on the originating side are met. 
6.	Terminating Access Domain Selection
The SCC AS performs initial T-ADS selecting IMS for the service control signalling when UE-B is registered in the IMS. 
7.	SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) – see example in Table A.5.5-7.
The SCC AS, acting as a routing B2BUA, generates a SIP INVITE request based upon the received SIP INVITE request and sends it to the intermediate subsystem entities.
Table A.5.5-7:	SIP INVITE request (SCC AS to intermediate IM CN subsystem entities)
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP sccas.home1.net;branch=z9hG4bKnas34r5
Max-Forwards: 65
Route: ;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"
Record-Route:
P-Access-Network-Info:
P-Asserted-Identity:
P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4ee]; ecf=[5555::6aa:7bb:8cc:9dd]
P-Charging-Vector:
P-Asserted-Service:
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"
Accept-Contact: *;+g.3gpp.ics="principal";explicit;require
Privacy:
From: ;tag=171828
To:
Call-ID:
Cseq:
Supported:
Accept:
Contact:
Allow:
Content-Type:
Content-Length:

v=0
o=2987933615 2987933615 IN IP6 5555::eee:ccc:aaa:bbb 
s=-
c=IN IP6 5555::eee:fff:aaa:bbb
t=0 0
a=creq:med-v0
m=audio 49170 RTP/AVP 97 3 98
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:98 telephone-event/8000
a=fmtp:98 0-15
a=ccap:2 PSTN E164 +12125556666
a=tcap:2 PSTN
a=omcap:4 -
a=acap:1 setup:actpass
a=acap:2 connection:new
a=pcfg:1
a=pcfg:2 t=2 m=4 c=2 a=1,2
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos optional remote sendrecv

8.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to SCC AS)
	The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response. There is no ICS specific content in this response.
9.	SIP INVITE request (intermediate IM CN subsystem entities to ICS UE B) 
	The SIP INVITE request is routed towards the called party ICS UE B since further iFC evaluation is not necessary.
10.	SIP 100 (Trying) response (ICS UE B to intermediate IM CN subsystem entities)
	The ICS UE B responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is no ICS specific content in this response.
11.	Terminating Access Domain Selection
	The ICS UE performs T-ADS. In this example the UE chooses a CS bearer for media
12	SIP 183 (Session Progress) response (ICS UE to intermediate IM CN subsystem entities) – see example in table A.5.5-12
The ICS UE generates a SIP 183 (Session Progress) response based upon the received SIP INVITE request and indicates in the SDP that the CS media bearer is used.
Table A.5.5-12: SIP 183 (Session Progress) response (IMS UE to intermediate IM CN subsystem entities) 
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK240f34.1,
SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1,
SIP/2.0/UDP sccas .home1.net;branch=z9hG4bKnas34r5,
Record-Route: ;
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCE11
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
Privacy: none
From: ;tag=171828
To: ;tag=171820
Call-ID:
CSeq:
Require: 100rel
Contact: ;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="principal"
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)

v=0
o=2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=
t=0 0
m=audio 9 PSTN -
c=PSTN - -
a=acfg:2 t=2 m=4 c=2 a=1,2
a=setup:active
a=connection:new
a=cs-correlation:callerid:+12125552222
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv

14.	SETUP message (ICS UE B to MSC Server enhanced for ICS)
	The ICS UE B inititates bearer setup in the CS domain by sending a SETUP message to the MSC Server enhanced for ICS.
	Specifically for this signalling flow, the SETUP message includes:
-	Called Party Number information element = = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits = 1212556666)].	The Called Party Number information element is set to the SCC AS PSI DN.
-	Bearer Capability information element = [(information transfer capability  = speech), (speech versions = FR AMR, GSM EFR, GSM FR)]
-	Supported Codec List information element = {[(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)]}
	The MSC Server enhanced for ICS knows the calling party number corresponding to the ICS UE B.
15.	CALL PROCEEDING message (MSC Server enhanced for ICS to ICS UE B)
	Upon receipt of the SETUP message from the ICS UE B, the MSC Server enhanced for ICS responds with a CALL PROCEEDING message. There is no ICS specific content in this message.
16.	SIP PRACK request (SCC AS to IM CN subsystem entities) 
	SCC AS acknowledges the receipt of SIP 183 (Session Progress) response.
16.	SIP PRACK request and SIP 200 (OK) response
	The SCC AS sends a SIP PRACK request towards the ICS UE via the intermediate IM CN subsystem entities as a result of receiving the reliably sent SIP 183 (Session Progress) response containing the SDP answer.
	Upon receipt of the SIP PRACK request, the ICS UE responds with a SIP 200 (OK) response towards the SCC AS via the intermediate IM CN subsystem entities.
	The is no ICS specific content in these SIP messages.
17.	SIP INVITE request (MSC Server enhanced for ICS to intermediate IM CN subsystem entities) – see example in A.5.5-17.
	The MSC Server enhanced for ICS maps the received SETUP message to a SIP INVITE request which is routed towards the intermediate IM CN subsystem entities. The INVITE request is addressed to the SCC AS PSI DN in the Request-URI.
Table A.5.5-17: SIP INVITE request (MSC Server enhanced for ICS to intermediate IM CN subsystem entities)
INVITE tel:+1-212-555-6666 SIP/2.0
Via: SIP/2.0/UDP msc2.home1.net;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: 
P-Asserted-Identity: 
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home2.net
P-Access-Network-Info:
Privacy: none
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"
From: ;tag=276859
To: 
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Cseq: 127 INVITE
Supported: 100rel, precondition, gruu, 199
Contact: ;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server"
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:fff
s=
c=IN IP6 5555::aaa:bbb:ccc:fff
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:96 telephone-event
a=maxptime:20

	Request-URI:	SCC AS PSI DN as received in the SETUP message.
	P-Asserted-Identity:	The MSC Server enhanced for ICS inserts the tel-URI containing the subscriber number, as received from the ICS UE B.
	Accept-Contact:	The MSC Server enhanced for ICS includes the mmtel feature tag in the INVITE request .
	Contact:	The MSC Server enhanced for ICS includes the GRUU received at registration, the media feature tag g.3gpp.icsi-ref set to "urn%3Aurn-7%3gpp-service.ims.icsi.mmtel" and the media feature tag g.3gpp.ics set to "server".
	SDP:	The SDP contains preconfigured set of codecs supported by the MGW.
18.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to MSC Server enhanced for ICS)
	The intermediate IM CN subsystem entities respond to the MSC Server enhanced for ICS with a SIP 100 (Trying) response. There is no ICS specific content in this response.
19.	SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) – see example in Table A.5.5-19
	The SIP INVITE request is sent to the SCC AS.
Table A.5.5-19: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS)
INVITE tel:+1-212-555-6666 SIP/2.0
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b33.1,SIP/2.0/UDP  icscf1.home1.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP msc2.home1.net;branch=z9hG4bKnashds7
Max-Forwards: 68
Route: , ;orig-dialog-id="yuflsae80r3rb3fh31ondyr829cnyr381cn932YDWref0w0-wwtg374"
Record-Route: 
P-Asserted-Identity:
P-Charging-Vector:
P-Access-Network-Info:
Privacy:
From:
To:
Call-ID:
Accept-Contact:
Cseq:
Supported:
Contact:
Allow:
Content-Type:
Content-Length: (…)

v=
o=-
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

20.	SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities)
	The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is no ICS specific content in this response.
21.	SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) – see example in table A.5.5-21.
	The SCC AS responds to the SIP INVITE request with a SIP 200 (OK) response that includes an SDP answer. The SDP shows local preconditions as received in the SIP INVITE request in step 4.
Table A.5.5-21: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b33.1,SIP/2.0/UDP  icscf1.home1.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP msc2.home1.net;branch=z9hG4bKnashds7
Record-Route: ,
P-Access-Network-Info:
Privacy: none
From: ;tag=276859
To: ;tag=347529
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
CSeq:
Require: 100rel, precondition
Contact:;+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=- 2987933623 2987933623 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrcv
a=curr:qos remote sendrcv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=maxptime:20

22.	SIP 200 (OK) response (intermediate IM CN subsystem to MSC Server enhanced for ICS) 
	The intermediate IM CN subsystem entities route the SIP 200 (OK) response to the MSC Server enhanced for ICS. 
23.	CONNECT message (MSC Server enhanced for ICS to ICS UE B)
	The enhance MSC Server maps the received SIP 200 (OK) response to a CONNECT message. There is no ICS specific content in this message.
24.	CONNECT ACKNOWLEDGEMENT message (ICS UE B to MSC Server enhanced for ICS)
	The ICS UE A sends a CONNECT ACKNOWLEDGMENT message upon receiving the CONNECT message. There is no ICS specific content in this message. 
25-26.	SIP ACK request (MSC Server enhanced for ICS to SCC AS via intermediate IM CN subsystem entities)
	The MSC Server enhanced for ICS interworks the received CONNECT ACKNOWLEDGEMENT message to a SIP ACK request which is routed to the SCC AS via the intermediate IM CN subsystem entities. There is no ICS specific content in this response.
27-28.	SIP 180 (Ringing) response (ICS UE B to SCC AS via intermediate IM CN subsystem entities)
	The ICS UE B responds to the received SIP INVITE request with a SIP 180 (Ringing) response. The response contains no SDP body and contains no ICS specific content. The SIP 180 (Ringing) response is routed to the SCC AS.
29-30.	SIP 180 (Ringing) response (SCC AS to originating IM CN subsystem via intermediate IM CN subsystem entities)
	The SCC AS routes the received SIP 180 (Ringing) response towards the originating network and the calling party.
31. SIP 200 (OK) response (ICS UE B to intermediate IM CN subsystem entities) – see example in Table A.5.5-27
	The ICS UE B responds to the received initial SIP INVITE request with a SIP 200 (OK) response. This SIP 200 (OK) does not include an SDP body.
32.	SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS)
	The SIP 200 (OK) response from the ICS UE is routed towards the SCC AS.
33-34.	SIP 200 (OK) response (SCC AS to originating IM CN subsystem via intermediate IM CN subsystem entities)
	The SIP 200 (OK) response is routed towards the originator of the session in the originating IM CN subsystem. This SIP 200 (OK) response includes an SDP answer the correponds to the SDP received from the MSC server enhanced for ICS and indicates that local preconditions are met.
Table A.5.5-33: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b33.1,SIP/2.0/UDP  icscf1.home1.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited2.net;branch=z9hG4bK431h23.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route: , , 
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCE11
Privacy: none
From: ;tag=171828
To: ;tag=684213
Call-ID: cb03a0s09a2sdfglkj490333
CSeq:
Require: 100rel, precondition
Contact:;+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=- 2987933623 2987933623 IN IP6 5555::aaa:bbb:ccc:eee
s=-
c=IN IP6 5555::aaa:bbb:ccc:eee
t=0 0
m=audio 3456 RTP/AVP 97 96
a=curr:qos local sendrcv
a=curr:qos remote sendrcv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=maxptime:20

35-36.	SIP ACK request (originating IM CN subsystem to SCC AS via intermediate IM CN subsystem entities and SCC AS)
	The originating IM CN subsystem sends a SIP ACK request to the SCC AS via the intermediate IM CN subsystem entities. There is no ICS specific content in this response.
37-38.	SIP ACK request (SCC AS to ICS UE B via intermediate IM CN subsystem entities and SCC AS)
	The SCC AS sends a SIP ACK request to the ICS UE B via the intermediate IM CN subsystem entities. There is no ICS specific content in this response.
A.5.6	Signalling flows for termination to an ICS UE with CS media using I1 reference point when using an MSC Server enhanced for ICS
Figure A.5.6-1 shows the termination of a call to a ICS UE via the I1 interface.
 EMBED Visio.Drawing.11  
Figure A.5.6-1:	ICS UE termination with CS media using I1 reference point when using an MSC Server enhanced for ICS
The details of the signalling flows are as follows:
1.	SIP INVITE request (originating IM CN subsystem to intermediate IM CN subsystem entities in terminating network) – see example in table A.5.6-1
	In this example, the originating UE initiates a voice call though its home IM CN subsystem (home1) with a terminating UE which is ICS capable which is in a different network (home2). 
Table A.5.6-1:	SIP INVITE request (originating IM CN subsystem to intermediate IM CN subsystem entities in terminating network)
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK431h23.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 67
Route: 
Record-Route: , 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
P-Asserted-Identity: "John Doe" , 
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: ;tag=171828
To: 
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Supported: 100rel, precondition, gruu
Contact: ;;+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 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd 
t=0 0
m=audio 3456 RTP/AVP 97 0 96
b=AS:25.4
a=curr:qos local sendrcv
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

NOTE 1:	This example assumes the session was originated from a 3GPP Release 8 IMS UE and thus includes the ICSI value defined for MMTel in the Contact header and Accept Contact header. However, termination procedures for ICS do not rely upon the MMTel ICSI value being present in the incoming request. 
2.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to originating IM CN subsystem)
	The intermediate IM CN subsystem entities respond to the originating IM CN subsystem with a SIP 100 (Trying) response. There is no ICS specific content in this response. 
3.	Evaluation of initial filter criteria
	The S-CSCF evaluates initial filter criteria for the served ICS user and as a result routes the SIP INVITE request towards the SCC AS.
NOTE 2:	for terminating scenario, the SCC AS is configured as the last AS in the terminating iFC chain.
4.	SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) – see example in table A.5.6-4
	As a result of iFC evaluation, the S-CSCF routes the INVITE request to the SCC AS.
Table A.5.6-4:	SIP INVITE request (intermediate IM CN subsystem entities to SCC AS)
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b33.1,SIP/2.0/UDP  icscf2.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK431h23.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 66
Route: , ;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"
Record-Route: , , 
P-Access-Network-Info:
P-Asserted-Identity:
P-Charging-Vector:
P-Asserted-Service:
Accept-Contact:
Privacy:
From:
To:
Call-ID:
Cseq:
Supported:
Contact:
Allow:
Content-Type:
Content-Length:

v=0
o=-
s=-
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

5.	SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities)
	The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is no ICS specific content in this response.
6.	Terminating Access Domain Selection
	The SCC AS performs Terminating Access Domain Selection and chooses the CS domain for the setup of the media. 
7.	I1 INVITE request (using I1 Protocol to ICS UE B) – see example in Table A.5.6-9.
	The I1 INVITE request is routed towards the called party ICS UE B.
	The SCC AS initiates service control signalling in the IM CN subsystem towards the ICS UE by sending an I1 Invite message.
	Specifically for this signalling flow, the I1 Invite message includes:
-	Protocol Information = 0x11
-	Message Type = I1 Invite
-	Reason = MO (0x000)
-	Call ID = (0x001)
-	Sequence-ID = (0x1)
-	To-id = [(international number), (12125556666)]
-	From-id = [(international number), (12125551111)]
-	SCC-AS-id information element = [(Code specific = E.164 number), (number digits = 1212556666)]. This is the allocated SCC AS PSI DN
-	Session-identifier information element = [(Code specific = E.164 number), (number digits = 1212557777)]. This is the allocated SCC AS STI
8.	SETUP message (ICS UE B to MSC Server enhanced for ICS)
	The ICS UE B inititates bearer setup in the CS domain by sending a SETUP message to the MSC Server enhanced for ICS.
	Specifically for this signalling flow, the SETUP message includes:
-	Called Party Number information element = = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits = 1212556666)].	The Called Party Number information element is set to the UAI PSI DN.
-	Bearer Capability information element = [(information transfer capability  = speech), (speech versions = FR AMR, GSM EFR, GSM FR)]
-	Supported Codec List information element = {[(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)]}
	The MSC Server enhanced for ICS knows the calling party number corresponding to the ICS UE B.
9.	CALL PROCEEDING message (MSC Server enhanced for ICS to ICS UE B)
	Upon receipt of the SETUP message from the ICS UE B, the MSC Server enhanced for ICS responds with a CALL PROCEEDING message. There is no ICS specific content in this message.
10.	SIP INVITE request (MSC Server enhanced for ICS to intermediate IM CN subsystem entities) – see example in table A.5.6-13.
	The MSC Server enhanced for ICS maps the received SETUP message to a SIP INVITE request which is routed towards the intermediate IM CN subsystem entities. The SIP INVITE request is addressed to the IUA PSI DN in the Request-URI.
Table A.5.6-10: SIP INVITE request (MSC Server enhanced for ICS to intermediate IM CN subsystem entities)
INVITE tel:+1-212-555-6666 SIP/2.0
Via: SIP/2.0/UDP msc2.home2.net;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: 
P-Asserted-Identity: 
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home2.net
P-Access-Network-Info:
Privacy: none
From: ;tag=171828
To: 
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Cseq: 127 INVITE
Supported: 100rel, precondition
Require: sec-agree
Proxy-Require: sec-agree
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port=7531
Contact: ;
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee
s=
c=IN IP6 5555::aaa:bbb:ccc:eee
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=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:	UAI PSI DN as received in the SETUP message.
	P-Asserted-Identity header:	The MSC Server enhanced for ICS inserts the tel URI containing the subscriber number, as received from the ICS UE B.
	SDP:	The SDP contains preconfigured set of codecs supported by the MGW.
11.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to MSC Server enhanced for ICS)
	The intermediate IM CN subsystem entities respond to the MSC Server enhanced for ICS with a SIP 100 (Trying) response. There is no ICS specific content in this response.
12.	SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) – see example in Table A.5.6-15
	The SIP INVITE request is sent to the SCC AS.
Table A.5.6-12: SIP INVITE request (MSC Server enhanced for ICS to intermediate IM CN subsystem entities)
INVITE tel:+1-212-555-6666 SIP/2.0
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b33.1,SIP/2.0/UDP  icscf2.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP msc2.home2.net;branch=z9hG4bKnashds7
Max-Forwards: 68
Route: , ;orig-dialog-id="yuflsae80r3rb3fh31ondyr829cnyr381cn932YDWref0w0-wwtg374"
Record-Route: 
P-Asserted-Identity:
P-Charging-Vector:
P-Access-Network-Info:
Privacy:
From:
To:
Call-ID:
Cseq:
Supported:
Require:
Proxy-Require:
Security-Verify:
Contact:
Allow:
Content-Type:
Content-Length: (…)

v=
o=-
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

13.	SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities)
	The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is no ICS specific content in this response.
14.	SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) – see example in table A.5.6-17.
	The SCC AS responds to the SIP INVITE request with a SIP 200 (OK) response that includes an SDP answer. 
Table A.5.6-14: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b33.1,SIP/2.0/UDP  icscf2.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP msc2.home2.net;branch=z9hG4bKnashds7
Record-Route: 
P-Access-Network-Info:
Privacy: none
From: ;tag=171828
To: 
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
CSeq:
Require: 100rel, precondition
Contact: 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933623 2987933623 IN IP6 5555::ggg:fff:aaa:bbb
s=-
c=IN IP6 5555::ggg:fff:aaa:bbb
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrcv
a=curr:qos remote sendrcv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=maxptime:20

15.	SIP 200 (OK) response (intermediate IM CN subsystem to MSC Server enhanced for ICS) 
	The intermediate IM CN subsystem entities route the SIP 200 (OK) response to the MSC Server enhanced for ICS. 
16.	CONNECT message (MSC Server enhanced for ICS to ICS UE B)
	The enhance MSC Server maps the received SIP 200 (OK) response to a CONNECT message. There is no ICS specific content in this message.
17.	CONNECT ACKNOWLEDGEMENT message (ICS UE B to MSC Server enhanced for ICS)
	The ICS UE A sends a CONNECT ACKNOWLEDGMENT message upon receiving the CONNECT message. There is no ICS specific content in this message. 
18-19.	SIP ACK request (MSC Server enhanced for ICS to SCC AS via intermediate IM CN subsystem entities)
	The MSC Server enhanced for ICS interworks the received CONNECT ACKNOWLEDGEMENT message to a SIP ACK request which is routed to the SCC AS via the intermediate IM CN subsystem entities. There is no ICS specific content in this response.
20.	I1 PROGRESS  response (ICS UE B to SCC AS via I1 Protocol) – see example in table A.5.6-23.
	The ICS UE B responds to the received I1 INVITE request with I1 Progress response. 
	Specifically for this signalling flow, the I1 Progress message includes:
-	Protocol Information = 0x11
-	Message Type = I1 Progress
-	Reason = 0x0 180
-	Call ID = (0x001)
-	Sequence-ID = 0x1
21-22.	SIP 180 (Ringing) response (SCC AS to originating IM CN subsystem via intermediate IM CN subsystem entities)
	The SCC AS routes the received SIP 180 (Ringing) response towards the originating network and the calling party.
23. I1 SUCCESS  response (ICS UE B to SCC AS via I1 Protocol) – see example in table A.5.6-27
	The ICS UE B responds to the received initial I1 INVITE request with a I1 SUCCESS response.
Specifically for this signalling flow, the I1 Success message includes:
-	Protocol Information = 0x11
-	Message Type = I1 Success
-	Reason = 0x0
-	Call ID = (0x001)
-	Sequence-ID = 0x3
24.	SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS)
	The SIP 200 (OK) response and final SDP answer from the ICS UE is routed towards the SCC AS.
25-26.	SIP 200 (OK) response (SCC AS to originating IM CN subsystem via intermediate IM CN subsystem entities)
	The SIP 200 OK response is routed towards the originator of the session in the originating IM CN subsystem.
27-28.	SIP ACK request (originating IM CN subsystem to SCC AS via intermediate IM CN subsystem entities and SCC AS)
	The originating IM CN subsystem sends a SIP ACK request to the SCC AS via the intermediate IM CN subsystem entities. There is no ICS specific content in this response.
A.5.7	Signalling flows for termination to an ICS UE with CS media using I1 reference point when using an MSC server enhanced for ICS and UE assisted T-ADS
Figure A.5.7-1 shows the termination of a call to an ICS UE using CS bearers controlled through the IM CN subsystem. 
 EMBED Visio.Drawing.6  
Figure A.5.7-1:	ICS UE termination with CS media using I1 reference point when using an MSC server – UE assisted T-ADS
The details of the signalling flows are as follows:
1-13:	These steps are identical to steps 1-5 described in subclause A.5.5.
6.	Terminating Access Domain Selection
	The SCC AS performs initial T-ADS selecting IMS for the service control signalling when UE-B is registered in the IMS. 
7.	I1 Invite message (SCC AS Via I1 Protocol to ICS UE B)
	The I1 Invite message is routed towards the called party ICS UE B.
	The SCC AS initiates service control signalling in the IM CN subsystem towards the ICS UE by sending an I1 Invite message.
	Specifically for this signalling flow, the I1 Invite message includes:
-	Protocol Information = 0x11
-	Message Type = I1 Invite
-	Reason = MO (0x000)
-	Call ID = (0x001)
-	Sequence-ID = (0x1)
-	To-id = [(international number), (12125556666)]
-	From-id = [(international number), (12125551111)]
-	SCC-AS-id information element = [(Code specific = E.164 number), (number digits = 1212556666)]. This is the allocated SCC AS PSI DN
-	Session-identifier information element = [(Code specific = E.164 number), (number digits = 1212557777)]. This is the allocated SCC AS STI
8.	I1 Progress message (ICS UE to SCC AS)
	The ISC UE generates an I1 Progress message based upon the received I1 INVITE request.
	Specifically for this signalling flow, the I1 Progress message includes:
-	Protocol Information = 0x11
-	Message Type = I1 Progress
-	Reason = 0x0 183
-	Call ID = (0x001)
-	Sequence-ID = 0x1
9.	CC SETUP message (ICS UE B to MSC server)
	The ICS UE B inititates bearer setup in the CS domain by sending a CC SETUP message to the MSC server.
	Specifically for this signalling flow, the CC SETUP message includes:
-	Called Party Number information element = = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits = 1212556666)].	The Called Party Number information element is set to the IUA PSI DN.
-	Bearer Capability information element = [(information transfer capability  = speech), (speech versions = FR AMR, GSM EFR, GSM FR)]
-	Supported Codec List information element = {[(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)]}
	The MSC server knows the calling party number corresponding to the ICS UE B.
10.	CC CALL PROCEEDING message (MSC server to ICS UE B)
	Upon receipt of the CC SETUP message from the ICS UE B, the MSC server responds with a CC CALL PROCEEDING message. There is no ICS specific content in this message.
11.	SIP INVITE request (MSC server to intermediate IM CN subsystem entities via MGCF) – see example in table A.5.7-11.
	The MSC server maps the received CC SETUP message an IAM. The MGCF then maps this to a SIP INVITE request which is routed towards the intermediate IM CN subsystem entities. The SIP INVITE request is addressed to the IUA PSI DN in the Request-URI.
Table A.5.7-11: SIP INVITE request (MSC server to intermediate IM CN subsystem entities via MGCF)
INVITE tel:+1-212-555-6666 SIP/2.0
Via: SIP/2.0/UDP mgcf2.home2.net;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: 
P-Asserted-Identity: 
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home2.net
P-Access-Network-Info:
Privacy: none
From: ;tag=171828
To: 
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Cseq: 127 INVITE
Supported: 100rel, precondition
Require: sec-agree
Proxy-Require: sec-agree
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port=7531
Contact:
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:fff
s=
c=IN IP6 5555::aaa:bbb:ccc:fff
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:96 telephone-event
a=maxptime:20

	Request-URI:	UAI PSI DN as received in the CC SETUP message.
	P-Asserted-Identity header:	The MSC server inserts the tel-URI containing the subscriber number, as received from the ICS UE B.
	SDP:	The SDP contains preconfigured set of codecs supported by the MGW.
12.	SIP 100 (Trying) response (intermediate IM CN subsystem entities to MGCF )
	The intermediate IM CN subsystem entities respond to the MGCF with a SIP 100 (Trying) response. There is no ICS specific content in this response.
13.	SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) – see example in table A.5.7-13
	The SIP INVITE request is sent to the SCC AS.
Table A.5.7-13: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS)
INVITE tel:+1-212-555-6666 SIP/2.0
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b33.1,SIP/2.0/UDP  icscf2.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP mgcf2.home2.net;branch=z9hG4bKnashds7
Max-Forwards: 68
Route: , ;orig-dialog-id="yuflsae80r3rb3fh31ondyr829cnyr381cn932YDWref0w0-wwtg374"
Record-Route: 
P-Asserted-Identity:
P-Charging-Vector:
P-Access-Network-Info:
Privacy:
From:
To:
Call-ID:
Cseq:
Supported:
Require:
Proxy-Require:
Security-Verify:
Contact:
Allow:
Content-Type:
Content-Length: (…)

v=
o=-
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=

14.	SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities)
	The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is no ICS specific content in this response.
15.	SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) – see example in table A.5.7-15.
	The SCC AS responds to the SIP INVITE request with a SIP 200 (OK) response that includes an SDP answer. The SDP shows local preconditions as received in the INVITE in step 4.
Table A.5.7-15: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b33.1,SIP/2.0/UDP  icscf2.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP mgcf2.home2.net;branch=z9hG4bKnashds7
Record-Route: 
P-Access-Network-Info:
Privacy: none
From: ;tag=171828
To: 
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
CSeq:
Require: 100rel, precondition
Contact: 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933623 2987933623 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrcv
a=curr:qos remote sendrcv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=maxptime:20

16.	SIP 200 (OK) response (intermediate IM CN subsystem to MSC server via MGCF) 
	The intermediate IM CN subsystem entities route the SIP 200 (OK) response to the MGCF. The MGCF maps the SIP (200) OK to a ISUP ANM which is sent to the MSC server. 
17.	CC CONNECT message (MSC server to ICS UE B)
	The MSC server maps the received SIP 200 (OK) response to a CC CONNECT message. There is no ICS specific content in this message.
18.	CC CONNECT ACKNOWLEDGEMENT message (ICS UE B to MSC server)
	The ICS UE A sends a CC CONNECT ACKNOWLEDGMENT message upon receiving the CC CONNECT message. There is no ICS specific content in this message. 
19-20.	SIP ACK request (MGCF to SCC AS via intermediate IM CN subsystem entities)
	The MGCF sends a SIP ACK request which is routed to the SCC AS via the intermediate IM CN subsystem entities. There is no ICS specific content in this response.
21.	I1 Progress response (ICS UE B to SCC AS via I1 Protocol)
	The ICS UE B responds to the received I1 Invite message with an I1 Progress message. 
	Specifically for this signalling flow, the I1 Progress message includes:
-	Protocol Information = 0x11
-	Message Type = I1 Progress
-	Reason = 0x0 180
-	Call ID = (0x001)
-	Sequence-ID = 0x1
22-23.	SIP 180 (Ringing) response (SCC AS to originating IM CN subsystem via intermediate IM CN subsystem entities)
	The SCC AS routes the received SIP 180 (Ringing) response towards the originating network and the calling party.
24.	I1 Success message (ICS UE B to SCC AS via I1 Protocol)
	The ICS UE B responds to the received initial I1 Invite message with an I1 Success message.
	Specifically for this signalling flow, the I1 Success message includes:
-	Protocol Information = 0x11
-	Message Type = I1 Success
-	Reason = 0x0
-	Call ID = (0x001)
-	Sequence-ID = 0x3
25-26.	SIP 200 (OK) response (SCC AS to originating IM CN subsystem via intermediate IM CN subsystem entities) – see example in table A.5.7-26
	The SIP 200 (OK) response is routed towards the originator of the session in the originating IM CN subsystem. This SIP 200 (OK) response includes an SDP answer the correponds to the SDP received from the MSC server and indicates that local preconditions are met.
Table A.5.7-26: SIP 200 (OK) response (ICS UE B to intermediate IM CN subsystem entities)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b33.1,SIP/2.0/UDP  icscf2.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK431h23.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route: , 
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCE11
Privacy: none
From: ;tag=171828
To: 
Call-ID: cb03a0s09a2sdfglkj490333
CSeq:
Require: 100rel, precondition
Contact: 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)

v=0
o=- 2987933623 2987933623 IN IP6 5555::aaa:bbb:ccc:eee
s=-
c=IN IP6 5555::aaa:bbb:ccc:eee
t=0 0
m=audio 3456 RTP/AVP 97 96
a=curr:qos local sendrcv
a=curr:qos remote sendrcv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=maxptime:20

27-28.	SIP ACK request (originating IM CN subsystem to SCC AS via intermediate IM CN subsystem entities and SCC AS)
	The originating IM CN subsystem sends a SIP ACK request to the SCC AS via the intermediate IM CN subsystem entities. There is no ICS specific content in this response.

A.6	Signalling flows for supplementary service invocation for ICS
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.
 EMBED Visio.Drawing.11  
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:[email protected];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: , , 
Privacy: none
From: ;tag=171829
To: ; tag=184483
Call-ID: cb03a0s09a2sdfgKlkj490334
Cseq: 127 INVITE
Contact: ;+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:[email protected];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: 
Privacy: none
From: ;tag=276859
To: ;tag=347529
Call-ID: cb03a0s09a2sdfgKlkj490334
Cseq: 127 INVITE
Contact: ;+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 [email protected];branch=z1hG4bKnashds8;SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1
From:
To:
Call-ID:
CSeq: 
Contact: 
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:[email protected] SIP/2.0
Via: SIP/2.0/UDP sccas.home1.net;branch=z9hG4bKnashdsb
Max-Forwards: 70
Route: 
From: ;tag=171828
To: ;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:[email protected];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: , , 
Privacy: none
From: ;tag=171829
To: ;tag=184483
Call-ID: cb03a0s09a2sdfgKlkj490334
Cseq: 127 INVITE
Contact: ;+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:[email protected] SIP/2.0
Via: SIP/2.0/UDP	sccas.home1.net;branch=z9hG4bKnashdsb
Max-Forwards: 70
Route: 
Privacy: none
From: ;tag=171829
To: ;tag=184483
Call-ID: cb03a0s09a2sdfgKlkj490334
Cseq: 127 INVITE
Contact: ;+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: ;+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:[email protected];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: 
Privacy: none
From: ;tag=171829
To: ;tag=184483
Call-ID: cb03a0s09a2sdfgKlkj490334
Cseq: 127 INVITE
Contact: ;+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: ;+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.
 EMBED Visio.Drawing.11  
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 user identity 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.
Table A.6.2-2: SIP REFER request (UE A to intermediate IM CN subsystem entities) 
REFER sip:[email protected] SIP/2.0
Via:	SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: , 
P-Preferred-Identity: "John Doe" 
Privacy: none
From: ; tag=171828
To: 
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 REFER
Refer-To: ?Replaces=cb03a0s09a2sdfhlij490444;from-tag=165343;to-taq=236717&Require=replaces
Referred-By: 
Contact;+ 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:[email protected] 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: 
P-Asserted-Identity: "John Doe" 
Privacy: 
From: 
To: ; tag=26876
Call-ID: 
Cseq: 
Refer-To: 
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: ; tag=26876
Call-ID: 
CSeq:
Contact:;+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:[email protected] SIP/2.0
Via: SIP/2.0/UDP [3333::ccc:ddd:ccc:eee]:1357;comp=sigcomp;branch=z9hG4bKnashds8
Max-Forwards: 70
Route: , 
P-Preferred-Identity: 
Privacy: none
From: ;tag=276589
To: 
Call-ID: cb03a0s09a2sdfgKlkj490334
Cseq: 127 INVITE
Contact:;+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:[email protected] SIP/2.0
Via: SIP/2.0/UDP sccas.home1.net;branch=z9hG4bKnashdsb
Max-Forwards: 70
Route: 
P-Asserted-Identity: 
Privacy: none
From: ;tag=171838
To: ;tag=184483
Call-ID: cb03a0s09a2sdfgKlkj490334
Cseq: 127 INVITE
Contact:;+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: ;+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:[email protected] SIP/2.0
Via: SIP/2.0/UDP sccas.home1.net;comp=sigcomp;branch=z9hG4bGnashds6
Max-Forwards: 70
Route: 
P-Asserted-Identity: 
Privacy: none
From: ;;tag=171838
To: 
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Contact: ;+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: ;+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: ;+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.
 EMBED Visio.Drawing.11  
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:[email protected] SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: , 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
P-Preferred-Identity: 
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: ;tag=171828
To: < sip:[email protected] >
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Supported: 100rel, precondition, gruu, 199
Contact: ; +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:[email protected] 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: , ;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"
Record-Route:	, , 
P-Access-Network-Info:
P-Asserted-Identity: "John Doe" , 
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: ;tag=687364
To: 
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Supported: 100rel, precondition, gruu, 199
Contact: ; +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



      

--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.
 EMBED Visio.Drawing.11  
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:[email protected] SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: , 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
P-Asserted-Identity: "John Doe" , 
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: ;tag=171828
To: < sip:[email protected] >
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Supported: 100rel, precondition, gruu, 199
Contact: ; +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:[email protected] 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: , ;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"
Record-Route:	, , 
P-Access-Network-Info:
P-Asserted-Identity:
P-Charging-Vector:
P-Asserted-Service:
Accept-Contact:
Privacy: 
From: ;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



      

--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 defined within the current document
B.1	General
This subclause describes the media feature tag definitions that are applicable for the 3GPP IM CN Subsystem for the realisation of ICS. 
B.2	Definition of media feature tag g.3gpp.ics
Media feature-tag name: g.3gpp.ics
ASN.1 Identifier: 1.3.6.1.8.2.6
Summary of the media feature indicated by this tag: This feature-tag when used in a SIP REGISTER request indicates that the function is ICS capability and may operate in ICS mode.  This feature-tag when used is a none SIP REGISTER method indicates that the function wants to invoke ICS functionality.
Values appropriate for use with this feature-tag: principal; server.
principal	When used in a SIP REGISTER request indicates that the function that is ICS capable is a mobile phone.  When used in another SIP method indicates that the function wants to invoke ICS functionality.
server		Indicates that the function that is ICS capable is a network node.
The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA.
Examples of typical use: Indicating that a mobile phone (principal) can support or wants to use ICS or that a network node (server) wants to invoke ICS functionality
Related standards or documents: 3GPP TS 24.292 [11]: "3GPP Technical Specification: IP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS); Stage 3"
Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of IETF RFC 3840 [34].
B.3	Definition of media feature tag g.3gpp.accesstype
Media feature-tag name: g.3gpp.accesstype
ASN.1 Identifier: 1.3.6.1.8.2.7
Summary of the media feature indicated by this tag: This feature-tag when used in a SIP REGISTER request indicates access network technology used by the device and the particular registration flow that the device is using to register over.
Values appropriate for use with this feature-tag: string with an equality relationship.
Examples
-	"wlan1": the UE is using WLAN access technology.
-	"cellular2": the UE is using cellular access technology.
-	"docsis4": the UE is using DOCSIS access technology.
	"dsl3": the UE is using DSL access technology.
-	"ethernet5": the UE is using Ethernet access technology.
This list is not exhaustive.
The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA.
Examples of typical use: Indicating the access technology that the device is using
Related standards or documents: 3GPP TS 24.292 [11]: "3GPP Technical Specification: IP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS); Stage 3"
Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of IETF RFC 3840 [34].
Annex C (informative):
Change history
Change history
DateTSG #TSG Doc.CRRevSubject/CommentOldNew2008-05CT1#53C1-081527Initial skeleton from rapporteur-0.0.02008-05CT1#53C1-082003
C1-082004Incorporate agreed P-CRs from CT1#530.0.00.1.02008-06Update to include specification number0.1.00.1.12008-06CT1#54C1-082130Update of skeleton. Additional editorial fixes:
Reduced numbering levels by reducing the nested subclauses (and this fixed the numbering issues in the process)0.1.10.2.02008-06CT1#54C1-082322Addition of deregistration for MSC Server enhanced for ICS 0.1.10.2.02008-06CT1#54C1-082756Example signalling flow for CS UE origination via an MSC enhanced for ICS where the origation MSC server enhanced for ICS supports codec negotiation.0.1.10.2.02008-06CT1#54C1-082757Example signalling flow for CS UE origination via an MSC enhanced for ICS where the origation MSC server enhanced for ICS does not supports codec negotiation.0.1.10.2.02008-06CT1#54C1-082758Pseudo-CR on Example signalling flow for CS UE termination with codec negotiation via enhanced MSC Server0.1.10.2.02008-06CT1#54C1-082759Pseudo-CR on Example signalling flow for CS UE termination when not registered in IMS0.1.10.2.02008-06CT1#54C1-082760Flow for ICS Registration0.1.10.2.02008-06CT1#54C1-082761Pseudo-CR on registration procedure for ICS0.1.10.2.02008-06CT1#54C1-082598Pseudo-CR MSC as functional entity0.1.10.2.02008-06CT1#54C1-082599Subscription to reg-event for ICS0.1.10.2.02008-06CT1#54C1-082600Reregistration for ICS0.1.10.2.02008-06CT1#54C1-082762Pseudo-CR on ICS UE termination with CS media using Gm reference point when using an enhanced MSC Server0.1.10.2.02008-06CT1#54C1-082763Pseudo-CR on Signalling flows for ICS UE origination with CS media using Gm reference point when using an MSC server (not enhanced for ICS)0.1.10.2.02008-06CT1#54C1-082764Pseudo-CR on Signalling flows for termination to an ICS UE with CS media using Gm reference point when using an MSC server (not enhanced for ICS)0.1.10.2.02008-06CT1#54Rapporteur Cleanups
MSC server to MSC Server
Consistent use of "MSC Server enhanced for ICS"
"reponse" should be "response"
"ISC" should be "ICS"
"a MSC" should be "an MSC"
fixed typos
fixed table numbering in A.2.10.1.10.2.02008-08CT1#55C1-082898General cleanup0.2.00.3.02008-08CT1#55C1-082900Add signalling flows scope0.2.00.3.02008-08CT1#55C1-082901Removal of unnecessary subclauses0.2.00.3.02008-08CT1#55C1-083061Introduction to Flows0.2.00.3.02008-08CT1#55C1-083063Introduction for Registration clause0.2.00.3.02008-08CT1#55C1-083066Network initiated deregistration0.2.00.3.02008-08CT1#55C1-083218ICS UE functional Entity0.2.00.3.02008-08CT1#55C1-083320supplementary service invocation using the MSC Server enhanced for ICS0.2.00.3.02008-08CT1#55C1-083321Supplementary service invocation for an ICS UE with IMS sessions using CS bearer0.2.00.3.02008-08CT1#55C1-083322When use of Gm or I1 reference point is not possible due to VPLMN limitations0.2.00.3.02008-08CT1#55C1-083327flow showing termination to an ICS UE with UE assisted T-ADS0.2.00.3.02008-08CT1#55C1-083328Registration procedure for SCC AS0.2.00.3.02008-08CT1#55C1-083330Use of I1 for Supplementary service invocation0.2.00.3.02008-08CT1#55C1-083331Supplementary service invocation for non ICS UE when attached to an MSC Server not enhanced for ICS0.2.00.3.02008-08CT1#55C1-083333ICS using Gm termination procedures for SCC AS0.2.00.3.02008-08CT1#55C1-083334introduction text for origination, termination and session release0.2.00.3.02008-08CT1#55C1-083335ICS UE role of registration0.2.00.3.02008-08CT1#55C1-083338ICS UE role of session release0.2.00.3.02008-08CT1#55C1-083339Signalling flow for Consultative ECT using 3PCC0.2.00.3.02008-08CT1#55C1-083340Signalling Flow for Communication HOLD/RESUME0.2.00.3.02008-08CT1#55C1-083341ECT service invocation using Gm interface for ICS0.2.00.3.02008-08CT1#55C1-083342Communication HOLD/RESUME service invocation using Gm interface for ICS0.2.00.3.02008-08CT1#55C1-083403ICS UE role of call origination0.2.00.3.02008-08CT1#55C1-083404ICS UE role of call termination0.2.00.3.02008-08CT1#55C1-083323I1 Mobile Originated session using Enhanced MSC for ICS0.2.00.3.02008-08CT1#55C1-083324I1 Mobile Terminated session using Enhanced MSC for ICS0.2.00.3.02008-08CT1#55C1-083325Signalling flows for termination to an ICS UE with CS media using I1 reference point when using an MSC server enhanced for ICS and UE assisted T-ADS0.2.00.3.02008-08CT1#55Rapporteur cleanup and additions:
Fixed A.4.x references in A.4.3
Added Editor's note related to dependence on 24.293 for I1 subclauses
Several formatting issues
Changed "enhanced MSC Server" to "MSC Server enhanced for ICS"
Fixed numerous typos0.2.00.3.02008-08CT1#55Rapporteur cleanup:
Fixed additional typos
Fixed formatting of Editor's note
Fixed some more "enhanced for MSC Server" than were previously missed0.3.00.3.12008-09Version 1.0.0 created for presentation to CT-41 for information0.3.11.0.02008-10CT1#55bisC1-083878Remove duplicate reference to 24.008
Other editorial cleanup1.0.01.1.02008-10CT1#55bisC1-084017Removal of I1 interface1.0.01.1.02008-10CT1#55bisC1-084050Authorization header in MSC server1.0.01.1.02008-10CT1#55bisC1-084051Reregistration Cleanup1.0.01.1.02008-10CT1#55bisC1-084206indicating CS bearers using SDP1.0.01.1.02008-10CT1#55bisC1-084208Correction to originating session set up over Gm1.0.01.1.02008-10CT1#55bisC1-084210Selecting the contact to route to with ICS and multiple registrations1.0.01.1.02008-10CT1#55bisC1-084211Session modification initiated from originating ICS UE1.0.01.1.02008-10CT1#55bisC1-084215Aligning initial INVITE request’s Accept header field with TS 24.2291.0.01.1.02008-10CT1#55bisC1-084217Text for Overview and Functional entities clauses1.0.01.1.02008-10CT1#55bisC1-084221Proposal for Instance ID1.0.01.1.02008-10CT1#55bisC1-084407UE Assisted T-ADS1.0.01.1.02008-10CT1#55bisC1-084408SCC AS session release procedures using Gm1.0.01.1.02008-10CT1#55bisC1-084428Correction to terminating session set up over Gm1.0.01.1.02008-10CT1#55bisC1-084429Session modification initiated from originating ICS UE1.0.01.1.02008-10CT1#55bisC1-084431Correction of ECT procedure1.0.01.1.02008-10CT1#55bisC1-084443Signalling flows for CW using Gm1.0.01.1.02008-10CT1#55bisC1-084444Clarification of P-Visited-Network-ID usage for MSC Server1.0.01.1.02008-10CT1#55bisRapporteur cleanup and editorials:
Typos
Correct list numbering (letters, then arabic numerals) (see 7.4.2)
Fix headings for tables in A.4.3
Fix headings for tables in A.4.4
TADS --> T-ADS
renumber subclauses
renumber references
media --> voice
Gm interface --> Gm reference point
2008-10Rapporteur: additional editorials based on received comments1.1.01.1.12008-11CT1#56C1-084685Indication of 199 (Early Dialog Terminated) support in ICS call flows1.1.11.2.02008-11CT1#56C1-084698MSC Server enhanced for ICS procedures during call release1.1.11.2.02008-11CT1#56C1-084738minor 24.292 cleanup (XML)1.1.11.2.02008-11CT1#56C1-084787ECT Clean Up1.1.11.2.02008-11CT1#56C1-085021Cleanup and fixes for 24.2921.1.11.2.02008-11CT1#56C1-085022Cleanup of feature tag name1.1.11.2.02008-11CT1#56C1-085107clarification of the use of PSI DN for ICS1.1.11.2.02008-11CT1#56C1-085108ICS procedures for Communication Waiting when using Gm service control1.1.11.2.02008-11CT1#56C1-085210Restructure of session modification session1.1.11.2.02008-11CT1#56C1-085211Addition to the procedure due to changes in the IETF drafts1.1.11.2.02008-11CT1#56C1-085212Clarification of the SDP answer for ECT1.1.11.2.02008-11CT1#56C1-085214Conferencing Procedure1.1.11.2.02008-11CT1#56C1-085215Feature tag clean up1.1.11.2.02008-11CT1#56C1-085217Signalling flow corrections1.1.11.2.02008-11CT1#56C1-0852223GPP2 Alignment1.1.11.2.02008-11CT1#56C1-085225Introducing Communication Waiting via the MSC Server enhanced for ICS1.1.11.2.02008-11CT1#56C1-085227UE executed T-ADS1.1.11.2.02008-11CT1#56C1-085228Service Configuration for ICS1.1.11.2.02008-11CT1#56C1-085229Removal of IMS XML body from MSC Server procedures1.1.11.2.02008-11CT1#56C1-085232Several Minor ICS Corrections1.1.11.2.02008-11CT1#56C1-085233using Garcia in modification procedures1.1.11.2.02008-11CT1#56C1-085234call flow to illustrate the example of CS UE origination when using an MSC server not enhanced for ICS1.1.11.2.02008-11CT1#56C1-085235clarification on the use of 24.228 in ICS1.1.11.2.02008-11CT1#56C1-085441MSC Server enhanced for ICS procedures during termination1.1.11.2.02008-11CT1#56C1-085444Completion of Instance ID procedures1.1.11.2.02008-11CT1#56C1-085447Removing the Inactive Calls1.1.11.2.02008-11CT1#56C1-085463SCC AS cleanup1.1.11.2.02008-11CT1#56C1-085479SCC AS behaviour when receiving BYE1.1.11.2.02008-11Rapporteur editorial fixes:
- Editorials (typos)
- header "field"
- Editor's notes cleanup2008-11Version 2.0.0 created for presentation to CT#42 for approval1.2.02.0.02008-12CT#42Version 8.0.0 created after approval in CT#422.0.08.0.02009-03CT#43CP-0901500002Deletion of editor’s note in subclause 8.4.28.0.08.1.02009-03CT#43CP-09015000042Treatment of Accept-Contact header8.0.08.1.02009-03CT#43CP-09015000072C-MSISDN usage for ICS8.0.08.1.02009-03CT#43CP-09015000081ICS UE behavior when offered a voice media in both CS and PS domains8.0.08.1.02009-03CT#43CP-09015000092Orig anchoring VCC8.0.08.1.02009-03CT#43CP-09015000101SDP for UE assisted T-ADS8.0.08.1.02009-03CT#43CP-0901500013Update to references in 24.2928.0.08.1.02009-03CT#43CP-09015000141Corrections to ICS origination call flows8.0.08.1.02009-03CT#43CP-09015000151Definition of term CS media8.0.08.1.02009-03CT#43CP-09015000161Conveying ICS registration information using 3rd party Registration and GRUU/ICSI/IARI corrections8.0.08.1.02009-03CT#43CP-09015000172SCC AS Transparently passing Contact To and From headers8.0.08.1.02009-03CT#43CP-09015000182Use of GRUU by ICS UE8.0.08.1.02009-03CT#43CP-09015000192Using forking method for ICS UE request CS bearer8.0.08.1.02009-06CT#44CP-0904190022Reference Update draft-ietf-mmusic-sdp-cs8.1.08.2.02009-06CT#44CP-09041900232T-ADS with reroute to CS8.1.08.2.02009-06CT#44CP-09041900271Clarification of ICS de-registration procedure8.1.08.2.02009-06CT#44CP-09041900322Clarification of PVI when used at registration8.1.08.2.02009-06CT#44CP-09041900332Clarification to CS bearer requested by the ICS UE8.1.08.2.02009-06CT#44CP-09041900341Clarifification to URI and address assignments8.1.08.2.02009-06CT#44CP-09041900381Add missing information to termination call flows using Gm8.1.08.2.02009-06CT#44CP-09041900392Correction of enhanced MSC Server for ICS procedures8.1.08.2.02009-06CT#44CP-09043300243Introduction of I1 Mobile Originated session using Enhanced MSC for ICS8.2.09.0.02009-06CT#44CP-09043300253Introduction of I1 Mobile Terminated session using Enhanced MSC for ICS8.2.09.0.02009-06CT#44CP-09043300263Introduction of flow showing terminating to an ICS UE with UE assisted T-ADS8.2.09.0.02009-09CT#45CP-0906840040Fixing I1 flows9.0.09.1.02009-09CT#45CP-09067100413SCC AS selection of PS Access network - Use of Accept-Contact9.0.09.1.02009-09CT#45CP-09067200521Correction of UE TADS behavior in presence of Voice_Domain_Preference leaf9.0.09.1.02009-09CT#45CP-09067100541Correction of e164-address portion usage9.0.09.1.02009-09CT#45CP-09068700561Path header from MSC server enhanced for ICS9.0.09.1.02009-09CT#45CP-0906710057Removing editor's note in subclause A.3.19.0.09.1.02009-09CT#45CP-09068400581Corrections to information flow for termination to an ICS UE using I1 with UE assisted T-ADS9.0.09.1.02009-09CT#45CP-0906710062Correcting references for ICS9.0.09.1.02009-12CT#46CP-09091500643Correction to take into account voice Domain Selection for Iu mode9.1.09.2.02009-12CT#46CP-0909280069Update of CW XML in flows9.1.09.2.02009-12CT#46CP-0909130071Updating of GRUU references9.1.09.2.02009-12CT#46CP-09092500722ICS UE using I19.1.09.2.02009-12CT#46CP-09092500732SCC AS for service control over I19.1.09.2.02009-12CT#46CP-09092500741Call control over I1 and voice over CS9.1.09.2.02009-12CT#46CP-09091300761Enabling ICS functionality9.1.09.2.02009-12CT#46CP-09092500792Introduction I1 BYE interworking9.1.09.2.02009-12CT#46CP-09092800802Video media over CS bearer9.1.09.2.02009-12CT#46CP-0909130082Specification of Circuit Switched SDP contents for ICS9.1.09.2.02010-03CT#47CP-10013700831Scope9.2.09.3.02010-03CT#47CP-10013700841Alias tel URI9.2.09.3.02010-03CT#47CP-10013700851Clean up of linkage between I1 specifications9.2.09.3.02010-03CT#47CP-10013700861Clarification on SCC AS PSI DN9.2.09.3.02010-03CT#47CP-10013700871TADS selection of I19.2.09.3.02010-03CT#47CP-10013700891Enable use of I1 when the home operator has configured it to do so9.2.09.3.02010-03CT#47CP-10013700902Inclusion of Accept / Reject contact capabilities for I1 protocol9.2.09.3.02010-03CT#47CP-1001370091I1 SIP Error cause handling9.2.09.3.02010-03CT#47CP-10012400962Terminations with acceptance only of non-audio media. 9.2.09.3.02010-03CT#47CP-10023200947Correcting T-ADS9.2.09.3.02010-03CT#47editorial cleanup by MCC9.2.09.3.02010-06CT#48CP-10034601021ICS UE handling clarification9.3.09.4.02010-06CT#48CP-10041801032Clarification of I1 call control handling9.3.09.4.02010-06CT#48CP-10034601051Add cases to definition of "failure to access the CS domain"9.3.09.4.02010-06CT#48CP-10035701061Rationalisation of I1 support in 3GPP TS 24.2929.3.09.4.02010-06CT#48CP-1003570107Removal of editor's notes relating to multiple sessions9.3.09.4.02010-06CT#48CP-10035701081Revision of flow for ICS UE origination when using I1 interface9.3.09.4.02010-06CT#48CP-10035701091Revision of flow for termination to an ICS UE with CS media using I1 reference point9.3.09.4.02010-06CT#48CP-1003460112Obsolete references9.3.09.4.02010-06CT#48CP-10035701131I1 EN resolution9.3.09.4.02010-06CT#48CP-10034601162IMS Voice over PS session indicators and ISR9.3.09.4.02010-06CT#48CP-10034601181Clearly specifying the conditions for ICS UE VoIP terminations9.3.09.4.02010-06CT#48CP-10035701221Editorial corrections to I1 subclauses9.3.09.4.02010-09CT#49CP-10049401294Correcting indication that aspects of the session description are not acceptable9.4.09.5.02010-09CT#49CP-10049401352Clarifications of SCC AS termination procedures.9.4.09.5.02010-09CT#49CP-1005030144Clarification of timer handling9.4.09.5.02010-09CT#49CP-10050301481I1 inconsistencies9.4.09.5.02010-12CT#50CP-10074501552In-dialog request targeted for SCC AS9.5.09.6.02010-12CT#50CP-10073801682Clarification of the Hold/Resume procedure9.5.09.6.02010-12CT#50CP-1007450170Clarification of the PSI DN usage9.5.09.6.02010-12CT#50CP-1007380173Correction for the reregistration procedure9.5.09.6.02011-03CT#51CP-11017701751Record-Rout at SCC AS – MO calls9.6.09.7.02011-03CT#51CP-1101770177Record-Rout at SCC AS – MT calls9.6.09.7.02011-03CT#51CP-11017001812Clarification for the terminating procedure when using MSC server enhanced for ICS9.6.09.7.02011-03CT#51CP-1101770183Signalling flow correction for the terminating case when using I1 reference point9.6.09.7.02011-03CT#51CP-1101750185Removal of confusing duplicate text for I1.9.6.09.7.02011-03CT#51CP-11017401904Inclusion of Network TADs functionality9.6.09.7.02011-06CT#52CP-11044701991MSC sends DeREGISTER9.7.09.8.02011-09CT#53CP-11065302032Correction of ccap SDP attribute9.8.09.9.02011-09CT#53CP-11066802051MSC server and initial registration9.8.09.9.02011-12CT#54CP-1108540208Inclusion of media feature tag ASN.1 identifiers for g.3gpp.ics and g.3gpp.accesstype9.9.09.10.02012-06CT#56CP-12028702131Reference update: draft-liess-dispatch-alert-info-urns9.10.09.11.02012-06CT#56CP-12028702193Updating Internet Draft references used by ICS9.10.09.11.02012-09CT#57CP-12056802251Correcting CS SDP usage and updating media capabilities draft reference9.11.09.12.02012-12CT#58CP-12077502341Updating MMUSIC draft references for TADS9.12.09.13.02012-12CT#58CP-12077502391Conference support in ICS MSC incomplete9.12.09.13.02013-03CT#59CP-13009202441Updating MMUSIC draft references for TADS9.13.09.14.02013-06CT#60CP-13022202572Updating MMUSIC draft references for TADS9.14.09.15.02013-06CT#60CP-13022202631Correction on MSC unsuccessful registration attempt9.14.09.15.02013-12CT#62CP-13072102761Reference update: RFC 7006 (draft-ietf-mmusic-sdp-miscellaneous-caps)9.15.09.16.02013-12CT#62CP-1307210282Reference Update: draft-ietf-salud-alert-info-urns9.15.09.16.02014-06CT#64CP-14029403021Removal of CDIVN9.16.09.17.02014-06CT#64CP-14029403082Updating CS-SDP draft reference to RFC 7195 and correcting UE-TADS procedures9.16.09.17.02015-06CT#68CP-15028803241Reference Update: RFC7462 (alert-info urns)9.17.09.18.0
Change history
DateMeetingTDocCRRevCatSubject/CommentNew version2016-09CT#73CP-16048203431ARemoval of obsolete editor's note9.19.0








 STYLEREF ZA 3GPP TS 24.292 V9.19.0 (2016-09)
 PAGE 177
 STYLEREF ZGSM Release 9


3GPP