Ts 13422905v160600p

ETSI TS 134 229-5 V16.6.
0 (2023-04)
TECHNICAL SPECIFICATION
5G;
Internet Protocol (IP) multimedia call control protocol based on
Session Initiation Protocol (SIP)
and Session Description Protocol (SDP);
User Equipment (UE) conformance specification;
Part 5: Protocol conformance specification using
5G System (5GS)
(3GPP TS 34.229-5 version 16.6.0 Release 16)
3GPP TS 34.229-5 version 16.6.0 Release 16 1 ETSI TS 134 229-5 V16.6.0 (2023-04)
Reference
RTS/TSGR-0534229-5vg60
Keywords
5G
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - APE 7112B

Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871
Important notice
The present document can be downloaded from:
https://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability

The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.
Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2023.
All rights reserved.
ETSI
Intellectual Property Rights

Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the
oneM2M Partners. GSM® and the GSM logo are trademarks registered and owned by the GSM Association.
Legal Notice
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found under https://webapp.etsi.org/key/queryform.asp.
Modal verbs terminology

In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
Contents
Intellectual Property Rights ................................................................................................................................2
Legal Notice .......................................................................................................................................................2
Modal verbs terminology....................................................................................................................................2
Foreword.............................................................................................................................................................7
Introduction ........................................................................................................................................................8
1 Scope ........................................................................................................................................................9
2 References ................................................................................................................................................9
3 Definitions of terms, symbols and abbreviations ...................................................................................12
3.1 Terms................................................................................................................................................................ 12
3.2 Symbols ............................................................................................................................................................ 12
3.3 Abbreviations ................................................................................................................................................... 12
4 Overview ................................................................................................................................................12
4.1 Test Methodology............................................................................................................................................. 12
4.1.1 Testing of optional functions and procedures ............................................................................................. 12
4.2 Implicit Testing ................................................................................................................................................ 12
4.3 Conformance Requirements ............................................................................................................................. 12
5 Reference Conditions .............................................................................................................................12
5.1 General ............................................................................................................................................................. 12
5.2 Generic setup procedures ................................................................................................................................. 13
5.3 Transport protocols applied .............................................................................................................................. 13
6 Registration ............................................................................................................................................14
6.1 Initial Registration / 5GS .................................................................................................................................. 14
6.2 Initial Registration Failures / 5GS .................................................................................................................... 25
6.3 Re-Registration Scenarios / 5GS ...................................................................................................................... 29
6.4 De-Registration Scenarios / 5GS ...................................................................................................................... 36
6.5 Void .................................................................................................................................................................. 43
6.6 Re-Registration after capability update / 5GS .................................................................................................. 44
6.7 Authentication / MAC Parameter Invalid / Only two consecutive invalid challenges / 5GS ........................... 46
6.8 Authentication / Security-Server missing / SQN out of range / 5GS ............................................................... 50
6.9 Subscription / 503 Service Unavailable / 5GS ................................................................................................. 54
7 Call Control ............................................................................................................................................56
7.1 MTSI MO Voice Call / 503 Service Unavailable / 5GS................................................................................... 56
7.2 MTSI MO Voice Call / 504 Server Time-out / 5GS ........................................................................................ 59
7.4 MTSI MO Voice Call with preconditions at both originating and terminating UE / 5GS ............................... 62
7.4a MTSI MO Voice Call with preconditions at both originating UE and terminating UE / Default
Configuration / 5GS ......................................................................................................................................... 72
7.5 MTSI MO Voice Call without preconditions at both originating UE and terminating UE / 5GS .................... 75
7.6 MTSI MT Voice Call with preconditions at both originating UE and terminating UE / 5GS.......................... 78
7.6a MTSI MT Voice Call with preconditions at both originating UE and terminating UE / Default
Configuration / 5GS ......................................................................................................................................... 82
7.7 MTSI MT Voice Call without preconditions at both originating UE and terminating UE / 5GS .................... 84
7.8 MTSI MT Voice Call without preconditions at originating UE and with preconditions at terminating UE
/ 5GS................................................................................................................................................................. 87
7.9 MTSI MT Voice Call with preconditions at originating UE and without preconditions at terminating UE
/ 5GS................................................................................................................................................................. 89
7.10 MTSI MT Voice call without preconditions and without SDP offer in MT INVITE / 5GS ............................ 91
7.11 MTSI MT Voice call without preconditions at terminating UE and originating UE requiring them / 5GS ..... 99
7.12 MTSI MO Voice Call with preconditions at originating UE and without preconditions at terminating
UE / 5GS ........................................................................................................................................................ 101
7.13 MTSI MT Voice Call with RTCP disabled / 5GS .......................................................................................... 103
7.14 MTSI MO Video Call with preconditions at both originating and terminating UE / 5GS ............................. 105
ETSI
7.15 MTSI MO Video call without preconditions at both originating UE and terminating UE / 5GS ................... 109
7.16 MTSI MT Video call with preconditions at both originating UE and terminating UE / 5GS ........................ 114
7.17 MTSI MT Video call without preconditions at both originating UE and terminating UE / 5GS ................... 120
7.18 MTSI MO Voice Call / EVS / AMR-WB / 5GS ............................................................................................ 125
7.19 MTSI MT Voice Call / EVS / AMR-WB IO mode / 5GS .............................................................................. 140
7.20 MTSI MO Voice Call / add video and remove video / with preconditions at both originating UE and
terminating UE / 5GS ..................................................................................................................................... 147
7.21 MTSI MO Voice Call / add video and remove video / without preconditions at both originating UE and
7.22 MTSI MT Voice Call / add video and remove video / with preconditions at both originating UE and
7.23 MTSI MT Voice Call / add video and remove video / without preconditions at both originating UE and
7.24 MTSI MT Voice Call / Forking / UE receives CANCEL request for a forked MT voice call / 5GS ............. 176
7.24a MTSI MO Voice Call / Forking / UE receives two preliminary responses and one early dialog
termination / 5GS ........................................................................................................................................... 179
7.24b MTSI MO Voice Call / Forking / UE receives two preliminary responses and one final response / 5GS ..... 182
7.25 MTSI MT Voice Call without SDP offer in INVITE / 5GS ........................................................................... 186
7.26 Mobile Originating CAT / Forking Model / MO Voice Call / 5GS ............................................................... 193
7.27 Session Timer / MO Voice Call / UE is able to refresh the session / 5GS ..................................................... 198
7.28 Session Timer / MO Voice Call / Remote end is refresher / 5GS .................................................................. 203
7.29 Session Timer / MO Voice Call / Remote end does not support Session Timer / 5GS .................................. 206
7.30 Session Timer / MO Voice Call / Remote end supports but does not use Session Timer / 5GS .................... 210
7.31 Session Timer / MT Voice Call / Remote end supports but does not send Session-Expires / 5GS ................ 213
7.32 Session Timer / MT Voice Call / Remote end sends Session-Expires but does not choose refresher /
5GS ................................................................................................................................................................. 216
7.33 Session Timer / MT Voice Call / Remote end chooses UE as refresher / 5GS .............................................. 219
7.34 Session Timer / MT Voice Call / Remote end does not support Session Timer / 5GS .................................. 222
8 Supplementary Services .......................................................................................................................225
8.1 Originating Identification Presentation / Configuration / 5GS ....................................................................... 225
8.2 Originating Identification Restriction / Configuration / 5GS ......................................................................... 229
8.3 Originating Identification Restriction / Signalling / 5GS ............................................................................... 231
8.4 Terminating Identification Presentation / Configuration / 5GS...................................................................... 233
8.5 Terminating Identification Restriction / Configuration / 5GS ........................................................................ 235
8.6 Terminating Identification Restriction / Signalling / 5GS .............................................................................. 237
8.7 Communication Forwarding Unconditional / Configuration / 5GS ............................................................... 239
8.8 Communication Forwarding Unconditional / Signalling / 5GS ..................................................................... 242
8.9 Communication Forwarding on Not Logged-in / Configuration / 5GS .......................................................... 245
8.10 Void ................................................................................................................................................................ 248
8.11 Communication Forwarding on Busy / Configuration / 5GS ......................................................................... 248
8.12 Void ................................................................................................................................................................ 251
8.13 Communication Forwarding on Subscriber Not Reachable / Configuration / 5GS ........................................ 251
8.14 Void ................................................................................................................................................................ 254
8.15 Communication Forwarding on No Reply / Configuration / 5GS .................................................................. 254
8.16 Void ................................................................................................................................................................ 258
8.17 Barring of All Incoming Calls / Configuration / 5GS .................................................................................... 258
8.18 Barring of All Incoming Calls / except for a specific user / Configuration / 5GS .......................................... 261
8.19 Barring of All Incoming Calls from anonymous users / Configuration / 5GS ............................................... 266
8.20 Void ................................................................................................................................................................ 269
8.21 Barring of all Outgoing Calls / Configuration / 5GS ...................................................................................... 269
8.22 Barring of Outgoing International Calls / Configuration / 5GS ..................................................................... 273
8.23 Barring of Outgoing International Calls / ex Home Country / Configuration / 5GS ...................................... 277
8.24 Barring of Outgoing International Calls / When Roaming / Configuration / 5GS ......................................... 280
8.25 Barring of Incoming Calls / When Roaming / Configuration / 5GS .............................................................. 284
8.26 MO Voice Call Hold without announcement / 5GS ....................................................................................... 287
8.27 MO Video Call Hold without announcement / 5GS ....................................................................................... 290
8.28 MT Voice Call Hold without announcement / 5GS ....................................................................................... 294
8.29 MT Video Call Hold without announcement / 5GS ....................................................................................... 296
8.30 Subscription to the MWI event package / 5GS .............................................................................................. 299
8.31 Creating and leaving a conference / 5GS ....................................................................................................... 303
8.32 Inviting user to conference by sending a REFER request to the conference focus / 5GS .............................. 305
ETSI
8.33 Inviting user to conference by sending a REFER request to the conference focus / Video / 5GS ................. 307
8.34 Three way session creation / Voice / 5GS ...................................................................................................... 310
8.35 Three way session creation / Video / 5GS ...................................................................................................... 316
8.36 MO Voice Call Explicit Communication Transfer / Consultative Call Transfer / 5GS ................................. 322
8.37 Communication Waiting and answering the voice call / 5Gs ......................................................................... 328
8.38 Communication Waiting and cancelling the voice call / 5GS ........................................................................ 332
8.39 GBA Authentication / 5GS ............................................................................................................................. 334
8.39a HTTP Digest Authentication / 5GS ................................................................................................................ 336
8.40 User initiated USSI / 5GS .............................................................................................................................. 338
8.41 Communication Forwarding on No Reply: MO Voice Call initiation with preconditions ............................. 342
9 SMS ......................................................................................................................................................347
9.1 Mobile Originating SMS / 5GS ...................................................................................................................... 347
9.2 Mobile Terminating SMS / 5GS..................................................................................................................... 352
9.3 Mobile Originating Concatenated SMS / 5GS ............................................................................................... 354
9.4 Mobile Terminating Concatenated SMS / 5GS .............................................................................................. 365
9.5 Mobile Originating SMS / RP-ERROR / 5GS ............................................................................................... 375
10 Emergency Calls ..................................................................................................................................380
10.1 Emergency Call with emergency registration / Success / Location information available / 5GS .................. 380
10.2 Emergency Call with emergency registration / Success / Location information not available / 5GS ............ 384
10.3 Emergency call with emergency registration / Emergency SIP signalling and media in parallel with
another ongoing IM CN subsystem signalling and media / 5GS .................................................................... 388
10.4 Non-UE detectable emergency call / IM CN sends a 1xx response / UE geographical location
information available or not / 5GS ................................................................................................................. 393
10.5 Void ................................................................................................................................................................ 397
10.6 Non-UE detectable emergency call / IM CN sends 380 with an Alternative Service / Previous
emergency IMS registration not expired / 5GS .............................................................................................. 397
10.7 Void ................................................................................................................................................................ 401
10.8 Void ................................................................................................................................................................ 401
10.9 Emergency call without emergency registration / UE credentials are not accepted / 5GS ............................. 401
10.10 Emergency call without emergency registration / Failure of registration / Rejected by 403(Forbidden) ....... 404
10.11 Void ................................................................................................................................................................ 409
10.12 User-initiated emergency reregistration / UE has emergency related ongoing dialog / 5GS ......................... 409
10.13 User-initiated emergency reregistration / User initiates an emergency call / 5GS ......................................... 416
10.14 In parallel emergency and non-emergency registrations / 5GS ...................................................................... 424
10.15 Void ................................................................................................................................................................ 426
11 eCall over IMS .....................................................................................................................................427
11.1 eCall over IMS / Manual initiation / Normal registration / Emergency registration / Success / 200 OK
with ACK / 5GS ............................................................................................................................................. 427
11.2 eCall over IMS / Automatic initiation / Normal registration / Emergency registration / Success / 200 OK
with ACK / 5GS ............................................................................................................................................. 429
11.3 432
11.4 eCall over IMS / Manual initiation / MSD transfer and 200 OK with ACK / SIP INFO for MSD Update
/ Success / 5GS ............................................................................................................................................... 432
11.5 eCall over IMS / Automatic initiation / MSD transfer and 200 OK with ACK / SIP INFO request for
MSD update / Success / 5GS .......................................................................................................................... 435
11.6 eCall over IMS / Automatic initiation / MSD transfer and 200 OK with ACK / SIP INFO request for
unsupported MSD / UE indicates unsuccessful in SIP INFO / 5GS............................................................... 439
Annex A (normative): Generic Test Procedures .............................................................................443

A.1 Introduction ..........................................................................................................................................443
A.2 IMS Registration / 5GS ........................................................................................................................443
A.3 IMS Emergency Registration / 5GS .....................................................................................................445
A.4 MTSI MO Voice Call / 5GS.................................................................................................................446
A.4.1 MTSI MO Voice Call / with preconditions / 5GS .......................................................................................... 446
A.4.1a MTSI MO Voice Call / Default Configuration / 5GS .................................................................................... 454
A.4.2 MTSI MO Voice Call / without preconditions / 5GS ..................................................................................... 459
A.5 MTSI MT Voice Call / 5GS .................................................................................................................466
ETSI
A.5.1 MTSI MT Voice Call / with preconditions / 5GS .......................................................................................... 466

A.5.1a MTSI MT Voice Call / Default Configuration / 5GS ..................................................................................... 471
A.5.2 MTSI MT Voice Call / without preconditions / 5GS ..................................................................................... 477
A.6 IMS Emergency Voice Call / 5GS .......................................................................................................481
A.7 MO Release of Voice or Video Call / 5GS ..........................................................................................483
A.8 MT Release of Voice or Video Call / 5GS ...........................................................................................484
A.9 EPS Fallback for Voice Call / 5GS ......................................................................................................485
A.9.1 EPS Fallback for Voice Call / steps before fallback / 5GS ............................................................................ 485
A.9.2 EPS Fallback for Voice Call / steps after fallback / 5GS ............................................................................... 487
A.10 Default handling of PUBLISH requests ...............................................................................................490
A.11 Mobile Initiated De-Registration / 5GS ...............................................................................................491
A.12 IMS Re-Registration / 5GS ..................................................................................................................494
A.13 IMS MO SMS / 5GS ............................................................................................................................495
A.14 IMS MT SMS / 5GS.............................................................................................................................496
A.15 MTSI MO Video Call / 5GS ................................................................................................................497
A.15.1 MTSI MO Video Call / with preconditions / 5GS .......................................................................................... 497
A.15.1a MTSI MO Video Call / Default Configuration / 5GS .................................................................................... 506
A.15.2 MTSI MO Video Call / without preconditions / 5GS ..................................................................................... 515
A.16 MTSI MT Video Call / 5GS .................................................................................................................520
A.16.1 MTSI MT Video Call / with preconditions / 5GS .......................................................................................... 520
A.16.2 MTSI MT Video Call / without preconditions / 5GS ..................................................................................... 530
A.17 Putting a MTSI speech call to hold or to resume the call from the UE / 5GS......................................533
A.18 Putting a MTSI speech call to hold or to resume the call from the SS / 5GS ......................................535
A.19 MTSI conference creation / 5GS ..........................................................................................................537
A.20 Inviting user to conference by sending a REFER request to the conference focus / 5GS ....................539
A.21 Activation and deactivation of Supplementary Services / 5GS............................................................540
A.22 GAA XCAP authentication ..................................................................................................................545
A.23 eCall Setup and MSD Update / 5GS ....................................................................................................548
A.24 UE putting a Video Call on hold or resume the call / 5GS ..................................................................550
A.25 Video Conference Creation / 5GS ........................................................................................................552
A.26 Inviting user to Video conference by sending a REFER request to the conference focus / 5GS .........554
A.27 Leaving a conference / 5GS .................................................................................................................556
A.28 SS putting a Video Call on hold or resume the call / 5GS ...................................................................557
Annex B (informative): Change history .............................................................................................559
History ............................................................................................................................................................572
ETSI
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.
In the present document, certain modal verbs have the following meanings:
shall indicates a mandatory requirement to do something
shall not indicates an interdiction (prohibition) to do something
The constructions "shall" and "shall not" are confined to the context of normative provisions, and do not appear in
Technical Reports.
The constructions "must" and "must not" are not used as substitutes for "shall" and "shall not". Their use is avoided
insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced,
non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a
referenced document.
should indicates a recommendation to do something
should not indicates a recommendation not to do something
may indicates permission to do something
need not indicates permission not to do something
The construction "may not" is ambiguous and is not used in normative elements. The unambiguous constructions
"might not" or "shall not" are used instead, depending upon the meaning intended.
can indicates that something is possible
cannot indicates that something is impossible
The constructions "can" and "cannot" shall not to be used as substitutes for "may" and "need not".
will indicates that something is certain or expected to happen as a result of action taken by an agency
the behaviour of which is outside the scope of the present document
will not indicates that something is certain or expected not to happen as a result of action taken by an
agency the behaviour of which is outside the scope of the present document
might indicates a likelihood that something will happen as a result of action taken by some agency the
behaviour of which is outside the scope of the present document
ETSI
might not indicates a likelihood that something will not happen as a result of action taken by some agency
the behaviour of which is outside the scope of the present document
In addition:
is (or any other verb in the indicative mood) indicates a statement of fact
is not (or any other negative verb in the indicative mood) indicates a statement of fact
The constructions "is" and "is not" do not indicate requirements.
Introduction
The present document is the fifth part of a multi-part conformance specification valid for 3GPP Release 15 and later
releases:
3GPP TS 34.229-1 [2]: "Internet Protocol (IP) multimedia call control protocol based on Session Initiation
Protocol (SIP) and Session Description Protocol (SDP); User Equipment (UE) conformance specification; Part 1:
Protocol conformance specification".
Implementation Conformance Statement (ICS) proforma specification".
Abstract Test Suites (ATS)".
Enabler for IP multimedia applications testing".
3GPP TS 34.229-5 (the present document): "Internet Protocol (IP) multimedia call control protocol based
on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); User Equipment (UE)
conformance specification; Part 5: Protocol conformance specification using 5G System (5GS)".
NOTE 1: The ATS is written in a standard testing language, TTCN-3, as defined in ETSI ES 201 873, Parts 1 to 3
[8], [9] and [10].
NOTE 2: Further information on testing can be found in ETSI ETS 300 406 [11] and ISO/IEC 9646-1 [12].
For at least a minimum set of services, the prose descriptions of test cases will have a matching detailed test case
implemented in TTCN-3 (and provided in 3GPP TS 34.229-3 [4]).
ETSI
1 Scope
The present document specifies the protocol conformance testing for the User Equipment (UE) supporting the Internet
Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description
Protocol (SDP) when using the 5G System (5GS).
This is the fifth part of a multi-part test specification. The following information can be found in this part:
- the overall test structure;
- the test configurations;
- the conformance requirement and reference to the core specifications;
- the test purposes; and
- the test procedure.
The following information relevant to testing can be found in accompanying specifications:
- Implementation Conformance Statement (ICS) pro-forma and the applicability of each test case [3].
The present document is valid for UE implemented according to 3GPP Releases starting from Release 15 up to the
Release indicated on the cover page of the present document.
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 34.229-1: "Internet Protocol (IP) multimedia call control protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol (SDP); User Equipment (UE)
conformance specification; Part 1: Protocol conformance specification".
conformance specification; Part 2: Implementation Conformance Statement (ICS) proforma
specification".
conformance specification; Part 3: Abstract Test Suites (ATS)".
conformance specification; Part 4: Enabler for IP multimedia applications testing".
[6] IETF RFC 3261: "SIP: Session Initiation Protocol".
[7] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP)
and Session Description Protocol (SDP); Stage 3".
ETSI
[8] ETSI ES 201 873-1: "Methods for Testing and Specification (MTS); The Testing and Test Control
Notation version 3; Part 1: TTCN-3 Core Language".
[9] ETSI ES 201 873-2: "Methods for Testing and Specification (MTS); The Testing and Test Control
Notation version 3; Part 2: TTCN-3 Tabular Presentation Format (TFT)".
[10] ETSI TR 201 873-3: "Methods for Testing and Specification (MTS); The Testing and Test Control
Notation version 3; Part 3: TTCN-3 Graphical Presentation Format (GFT)".
[11] ETSI ETS 300 406: "Methods for testing and Specification (MTS); Protocol and profile
conformance testing specifications; Standardization methodology".
[12] ISO/IEC 9646-1: "Information technology - Open systems interconnection - Conformance testing
methodology and framework - Part 1: General concepts".
[13] ISO/IEC 9646-7: "Information technology - Open systems interconnection - Conformance testing
methodology and framework - Part 7: Implementation Conformance Statements".
[14] 3GPP TS 24.341: "Support of SMS over IP networks; Stage 3".
[15] IETF RFC 3310: "Hypertext Transfer Protocol (HTTP) Digest Authentication Using
Authentication and Key Agreement (AKA)".
[16] 3GPP TS 33.203: "3G security;Access security for IP-based services".
[17] IETF RFC 3329: "Security Mechanism Agreement for the Session Initiation Protocol (SIP)".
[18] IETF RFC 3680: "A Session Initiation Protocol (SIP) Event Package for Registrations".
[19] 3GPP TS 23.501: "System Architecture for the 5G System; Stage 2".
[20] 3GPP TS 24.501: "Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3".
[21] 3GPP TS 38.508-1: "5GS; User Equipment (UE) conformance specification; Part 1: Common test
environment".
[22] 3GPP TS 27.007: "AT command set for User Equipment (UE)".
[23] IETF RFC 2617: "HTTP Authentication: Basic and Digest Access Authentication".
[24] 3GPP TS 23.040: "Technical realization of the Short Message Service (SMS)".
[25] 3GPP TS 24.011: "Point-to-Point (PP) Short Message Service (SMS) support on mobile radio
interface".
[26] 3GPP TS 24.237: "IP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem
(IMS) Service Continuity".
[27] 3GPP TS 23.003: "Numbering, addressing and identification".
[28] IETF RFC 6665: “SIP-Specific Event Notification”.
[29] IETF RFC 3312: “Integration of Resource Management and SIP”.
[30] IETF RFC 3262: “Reliability of Provisional Responses in the Session Initiation Protocol (SIP)”.
[31] GSMA PRD NG.114: "IMS Profile for Voice, Video and Messaging over 5GS".
[32] 3GPP TS 24.610: "Communication HOLD (HOLD) using IP Multimedia (IM) Core Network
(CN) subsystem".
[33] 3GPP TS 26.114: "IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and
interaction".
[34] 3GPP TS 24.606: "Message Waiting Indication (MWI) using IP Multimedia (IM) Core Network
(CN) subsystem".
ETSI
[35] 3GPP TS 24.147: "Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem".
[36] 3GPP TS 24.629: "Explicit Communication Transfer (ECT) using IP Multimedia (IM) Core
Network (CN) subsystem".
[37] IETF RFC 4028: "Session Timers in the Session Initiation Protocol (SIP)".
[38] IETF RFC 4566: "SDP: Session Description Protocol".
[39] IETF RFC 7462: "URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP) ".
[40] IETF RFC 3891: "The Session Initiation Protocol (SIP) "Replaces" Header".
[41] IETF RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax".
[42] IETF RFC 3326: "The Reason Header Field for the Session Initiation Protocol (SIP)".
[43] 3GPP TS 24.109: "Bootstrapping interface (Ub) and network application function interface (Ua);
Protocol details".
[44] 3GPP TS 33.220: "Generic Authentication Architecture (GAA); Generic Bootstrapping

Architecture".
[45] IETF RFC 4825: "The Extensible Markup Language (XML) Configuration Access Protocol
(XCAP)".
[46] IETF RFC 2616: "Hypertext Transfer Protocol -- HTTP/1.1".
[47] IETF RFC 3310: "Hypertext Transfer Protocol (HTTP) Digest Authentication Using
Authentication and Key Agreement (AKA)".
[48] 3GPP TS 38.509: "5GS; Special conformance testing functions for User Equipment (UE)".
[49] IETF RFC 6228: "Session Initiation Protocol (SIP) Response Code for Indication of Terminated
Dialog".
[50] IETF RFC 3323: "A Privacy Mechanism for the Session Initiation Protocol (SIP)".
[51] IETF RFC 3325: "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks".
[52] 3GPP TS 38.508-2: "5GS; User Equipment (UE) conformance specification; Part 2: Common
Implementation Conformance Statement (ICS) proforma".
[53] 3GPP TS 36.523-3: "LTE; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Packet Core (EPC); User Equipment (UE) conformance specification; Part 3: Test suites".
ETSI
3 Definitions of terms, symbols and abbreviations
3.1 Terms
Void
3.2 Symbols
Void
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in 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].
SS System Simulator
4 Overview
4.1 Test Methodology

4.1.1 Testing of optional functions and procedures
Any function or procedure which is optional, as indicated in the present document may be subject to a conformance test
if it is implemented in the UE.
A declaration by the apparatus supplier (Implementation Conformance Statement (ICS)) is used to determine whether
an optional function/procedure has been implemented (see ISO/IEC 9646-7 [13] for general information about ICS).
4.2 Implicit Testing

For some 3GPP signalling and protocol features conformance is not verified explicitly in the present document. This
does not imply that correct functioning of these features is not essential, but that these are implicitly tested to a
sufficient degree in other tests.
4.3 Conformance Requirements

The Conformance Requirements clauses in the present document are copy/paste from the relevant core specification
where skipped text has been replaced with "...". References to clauses in the Conformance Requirements clause of the
test body refers to clauses in the referred specification, not clauses in the present document.
5 Reference Conditions
5.1 General
The test cases are expected to be executed through the 3GPP radio interface. Details of the radio interfaces are outside
the scope of this specification. The reference environments used by tests are specified in the test.
ETSI
5.2 Generic setup procedures

A set of basic generic procedures for different IMS usage scenarios are described in Annex A of this specification.
These procedures are used in numerous test cases throughout the present document. Default Messages are used from
and maintained in Annex A of TS 34.229-1 [2].
5.3 Transport protocols applied

For simplicity, UDP (User Datagram Protocol) is applied to IMS testing as default DL transport protocol, except for
the test cases in clause 6 where TCP (Transmission Control Protocol) is applied as DL transport protocol.
NOTE: Which UL transport protocol is used in the test is decided by the UE.
ETSI
6 Registration
6.1 Initial Registration / 5GS

6.1.1 Test Purpose (TP)
(1)
with { UE has an ISIM or USIM inserted, is registered for 5GS, and has acquired P-CSCF address(es) }
ensure that {
when { UE is made to register for IMS }
then { UE sends a correctly composed initial REGISTER request to the P-CSCF }
}
(2)
with { UE having sent unprotected REGISTER request }
ensure that {
when { UE receiving a valid 401 (Unauthorized) response for the initial REGISTER request sent }
then { UE correctly authenticates itself by sending another REGISTER request with a correctly
composed Authorization header using the AKAv1-MD5 algorithm }
}
(3)
with { UE having sent unprotected and then protected REGISTER request }
ensure that {
when { UE receiving a valid 200 OK response from S-CSCF for the REGISTER sent for authentication }
then { UE subscribes to the reg event package for the public user identity registered, using the
stored service route for routing the SUBSCRIBE request }
}
(4)
with { UE having subscribed to reg event }
ensure that {
when { UE receives NOTIFY request for reg event }
then { UE responds with a valid 200 OK response }
}
6.1.2 Conformance Requirements
The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.
[TS 24.229, clause C.2]:
In case the UE is loaded with a UICC that contains a USIM but does not contain an ISIM, the UE shall:
- generate a private user identity;
- generate a temporary public user identity; and
- generate a home network domain name to address the SIP REGISTER request to.
All these three parameters are derived from the IMSI parameter in the USIM, according to the procedures described in
TS 23.003 [3]. Also in this case, the UE shall derive new values every time the UICC is changed, and shall discard
existing values if the UICC is removed.
NOTE: If there is an ISIM and a USIM on a UICC, the ISIM is used for authentication to the IM CN subsystem,
as described in TS 33.203 [19]. See also clause 5.1.1.1A.
[TS 24.229, clause 5.1.1.1A]:
The ISIM shall always be used for authentication to the IM CN subsystem, if it is present, as described in
3GPP TS 33.203 [19].
ETSI
The ISIM is preconfigured with all the necessary parameters to initiate the registration to the IM CN subsystem. These
parameters include:
- the private user identity;
- one or more public user identities; and
- the home network domain name used to address the SIP REGISTER request
The first public user identity in the list stored in the ISIM is used in emergency registration requests.
In case the UE does not contain an ISIM, the UE shall:
- generate a private user identity;
- generate a temporary public user identity; and
- generate a home network domain name to address the SIP REGISTER request to;
in accordance with the procedures in clause C.2.
The temporary public user identity is only used in REGISTER requests, i.e. initial registration, re-registration, UE-
initiated deregistration.
The UE shall not reveal to the user the temporary public user identity if the temporary public user identity is barred. The
temporary public user identity is not barred if received by the UE in the P-Associated-URI header field.
If the UE is unable to derive the parameters in this clause for any reason, then the UE shall not proceed with the request
associated with the use of these parameters and will not be able to register to the IM CN subsystem.
[TS 24.229, clause 5.1.1.2.1]:
The initial registration procedure consists of the UE sending an unprotected REGISTER request and, if challenged
depending on the security mechanism supported for this UE, sending the integrity-protected REGISTER request or
other appropriate response to the challenge. The UE can register a public user identity with any of its contact addresses
at any time after it has acquired an IP address, discovered a P-CSCF, and established an IP-CAN bearer that can be used
for SIP signalling. However, the UE shall only initiate a new registration procedure when it has received a final
response from the registrar for the ongoing registration, or the previous REGISTER request has timed out.
...
The UE shall send the unprotected REGISTER requests to the port advertised to the UE during the P-CSCF discovery
procedure. If the UE does not receive any specific port information during the P-CSCF discovery procedure, or if the
UE was pre-configured with the P-CSCF's IP address or domain name and was unable to obtain specific port
information, the UE shall send the unprotected REGISTER request to the SIP default port values as specified in
RFC 3261 [26].
NOTE 1: The UE will only send further registration and subsequent SIP messages towards the same port of the P-
CSCF for security mechanisms that do not require to use negotiated ports for exchanging protected
messages.
The UE shall extract or derive a public user identity, the private user identity, and the domain name to be used in the
Request-URI in the registration, according to the procedures described in subclause 5.1.1.1A or subclause 5.1.1.1B. A
public user identity may be input by the end user.
On sending an unprotected REGISTER request, the UE shall populate the header fields as follows:
a) a From header field set to the SIP URI that contains:
...
2) the public user identity to be registered;
b) a To header field set to the SIP URI that contains:
...
ETSI
c) a Contact header field set to include SIP URI(s) containing the IP address or FQDN of the UE in the hostport
parameter. If the UE:
1) supports GRUU (see table A.4, item A.4/53);
...
3) has an IMEI available; or
...
the UE shall include a "+sip.instance" header field parameter containing the instance ID. ...
NOTE 2: The requirement placed on the UE to include an instance ID based on the IMEI or the MEID when the
UE does not support GRUU and does not support multiple registrations does not imply any additional
requirements on the network.
...
The UE shall include all supported ICSI values (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref
media feature tag as defined in subclause 7.9.2 and RFC 3840 [62] for the IMS communication services it
intends to use, and IARI values (coded as specified in subclause 7.2A.9.2), for the IMS applications it intends to
use in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3840 [62].
The UE shall include the media feature tags as defined in RFC 3840 [62] for all supported streaming media
types.
...
If the UE has no specific reason not to include a user part in the URI of the contact address (e.g. some UE
performing the functions of an external attached network), the UE should include a user part in the URI of the
contact address such that the user part is globally unique and does not reveal any private information;
NOTE 3: A time-based UUID (Universal Unique Identifier) generated as per subclause 4.2 of RFC 4122 [154] is
globally unique and does not reveal any private information.
d) a Via header field set to include the sent-by field containing the IP address or FQDN of the UE and the port
number where the UE expects to receive the response to this request when UDP is used. For TCP, the response is
received on the TCP connection on which the request was sent. For the UDP, the UE shall also include a "rport"
header field parameter with no value in the Via header field. Unless the UE has been configured to not send
keep-alives, and unless the UE is directly connected to an IP-CAN for which usage of NAT is not defined, it
shall include a "keep" header field parameter with no value in the Via header field, in order to indicate support of
sending keep-alives associated with the registration, as described in RFC 6223 [143];
NOTE 4: When sending the unprotected REGISTER request using UDP, the UE transmit the request from the same
IP address and port on which it expects to receive the response to this request.
e) a registration expiration interval value of 600 000 seconds as the value desired for the duration of the
registration;
NOTE 5: 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.
f) a Request-URI set to the SIP URI of the domain name of the home network used to address the REGISTER
request;
g) the Supported header field containing the option-tag "path", and
1) if GRUU is supported, the option-tag "gruu"; and
2) if multiple registrations is supported, the option-tag "outbound".
ETSI
h) if a security association or TLS session exists, and if available to the UE (as defined in the access technology
specific annexes for each access technology), a P-Access-Network-Info header field set as specified for the
access network technology (see subclause 7.2A.4);
...
On receiving the 200 (OK) response to the REGISTER request, the UE shall:
a) store the expiration time of the registration for the public user identities found in the To header field value and
bind it either to the respective contact address of the UE or to the registration flow and the associated contact
address (if the multiple registration mechanism is used);
...
b) store as the default public user identity the first URI on the list of URIs present in the P-Associated-URI header
field and bind it to the respective contact address of the UE and the associated set of security associations or TLS
session;
...
d) store the list of service route values contained in the Service-Route header field and bind the list either to the
contact address or to the registration flow and the associated contact address (if the multiple registration
mechanism is used), and the associated set of security associations or TLS session over which the REGISTER
request was sent;
NOTE 10: When multiple registration mechanism is not used, there will be only one list of service route values
bound to a contact address. However, when multiple registration mechanism is used, there will be
different list of service route values bound to each registration flow and the associated contact address.
NOTE 11: The UE will use the stored list of service route values to build a proper preloaded Route header field for
new dialogs and standalone transactions (other than REGISTER method) when using either the respective
contact address or the registration flow and the associated contact address (if the multiple registration
mechanism is used), and the associated set of security associations or TLS session.
e) if the UE indicated support for GRUU in the Supported header field of the REGISTER request then:
- if the UE did not use the procedures specified in RFC 6140 [191] for registration, find the Contact header
field within the response that matches the one included in the REGISTER request. If this contains a "pub-
gruu" header field parameter or a "temp-gruu" header field parameter or both, then store the value of those
parameters as the GRUUs for the UE in association with the public user identity and the contact address that
was registered; and
...
NOTE 12: When allocating public GRUUs to registering UAs the functionality within the UE that performs the role
of registrar will add an "sg" SIP URI parameter that uniquely identifies that UA to the public GRUU it
received in the "pub-gruu" header field parameter. The procedures for generating a temporary GRUU
using the "temp-gruu-cookie" header field parameter are specified in subclause 7.1.2.2 of
RFC 6140 [191].
f) if the REGISTER request contained the "reg-id" and "+sip.instance" Contact header field parameter and the
"outbound" option tag in a Supported header field, the UE shall check whether the option-tag "outbound" is
present in the Require header field:
- if no option-tag "outbound" is present, the UE shall conclude that the S-CSCF does not support the
registration procedure as described in RFC 5626 [92], and the S-CSCF has followed the registration
procedure as described in RFC 5627 [93] or RFC 3261 [26], i.e., if there is a previously registered contact
address, the S-CSCF replaced the old contact address and associated information with the new contact
address and associated information (see bullet e) above). Upon detecting that the S-CSCF does not support
the registration procedure as defined in RFC 5626 [92], the UE shall refrain from registering any additional
IMS flows for the same private identity as described in RFC 5626 [92]; or
ETSI
NOTE 13: Upon replaces the old contact address with the new contact address, the S-CSCF performs the network
initiated deregistration procedure for the previously registered public user identities and the associated old
contact address as described in subclause 5.4.1.5. Hence, the UE will receive a NOTIFY request
informing the UE about the deregistration of the old contact address.
- if an option-tag "outbound" is present, the UE may establish additional IMS flows for the same private
identity, as defined in RFC 5626 [92];
g) if available, store the announcement of media plane security mechanisms the P-CSCF (IMS-ALG) supports
labelled with the "mediasec" header field parameter specified in subclause 7.2A.7 and received in the Security-
Server header field, if any. Once the UE chooses a media security mechanism from the list received in the
Security-Server header field from the server, it may initiate that mechanism on a media level when it initiates
new media in an existing session;
NOTE 14: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.
[TS 24.229, clause 5.1.1.2.2]:
On sending a REGISTER request, as defined in subclause 5.1.1.2.1, the UE shall additionally populate the header fields
as follows:
a) an Authorization header field, with:
- the "username" header field parameter, set to the value of the private user identity;
- the "realm" header field parameter, set to the domain name of the home network;
- the "uri" header field parameter, set to the SIP URI of the domain name of the home network;
- the "nonce" header field parameter, set to an empty value; and
- the "response" header field parameter, set to an empty value;
NOTE 1: If the UE specifies its FQDN in the hostport parameter in the Contact header field and in the sent-by field
in the Via header field, then it has to ensure that the given FQDN will resolve (e.g., by reverse DNS
lookup) to the IP address that is bound to the security association.
NOTE 2: The UE associates two ports, a protected client port and a protected server port, with each pair of security
association. For details on the selection of the port values see 3GPP TS 33.203 [19].
b) additionally for the Contact header field, if the REGISTER request is protected by a security association, include
the protected server port value in the hostport parameter;
c) additionally for the Via header field, for UDP, if the REGISTER request is protected by a security association,
include the protected server port value in the sent-by field; and
d) a Security-Client header field set to specify the signalling plane security mechanism the UE supports, the IPsec
layer algorithms the UE supports and the parameters needed for the security association setup. The UE shall
support the setup of two pairs of security associations as defined in 3GPP TS 33.203 [19]. The syntax of the
parameters needed for the security association setup is specified in annex H of 3GPP TS 33.203 [19]. The UE
shall support the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The UE shall support the
IPsec layer algorithms for integrity and confidentiality protection as defined in 3GPP TS 33.203 [19], and shall
announce support for them according to the procedures defined in RFC 3329 [48].
[TS 24.229, clause 5.1.1.5.1]:
Authentication is performed during initial registration. A UE can be re-authenticated during subsequent reregistrations,
deregistrations or registrations of additional public user identities. When the network requires authentication or re-
authentication of the UE, the UE will receive a 401 (Unauthorized) response to the REGISTER request.
On receiving a 401 (Unauthorized) response to the REGISTER request, the UE shall:
1) extract the RAND and AUTN parameters;
ETSI
2) check the validity of a received authentication challenge, as described in 3GPP TS 33.203 [19] i.e. the locally
calculated XMAC must match the MAC parameter derived from the AUTN part of the challenge; and the SQN
parameter derived from the AUTN part of the challenge must be within the correct range; and
3) check the existence of the Security-Server header field as described in RFC 3329 [48]. If the Security-Server
header field is not present or it does not contain the parameters required for the setup of the set of security
associations (see annex H of 3GPP TS 33.203 [19]), the UE shall abandon the authentication procedure and send
a new REGISTER request with a new Call-ID.
In the case that the 401 (Unauthorized) response to the REGISTER request is deemed to be valid the UE shall:
1) calculate the RES parameter and derive the keys CK and IK from RAND as described in 3GPP TS 33.203 [19];
2) set up a temporary set of security associations for this registration based on the static list and parameters the UE
received in the 401 (Unauthorized) response and its capabilities sent in the Security-Client header field in the
REGISTER request. The UE sets up the temporary set of security associations using the most preferred
mechanism and algorithm returned by the P-CSCF and supported by the UE and using IK and CK (only if
encryption enabled) as the shared key. The UE shall use the parameters received in the Security-Server header
field to setup the temporary set of security associations. The UE shall set a temporary SIP level lifetime for the
temporary set of security associations to the value of reg-await-auth timer;
...
4) send another REGISTER request towards the protected server port indicated in the response using the temporary
set of security associations to protect the message. The header fields are populated as defined for the initial
REGISTER request that was challenged with the received 401 (Unauthorized) response, with the addition that
the UE shall include an Authorization header field containing:
- the "realm" header field parameter set to the value as received in the "realm" WWW-Authenticate header
field parameter;
- the "response" header field parameter that contains the RES parameter, as described in RFC 3310 [49];
- the "algorithm" header field parameter, set to the value received in the 401 (Unauthorized) response; and
- the "nonce" header field parameter, set to the value received in the 401 (Unauthorized) response.
The UE shall also insert the Security-Client header field that is identical to the Security-Client header field that
was included in the previous REGISTER request (i.e. the REGISTER request that was challenged with the
received 401 (Unauthorized) response). The UE shall also insert the Security-Verify header field into the request,
by mirroring in it the content of the Security-Server header field received in the 401 (Unauthorized) response.
The UE shall set the Call-ID of the security association protected REGISTER request which carries the
authentication challenge response to the same value as the Call-ID of the 401 (Unauthorized) response which
carried the challenge.
NOTE 2: The Security-Client header field contains signalling plane security mechanism and if the UE supports
media plane security, then media plane security mechanisms are contained, too.
[TS 24.229, clause 5.1.1.5.1]:
On receiving the 200 (OK) response for the security association protected REGISTER request registering a public user
identity with the associated contact address, the UE shall:
- change the temporary set of security associations to a newly established set of security associations, i.e. set its
SIP level lifetime to the longest of either the previously existing set of security associations SIP level lifetime, or
the lifetime of the just completed registration plus 30 seconds; and
- if this is the only set of security associations available toward the P-CSCF, use the newly established set of
security associations for further messages sent towards the P-CSCF. If there are additional sets of security
associations (e.g. due to registration of multiple contact addresses), the UE can either use them or use the newly
established set of security associations for further messages sent towards the P-CSCF as appropriate.
ETSI
NOTE 3: If the UE has registered multiple contact addresses, the UE can either send requests towards the P-CSCF
over the newly established set of security associations, or use different UE's contact address and
associated set of security associations when sending the requests towards the P-CSCF. Responses towards
the P-CSCF that are sent via UDP will be sent over the same set of security associations that the related
request was received on. Responses towards the P-CSCF that are sent via TCP will be sent over the same
set of security associations that the related request was received on.
When the first request or response protected with the newly established set of security associations is received from the
P-CSCF or when the lifetime of the old set of security associations expires, the UE shall delete the old set of security
associations and related keys it may have with the P-CSCF after all SIP transactions that use the old set of security
associations are completed.
[TS 24.229, clause 5.1.1.3]:
Upon receipt of a 2xx response to the initial registration, the UE shall subscribe to the reg event package for the public
user identity registered at the user's registrar (S-CSCF) as described in RFC 3680 [43] and RFC 6665 [28].
...
The UE shall subscribe to the reg event package upon registering a new contact address via an initial registration
procedure. If the UE receives a NOTIFY request via the newly established subscription dialog and via the previously
established subscription dialogs (there will be at least one), the UE may terminate the previously established
subscription dialogs and keep only the newly established subscription dialog.
The UE shall use the default public user identity for subscription to the registration-state event package.
NOTE 2: The subscription information stored in the HSS ensures that the default public user identity is a SIP URI.
On sending a SUBSCRIBE request, the UE shall populate the header fields as follows:
a) a Request-URI set to the resource to which the UE wants to be subscribed to, i.e. to the SIP URI that is the
default public user identity used for subscription;
b) a From header field set to the SIP URI that is the default public user identity used for subscription;
c) a To header field set to the SIP URI that is the default public user identity used for subscription;
d) an Event header field set to the "reg" event package;
e) an Expires header field set to 600 000 seconds as the value desired for the duration of the subscription;
f) void; and
g) void.
[TS 24.229, clause 5.1.2.1]:
Upon receipt of a NOTIFY request for the dialog associated with the subscription to the reg event package the UE shall
perform the following actions:
- store the information for the established dialog;
- store the expiration time as indicated in the "expires" header field parameter of the Subscription-State header
field, if present, of the NOTIFY request. Otherwise the expiration time is retrieved from the Expires header field
of the 2xx response to SUBSCRIBE request;
- if a <registration> element with state attribute "active", i.e. registered, is received for one or more public user
identities, the UE shall store the indicated public user identities as registered;
- if a <registration> element with state attribute "active" is received, and the UE supports GRUU (see table A.4,
item A.4/53), then for each public user identity indicated in the notification that contains a <pub-gruu> element
or a <temp-gruu> element or both (as defined in RFC 5628 [94]), the UE shall store the value of those elements
in association with the public user identity;
[TS 24.229, clause 5.1.2A.1.1]:
ETSI
When the UE sends any request, the UE shall use either a given contact address that has been previously registered or a
registration flow and the associated contact address (if the multiple registration mechanism is used) and shall:
- if IMS AKA is in use as a security mechanism:
a) if the UE has not obtained a GRUU, populate the Contact header field of the request with the protected server
port and the respective contact address; and
b) include the protected server port and the respective contact address in the Via header field entry relating to
the UE;
...
The UE shall determine the public user identity to be used for this request as follows:
1) if a P-Preferred-Identity was included, then use that as the public user identity for this request; or
2) if no P-Preferred-Identity was included, then use the default public user identity for the security association or
TLS session and the associated contact address as the public user identity for this request;
...
If this is a request for a new dialog, the Contact header field is populated as follows:
1) a contact header value which is one of:
- if a public GRUU value ("pub-gruu" header field parameter) has been saved associated with the public user
identity to be used for this request, and the UE does not indicate privacy of the P-Asserted-Identity, then the
UE should insert the public GRUU ("pub-gruu" header field parameter) value as specified in RFC 5627 [93];
or
- if a temporary GRUU value ("temp-gruu" header field parameter) has been saved associated with the public
user identity to be used for this request, and the UE does indicate privacy of the P-Asserted-Identity, then the
UE should insert the temporary GRUU ("temp-gruu" header field parameter) value as specified in
RFC 5627 [93];
- otherwise, a SIP URI containing the contact address of the UE that has been previously registered without
any contact parameters dedicated to registration procedure;
NOTE 7: The above items are mutually exclusive.
...
If available to the UE (as defined in the access technology specific annexes for each access technology), the UE shall
insert a P-Access-Network-Info header field into any request for a dialog, any subsequent request (except CANCEL
requests) or response (except CANCEL responses) within a dialog or any request for a standalone method (see
subclause 7.2A.4). Insertion of the P-Access-Network-Info header field into the ACK request is optional.
NOTE 13: During the dialog, the points of attachment to the IP-CAN of the UE can change (e.g. UE connects to
different cells). The UE will populate the P-Access-Network-Info header field in any request or response
within a dialog with the current point of attachment to the IP-CAN (e.g. the current cell information).
NOTE 14: The value of the P-Access-Network-Info header field could be stale if the point of attachment of the UE
with the network changes before the message is received by the network.
The UE shall build a proper preloaded Route header field value for all new dialogs and standalone transactions. The UE
shall build a list of Route header field values made out of the following, in this order:
a) the P-CSCF URI containing the IP address acquired at the time of the P-CSCF discovery procedures which was
used in registration of the contact address (or registration flow); and
NOTE 15: If the UE is provisioned with or receives a FQDN at the time of the P-CSCF discovery procedures, the
FQDN is resolved to an IP address at the time of the P-CSCF discovery procedures.
b) the P-CSCF port based on the security mechanism in use:
ETSI
- if IMS AKA or SIP digest with TLS is in use as a security mechanism, the protected server port learnt during
the registration procedure;
...
c) and the values received in the Service-Route header field saved from the 200 (OK) response to the last
registration or re-registration of the public user identity with associated contact address.
NOTE 16: When the UE registers multiple contact addresses, there will be a list of Service-Route headers for each
contact address. When sending a request using a given contact address and the associated security
associations or TLS session, the UE will use the corresponding list of Service-Route headers to construct
a list of Route headers.
[TS 24.341, clause 5.3.2.2]
On sending a REGISTER request, the SM-over-IP receiver shall indicate its capability to receive traditional short
messages over IMS network by including a "+g.3gpp.smsip" parameter into the Contact header according to
RFC 3840 [16].
6.1.3 Test description
6.1.3.1 Pre-test conditions
System Simulator:
- SS is configured with the IMSI within the USIM application, the home domain name, public and private user
identities together with the shared secret key of IMS AKA algorithm, related to the IMS private user identity
(IMPI) that is configured on the UICC card equipped into the UE.
- SS is listening to SIP default port 5060 for both UDP and TCP protocols.
- SS is able to perform IMS AKA authentication for the IMPI, according to 3GPP TS 33.203 [16] clause 6.1.
- 1 NR Cell
UE:
- The UE contains either ISIM and USIM applications or only USIM application on UICC.
- The UE is configured to register for IMS after switch on.
- The UE is switched off.
Preamble:
- None
ETSI
6.1.3.2 Test procedure sequence
Table 6.1.3.2-1: Main Behaviour
St Procedure Message Sequence TP Verdict

U-S Message
1 The UE is switched on.
2 Check: does the UE send an initial registration --> REGISTER 1 P
request?
3 SS sends 401 Unauthorized. <-- 401 Unauthorized
4 Check: does the UE send a subsequent --> REGISTER 2 P
registration request?
5 SS sends 200 OK for REGISTER. <-- 200 OK
EXCEPTION: In parallel to the events described
in steps 6 to 9, the steps specified in Table
6.1.3.2-2 may take place.
6 Check: does the UE subscribe to reg-event? --> SUBSCRIBE 3 P
7 SS sends 200 OK for SUBSCRIBE. <-- 200 OK
8 SS sends NOTIFY for reg-event package, <-- NOTIFY
containing full registration state information for
the registered public user identity in the XML
body.
9 Check: does the UE acknowledge reception of --> 200 OK 4 P
NOTIFY?
NOTE: The associated NR/5GC signalling is specified in TS 38.508-1 [21] generic procedure 4.5.2.
Table 6.1.3.2-2: Parallel Behaviour

U-S Message
1 UE sends a PUBLISH request. --> PUBLISH
2 SS sends a 503 Service Unavailable response <-- 503 Service Unavailable
6.1.3.3 Specific message contents
Table 6.1.3.3-1: REGISTER (step 2, table 6.1.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in subclause A.1.1, Condition A1
Table 6.1.3.3-2: 401 Unauthorized for REGISTER (step 3, table 6.1.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in subclause A.1.1, Conditions A2 and A32
Table 6.1.3.3-4: 200 OK for REGISTER (step 5, table 6.1.3.2-1)
Table 6.1.3.3-5: SUBSCRIBE for reg-event package (step 6, table 6.1.3.2-1)
ETSI
Table 6.1.3.3-6: 200 OK for SUBSCRIBE (step 7, table 6.1.3.2-1)
Table 6.1.3.3-7: NOTIFY for reg-event package (step 8, table 6.1.3.2-1)
Table 6.1.3.3-8: 200 OK for requests other than REGISTER or SUBSCRIBE (step 9, table 6.1.3.2-1)
Table 6.1.3.3-9: PUBLISH (step 1, table 6.1.3.2-2)
Table 6.1.3.3-10: 503 Service Unavailable (step 2, table 6.1.3.2-2)
Derivation Path: TS 34.229-1 [2], Table in subclause A.4.2
ETSI
6.2 Initial Registration Failures / 5GS

(1)
ensure that {
when { UE receiving a 503 (Service Unavailable) response without Retry-After header for the
unprotected REGISTER request sent }
then { UE waits at most 5 minutes and then sends another unprotected REGISTER request }
}
(2)
with { UE having sent an unprotected REGISTER request }
ensure that {
when { UE receiving a 503 (Service Unavailable) response with Retry-After header for the initial
REGISTER request sent }
then { UE waits until interval given is up and then sends another unprotected REGISTER request }
}
(3)
ensure that {
when { UE receiving a 423 (Interval Too Brief) response }
then { UE sends another unprotect REGISTER request with new expiration interval }
}
[TS 24.229, clause 5.1.1.2.1, Release 17]:
For each 4xx, 5xx or 6xx response received without a Retry-After header field to the REGISTER request, the UE shall:
a) use the mechanism defined in subclause 4.5 of RFC 5626 [92] for determination of the retry delay time before
each new registration attempt;
b) mark the currently used P-CSCF address as unavailable for the last duration of the retry delay time computed by
the algorithm defined in subclause 4.5 of RFC 5626 [92] plus 5 minutes; and
c) initiate an initial registration as specified in subclause 5.1.1.2 after the amount of time of the last retry delay time
computed by the algorithm defined in subclause 4.5 of RFC 5626 [92]; and
- if there is a locally stored P-CSCF address as specified in subclause 5.1.9 which is different from the
currently used P-CSCF address and which is not marked as unavailable, may initiate the initial registration
using that P-CSCF; and
- if there is no locally stored P-CSCF address as specified in subclause 5.1.9 which is different from the
currently used P-CSCF address and which is not marked as unavailable, may get a new set of P-CSCF
addresses as described in subclause 9.2.1 unless otherwise specified in the access specific annexes (as
described in annex B, annex L or annex U) and initiate the initial registration as specified in
subclause 5.1.1.2.
The values of max-time and base-time (if all failed) may be provided by the network to the UE with the management
objects specified in 3GPP TS 24.167 [8G]. If no values of the parameters max-time and base-time (if all failed) have
been provided to the UE by the network, the default values defined in subclause 4.5 of RFC 5626 [92] shall be used.
Other mechanisms may be used as well and are outside the scope of the present document.
[TS 24.229, clause 5.1.1.2.1]:
On receiving a 503 response with a Retry-After header field to the REGISTER request and the Retry-After header field
indicates time bigger than the value for timer F as specified in table 7.7.1, the UE:
ETSI
a) shall mark the currently used P-CSCF address as unavailable for the time indicated by the Retry-After header
field;
b) if there is a locally stored P-CSCF address as specified in subclause 5.1.9 which is different than the currently
used P-CSCF address and which is not marked as unavailable, may initiate an initial registration as specified in
subclause 5.1.1.2 using that P-CSCF; and
c) if there is no locally stored P-CSCF address as specified in subclause 5.1.9 which is different than the currently
used P-CSCF address and which is not marked as unavailable, may get a new set of P-CSCF addresses as
described in subclause 9.2.1 unless otherwise specified in the access specific annexes (as described in annex B,
annex L or annex U) and initiate an initial registration as specified in subclause 5.1.1.2.
NOTE 19: if the Retry-After header field indicates time smaller than the value for timer F as specified in table 7.7.1,
the UE continues using the currently used P-CSCF address.
[TS 24.229, clause 5.1.1.2.1]:
On receiving a 423 (Interval Too Brief) response to the REGISTER request, the UE shall:
- send another REGISTER request populating the registration expiration interval value with an expiration timer of
at least the value received in the Min-Expires header field of the 423 (Interval Too Brief) response.
System Simulator:
- 1 NR Cell
- UE provided with a second P-CSCF in the PDU SESSION ESTABLISHMENT ACCEPT according to Table
4.7.2-2 (conditions Additional_P-CSCF_IPv6 and Additional_P-CSCF_IPv4) of TS 38.508-1 [21].
UE:
Preamble:
- None
ETSI

U-S Message
1 The UE is switched on - -
2 UE sends an initial registration request. --> REGISTER - -
3 SS sends 503 Service Unavailable without <-- 503 Service Unavailable - -
Retry-After header.
- The subsequent messages are sent to second - - - -
P-CSCF
request ?
5 SS sends 503 Service Unavailable with Retry- <-- 503 Service Unavailable - -
After header set to 10 seconds.
request, but no earlier than 10 seconds after
step 5?
7 SS sends 423 Interval Too Brief. <-- 423 Interval Too Brief - -
request with an expiration value set to the value
provided in Step 7?
9 SS sends 401 Unauthorized. <-- 401 Unauthorized - -
10 UE sends a subsequent registration request. --> REGISTER - -
11 SS sends 200 OK for REGISTER <-- 200 OK - -
EXCEPTION: In parallel to the events described - - - -
in steps 12 to 15, the steps specified in Table
6.1.3.2-2 may take place.
12- Steps 5-8 from clause A.2. - - - -
15

U-S Message
1 UE sends a PUBLISH request. --> PUBLISH - -
2 SS sends a 503 Service Unavailable response <-- 503 Service Unavailable - -
Derivation path: TS 34.229-1 [2], Table in subclause A.4.2

Header/param Cond Value/remark Rel Reference
Retry-After not present
Derivation path: TS 34.229-1 [2], Table in subclause A.1.1, Condition A1
ETSI

Retry-After
delta-seconds 10
Table 6.2.3.3-6: 423 Interval Too Brief (step 7, table 6.2.3.2-1)

Min-Expires
delta-seconds 800000

Contact
expires 800000
Expires
Note: value 800000 is given in at least one of Contact or
Expires header.
CSeq
value incremented from previous REGISTER
Table 6.2.3.3-8: 401 Unauthorized (step 9, table 6.2.3.2-1)
Derivation path: TS 34.229-1 [2], Table in subclause A.1.1, Conditions A2 and A32
Contact
expires 800000
Expires
Note: value 800000 is given in at least one of Contact or
Expires header.
Table 6.2.3.3-10: 200 OK (step 11, table 6.2.3.2-1)

Contact
expires 800000
ETSI
6.3 Re-Registration Scenarios / 5GS

(1)
with { UE being registered to IMS with expiration interval at 120 seconds }
ensure that {
when { 60 seconds passed }
then {UE re-registers }
}
(2)
with { UE starting re-registration procedure by sending REGISTER }
ensure that {
when { UE receives 500 Server Internal Error response }
then {UE starts initial registration }
}
(3)
ensure that {
}
(4)
ensure that {
}
(5)
with { UE attempting re-registration }
ensure that {
when { UE receives 423 Interval Too Brief response }
then {UE sends another re-registration request with given expiration interval }
}
(6)
with { UE being registered }
ensure that {
when { UE receives notification about shortened expiration interval for one of its registered
public user identities }
then {UE re-registers after half of the shorted expiration interval elapses }
}
[TS 24.229, clause 5.1.1.4.1]:
The UE can perform the reregistration of a previously registered public user identity bound to any one of its contact
addresses and the associated set of security associations or TLS sessions at any time after the initial registration has
been completed.
...
Unless either the user or the application within the UE has determined that a continued registration is not required the
UE shall reregister an already registered public user identity either 600 seconds before the expiration time if the
ETSI
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,
...
On receiving a 423 (Interval Too Brief) response to the REGISTER request, the UE shall:
- send another REGISTER request populating the registration expiration interval value 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 or 403 (Forbidden) response for a reregistration, the UE shall perform the procedures for initial
registration as described in subclause 5.1.1.2.
[TS 24.229, clause 5.1.1.4.1]:
At any time, the UE can receive a NOTIFY request carrying information related to the reg event package (as described
in subclause 5.1.1.3). If:
- the state attribute in any of the <registration> elements is set to "active";
- the value of the <uri> sub-element inside the <contact> sub-element is set to the Contact address that the UE
registered; and
- the event attribute of that <contact> sub-element(s) is set to "shortened";
the UE shall:
1) use the expires attribute of the <contact> sub-element that the UE registered to adjust the expiration time for that
public user identity; and
2) start the re-authentication procedures at the appropriate time (as a result of the S-CSCF procedure described in
subclause 5.4.1.6) by initiating a reregistration as described in subclause 5.1.1.4, if required.
NOTE: When authenticating a given private user identity, the S-CSCF will only shorten the expiry time within
the <contact> sub-element that the UE registered using its private user identity. The <contact> elements
for the same public user identity, if registered by another UE using different private user identities remain
unchanged. The UE will not initiate a reregistration procedure, if none of its <contact> sub-elements was
modified.
System Simulator:
- 1 NR Cell
UE:
ETSI
Preamble:
- None

U-S Message
1 UE is switched on.
2-9 Steps 1-8 from clause A.2: initial IMS
registration happens, with SS giving 120
seconds expiration interval.
10 UE re-registers 60 seconds later. --> REGISTER 1 P
11 SS declines re-registration attempt. <-- 500 Server Internal Error
12 Step 1 from clause A.2: UE sends initial IMS --> REGISTER 2 P
registration request
13- Steps 2-8 from clause A.2, with SS giving 360
19 seconds expiration interval.
20 UE re-registers 180 seconds later. --> REGISTER 3 P
21 SS responds with 1600 seconds expiration <-- 200 OK
interval
22 UE re-registers 1000 seconds later --> REGISTER 4 P
23 SS responds with 423 Interval Too Brief with <-- 423 Interval Too Brief
Min-Expires value of 800000 seconds
24 UE sends a new another re-registration request --> REGISTER 5 P
using at least 800000 seconds expiration.
25 SS responds with 200 OK. <-- 200 OK
26 SS notifies UE about shortened expiration time <-- NOTIFY
of 60 seconds for one of the registered public
user identities.
27 UE responds with 200 OK --> 200 OK
28 30 seconds before new expiry time, UE re- --> REGISTER 6 P
registers
29 SS responds with authentication challenge and <-- 401 Unauthorized
security mechanism supported by the network
30 UE completes security procedures --> REGISTER
31 SS responds with 200 OK <-- 200 OK
Table 6.3.3.3-1: 200 OK for REGISTER (step 5, Table 6.3.3.2-1)

Contact
expires 120
ETSI
Table 6.3.3.3-2: REGISTER (step 10, Table 6.3.3.2-1)
Derivation path: TS 34.229-1 [2], Table in subclause A.1.1, Conditions A2, A17, A32
Security-Client
spi-c new SPI number of the inbound SA at the protected client
port, shall be different from previously used number
spi-s new SPI number of the inbound SA at the protected
server port, shall be different from previously used number
port-c new protected client port, shall be different from previously
used number
port-s same value as in the previous REGISTER
Authorization RFC 2617 [23]
nonce-count 2 TS 24.229 [7]
Table 6.3.3.3-3: 500 Server Internal Error (step 11, Table 6.3.3.2-1)

Contact
expires 360
Security-Client
port, shall be different from previously used numbers
server port, shall be different from previously used
numbers
used numbers

Contact
expires 1600
ETSI
Security-Client
port, shall be different from previously used numbers
numbers
used numbers
Table 6.3.3.3-8: 423 Interval Too Brief (step 23, Table 6.3.3.2-1)

Min-Expires
Contact
expires 800000 or more (Remark: either the Contact header
contains such expires parameter or below Expires header
is present. If both are present, Expires header is to be
ignored)
Expires
delta-seconds 800000 or more (Remark: either the Contact header
contains above expires parameter or Expires header is
present. If both are present, Expires header is to be
ignored)
Table 6.3.3.3-9A: 200 OK for REGISTER (step 25, Table 6.3.3.2-1)

Contact
expires 800000
ETSI
Table 6.3.3.3-10: NOTIFY (step 26, Table 6.3.3.2-1)
Derivation path: TS 34.229-1 [2], Table in subclause A.1.6, Conditions A1, and A3 OR A4
Message-body
A3 <?xml version="1.0" encoding="UTF-8"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
version="1" state="partial">
<registration aor=" PublicUserIdentity1 (NOTE 1)"
id="a100" state="active">
<contact id="980" state="active" event="shortened"
expires="60">
<uri>same value as in Contact header of REGISTER
request</uri>
</contact>
</registration>
</reginfo>
A4 <?xml version="1.0" encoding="UTF-8"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
xmlns:gr="urn:ietf:params:xml:ns:gruuinfo" version="1"
state="partial">
<registration aor=" PublicUserIdentity1 (NOTE 1)"
id="a100" state="active">
<contact id="980" state="active" event="shortened"
expires="60">
callid="Call-Id of most recent REGISTER"
cseq="CSeq value of most recent REGISTER">
request</uri>
<unknown-param name="+sip.instance"> "Instance ID of
the UE;" </unknown-param>
<gr:pub-gruu uri="public GRUU associated to this aor"/>
<gr:temp-gruu uri="temporary GRUU associated to this
aor" first-cseq="CSeq of the REGISTER request that
caused the temporary GRUU to assigned for the UE"/>
</contact>
</registration>
</reginfo>
Table 6.3.3.3-11: 200 OK for other requests than REGISTER or SUBSCRIBE (step 27, Table 6.3.3.2-1)
Contact
expires 800000 (if present)
Expires present if no expires parameter in Contact header
Authorization
nonce-count 5
Table 6.3.3.3-13: 401 Unauthorized (step 29, Table 6.3.3.2-1)

WWW- RFC 2617 [23]
Authenticate
nonce Base 64 encoding of new RAND and new AUTN (different TS 24.229 [7]
from the values used in step 3)
ETSI
Contact
Expires present if no expires parameter in Contact header
Authorization
nonce-count 1
ETSI
6.4 De-Registration Scenarios / 5GS

(1)
Void
(2)
with { UE being registered to IMS }
ensure that {
when { UE receiving a NOTIFY request containing de-registration information with contact elements
being "deactivated" }
then { UE acknowledges de-registration }
}
(3)
with { UE being de-registered from IMS by the network with contact elements being "deactivated" }
ensure that {
when { UE acknowledging de-registration }
then { UE performs initial registration to IMS }
}
(4)
ensure that {
when { UE is made to de-register its contact address }
then { UE performs de-registration from IMS }
}
[TS 24.229, clause 5.4.1.5]:
For any registered public user identity, the S-CSCF can deregister:
- all contact addresses bound to the indicated public user identity (i.e. deregister the respective public user
identity);
- some contact addresses bound to the indicated public user identity;
- a particular contact address bound to the indicated public user identity; or
- one or more registration flows and the associated contact address bound to the indicated public user identity,
when the UE supports multiple registration procedure;
by sending a single NOTIFY request.
...
When a network-initiated deregistration event occurs for one or more public user identities that are bound either to one
or more contact addresses or registration flows and the associated contact addresses (if the multiple registration
mechanism is used), the S-CSCF shall send a NOTIFY request to all subscribers that have subscribed to the respective
reg event package. For each NOTIFY request, the S-CSCF shall:
1) set the Request-URI and Route header field to the saved route information during subscription;
2) set the Event header field to the "reg" value;
3) in the body of the NOTIFY request, include as many <registration> elements as many public user identities the
S-CSCF is aware of the user owns;
4) set the aor attribute within each <registration> element to one public user identity:
ETSI
a) set the <uri> sub-element inside each <contact> sub-element of each <registration> element to the respective
contact address provided by the UE;
b) if the public user identity:
i) has been deregistered (i.e. all contact addresses and all registration flows and associated contact addresses
bound to the indicated public user identity are removed) then:
- set the state attribute within the <registration> element to "terminated";
- set the state attribute within each <contact> element belonging to this UE to "terminated"; and
- set the event attribute within each <contact> element belonging to this UE to either "unregistered", or
"deactivated" if the S-CSCF expects the UE to reregister or "rejected" if the S-CSCF does not expect
the UE to reregister; or
...
When sending a final NOTIFY request with all <registration> element(s) having their state attribute set to "terminated"
(i.e. all public user identities have been deregistered or expired), the S-CSCF shall also terminate the subscription to the
registration event package by setting the Subscription-State header field to the value of "terminated".
[TS 24.229, clause 5.1.1.7]:
Upon receipt of a NOTIFY request, on any dialog which was generated during the subscription to the reg event package
as described in subclause 5.1.1.3, including one or more <registration> element(s) which were registered by this UE,
with:
1) the state attribute within the <registration> element set to "terminated", and within each <contact> element
belonging to this UE, the state attribute set to "terminated" and the event attribute set either to "unregistered", or
"rejected", or "deactivated", the UE shall remove all registration details relating to the respective public user
identity (i.e. consider the public user identity indicated in the aor attribute of the <registration> element as
deregistered); or
...
In case of a "deactivated" event attribute, the UE shall start the initial registration procedure as described in
subclause 5.1.1.2. In case of a "rejected" event attribute, the UE shall release all dialogs related to those public user
identities.
Upon receipt of a NOTIFY request, the UE shall delete all security associations or TLS sessions towards the P-CSCF
either:
- if all <registration> element(s) have their state attribute set to "terminated" (i.e. all public user identities are
deregistered) and the Subscription-State header field contains the value of "terminated"; or
- if each <registration> element that was registered by this UE has either the state attribute set to "terminated", or
the state attribute set to "active" and the state attribute within the <contact> element belonging to this UE set to
"terminated".
When all UE's public user identities are registered via a single P-CSCF and the subscription dialog to the reg event
package of the UE is set via the respective P-CSCF, the UE shall delete these security associations or TLS sessions
towards the respective P-CSCF when all public user identities have been deregistered and after the server transaction (as
defined in RFC 3261 [26]) pertaining to the received NOTIFY request terminates.
NOTE 3: Deleting a security association or TLS session is an internal procedure of the UE and does not involve
any SIP procedures.
NOTE 4: If all the public user identities (i.e. <contact> elements) registered by this UE are deregistered and the
security associations or TLS sessions have been removed, the UE considers the subscription to the reg
event package terminated since the NOTIFY request was received with Subscription-State header field
containing the value of "terminated".
[TS 24.229, clause 5.1.1.6.1]:
ETSI
For any public user identity that the UE has previously registered, the UE can deregister via a single registration
procedure:
- all contact addresses bound to the indicated public user identity;
- some contact addresses bound to the indicated public user identity;
- a particular contact address bound to the indicated public user identity; or
- when the UE supports multiple registrations (i.e. the "outbound" option tag is included in the Supported header
field) one or more flows bound to the indicated public user identity.
The UE can deregister a public user identity that it has previously registered with its contact address at any time. The
UE shall protect the REGISTER request using a security association or TLS session that is associated with contact
address, see 3GPP TS 33.203 [19], established as a result of an earlier registration, if one is available.
Request-URI in the registration, according to the procedures described in subclause 5.1.1.1A or subclause 5.1.1.1B.
Prior to sending a REGISTER request for deregistration, the UE shall release all dialogs that were using the contact
addresses or the flow that is going to be deregistered and related to the public user identity that is going to be
deregistered or to one of the implicitly registered public user identities. However:
- if the dialog that was established by the UE subscribing to the reg event package used the public user identity
that is going to be deregistered; and
- this dialog is the only remaining dialog used for subscription to reg event package of the user, i.e. there are no
other contact addresses registered with associated subscription to the reg event package of the user;
then the UE shall not release this dialog.
On sending a REGISTER request that will remove the binding between the public user identity and one of its contact
addresses or one of its flows, the UE shall populate the header fields as follows:
1) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, the main URI
of the UE; else
2) the public user identity to be deregistered;
of the UE; else
2) the public user identity to be deregistered;
c) a Contact header field set to the SIP URI(s) that contain(s) in the hostport parameter the IP address of the UE or
FQDN, and:
1) if the UE is removing the binding between the public user identity indicated in the To header field, (together
with the associated implicitly registered public user identities), and the contact address indicated in the
Contact header field; and
- if the UE supports GRUU, or multiple registrations (i.e. the "outbound" option tag is included in the
Supported header field), or has an IMEI available, or has an MEID available, the Contact header field
also contains the "+sip.instance" header field parameter. Only the IMEI shall be used for generating an
instance ID for a multi-mode UE that supports both 3GPP and 3GPP2 defined radio access networks;
- if the UE supports multiple registrations (i.e. the "outbound" option tag is included in the Supported
header field), the Contact header field does not contain the "reg-id" header field parameter;
- if the UE does not supports GRUU and does not support multiple registrations (i.e. the "outbound" option
tag is not included in the Supported header field), and does not have an IMEI available, and does not have
ETSI
an MEID available, the Contact header field does not contain either the "+sip.instance" header field
parameter or the "reg-id" header field parameter;
NOTE 1: Since the contact address is deregistered, if there are any flows that were previously registered with the
respective contact address, all flows terminating at the respective contact address are removed.
2) if the UE is removing the binding between the public user identity indicated in the To header field, (together
with the associated implicitly registered public user identities) and one of its flows, the Contact header field
contains the "+sip.instance" header field parameter and the "reg-id" header field parameter that identifies the
flow; and
NOTE 2: The requirement placed on the UE to include an instance ID based on the IMEI when the UE does not
support GRUU and does not support multiple registrations does not imply any additional requirements on
the network.
3) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the
registration of bulk number contacts the UE shall include a Contact URI without a user portion and
containing the "bnc" URI parameter;
d) a Via header field set to include the IP address or FQDN of the UE in the sent-by field;
e) a registration expiration interval value set to the value of zero, appropriate to the deregistration requirements of
the user;
request;
g) if available to the UE (as defined in the access technology specific annexes for each access technology), a P-
Access-Network-Info header field set as specified for the access network technology (see subclause 7.2A.4);
h) a Security-Client header field to announce the media plane security mechanisms the UE supports, if any;
i) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the
registration of bulk number contacts the UE shall include a Require header field containing the option-tag "gin";
and
j) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the
registration of bulk number contacts the UE shall include a Proxy-Require header field containing the option-tag
"gin".
For a public user identity that the UE has registered with multiple contact addresses or multiple flows (e.g. via different
P-CSCFs), the UE shall also be able to deregister multiple contact addresses or multiple flows, bound to its public user
identity, via single deregistration procedure as specified in RFC 3261 [26]. The UE shall send a single REGISTER
request, using one of its contact addresses and the associated set of security associations or TLS session, containing a
list of Contact headers. Each Contact header field is populated as specified above in bullets a) through i).
The UE can deregister all contact addresses bound to its public user identity and associated with its private user identity.
The UE shall send a single REGISTER request, using one of its contact addresses and the associated set of security
associations or TLS session, containing a public user identity that is being deregistered in the To header field, and a
single Contact header field with value of "*" and the Expires header field with a value of "0". The UE shall not include
the "instance-id" feature tag and the "reg-id" header field parameter in the Contact header field in the REGISTER
request.
NOTE 4: All entities subscribed to the reg event package of the user will be informed via NOTIFY request which
contact addresses bound to the public user identity have been deregistered.
When a 401 (Unauthorized) response to a REGISTER request is received the UE shall behave as described in
subclause 5.1.1.5.1.
- remove all registration details relating to this public user identity and the associated contact address.
ETSI
- store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports labelled with
the "mediasec" header field parameter specified in subclause 7.2A.7 and received in the Security-Server header
field, if any.
If there are no more public user identities registered with this contact address, the UE shall delete any stored media
plane security mechanisms and related keys and any security associations or TLS sessions and related keys it may have
towards the IM CN subsystem.
If all public user identities are deregistered and all security association or TLS session is removed, then the UE shall
consider subscription to the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an
Expires header field containing a value of zero).
[TS 24.229, clause 5.1.1.6.2]:
as follows:
- the "realm" header field parameter, set to the value as received in the "realm" WWW-Authenticate header
field parameter;
- the "nonce" header field parameter, set to last received nonce value; and
- the response directive, set to the last calculated response value;
b) additionally for each Contact header field and associated contact address, include the associated protected server
port value in the hostport parameter;
c) additionally for the Via header field, include the protected server port value bound to the security association in
the sent-by field;
d) a Security-Client header field, set to specify the signalling plane security mechanisms it supports, the IPsec layer
algorithms for integrity and confidentiality protection it supports and the new parameter values needed for the
setup of two new pairs of security associations. For further details see 3GPP TS 33.203 [19] and RFC 3329 [48];
and
e) a Security-Verify header field that contains the content of the Security-Server header field received in the 401
(Unauthorized) response of the last successful authentication.
NOTE 2: When the UE has received the 200 (OK) response for the REGISTER request of the only public user
identity currently registered with this contact address and its associated set of implicitly registered public
user identities (i.e. no other public user identity is registered), the UE removes the security association
(between the P-CSCF and the UE) that were using this contact address. Therefore further SIP signalling
using this security association (e.g. the NOTIFY request containing the deregistration event) will not
reach the UE.
ETSI
System Simulator:
- 1 NR Cell
UE:
Preamble:
- None
ETSI

U-S Message
1 UE is switched on. - - - -
2-9 Steps 1-8 from Annex A.2: initial IMS - - - -
registration happens.
10- Void - - -
12
13 SS de-registers the UE's contact address. <-- NOTIFY - -
14 UE acknowledges. --> 200 OK 2 P
15- Steps 1-8 from Annex A.2: initial IMS - - 3 P
22 registration happens.
- EXCEPTION: Steps 23a1-23a8 describe - - - -
behaviour that depends on UE configuration;
the "lower case letter" identifies a step
sequence that takes place if data centric mode
is configured
23a1 IF [52] pc_data_centric THEN UE is made to - - - -
de-register its contact address.
23a2 Steps 0A-2 defined in Annex A.11 - - 4 P
-
23a8
24- Void - - - -
29
- EXCEPTION: Steps 30a1 to 30a2 may be - - - -
performed depending on UE implementation;
the "lower case letter" identifies a step
sequence that take place if the UE performs a
specific action.
30a1 The UE transmits a PDU SESSION RELEASE --> PDU SESSION RELEASE - -
REQUEST message to release ‘ims’ PDU REQUEST
session.
30a2 PDU session release procedure defined in - - - -
clause 4.9.21 of TS 38.508-1 [4] is performed.
- EXCEPTION: Step 31a1 may be performed - - - -
depending on UE implementation; the "lower
case letter" identifies a step sequence that take
place if the UE performs a specific action.
31a1 The UE transmits a DEREGISTRATION --> DEREGISTRATION REQUEST - -
REQUEST message.
Table 6.4.3.3-0: Void
Table 6.4.3.3-1: NOTIFY (step 13, Table 6.4.3.2-1)
Derivation path: TS 34.229-1 [2], Table in subclause A.1.6, Conditions A1 AND ((A3 AND A6) OR (A4 AND A6))
Table 6.4.3.3-2: 200 OK for other requests than REGISTER or SUBSCRIBE (step 14, Table 6.4.3.2-1)
ETSI
6.5 Void
ETSI
6.6 Re-Registration after capability update / 5GS

(1)
ensure that {
when { UE is made to update its capabilities }
then { UE re-registers }
}
[TS 24.229, clause 5.1.1.4.1]:
Unless either the user or the application within the UE has determined that a continued registration is not required the
UE shall reregister an 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 UE intends to update its capabilities according to RFC 3840 [62] or when the
UE needs to modify the ICSI values that the UE intends to use in a g.3gpp.icsi-ref media feature tag or IARI values that
the UE intends to use in the g.3gpp.iari-ref media feature tag.
System Simulator:
- SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity
- SS is able to perform AKAv1-MD5 authentication algorithm for that IMPI, according to 3GPP TS 33.203 [16]
clause 6.1 and RFC 3310 [15].
- 1 NR Cell
UE:
- UE contains either ISIM and USIM applications or only USIM application on UICC.
- UE is registered to IMS services, by executing the generic test procedure in Annex A.2 up to the last step.
- UE is able to be made change its capabilities, manifested through a specific instance which is setting the AT
Command +CASIMS (Availability for SMS using IMS, defined in 3GPP TS 27.007 [22] 8.72) to 0.
Preamble:
- UE complete the registration procedure and IMS PDU session establishment procedure according to Steps 2-
19a1 of TS 38.508-1 table 4.5.2.2-2.
ETSI

U-S Message
1 UE is made to turn off its SMS over IMS
capability.
2 Check: does the UE initiate a re-registration --> REGISTER 1 P
procedure, and indicating the changed
capabilities in the REGISTER message?
3 Void
4 Void
5 SS responds with 200 OK for REGISTER <-- 200 OK
Derivation Path: TS 34.229-1 [2], Table in subclause A.1.1, Condition A2, A17 and A32
Contact
feature-param does not contain "+g.3gpp.smsip"
Authorization
nonce-count 2
ETSI
6.7 Authentication / MAC Parameter Invalid / Only two

consecutive invalid challenges / 5GS
(1)
with { UE starting registration procedure }
ensure that {
when { UE receiving invalid MAC parameter }
then { UE sends another REGISTER request without challenge response AUTS and populates a new
Security-Client header }
}
(2)
with { UE having responded to invalid MAC parameter }
ensure that {
when { UE receives another invalid MAC parameter }
then { UE sends another REGISTER request without challenge response AUTS and populates a new
}
(3)
Void
[TS 24.229 clause 5.1.1.5.3]:
If, in a 401 (Unauthorized) response, either the MAC or SQN is incorrect the UE shall respond with a further
REGISTER indicating to the S-CSCF that the challenge has been deemed invalid as follows:
- in the case where the UE deems the MAC parameter to be invalid the subsequent REGISTER request shall contain
no "auts" Authorization header field parameter and an empty "response" Authorization header field parameter, i.e. no
authentication challenge response;
Whenever the UE detects any of the above cases, the UE shall:
- send the REGISTER request using an existing set of security associations, if available (see
3GPP TS 33.203 [16]);
- populate a new Security-Client header field within the REGISTER request and associated contact address, set to
specify the security mechanisms it supports, the IPsec layer algorithms for integrity and confidentiality
protection it supports and the parameters needed for the new security association setup. These parameters shall
contain new values for spi_uc, spi_us and port_uc; and
- not create a temporary set of security associations.
[TS 24.229 clause 5.1.1.5.12]:
A UE shall only respond to two consecutive invalid challenges and shall not automatically attempt authentication after
receiving two consecutive invalid challenges. The UE may attempt to register with the network again after an
implementation specific time.
ETSI
System Simulator:
(IMPI) configured on the UICC card equipped into the UE.
- 1 NR Cell
UE:
Preamble:
- None.
ETSI

U-S Message
2 UE sends initial registration for IMS services. --> REGISTER
3 SS responds with an invalid AKAv1-MD5 <-- 401 Unauthorized
authentication challenge with an invalid MAC
value.
4 Check: does the UE send a REGISTER --> REGISTER 1 P
request:
- contains no AUTS directive and an empty
response directive, i.e. no authentication
challenge response
- UE populates a new Security-Client header
set to specify the security mechanism it
supports, the IPsec layer algorithms it supports
and the parameters needed for the new security
association setup
authentication challenge with an invalid MAC
value.
6 Check: does the UE send another REGISTER --> REGISTER 2 P
request:
- contains no AUTS directive and an empty
response directive, i.e. no authentication
challenge response
association setup
7 Void
8 Void
9-15 Steps 2-8 from Clause A.2 are performed.
Table 6.7.3.3-2: 401 Unauthorized for REGISTER (step 3/5, table 6.7.3.2-1)

WWW-
Authenticate
nonce Base 64 encoding of RAND and AUTN, generated using
invalid MAC value
ETSI
Table 6.7.3.3-3: REGISTER (step 4/6, table 6.7.3.2-1)

CSeq
value must be incremented from previous REGISTER
Call-ID
callid same value as in REGISTER at Step 2
Authorization
response present, but empty
auts not present
Security-Client
spi-c new SPI number of the inbound SA at the protected
client port, shall be different from previously used
number(s)
number(s)
port-c new protected client port, shall be different from
previously used number(s)
ETSI
6.8 Authentication / Security-Server missing / SQN out of range

/ 5GS
(1)
with { UE starting registration procedure }
ensure that {
when { UE receiving a challenge response without Security-Server header }
then { UE abandons the authentication procedure and sends a new REGISTER request with new Call-
ID }
}
(2)
with { UE having sent a new initial REGISTER request }
ensure that {
when { UE receiving a challenge response with SQN out of range }
then { UE sends another REGISTER request with challenge response AUTS and populates a new
}
[TS 24.229 clause 5.1.1.5.1]:
Authentication is performed during initial registration. A UE can be re-authenticated during subsequent reregistrations,
deregistrations or registrations of additional public user identities. When the network requires authentication or re-
authentication of the UE, the UE will receive a 401 (Unauthorized) response to the REGISTER request.
In the case that the 401 (Unauthorized) response is deemed to be invalid then the UE shall behave as defined in
subclause 5.1.1.5.3.
[TS 24.229, clause 5.1.1.5.3]
If, in a 401 (Unauthorized) response, either the MAC or SQN is incorrect the UE shall respond with a further
REGISTER indicating to the S-CSCF that the challenge has been deemed invalid as follows:
- in the case where the UE deems the MAC parameter to be invalid the subsequent REGISTER request shall
contain no "auts" Authorization header field parameter and an empty "response" Authorization header field
parameter, i.e. no authentication challenge response;
- in the case where the UE deems the SQN to be out of range, the subsequent REGISTER request shall contain the
"auts" Authorization header field parameter (see 3GPP TS 33.102 [18]).
NOTE: In the case of the SQN being out of range, a "response" Authorization header field parameter can be
included by the UE, based on the procedures described in RFC 3310 [49].
ETSI
Whenever the UE detects any of the above cases, the UE shall:
- send the REGISTER request using an existing set of security associations, if available (see
3GPP TS 33.203 [19]);
- populate a new Security-Client header field within the REGISTER request and associated contact address, set to
specify the security mechanisms it supports, the IPsec layer algorithms for integrity and confidentiality
protection it supports and the parameters needed for the new security association setup. These parameters shall
contain new values for spi_uc, spi_us and port_uc; and
- not create a temporary set of security associations.
System Simulator:
- 1 NR Cell
UE:
Preamble:
- None.
ETSI

U-S Message
2 UE sends initial registration for IMS services. --> REGISTER
3 SS responds challenge response without <-- 401 Unauthorized
Security-Server header.
4 Check: does the UE sends a new REGISTER --> REGISTER 1 P
request with new Call-ID
authentication challenge with SQN out of range.
6 Check: does the UE send another REGISTER --> REGISTER 2 P
request:
- contains AUTS directive
association setup.
7-13 Continue with Annex A.2 step 2-8 in order to get -
the UE in a stable registered state.

Security-Server not present.
Derivation path: TS 34.229-1 [2], Table in subclause A.1.1, Condition A1 and A32
Call-ID
callid Value differs from the one sent in in Step 2 of table
6.8.3.2-1.

WWW-Authenticate
nonce Base 64 encoding of RAND and AUTN, generated with
SQN out of range with the AMF information field set to
AMFRESYNCH value to trigger SQN re-synchronisation
procedure in test ISIM/USIM, see TS 34.108 clause
8.1.2.2.
ETSI
Derivation Path: TS 34.229-1 [2], Table in subclause A.1.1, Conditions A1

CSeq
value must be incremented from previous REGISTER
Call-ID
callid same value as in REGISTER at Step 4
Authorization
nonce same as in previous 401 UNAUTHORIZED message
opaque same as in previous 401 UNAUTHORIZED message
auts any value
Security-Client
spi-c new SPI number of the inbound SA at the protected
client port, shall be different from previously used
number
number
port-c new protected client port, shall be different from
previously used number
ETSI
6.9 Subscription / 503 Service Unavailable / 5GS

(1)
with { UE subscribing to reg event }
ensure that {
when { UE receives 503 Service unavailable containing a Retry-After header field }
then { UE does not reattempt the request for the indicated time period }
}
[TS 24.229 clause 5.1.2.2]:
If the UE receives a 503 (Service Unavailable) response to an initial SUBSCRIBE request containing a Retry-After
header field, then the UE shall not automatically reattempt the request until after the period indicated by the Retry-After
header field contents.
System Simulator:
- SS has performed AKAv1-MD5 authentication with the UE and accepted the registration (IMS security).
- 1 NR Cell
UE:
Preamble:
- None.
ETSI

U-S Message
2-5 Steps 1-4 of Annex A.2 happen.
6 UE subscribes to its registration event package. --> SUBSCRIBE
7 SS responds with 503 response containing a <-- 503 Service Unavailable
Retry-After header with period set to T=128s.
8 Check: does the SS receive the UE's re-attempt 1 F
of SUBSCRIBE within the Time T=128s?
9 UE reattempts to subscribe to its registration --> SUBSCRIBE
event package.
10- Continue with Annex A.2 step 6-8 in order to get -
12 the UE in a stable registered state.

Retry-After RFC 3261 [6]
period 128

Call-ID RFC 3261 [6]
callid value different from the previous SUBSCRIBE request
ETSI
7 Call Control
7.1 MTSI MO Voice Call / 503 Service Unavailable / 5GS

(1)
with { UE being registered to IMS and UE having sent an initial INVITE request for MO Voice call }
ensure that {
when { UE receiving a 503 Service Unavailable response containing a Retry-After header indicating
a period of 20 seconds }
then { UE does not reattempt the request until after the indicated period }
}
(2)
Void
[TS 24.229, clause 5.1.3.1]:
Upon receiving a 503 (Service Unavailable) response to an initial INVITE request containing a Retry-After header, then
the originating UE shall not automatically reattempt the request until after the period indicated by the Retry-After
header contents.
[TS 24.229, clause 6.1.2]:
An INVITE request generated by a UE shall contain a SDP offer and at least one media description. This SDP offer
shall reflect the calling user's terminal capabilities and user preferences for the session.
NOTE 2: If the originating UE does not use the precondition mechanism (see subclause 5.1.3.1), it will not include
any precondition information in the SDP message body.
System Simulator:
- 1 NR Cell connected to 5GC, default parameters.
UE:
- The UE is either configured to use preconditions or to not use preconditions or does not support preconditions..
Preamble:
- UE is in state 1N-A and registered to IMS
ETSI

U-S Message
1 UE is made to attempt an IMS voice call - - - -
2-7 Steps 2-7 of generic procedure specified in - - - -
Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
- EXCEPTION: In parallel with Step 8, parallel - - - -
behaviour defined in table 7.1.3.2-2 takes place
- EXCEPTION: Steps 8a to 8b describe - - - -
the “lower case letter” identifies a step
sequence that takes place if such configuration
was conducted.
8a IF the UE is configured to use preconditions --> INVITE - -
THEN step1 of Annex A.4.1 takes place.
8b ELSE step 1 of Annex A.4.2 takes place. --> INVITE - -
9 SS sends 503 (Service Unavailable) with Retry- <-- 503 Service Unavailable - -
After header indicating a period of 20 seconds.
10 UE acknowledges the reception of 503 (Service --> ACK - -
Unavailable) message.
11 The SS starts timer t_Waits=20s. - - - -
12 Check: Does the UE reattempt the INVITE --> INVITE 1 F
request?
13 The SS waits for expiry of t_Waits. - - - -
- EXCEPTION: Steps 14a1 to 14b8 happen if the - - - -
UE choses to reattempt the INVITE request,
i.e., these steps are optional. The SS waits at
most 30 more seconds for such INVITE request
before it terminates the test case.
- EXCEPTION: Steps 14a1 to 14b11 describe - - - -
the “lower case letter” identifies a step
sequence that takes place if such configuration
was conducted.
14a1 IF the UE is configured to use preconditions - - - -
- THEN steps 1 to 5 of Annex A.4.1 take place.
14a5
14a6 Step 10 of generic procedure specified in Table - - - -
4.9.15.2.2-1 of TS 38.508-1 [21] is performed.
- EXCEPTION: In parallel to steps 14a7 and - - - -
14a8 below, step 14a9 occurs.
14a7 Steps 11-12 of generic procedure specified in - - - -
- Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
14a8 performed.
14a9 steps 6 to 12 of Annex A.4.1 take place - - - -
-
14a1
5
14b1 ELSE steps 1 to 5 of Annex A.4.2 takes place - - - -
-
14b5
14b6 Steps 10-12 of generic procedure specified in - - - -
- Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
14b8 performed.
14b9 Steps 6 to 8 of Annex A.4.2 take place - - - -
-
14b1
1
ETSI
Table 7.1.3.2-2: Parallel behaviour

U-S Message
1 The UE transmits an --> NR RRC: - -
RRCReconfigurationComplete message. RRCReconfigurationComplete
Derivation path: TS 34.229-1 [2], Annex A.4.2

Retry-After
delta-seconds 20
ETSI
7.2 MTSI MO Voice Call / 504 Server Time-out / 5GS

(1)
with { UE being registered to IMS and UE having sent an INVITE request }
ensure that {
when { UE receives 504 Server Time-out response }
then { UE performs initial registration to IMS }
}
[TS 24.229, clause 5.1.2A.1.6]
In the event the UE receives a 504 (Server Time-out) response containing:
1) a P-Asserted-Identity header field set to a value equal to a URI:
a) from the Service-Route header field value received during registration; or
b) from the Path header field value received during registration; and
NOTE 1: If there are multiple registration flows associated with the registration, then the UE has received from the
P-CSCF during registration multiple sets of Path header field and Service-Route header field values. The
Path header field value and Service-Route header field value corresponding to the flow on which the 504
(Server Time-out) response was received are checked.
2) a Content-Type header field set according to subclause 7.6 (i.e. "application/3gpp-ims+xml"), independent of the
value or presence of the Content-Disposition header field, independent of the value or presence of Content-
Disposition parameters,
then the following treatment is applied:
a) if the 504 (Server Time-out) response includes an IM CN subsystem XML body as described in subclause 7.6
with the <ims-3gpp> element, including a version attribute, with the <alternative-service> child element:
A) with the <type> child element set to "restoration" (see table 7.6.2); and
B) with the <action> child element set to "initial-registration" (see table 7.6.3);
then the UE:
- shall initiate S-CSCF restoration procedures by performing an initial registration as specified in

subclause 5.1.1.2; and
- may provide an indication to the user based on the text string contained in the <reason> child element of the
<alternative-service> child element of the <ims-3gpp> element.
NOTE 2: If the UE has discovered multiple P-CSCF addresses and has information that the P-CSCF was unable to
forward the request resulting in sending back the 504 (Server Time-out) response, when starting the initial
registration it is appropriate for the UE to select a P-CSCF address different from the one used for the
registration binding on which the 504 (Server Time-out) response was received.
System Simulator:
ETSI
UE:
- UE is configured to register for IMS after switch on.
- The UE is either configured to use preconditions or to not use preconditions or does not support preconditions.
Preamble:
- UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS.

U-S Message
1 UE is made to attempt an IMS voice call. - - - -
Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
- EXCEPTION: In parallel to INVITE at Steps 8 a --> - - -
or 8b, step described in Table 7.2.3.2-2: Parallel
behaviour takes place.
- EXCEPTION: Steps 8a to 8b describe behaviour - - - -
that depends on UE configuration; the “lower
case letter” identifies a step sequence that takes
place if such configuration was conducted.
8a IF the UE is configured to use preconditions --> INVITE - -
THEN step 1 of Annex A.4.1 takes place.
8b ELSE step 1 of Annex A.4.2 takes place. --> INVITE - -
9 SS sends 504 Server Time-out <-- 504 Server Time-out - -
9A UE acknowledges the reception of 504 Server --> ACK - -
Time-out.
10 Check: Does the UE send an initial registration --> REGISTER 1 P
request?
11- Continue with Annex A.2 steps 2-8 in order to - - - -
17 get the UE in a stable registered state.

U-S Message
Table 7.2.3.3-3: ACK (step 9A, Table 7.2.3.2-1)
Derivation path: TS 34.229-1 [2], Table in subclause A.2.7 Conditions A1 and A4
Table 7.2.3.3-1: 504 Server Time-out (step 3, Table 7.2.3.2-1)
ETSI
Derivation path: TS 34.229-1 [2], Table in subclause A.1.1 conditions A1 and A32
ETSI
7.3 Void
7.4 MTSI MO Voice Call with preconditions at both originating

and terminating UE / 5GS
(1)
with { UE being registered to IMS and configured to use preconditions }
ensure that {
when { UE is being made to initiate a voice call }
then { UE sends INVITE for voice call with preconditions }
}
(2)
with { UE having sent INVITE with preconditions }
ensure that {
when { UE receives 100 Trying followed by 183 Session Progress }
then { UE sends PRACK for 183 Session Progress }
}
(3)
with { UE having sent PRACK }
ensure that {
when { UE receives 200 OK for PRACK and resources are available }
then { UE sends UPDATE }
}
(4)
with { UE having sent UPDATE }
ensure that {
when { UE receives 200 OK for UPDATE followed by 180 Ringing sent reliably }
then { UE sends PRACK for 180 Ringing }
}
(5)
with { UE having sent PRACK for 180 Ringing }
ensure that {
when { UE receives 200 OK for PRACK followed by 200 OK for INVITE }
then { UE sends ACK }
}
[TS 24.229, clause 5.1.2A.1.1]:
The procedures of this subclause are general to all requests and responses, except those for the REGISTER method.
When the UE re-uses a previously registered contact address, the UE shall remove any parameters dedicated to
registration from the Contact header field (e.g. "expires").
When the UE sends any request, the UE shall use either a given contact address that has been previously registered or a
registration flow and the associated contact address (if the multiple registration mechanism is used) and shall:
- if IMS AKA is in use as a security mechanism:
a) if the UE has not obtained a GRUU, populate the Contact header field of the request with the protected server
port and the respective contact address; and
ETSI
b) include the protected server port and the respective contact address in the Via header field entry relating to
the UE;
If this is a request for a new dialog, the Contact header field is populated as follows:
1) a contact header value which is one of:
- if a public GRUU value ("pub-gruu" header field parameter) has been saved associated with the public user
identity to be used for this request, and the UE does not indicate privacy of the P-Asserted-Identity, then the
UE should insert the public GRUU ("pub-gruu" header field parameter) value as specified in RFC 5627 [93];
or
- if a temporary GRUU value ("temp-gruu" header field parameter) has been saved associated with the public
user identity to be used for this request, and the UE does indicate privacy of the P-Asserted-Identity, then the
UE should insert the temporary GRUU ("temp-gruu" header field parameter) value as specified in
RFC 5627 [93];
- otherwise, a SIP URI containing the contact address of the UE that has been previously registered without
any contact parameters dedicated to registration procedure;
NOTE 7: The above items are mutually exclusive.
2) include an "ob" SIP URI parameter, if the UE supports multiple registrations, and the UE wants all subsequent
requests in the dialog to arrive over the same flow identified by the flow token as described in RFC 5626 [92];
3) if the request is related to an IMS communication service that requires the use of an ICSI then the UE shall
include in a g.3gpp.icsi-ref media feature tag, as defined in subclause 7.9.2 and RFC 3841 [56B], the ICSI value
(coded as specified in subclause 7.2A.8.2) for the IMS communication service. The UE may also include other
ICSI values that the UE is prepared to use for all dialogs with the terminating UE(s); and
4) if the request is related to an IMS application that is supported by the UE, then the UE may include in a
g.3gpp.iari-ref media feature tag, as defined in subclause 7.9.3 and RFC 3841 [56B], the IARI value (coded as
specified in subclause 7.2A.9.2) that is related to the IMS application and that applies for the dialog.
If this is a request for a new dialog or standalone transaction and the request is related to an IMS communication service
that requires the use of an ICSI then the UE:
1) shall include the ICSI value (coded as specified in subclause 7.2A.8.2), for the IMS communication service that
is related to the request in a P-Preferred-Service header field according to RFC 6050 [121]. If a list of network
supported ICSI values was received as specified in 3GPP TS 24.167 [8G], the UE shall only include an ICSI
value that is in the received list;
NOTE 8: The UE only receives those ICSI values corresponding to the IMS communication services that the
network provides to the user.
2) may include an Accept-Contact header field containing an ICSI value (coded as specified in subclause 7.2A.8.2)
that is related to the request in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 if the ICSI for the
IMS communication service is known. The UE may remove one or more subclasses from an ICSI when
including it in an Accept-Contact header field provided that the included ICSI corresponds to an IMS
communication service.
NOTE 9: If the UE includes the same ICSI values into the Accept-Contact header field and the P-Preferred-Service
header field, there is a possibility that one of the involved S-CSCFs or an AS changes the ICSI value in
the P-Asserted-Service header field, which results in the message including two different ICSI values
(one in the P-Asserted-Service header field, changed in the network and one in the Accept-Contact header
field).
If available to the UE (as defined in the access technology specific annexes for each access technology), the UE shall
insert a P-Access-Network-Info header field into any request for a dialog, any subsequent request (except CANCEL
requests) or response (except CANCEL responses) within a dialog or any request for a standalone method (see
subclause 7.2A.4). Insertion of the P-Access-Network-Info header field into the ACK request is optional.
ETSI
different cells). The UE will populate the P-Access-Network-Info header field in any request or response
within a dialog with the current point of attachment to the IP-CAN (e.g. the current cell information).
NOTE 14: The value of the P-Access-Network-Info header field could be stale if the point of attachment of the UE
with the network changes before the message is received by the network.
The UE shall build a proper preloaded Route header field value for all new dialogs and standalone transactions. The UE
shall build a list of Route header field values made out of the following, in this order:
a) the P-CSCF URI containing the IP address acquired at the time of the P-CSCF discovery procedures which was
used in registration of the contact address (or registration flow); and
NOTE 15: If the UE is provisioned with or receives a FQDN at the time of the P-CSCF discovery procedures, the
FQDN is resolved to an IP address at the time of the P-CSCF discovery procedures.
b) the P-CSCF port based on the security mechanism in use:
- if IMS AKA or SIP digest with TLS is in use as a security mechanism, the protected server port learnt during
the registration procedure;
- if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled authentication is in

use as a security mechanism, the unprotected server port used during the registration procedure;
c) and the values received in the Service-Route header field saved from the 200 (OK) response to the last
registration or re-registration of the public user identity with associated contact address.
NOTE 16: When the UE registers multiple contact addresses, there will be a list of Service-Route headers for each
contact address. When sending a request using a given contact address and the associated security
associations or TLS session, the UE will use the corresponding list of Service-Route headers to construct
a list of Route headers.
[TS 24.229, clause 5.1.2A.1.2]:
The UE may include a SIP URI complying with RFC 3261 [26], a tel URI complying with RFC 3966 [22], a pres URI
complying with RFC 3859 [179], an im URI complying with RFC 3860 [180] or a mailto URI complying with
RFC 2368 [181].
NOTE: This version of the document does not specify how the UE determines the host part of the SIP URI.
The UE may use non-international formats of E.164 numbers or non-E.164 numbers, including geo-local numbers and
home-local numbers and other local numbers (e.g. private number), in the Request-URI.
The actual value of the URI depends on whether user equipment performs an analysis of the dial string input by the end
user or not, see subclauses 5.1.2A.1.3 and 5.1.2A.1.4.
[TS 24.229, clause 5.1.2A.1.5]:
When the UE uses home-local number, the UE shall include in the "phone-context" tel URI parameter the home
network domain name in accordance with RFC 3966 [22].
When the UE uses geo-local number, the UE shall:
- if access technology information available to the UE (i.e., the UE can insert P-Access-Network-Info header field
into the request), include the access technology information in the "phone-context" tel URI parameter according
to RFC 3966 [22] as defined in subclause 7.2A.10; and
- if access technology information is not available to the UE (i.e., the UE cannot insert P-Access-Network-Info
header field into the request), include in the "phone-context" tel URI parameter the home network domain name
prefixed by the "geo-local." string according to RFC 3966 [22] as defined in subclause 7.2A.10.
When the UE uses other local numbers, than geo-local number or home local numbers, e.g. private numbers that are
different from home-local number or the UE is unable to determine the type of the dialled number, the UE shall include
a "phone-context" tel URI parameter set according to RFC 3966 [22], e.g. if private numbers are used a domain name to
which the private addressing plan is associated. The "phone-context" value used in the case of other local numbers shall
be different from "phone-context" values used with geo-local numbers and home-local numbers.
ETSI
NOTE 1: The "phone-context" tel URI parameter value can be entered or selected by the subscriber, or can be a
"pre-configured" value (e.g. using OMA-DM with the management object specified in
3GPP TS 24.167 [8G]) inserted by the UE.
NOTE 2: The way how the UE determines whether numbers in a non-international format are geo-local, home-local
or relating to another network in absence of matching UE configuration in subclause 5.1.2A.1.5A, is
implementation specific.
NOTE 3: Home operator's local policy can define a prefix string(s) to enable subscribers to differentiate dialling a
geo-local number and/or a home-local number.
[TS 24.229, clause 5.1.3.1]:
Upon generating an initial INVITE request, the UE shall include the Accept header field with "application/sdp", the
MIME type associated with the 3GPP IM CN subsystem XML body (see subclause 7.6.1) and any other MIME type the
UE is willing and capable to accept.
The "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the
precondition mechanism" and is defined in RFC 3312 [30] as updated by RFC 4032 [64].
The preconditions mechanism should be supported by the originating UE.
If the precondition mechanism is disabled as specified in subclause 5.1.5A, the UE shall not use the precondition
mechanism.
The UE may initiate a session without the precondition mechanism if the originating UE does not require local resource
reservation.
NOTE 1: The originating UE can decide if local resource reservation is required based on e.g. application
requirements, current access network capabilities, local configuration, etc.
In order to allow the peer entity to reserve its required resources, if the precondition mechanism is enabled as specified
in subclause 5.1.5A; the originating UE supporting the precondition mechanism should make use of the precondition
mechanism, even if it does not require local resource reservation.
Upon generating an initial INVITE request using the precondition mechanism, the UE shall:
- indicate the support for reliable provisional responses and specify it using the Supported header field; and
- indicate the support for the preconditions mechanism and specify it using the Supported header field.
Upon generating an initial INVITE request using the precondition mechanism, the UE shall not indicate the requirement
for the precondition mechanism by using the Require header field.
During the session initiation, if the originating UE indicated the support for the precondition mechanism in the initial
INVITE request and:
a) the received response with an SDP body includes a Require header field with "precondition" option-tag, the
originating UE shall include a Require header field with the "precondition" option-tag:
- in subsequent requests that include an SDP body, that the originating UE sends in the same dialog as the
response is received from; and
- in responses with an SDP body to subsequent requests that include an SDP body and include "precondition"
option-tag in Supported header field or Require header field received in-dialog; or
b) the received response with an SDP body does not include the "precondition" option-tag in the Require header
field,
- in subsequent requests that include an SDP body, the originating UE shall not include a Require or Supported
header field with "precondition" option-tag in the same dialog;
- in responses with an SDP body to subsequent requests with an SDP body but without "precondition" option-
tag in the Require or Supported header field, the originating UE shall not include a Require or Supported
header field with "precondition" option-tag in the same dialog; and
ETSI
- in responses with an SDP body to subsequent requests with an SDP body and with "precondition" option-tag
in the Require or Supported header field, the originating UE shall include a Require header field with
"precondition" option-tag in the same dialog.
NOTE 2: Table A.4 specifies that UE support of forking is required in accordance with RFC 3261 [26]. The UE can
accept or reject any of the forked responses, for example, if the UE is capable of supporting a limited
number of simultaneous transactions or early dialogs.
Upon successful reservation of local resources the UE shall confirm the successful resource reservation (see
subclause 6.1.2) within the next SIP request.
NOTE 3: In case of the precondition mechanism being used on both sides, this confirmation will be sent in either a
PRACK request or an UPDATE request. In case of the precondition mechanism not being supported on
one or both sides, alternatively a reINVITE request can be used for this confirmation after a 200 (OK)
response has been received for the initial INVITE request, in case the terminating UE does not support
the PRACK request (as described in RFC 3262 [27]) and does not support the UPDATE request (as
described in RFC 3311 [29]).
NOTE 4: The UE can receive a P-Early-Media header field authorizing an early-media flow while the required
preconditions, if any, are not met and/or the flow direction is not enabled by the SDP direction parameter.
According to RFC 5009 [109], an authorized early-media flow can be established only if the necessary
conditions related to the SDP negotiation are met. These conditions can evolve during the session
establishment.
NOTE 5: When the UE is confirming the successful resource reservation using an UPDATE request (or a PRACK
request) and the UE receives a 180 (Ringing) response or a 200 (OK) response to the initial INVITE
request before receiving a 200 (OK) response to the UPDATE request (or a 200 (OK) response to the
PRACK request), the UE does not treat this as an error case and does not release the session.
NOTE 6: The UE procedures for rendering of the received early media and of the locally generated communication
progress information are specified in 3GPP TS 24.628 [8ZF].
[TS 24.229, clause 5.1.5A]:
The precondition disabling policy indicates whether the UE is allowed to use the precondition mechanism or whether
the UE is not allowed to use the precondition mechanism.
If the precondition disabling policy is not configured, the precondition disabling policy is assumed to indicate that the
UE is allowed to use the precondition mechanism.
The UE may support the precondition disabling policy.
If the UE supports the precondition disabling policy, the UE may support being configured with the precondition
disabling policy using one or more of the following methods:
a) the Precondition_disabling_policy node of the EFIMSConfigData file described in 3GPP TS 31.102 [15C];
b) the Precondition_disabling_policy node of the EFIMSConfigData file described in 3GPP TS 31.103 [15B]; and
c) the Precondition_disabling_policy node of 3GPP TS 24.167 [8G].
If the UE is configured with both the Precondition_disabling_policy node of 3GPP TS 24.167 [8G] and the
Precondition_disabling_policy node of the EFIMSConfigData file described in 3GPP TS 31.102 [15C] or
3GPP TS 31.103 [15B], then the Precondition_disabling_policy node of the EFIMSConfigData file shall take precedence.
NOTE: Precedence for files configured on both the USIM and ISIM is defined in 3GPP TS 31.103 [15B].
The precondition mechanism is disabled, if the UE supports the precondition disabling policy and the precondition
disabling policy indicates that the UE is not allowed to use the precondition mechanism.
The precondition mechanism is enabled, if:
1) the UE does not support the precondition disabling policy; or
2) the UE supports the precondition disabling policy and the precondition disabling policy indicates that the UE is
allowed to use the precondition mechanism.
ETSI
[TS 24.229, clause 6.1.1]:
In order to authorize the media streams, the P-CSCF and S-CSCF have to be able to inspect SDP message bodies.
Hence, the UE shall not encrypt SDP message bodies.
During the session establishment procedure, and during session modification procedures, SIP messages shall only
contain an SDP message body if that is intended to modify the session description, or when the SDP message body is
included in the message because of SIP rules described in RFC 3261 [26].
NOTE 1: A codec can have multiple payload type numbers associated with it.
In order to support accurate bandwidth calculations, the UE may include the "a=ptime" attribute for all "audio" media
lines as described in RFC 4566 [39]. If a UE receives an "audio" media line with "a=ptime" specified, the UE should
transmit at the specified packetization rate. If a UE receives an "audio" media line which does not have "a=ptime"
specified or the UE does not support the "a=ptime" attribute, the UE should transmit at the default codec packetization
rate as defined in RFC 3551 [55A]. The UE will transmit consistent with the resources available from the network.
For "video" and "audio" media types that use the RTP/RTCP and where the port number is not zero, the UE shall
specify the proposed bandwidth for each media stream using the "b=" media descriptor and the "AS" bandwidth
modifier in the SDP.
NOTE 2: The above is the minimum requirement for all UEs. Additional requirements can be found in other
specifications.
If the media line in the SDP message body indicates the usage of RTP/RTCP, and if the UE is configured to request an
RTCP bandwidth level for the session is different than the default RTCP bandwidth as specified in RFC 3556 [56], then
in addition to the "AS" bandwidth modifier in the media-level "b=" line, the UE shall include two media-level "b="
lines, one with the "RS" bandwidth modifier and the other with the "RR" bandwidth modifier as described in
RFC 3556 [56] to specify the required bandwidth allocation for RTCP. The bandwidth-value in the b=RS: and b=RR:
lines may include transport overhead as described in subclause 6.1 of RFC 3890 [152].
If an in-band DTMF codec is supported by the application associated with an audio media stream, then the UE shall
include, in addition to the payload type numbers associated with the audio codecs for the media stream, for each clock
rate associated with the audio codecs for the media stream, a payload type number associated with the MIME subtype
"telephone-event", to indicate support of in-band DTMF as described in RFC 4733 [23].
The UE shall inspect the SDP message body contained in any SIP request or response, looking for possible indications
of grouping of media streams according to RFC 3524 [54] and perform the appropriate actions for IP-CAN bearer
establishment for media according to IP-CAN specific procedures (see subclause B.2.2.5 for IP-CAN implemented
using GPRS, subclause L.2.2.5 for IP-CAN implemented using EPS, and subclause U.2.2.5 for IP-CAN implemented
using 5GS).
In case of UE initiated resource reservation and if the UE determines resource reservation is needed, the UE shall start
reserving its local resources whenever it has sufficient information about the media streams, media authorization and
used codecs available.
NOTE 4: Based on this resource reservation can, in certain cases, be initiated immediately after the sending or
receiving of the initial SDP offer.
If the desired QoS resources for one or more media streams have not been reserved at the UE when constructing the
SDP offer, the UE:
- shall indicate the related local preconditions for QoS as not met, using the segmented status type, as defined in
RFC 3312 [30] and RFC 4032 [64], as well as the strength-tag value "mandatory" for the local segment and the
strength-tag value either "optional" or as specified in RFC 3312 [30] and RFC 4032 [64] for the remote segment,
if the UE uses the precondition mechanism (see subclause 5.1.3.1); and
- if the UE uses the precondition mechanism (see subclause 5.1.3.1), shall not request confirmation for the result
of the resource reservation (as defined in RFC 3312 [30]) at the terminating UE.
ETSI
NOTE 1: Previous versions of this document mandated the use of the SDP inactive attribute. This document does
not prohibit specific services from using direction attributes to implement their service-specific
behaviours.
If the UE uses the precondition mechanism (see subclause 5.1.3.1), and the desired QoS resources for one or more
media streams are available at the UE when the SDP offer is sent, the UE shall indicate the related local preconditions
as met, using the segmented status type, as defined in RFC 3312 [30] and RFC 4032 [64], as well as the strength-tag
value "mandatory" for the local segment and the strength-tag value either "optional" or as specified in RFC 3312 [30]
and RFC 4032 [64] for the remote segment and shall not request confirmation for the result of the resource reservation
(as defined in RFC 3312 [30]) at the terminating UE.
Upon confirming successful local resource reservation, the UE shall create an SDP offer in which the related local
preconditions are set to met, using the segmented status type, as defined in RFC 3312 [30] and RFC 4032 [64].
Upon receiving an SDP answer, which includes more than one codec per media stream, excluding the in-band DTMF
codec, as described in subclause 6.1.1, the UE shall:
- send an SDP offer at the first possible time, selecting only one codec per media stream; or
- if the UE is participant in a multi-stream multiparty multimedia conference session using simulcast (indicated by
the presence of "a=simulcast" SDP attribute(s) in the SDP answer, as defined in draft-ietf-mmusic-sdp-
simulcast [249]), apply the procedures defined in 3GPP TS 26.114 [9B] annex S.
[TS 26.114, clause 5.2.1.1]:
MTSI clients in terminals offering speech communication shall support narrowband, wideband and super-wideband
communication.
In addition, MTSI clients in terminals offering speech communication shall support:
- AMR speech codec (3GPP TS 26.071 [11], 3GPP TS 26.090 [12], 3GPP TS 26.073 [13] and
3GPP TS 26.104 [14]) including all 8 modes and source controlled rate operation 3GPP TS 26.093 [15]. The
MTSI client in terminal shall be capable of operating with any subset of these 8 codec modes. More detailed
codec requirements for the AMR codec are defined in clause 5.2.1.2.
MTSI clients in terminals offering wideband speech communication at 16 kHz sampling frequency shall support:
- AMR-WB codec (3GPP TS 26.171 [17], 3GPP TS 26.190 [18], 3GPP TS 26.173 [19] and 3GPP TS 26.204 [20])
including all 9 modes and source controlled rate operation 3GPP TS 26.193 [21]. The MTSI client in terminal
shall be capable of operating with any subset of these 9 codec modes. More detailed codec requirements for the
AMR-WB codec are defined in clause 5.2.1.3. When the EVS codec is supported, the EVS AMR-WB IO mode
may serve as an alternative implementation of AMR-WB as defined in clause 5.2.1.4.
MTSI clients in terminals offering super-wideband or full band speech communication shall support:
- EVS codec ( TS 26.441 [121], TS 26.444 [124], TS 26.445 [125], TS 26.447 [127], TS 26.451 [131],
TS 26.442 [122] and TS 26.443 [123]) as described below including functions for backwards compatibility with
AMR-WB ( TS 26.446 [126]) and discontinuous transmission ( TS 26.449 [129] and TS 26.450 [130]). More
detailed codec requirements for the EVS codec are defined in clause 5.2.1.4.
[TS 26.114, clause 6.2.5.1]:
The SDP shall include bandwidth information for each media stream and also for the session in total. The bandwidth
information for each media stream and for the session is defined by the Application Specific (AS) bandwidth modifier
as defined in RFC 4566 [8].
The bandwidth for RTCP traffic shall be described using the "RS" and "RR" SDP bandwidth modifiers at media level,
as specified by RFC 3556 [42]. Therefore, an MTSI client shall include the "b=RS:" and "b=RR:" fields in SDP, and
shall be able to interpret them. There shall be an upper limit on the allowed RTCP bandwidth for each RTP session
signalled by the MTSI client. This limit is defined as follows:
- 8 000 bps for the RS field (at media level);
ETSI
- 6 000 bps for the RR field (at media level).
The RS and RR values included in the SDP answer should be treated as the negotiated values for the session and should
be used to calculate the total RTCP bandwidth for all terminals in the session.
If the session described in the SDP is a point-to-point speech only session, the MTSI client may request the deactivation
of RTCP by setting its RTCP bandwidth modifiers to zero.
If a MTSI client receives SDP bandwidth modifiers for RTCP equal to zero from the originating MTSI client, it should
reply (via the SIP protocol) by setting its RTCP bandwidth using SDP bandwidth modifiers with values equal to zero.
7.4.2A Profile requirements (Informative)
[NG.114 Version 1.0, clause 2.3.4.1]:
The ICSI value used must indicate the IMS Multimedia Telephony service, which is urn:urn-7:3gpp-
service.ims.icsi.mmtel, as specified in 3GPP TS 24.173 [10].
The UE must include the audio and video media feature tags, as defined in IETF RFC 3840 [18], in the Contact header
field of the SIP INVITE request, and in the Contact header field of the SIP response to the SIP INVITE request, as
specified in 3GPP TS 24.229 [8].
[NG.114 Version 1.0, clause 2.3.5]:
For MMTEL Voice/Conversational Video sessions, the UE must support the preconditions mechanism as specified in
sections 5.1.3.1 and 5.1.4.1 of 3GPP TS 24.229 [8]. If the precondition mechanism is enabled by the
Precondition_disabling_policy node in Annex C.3, the UE must use the precondition mechanism. If preconditions are
used, and the originating UE receives the selected codec in the SDP of a SIP 18x response, then the UE must include
only the same codec with its selected configuration parameters in the SDP of the SIP UPDATE request, used for
precondition status update.
[NG.114 Version 1.0 and 2.0, clause 3.2.2.1]:
The UE must include in an initial SDP offer at least:
1. one EVS payload type with one of the configurations supporting super-wideband speech as defined in section 3.2.2.3
of this document.
2. one AMR-WB payload type with no mode-set specified as defined in table 6.1 of 3GPP TS 26.114 [16].
3. one AMR payload type with no mode-set specified as defined in table 6.1 of 3GPP TS 26.114 [16].
The codec preference order must be as specified in sections 5.2.1.5 and 5.2.1.6 of 3GPP TS 26.114 [16].
[NG.114 Version 1.0, clause 3.2.2.2 on AMR and AMR-WB]:
The UE must set the b=AS to match the highest codec mode for the offer (maximum codec bit rate if no mode set is
included).
[NG.114 Version 1.0 and 2.0, clause 3.2.2.3 on EVS]:
The UE that sends the SDP offer for voice media must include in this SDP offer at least one EVS payload type with one
of the following EVS configurations:
1. EVS Configuration A1: br=5.9-13.2; bw=nb-swb.
3. EVS Configuration B0: br=13.2; bw=swb.
4. EVS Configuration B1: br=9.6-13.2; bw=swb.
ETSI
SDP parameters other than br, bw, max-red and ch-aw-recv must not be included in a media format description
associated with the EVS codec within the initial SDP offer (for a list of SDP parameters see table 6.2a in 3GPP TS
26.114 [16]).
The configuration of the EVS payload type to be included first in the initial SDP offer for EVS is defined by the
EVS/Br and EVS/Bw parameters as specified in Annex C.3, which must be configured to one of the five above EVS
Configurations.
The UE and the entities in the IMS core network that terminate the user plane must set the ptime attribute value to
receive one speech frame encapsulated in each RTP packet, but must accept any number of frames per RTP packet, up
to the maximum limit of 12 speech frames per RTP packet.
Note 1: This means that the ptime attribute must be set to 20 and the maxptime attribute must be set to 240 in the
SDP negotiation.
System Simulator:
UE:
- The UE is configured to use preconditions
Preamble:
- UE is in state 1N-A (TS 38.508-1 [21]) and registered to IMS
ETSI

U-S Message
1A- Steps 2-7 of generic procedure specified in - - - -
1F Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
- EXCEPTION: In parallel to step 2 below, the - - - -
steps specified in Table 7.4.3.2-2 are
performed.
2 UE sends INVITE with first SDP offer --> INVITE 1 P
(Step 1 of Annex A.4.1)
3 SS sends a 100 Trying provisional response <-- 100 Trying - -
4 SS sends an SDP answer <-- 183 Session Progress - -
5 UE acks 183 Session Progress --> PRACK 2 P
6 SS responds to PRACK <-- 200 OK - -
6A Step 10 of the generic procedure specified in - - - -
Table 4.9.15.2.2-1 of TS 38.508-1 [21] is
performed.
EXCEPTION: In parallel to steps 6B and 6C - - - -
below, step 7 occurs.
6B- Steps 11-12 of the generic procedure specified - - - -
6C in Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
7 UE sends UPDATE with second SDP offer --> UPDATE 3 P
8 SS sends an SDP answer <-- 200 OK - -
9 SS sends 180 Ringing reliably <-- 180 Ringing - -
10 UE acks 180 Ringing --> PRACK 4 P
12 SS responds to INVITE <-- 200 OK - -
13 UE acks 200 OK for INVITE --> ACK 5 P

U-S Message
1 Step 8 of the generic procedure specified in - - - -
Table 4.9.15.2.2-1 of TS 38.508-1 [21] is
performed.
None as fully described in Annex A.4.1.
ETSI
7.4a MTSI MO Voice Call with preconditions at both originating

UE and terminating UE / Default Configuration / 5GS
7.4a.1 Test Purpose (TP)
(1)
with { UE being registered to IMS and configured to use preconditions and configured to use the EVS
default configuration included first in the initial SDP offer }
ensure that {
then { UE sends INVITE for voice call with preconditions and EVS default configuration }
}
(2)
ensure that {
}
(3)
ensure that {
when { UE receives 200 OK for PRACK and resources are available }
}
(4)
ensure that {
}
(5)
ensure that {
}
7.4a.2 Conformance Requirements
Same as test case 7.4.
7.4a.2A Profile requirements (Informative)
Same as test case 7.4 with the following additions:
[NG.114 Version 1.0 and 2.0, clause 3.2.2.3]:
The configuration of the EVS payload type to be included first in the initial SDP offer for EVS is defined by the
EVS/Br and EVS/Bw parameters as specified in Annex C.3, which must be configured to one of the five above EVS
Configurations.
[NG.114 Version 1.0 and 2.0, clause C.3]:
Table C.3-1 contains the configuration parameters with their default values, that must be supported by the UE and the
network. The UE must use the default value for each parameter in Table C.3-1 unless configured differently as
described in Annex C.2.
ETSI
EVS/Br 5.9-24.4 Section 15.2 of 3GPP TS 26.114 [16] 3.2.2.3

(/<X>/Speech/<X>/EVS/Br) and section 5 of
3GPP TS 26.441 [56] (Table 1)
EVS/Bw nb-swb Section 15.2 of 3GPP TS 26.114 [16] 3.2.2.3
(/<X>/Speech/<X>/EVS/Bw) and section 5 of
3GPP TS 26.441 [56] (Table 1)
7.4a.3 Test description
7.4a.3.1 Pre-test conditions
System Simulator:
UE:
- The UE is configured to use preconditions.
Preamble:
- UE is in state 1N-A (TS 38.508-1 [21]) and registered to IMS.
ETSI
7.4a.3.2 Test procedure sequence
Table 7.4a.3.2-1: Main Behaviour

U-S Message
1F Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
behaviour defined in table 7.4a.3.2-2 takes
place
2 UE sends INVITE with first SDP offer --> INVITE 1 P
(Step 1 of Annex A.4.1a)
5 UE acks 183 Session Progress --> PRACK 2 P
6A Step 10 of generic procedure specified in Table - - - -
- EXCEPTION: In parallel to steps 6B and 6C - - - -
6B- Steps 11-12 of generic procedure specified in - - - -
6C Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
7 UE sends UPDATE with second SDP offer --> UPDATE 3 P
8 SS sends an SDP answer <-- 200 OK - -
9 SS sends 180 Ringing reliably <-- 180 Ringing - -
10 UE acks 180 Ringing --> PRACK 4 P
12 SS responds to INVITE <-- 200 OK - -
13 UE acks 200 OK for INVITE --> ACK 5 P
14- SS releases the call. - - - -
15 (Annex A.8)
Table 7.4a.3.2-2: Parallel behaviour

U-S Message
7.4a.3.3 Specific message contents
None.
ETSI
7.5 MTSI MO Voice Call without preconditions at both

originating UE and terminating UE / 5GS
(1)
with { UE being registered to IMS and configured to not use preconditions }
ensure that {
then { UE sends INVITE for voice call without preconditions }
}
(2)
with { UE having sent INVITE without preconditions }
ensure that {
when { UE receives 183 Session Progress without preconditions }
}
(3)
ensure that {
when { UE receives 200 OK for PRACK followed by 180 Ringing followed by 200 OK for INVITE }
}
As described in 7.4.2 except:
[TS 24.229, clause 5.1.3.1]:
mechanism.
[TS 24.229, clause 5.1.5A]:
The precondition disabling policy indicates whether the UE is allowed to use the precondition mechanism or whether
the UE is not allowed to use the precondition mechanism.
If the precondition disabling policy is not configured, the precondition disabling policy is assumed to indicate that the
UE is allowed to use the precondition mechanism.
The UE may support the precondition disabling policy.
If the UE supports the precondition disabling policy, the UE may support being configured with the precondition
disabling policy using one or more of the following methods:
a) the Precondition_disabling_policy node of the EFIMSConfigData file described in 3GPP TS 31.102 [15C];
b) the Precondition_disabling_policy node of the EFIMSConfigData file described in 3GPP TS 31.103 [15B]; and
c) the Precondition_disabling_policy node of 3GPP TS 24.167 [8G].
ETSI
If the UE is configured with both the Precondition_disabling_policy node of 3GPP TS 24.167 [8G] and the
Precondition_disabling_policy node of the EFIMSConfigData file described in 3GPP TS 31.102 [15C] or
3GPP TS 31.103 [15B], then the Precondition_disabling_policy node of the EFIMSConfigData file shall take precedence.
NOTE: Precedence for files configured on both the USIM and ISIM is defined in 3GPP TS 31.103 [15B].
The precondition mechanism is disabled, if the UE supports the precondition disabling policy and the precondition
disabling policy indicates that the UE is not allowed to use the precondition mechanism.
The precondition mechanism is enabled, if:
1) the UE does not support the precondition disabling policy; or
2) the UE supports the precondition disabling policy and the precondition disabling policy indicates that the UE is
allowed to use the precondition mechanism.
[TS 24.229, clause 6.1.2]:
System Simulator:
UE:
- The UE is configured to not use preconditions.
Preamble:
- The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS.
ETSI

U-S Message
1F Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
2 Step 1 of Annex A.4.2 happens --> INVITE 1 P
3 Step 2 of Annex A.4.2 happens <-- 100 Trying - -
4 Step 3 of Annex A.4.2 happens <-- 183 Session Progress - -
5 Step 4 of Annex A.4.2 happens --> PRACK 2 P
6 Step 5 of Annex A.4.2 happens <-- 200 OK
6C Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
7 Step 6 of \Annex A.4.2 happens <-- 180 Ringing - -
8 Step 7 of Annex A.4.2 happens <-- 200 OK - -
9 Step 8 of Annex A.4.2 happens --> ACK 3 P

U-S Message
None as fully described in annex A.4.2.
ETSI
7.6 MTSI MT Voice Call with preconditions at both originating

UE and terminating UE / 5GS
(1)
ensure that {
when { UE receives INVITE for voice call }
then { UE responds with 183 Session Progress including SDP }
}
(2)
with { UE having sent 183 Session Progress }
ensure that {
when { UE receives PRACK for 183 Session Progress }
then { UE sends 200 OK for PRACK }
}
(3)
with { UE having sent 200 OK for PRACK }
ensure that {
when { UE receives UPDATE including SDP }
then { UE sends 200 OK for UPDATE including SDP and 180 Ringing }
}
(4)
with { UE having sent 180 Ringing, possibly reliably }
ensure that {
when { 180 was sent reliably and consequently UE receives PRACK for 180 Ringing }
}
(5)
with { UE having sent 180 Ringing }
ensure that {
when { User accepts the incoming voice call request }
then { UE sends 200 OK for INVITE }
}
(6)
with { UE having sent 200 OK for INVITE }
ensure that {
when { UE receives ACK followed by BYE }
then { UE sends 200 OK for BYE }
}
[TS 24.229, clause 5.1.4.1]
If an initial INVITE request is received the terminating UE shall check whether the terminating UE requires local
resource reservation.
NOTE 1: The terminating UE can decide if local resource reservation is required based on e.g. application
During the session initiation, if local resource reservation is required at the terminating UE and the terminating UE
supports the precondition mechanism, and:
ETSI
a) the received INVITE request includes the "precondition" option-tag in the Supported header field or Require
header field and the precondition mechanism is enabled as specified in subclause 5.1.5A, the terminating UE
shall use the precondition mechanism and shall include a Require header field with the "precondition" option-
tag:
If the terminating UE included an SDP offer or an SDP answer in a reliable provisional response to the INVITE request
and both the terminating UE and the originating UE support UPDATE method, then in order to remove one or more
media streams negotiated in the session for which a final response to the INVITE request has not been sent yet, the
terminating UE shall send an UPDATE request with a new SDP offer and delays sending of 200 (OK) response to the
INVITE request till after reception of 200 (OK) response to the UPDATE request.
If the user does not accept a media stream accepted in the SDP answer and the terminating UE, the originating UE or
both do not support the UPDATE method, then after reception of ACK request related to 200 (OK) response to the
INVITE request, the UE shall modify the session.
The terminating UE shall include the media feature tags as defined in RFC 3840 [62] for all supported streaming media
types in the SIP response other than the 100 (Trying) response to the SIP INVITE request.
[TS 24.229, clause 6.1.1]
[TS 24.229, clause 6.1.3]
If the terminating UE had previously set one or more media streams to inactive mode and the QoS resources for those
media streams are now ready, the UE shall set the media streams to active mode by applying the procedures described
in RFC 4566 [39] with respect to setting the direction of media streams.
Upon sending an SDP answer to an SDP offer, with the SDP answer including one or more media streams for which the
originating side did indicate its local preconditions as not met, if the precondition mechanism is used by the terminating
UE (see subclause 5.1.4.1), the terminating UE shall indicate its local preconditions and request the confirmation for the
result of the resource reservation at the originating end point.
[TS 26.114, clause 5.2.1]
- AMR speech codec (3GPP TS 26.071 [11], 3GPP TS 26.090 [12], 3GPP TS 26.073 [13] and
[TS 26.114, clause 6.2.2.1]
An MTSI client offering a speech media session for narrow-band speech and/or wide-band speech should generate an
SDP offer according to the examples in Annexes A.1 to A.3. An MTSI client offering EVS should generate an SDP
offer according to the examples in Annex A.14.
An MTSI client in terminal supporting EVS should support the RTCP-APP signalling for speech adaptation defined
clause 10.2.1, and shall support the RTCP-APP signalling when the MTSI client in terminal supports adaptation for call
cases where the RTP-based CMR cannot be used.
[TS 26.114, clause 6.2.5]
[TS 26.114, clause 7.3.1]
ETSI
as specified by RFC 3556 [42].
7.6.2A Profile requirements (Informative)
For MMTEL Voice/Conversational Video sessions, the UE must support the preconditions mechanism as specified in
sections 5.1.3.1 and 5.1.4.1 of 3GPP TS 24.229 [8]. If the precondition mechanism is enabled by the
Precondition_disabling_policy node in Annex C.3, the UE must use the precondition mechanism.
[NG.114 Version 1.0, clause 3.2.2.3]:
A UE must answer according to both the received SDP Offer and the UE's EVS configuration (i.e. EVS/Br and
EVS/Bw parameters as specified in see Annex C.3) as described in Table 3.2.2.3-1 below:
EVS configuration of the UE that received the SDP Offer

Received A1 A2 B0 B1 B2
SDP Offer
for EVS
(preferred
payload
type listed
first)
A1 A1 A1 A1 A1 A1
A2 A1 A2 A1 A1 A2
B0 B0 B0 B0 B0 B0
B1 A1 A1 B1 B1 B1
B2 A1 A2 B1 B1 B2
Note 2: This table applies only to received SDP Offers compliant with this PRD, i.e. including A1, if B0 or B1 are
listed first and including A2, if B2 is listed first.
If the selected EVS configuration is A1, B0 or B1 then "mode set = 0,1,2" must be included in the SDP answer.
The UE must add only SDP parameters that are applicable to EVS in the SDP answer that are already present in the
corresponding received and accepted SDP Offer. If SDP parameters applicable to EVS, are included in the accepted
SDP offer, then the UE must handle these parameters as specified in 3GPP TS 26.445 [58].
If the SDP parameter ch-aw-recv is present in the corresponding received and accepted SDP offer, then the SDP
parameter ch-aw-recv must be included in the SDP answer with the same value as received.
Default values as specified in 3GPP TS 26.445 [58] apply for all other SDP parameters applicable to EVS that are not
included in the SDP Answer.
System Simulator:
UE:
ETSI
Preamble:

U-S Message
0H Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
1 SS sends INVITE for voice call <-- INVITE - -
(Step 1 of Annex A.5.1) happens
2 UE may send 100 Trying response --> 100 Trying - -
(Step 2 of Annex A.5.1) happens
3 UE sends 183 Session Progress response --> 183 Session Progress 1 P
4 SS sends PRACK <-- PRACK - -
5 UE sends 200 OK for PRACK --> 200 OK 2 P
5C Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
6 SS sends UPDATE <-- UPDATE - -
7 UE sends 200 OK for UPDATE --> 200 OK 3 P
8 UE sends 180 Ringing --> 180 Ringing - -
9 SS sends PRACK if 180 Ringing was sent <-- PRACK - -
reliably
10 UE sends 200 OK for PRACK if SS sent --> 200 OK 4 P
PRACK
10A Make UE accept the voice call - - - -
11 UE accepts the call --> 200 OK 5 P
12 SS sends ACK <-- ACK - -
13 SS releases the call <-- BYE - -
(Step 1 of Annex A.8)
14 UE sends 200 OK for BYE --> 200 OK 6 P
None as fully described in Annexes A.5.1 and A.8.
ETSI
7.6a MTSI MT Voice Call with preconditions at both originating

UE and terminating UE / Default Configuration / 5GS
(1)
ensure that {
when { UE receives INVITE for voice call with preconditions and to use the EVS default
configuration }
then { UE responds with 183 Session Progress including SDP accepting the EVS default
configuration}
}
(2)
ensure that {
}
(3)
ensure that {
}
(4)
ensure that {
when { UE receives PRACK for 180 Ringing }
}
(5)
ensure that {
when { User accepts the incoming voice call request }
}
(6)
ensure that {
}
Same as TC 7.6.
7.6a.2A Profile requirements (Informative)
Same as TC 7.6 with the following additions:
[NG.114 Version 1.0 and 2.0, clause C.3]:
ETSI
Table C.3-1 contains the configuration parameters with their default values, that must be supported by the UE and the
network. The UE must use the default value for each parameter in Table C.3-1 unless configured differently as
described in Annex C.2.
Reliable 18x policy 1 – Indicates Section 5.56 of 3GPP TS 24.167 [67] (/<X>/ 2.2.4
(Sending SIP 18x reliably) that the SIP 18x Reliable_18x_policy /<X>/
responses Send_18x_Reliably)
(other than SIP and 3GPP TS 24.229 [8]
183 response)
are to be sent
reliably
Same as TC 7.6.

U-S Message
0H Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
1 SS sends INVITE for voice call <-- INVITE - -
(Step 1 of Annex A.5.1a) happens
2 UE may send 100 Trying response --> 100 Trying - -
(Step 2 of Annex A.5.1a) happens
3 UE sends 183 Session Progress response --> 183 Session Progress 1 P
4 SS sends PRACK <-- PRACK - -
5 UE sends 200 OK for PRACK --> 200 OK 2 P
5C Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
6 SS sends UPDATE <-- UPDATE - -
7 UE sends 200 OK for UPDATE --> 200 OK 3 P
8 UE sends 180 Ringing --> 180 Ringing - -
9 SS sends PRACK if 180 Ringing was sent <-- PRACK - -
reliably
10 UE sends 200 OK for PRACK if SS sent --> 200 OK 4 P
PRACK
10A Make UE accept the voice call - - - -
11 UE accepts the call --> 200 OK 5 P
13 SS releases the call <-- BYE - -
14 UE sends 200 OK for BYE --> 200 OK 6 P
ETSI
None.
7.7 MTSI MT Voice Call without preconditions at both

(1)
ensure that {
then { UE may respond with 100 Trying and then sends 183 Session Progress with SDP without
preconditions }
}
(2)
ensure that {
}
(3)
ensure that {
when { UE is ready to start the call }
then { UE sends 180 Ringing followed by 200 OK for INVITE }
}
[TS 24.229, annex U.3.1.4]:
Upon receiving an INVITE request not including the "precondition" option-tag in the Supported header field and not
including the "precondition" option-tag in the Require header field, and the IP-CAN performs network-initiated
resource reservation for the UE, the UE:
1) if the INVITE request contains an SDP offer and the local resources required at the terminating UE for the
received SDP offer are not available:
a) shall not alert the user; and
b) shall send 183 (Session Progress) response to the INVITE request without waiting for resource reservation
and without alerting the user. If the INVITE request includes a Supported header field indicating support of
reliable provisional responses, the UE shall send the 183 (Session Progress) response reliably. In the 183
(Session Progress) response, the UE shall include an SDP answer; and
2) if the INVITE request does not contain an SDP offer and the INVITE request includes a Supported header field
indicating support of reliable provisional responses:
a) shall generate an SDP offer;
b) if the local resources required at the terminating UE for the generated SDP offer are not available:
A) shall not alert the user; and
ETSI
B) shall reliably send 183 (Session Progress) response to the INVITE request without waiting for resource
reservation and without alerting the user. In the 183 (Session Progress) response, the UE shall include the
generated SDP offer.
Upon successful reservation of local resources, if the precondition mechanism is not used by the terminating UE, the
UE can send 180 (Ringing) response to the INVITE request and can alert the user.
System Simulator:
UE:
Preamble:

U-S Message
0A- Steps 1-8 of generic procedure specified in - -
0H Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
1 SS sends INVITE with SDP offer <-- INVITE
2 UE may send a 100 Trying provisional response --> 100 Trying
3 UE sends SDP answer --> 183 Session Progress 1 P
4 SS acks reception of 183 Session Progress <-- PRACK
5 UE responds to PRACK --> 200 OK 2 P
5C Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
6 UE sends 180 Ringing --> 180 Ringing 3 P
7 If 180 Ringing was sent reliably, SS sends <-- PRACK
PRACK (Step 7 of Annex A.5.2)
8 If 180 Ringing was sent reliably, UE sends 200 --> 200 OK
OK for PRACK (Step 8 of Annex A.5.2)
8A Make the UE accept the voice call.
9 UE accepts the voice call --> 200 OK
10 SS acknowledges <-- ACK
ETSI
ETSI
7.8 MTSI MT Voice Call without preconditions at originating UE

and with preconditions at terminating UE / 5GS
(1)
ensure that {
when { UE receives INVITE for voice call without precondition option-tag in Require or Supported
header }
then { UE completes setup of voice call without preconditions }
}
[TS 24.229, clause 5.1.4.1]
tag:
- in responses to that INVITE request if those responses include an SDP body;
- in responses to subsequent requests received in-dialog that include an SDP body and include "precondition"
option-tag in Supported header field or Require header field; and
- in subsequent requests that include an SDP body, that it sends towards the originating UE during the session
initiation;
b) the received INVITE request includes the "precondition" option-tag in the Supported header field, and the
precondition mechanism is disabled as specified in subclause 5.1.5A, the terminating UE shall not use the
precondition mechanism:
c) the received INVITE request includes the "precondition" option-tag in the Require header field, and the
precondition mechanism is disabled as specified in subclause 5.1.5A, the terminating UE shall reject the INVITE
request with a 420 (Bad Extension) response; and
d) the received INVITE request does not include the "precondition" option-tag in the Supported header field or
Require header field, the terminating UE shall not use the precondition mechanism.
System Simulator:
ETSI
UE:
- UE is configured to use preconditions.
Preamble:
- The UE has registered to IMS and set up an MO voice call, by executing the generic test procedure in Annex A.2
up to the last step and thereafter executing the generic test procedure in Annex A.4.1. The SS then ends the MO
voice call by sending BYE.

U-S Message
Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
9-13 Steps 1-5 of Annex A.5.2 happens - - - -
13C Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
14- Steps 6-8 of Annex A.5.2 happen. - - - -
16
18 Step 10 of Annex A.5.2 happens <-- ACK - -
ETSI
7.9 MTSI MT Voice Call with preconditions at originating UE

and without preconditions at terminating UE / 5GS
(1)
ensure that {
when { UE receives INVITE for voice call with preconditions }
then { UE completes setup of voice call without preconditions }
}
[TS 24.229, clause 5.1.4.1]
tag:
initiation;
System Simulator:
UE:
ETSI
Preamble:

U-S Message
Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
9 Step 1 of Annex A.5.1 happens. <-- INVITE - -
13
13C Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
16
17 Step 9 of Annex A.5.2 happens. --> 200 OK 1 P
18 Step 10 of Annex A.5.2 happens. <-- ACK - -
None as fully described in annex A.5.1 and A.5.2.
ETSI
7.10 MTSI MT Voice call without preconditions and without SDP

offer in MT INVITE / 5GS
(1)
ensure that {
when { UE receives INVITE for voice call not containing an SDP offer, but indicating support for
reliable provisional responses }
then { UE sends 183 Session Progress reliably and containing an SDP offer }
}
(2)
ensure that {
}
(3)
ensure that {
}
[TS 24.229, annex U.3.1.4]:
Upon receiving an INVITE request not including the "precondition" option-tag in the Supported header field and not
including the "precondition" option-tag in the Require header field, and the IP-CAN performs network-initiated
resource reservation for the UE, the UE:
2) if the INVITE request does not contain an SDP offer and the INVITE request includes a Supported header field
indicating support of reliable provisional responses:
a) shall generate an SDP offer;
b) if the local resources required at the terminating UE for the generated SDP offer are not available:
A) shall not alert the user; and
B) shall reliably send 183 (Session Progress) response to the INVITE request without waiting for resource
reservation and without alerting the user. In the 183 (Session Progress) response, the UE shall include the
generated SDP offer.
Upon successful reservation of local resources, if the precondition mechanism is not used by the terminating UE, the
UE can send 180 (Ringing) response to the INVITE request and can alert the user.
ETSI
System Simulator:
UE:
Preamble:
- UE is in state 1N-A (38.508-1[21]) and registered to IMS

U-S Message
1 Steps 1-8 of generic procedure specified in - - - -
Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
2 Step 1 of Annex A.5.2 happens <-- INVITE - -
(Note: the INVITE message doesn’t include an
SDP offer, but includes an option-tag indicating
reliable provisional responses.)
3 Step 2 of Annex A.5.2 happens --> (Optional) 100 Trying - -
(Note: this step is optional.)
4 Check: Does the UE send 183 Session --> 183 Session Progress 1 P
Progress reliably and containing an SDP offer?
(Step 3 of Annex A.5.2 happens)
5 Step 4 of Annex A.5.2 happens <-- PRACK - -
(Note: an SDP answer is included.)
6 Step 5 of Annex A.5.2 happens --> 200 OK 2 P
(Check: does the UE send 200 OK for
PRACK?)
6C Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
7 Step 6 of Annex A.5.2 happens --> 180 Ringing 3 P
(Check: does the UE send 180 Ringing followed
by 200 OK for INVITE?)
8 Step 7 of Annex A.5.2 happens <-- (Conditional) PRACK - -
(Conditional step: if UE sent 180 Ringing
reliably, SS acknowledges reception of 180
Ringing)
9 Step 8 of Annex A.5.2 happens --> (Conditional) 200 OK - -
(Conditional step: if UE sent 180 Ringing
reliably, UE responds to PRACK)
10 Step 9 of Annex A.5.2 happens --> 200 OK - -
11 Step 10 of Annex A.5.2 happens <-- ACK - -
ETSI
Table 7.10.3.3-1: INVITE (step 2, table 7.10.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in subclause A.2.9, Conditions A1, A3, and A4
Content-Type Not present
Content-Length 0
Message-body Not present
ETSI
Table 7.10.3.3-2: 183 Session Progress with an SDP offer (step 4, table 7.10.3.2-1)
ETSI
Derivation Path: TS 34.229-1 [2], Table in annex A.2.3, condition A2

ETSI
Message-body NOTE: the following SDP offer is identical to the SDP offer TS 24.229 [7]
shown in Annex A.4.2, Step 1, apart from video media: the
UE may include addition video media description. These
shall be accepted but not checked.
Session description:
v=0
o=(username) (sess-id) (sess-version) IN (addrtype)
(unicast-address for UE)
s=(session name)
c=IN (addrtype) (connection-address for UE) [Note 1]
b=AS: (bandwidth-value)
Time description:
t= (start-time) (stop-time)
Media description:
m=audio (transport port) RTP/AVP (fmt)
b=RS: (bandwidth-value) [Note 2]
b=RR: (bandwidth-value) [Note 2]
Attributes for media:

a=rtpmap: (payload type) EVS/16000 [Note 3, 9, 10, 12]
a=fmtp: (format) br=5.9-13.2; bw=nb-swb; max-red= (att-
field) [Note 4, 5, 10, 12]
field) [Note 4, 5, 10, 13]
a=fmtp: (format) br=13.2; bw=swb; max-red= (att-field)
[Note 4, 5, 10, 14]
a=fmtp: (format) br=9.6-13.2; bw=swb; max-red= (att-field)
[Note 4, 5, 10, 15]
a=fmtp: (format) br=9.6-24.4; bw=swb; max-red= (att-field)
[Note 4, 5, 10, 16]
a=rtpmap: (payload type) EVS/16000 [Note 3, 9, 11]
a=fmtp: (format) bw=nb-swb; max-red= (att-field) [Note 4,
5, 11]
a=rtpmap: (payload type) AMR-WB/16000 [Note 3, 9]
a=fmtp: (format) mode-change-capability=2; max-red=
(att-field) [Note 4, 6]
a=rtpmap: (payload type) telephone-event/16000
a=fmtp: (format)
a=rtpmap: (payload type) AMR/8000 [Note 3, 9]
a=fmtp: (format)
a=ecn-capable-rtp: leap ect=0 [Note 7]
a=rtcp-fb:* nack ecn [Note 7]
a=rtcp-xr:ecn-sum [Note 7]
a=rtcp-rsize [Note 7]
a=ptime:20
a=maxptime:240
Attributes for media security mechanism:

a=3ge2ae: requested [Note 8]
a=crypto:1
AES_CM_128_HMAC_SHA1_80inline:WVNfX19zZW1jdG
wgKCkgewkyMjA7fQp9CnVubGVz|2^20|
1:4FEC_ORDER=FEC_SRTP" [Note 8]
Note 1: At least one "c=" field shall be present.
ETSI
Note 2: The RR value shall be greater than 0. The RS

value can be any value.
Note 3: The channel number shall be "/1" or omitted.
Note 4: The max-red values from 0 to 220 are allowed.
Note 5: The parameters dtx, dtx-recv and evs-mode-
switch shall not be present.
Note 6: The parameters mode-set, mode-change-period,
mode-change-neighbour, crc, robust-sorting and
interleaving shall not be included.
Note 7: Attributes for ECN Capability may be present if the
UE supports Explicit Congestion Notification.
Note 8: Attributes for media plane security are present if
the use of end-to-access-edge security is supported by
UE.
Note 9: The ordering of payload types shall be as listed,
i.e., EVS before AMR-WB before AMR.
Note 10: The EVS payload type shall carry at least one of
the five EVS configurations according to NG.114 [31]
clause 3.2.2.3. In addition, if there is no further EVS
payload type according to the criteria of Note 11, the
following rules shall be checked:
IF the first EVS payload type is configuration B0 or B1
THEN
there shall be a second EVS payload type with
configuration A1
ELSE IF the first EVS payload type is configuration B2
THEN
there shall be a second EVS payload type with
configuration A2
(NOTE: if the first EVS payload type is configuration
A1 or A2 there does not need to be any further EVS
payload type)
Note 11: Further EVS payload type according to NG.114
[31] clause 3.2.2.3 with bandwidth up to super-wideband,
no br parameter and no mode-set parameter.
Note 12: EVS payload type with EVS Configuration A1
(NG.114 [31] clause 3.2.2.3).
Note 13: EVS payload type with EVS Configuration A2
(NG.114 [31] clause 3.2.2.3).
Note 14: EVS payload type with EVS Configuration B0
(NG.114 [31] clause 3.2.2.3).
(NG.114 [31] clause 3.2.2.3).
(NG.114 [31] clause 3.2.2.3).
ETSI
Table 7.10.3.3-3: PRACK with an SDP answer (step 5, table 7.10.3.2-1)

shown in Annex A.4.2, Step 3, apart from the video media:
if the UE included such lines, SS copies the video media
description and changes the port number to zero.
v=0
o=- 1111111111 1111111111 IN (addrtype) (unicast-
address for SS)
s=-
c=IN (addrtype) (connection-address for SS)
b=AS:65
Time description:
t=0 0
Media description:
m=audio (transport port) RTP/AVP (fmt) [Note 1, 2]
b=AS:65

a=rtpmap: (payload type) EVS/16000/1 [Note 1, 8]
a=fmtp: (format) br=13.2; bw=swb; mode-set=0,1,2; max-
red=220 [Note 8]
a=fmtp: (format) br=5.9-13.2; bw=nb-swb; mode-
set=0,1,2; max-red=220 [Note 9]
a=ptime:20
a=maxptime:240

a=crypto:1
AES_CM_128_HMAC_SHA1_80inline:PS1uQCVeeCFCa
nVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 [Note 7]
Note 1: The values for fmt, payload type and format are
copied from step 3.
Note 2: Transport port is the port number of the SS (see
RFC 3264 clause 6).
Note 3: The bandwidth-value is copied from step 4.
Note 4: All present br, br-send and br-recv
parameter=value pairs are copied from step 4.
Note 5: bw, bw-send and bw-recv parameter are copied
from bw at step 4.
Note 6: Attributes for ECN Capability are present if the UE
supports Explicit Congestion Notification.
UE.
Note 8: This EVS configuration is sent if UE sent it as the
first of its EVS configurations in previous SDP offer.
Note 9: This EVS configuration is sent if UE did not send
"br=13.2; bw=swb" as the first of its EVS configurations in
previous SDP offer.
ETSI
7.11 MTSI MT Voice call without preconditions at terminating UE

and originating UE requiring them / 5GS
(1)
with { UE being registered to IMS and configured to not use preconditions or the UE does not support
preconditions }
ensure that {
when { UE receives INVITE for voice call where remote UE requires usage of preconditions }
then { UE rejects INVITE with 420 Bad Extension response }
}
[TS 24.229, clause 5.1.4.1]
tag:
initiation;
System Simulator:
ETSI
UE:
- UE is configured to not use preconditions or the UE does not support preconditions .
Preamble:

U-S Message
1-8 Steps 1-8 of generic procedure specified in - -
Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
9 Step 1 of A.5.1 happens, with one change: SS <-- INVITE
sends an INVITE request with a Require header
field containing the precondition option-tag.
9A Optional step: UE may send a 100 Trying --> (Optional) 100 Trying
provisional response.
10 UE sends a 420 Bad Extension response with --> 420 Bad Extension 1 P
an Unsupported header field containing the
precondition option-tag.
11 SS acknowledges the reception of 420 Bad <-- ACK
Extension.
Derivation Path: Annex A.5.1

Require RFC 3261 [6]
option-tag precondition
Table 7.11.3.3-2: 100 Trying (step 9A, Table 7.11.3.2-1)
Derivation path: TS 34.229-1 [2], Annex A.2.2, Condition A2
Table 7.11.3.3-3: 420 Bad Extension for INVITE (step 10, table 7.11.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.2.25

Unsupported RFC 3261 [6]
Table 7.11.3.3-4: ACK (step 11, Table 7.11.3.2-1)
Derivation path: TS 34.229-1 [2], Annex A.2.7, Conditions A2 and A4
ETSI
7.12 MTSI MO Voice Call with preconditions at originating UE

and without preconditions at terminating UE / 5GS
(1)
ensure that {
}
(2)
ensure that {
}
(3)
ensure that {
}
[TS 24.229, clause 5.1.3.1]:
INVITE request and:
field,
ETSI
System Simulator:
UE:
Preamble:

U-S Message
Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
behaviour defined in table 7.12.3.2-2 takes
place
(Check: does the UE send INVITE for voice call
with preconditions?)
4 Step 2 of Annex A.4.1 happens <-- 100 Trying - -
5 Step 3 of Annex A.4.2 happens <-- 183 Session Progress - -
(Note: the SS sends 183 Session Progress
without attributes for preconditions in the SDP
body.)
6 Step 4 of Annex A.4.2 happens --> PRACK 2 P
(Check: does the UE send PRACK?)
7C Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
8 Step 6 of Annex A.4.2 happens <-- 180 Ringing - -
10 Step 8 of Annex A.4.2 happens --> ACK 3 P
(Check: does the UE send ACK?)

U-S Message
None as fully described in Annex A.4.1 and A.4.2.
ETSI
7.13 MTSI MT Voice Call with RTCP disabled / 5GS

(1)
ensure that {
when { UE receives INVITE for voice call with both b=RS and b=RR attributes set to zero }
then { UE may respond with 100 Trying and then sends 183 Session Progress with SDP with both
b=RS and b=RR set to zero and completes setup of voice call with preconditions }
}
[TS 26.114, clause 7.3.1]
Point-to-point speech only sessions may not require the above functionalities and may therefore turn off RTCP by
setting the SDP bandwidth modifiers (RR and RS) to zero. When RTCP is turned off (for point-to-point speech only
sessions) and the media is put on hold, the MTSI client should re-negotiate the RTCP bandwidth with the SDP
bandwidth modifier RR value set greater than zero, and send RTCP packets (i.e., Receiver Reports) to the other end.
This allows the remote end to detect link aliveness during hold. When media is resumed, the resuming MTSI client
should request to turn off the RTCP sending again through a re-negotiation of the RTCP bandwidth with SDP
bandwidth modifiers equal to zero.
When RTCP is turned off (for point-to-point speech only sessions) and if sending of an additional associated RTP
stream becomes required and both RTP streams need to be synchronized, or if transport feedback due to lack of end-to-
end QoS guarantees is needed, a MTSI client should re-negotiate the bandwidth for RTCP by sending an SDP with the
RR bandwidth modifier greater than zero. Setting the RR bandwidth modifier greater than zero allows sending of RTCP
Receiver Reports even when the session is put on hold and neither terminal is actively sending RTP media.
7.13.3 Profile requirements (Informative)
[GSMA NG.114 V1.0, cl3.6.3]
The RTP implementation must include an RTP Control Protocol (RTCP) implementation according to section 7.3.1 of
3GPP TS 26.114 [16].
The UE and the entities in the IMS core network that terminate the user plane must use symmetric RTCP as defined in
IETF RFC 4961 [77], and section 7.3.1 of 3GPP TS 26.114 [16].
The bandwidth for RTCP traffic must be described using the "RS" and "RR" SDP bandwidth modifiers at media level,
as specified by IETF RFC 3556 [78], and section 7.3.1 of 3GPP TS 26.114 [16]. Therefore, a UE must include the
"b=RS:" and "b=RR:" fields in SDP, and a UE and the entities in the IMS core network that terminate the user plane
must be able to interpret them. If the “b=RS:” field or “b=RR:” field or both these fields are not included in a received
SDP (offer or answer), then the UE must use the recommended default value for the missing field(s) as defined in IETF
RFC 3556 [78].
RTCP is controlled on a per session basis by the SDP offer/answer exchange as defined in section 7.3 of 3GPP TS
26.114 [16] with the following clarifications:
1. If the UE receives an SDP offer that contains “b=RS:” attribute set to zero, then the UE must set the “b=RS:”
attribute to zero in an SDP answer to that SDP offer. If the UE receives an SDP offer that contains “b=RR:”
attribute set to zero, then the UE must set the “b=RR:” attribute to zero in an SDP answer to that SDP offer. If
the UE receives an SDP offer that contains both "b=RR:" and "b=RS:" attributes set to zero, then the UE must
not send RTCP packets and must consider RTCP to be disabled for the session.
2. If the UE received an SDP answer containing zero values in both of the “b=RS:” and “b=RR:” attributes, then
(regardless of the values assigned to these attributes in the corresponding SDP offer) the UE must not send
RTCP packets and must consider RTCP to be disabled for the session.
ETSI
3. The UE must accept receiving RTCP packets for a session that the UE considers RTCP to be disabled. The UE is
not required to process these received RTCP packets.
System Simulator:
UE:
Preamble:

U-S Message
0A- Steps 1-8 of generic procedure specified in Table - -
0H 4.9.16.2.2-1 of TS 38.508-1 [21] are performed.
1 SS sends INVITE, with both b=RS and b=RR attributes set <-- INVITE
to zero in SDP.
2 Optional step: UE may send a 100 Trying provisional --> 100 Trying
response.
3 Check: Does the UE send 183 Session Progress with both --> 183 Session Progress 1 P
b=RS and b=RR set to zero in SDP?
4 SS acknowledges reception of 183 Session Progress. <-- PRACK
5 UE responds to PRACK. (Step 5 of Annex A.5.1) --> 200 OK 1 P
5A- Steps 10-12 of generic procedure specified in Table - -
5C 4.9.16.2.2-1 of TS 38.508-1 [21] are performed.
6 SS sends a second SDP offer. (Step 6 of Annex A.5.1) UPDATE
7 UE responds to UPDATE, including an SDP answer. 200 OK
8 UE sends 180 Ringing. (Step 8 of Annex A.5.1) --> 180 Ringing 1 P
9 Conditional step: if UE sent 180 Ringing reliably, SS <-- PRACK
acknowledges reception of 180 Ringing.
10 Conditional step: if UE sent 180 Ringing reliably, UE --> 200 OK
responds to PRACK. (Step 10 of Annex A.5.1)
11 Make UE accept the voice call.
12 UE responds to INVITE. (Step 11 of Annex A.5.1) --> 200 OK
13 SS acknowledges. (Step 12 of Annex A.5.1) <-- ACK
ETSI
Derivation Path: TS 34.229-5, Step 1 of A.5.1, with following exceptions

Message-body Media description: TS 26.114 [33]
b=RR:0 GSMA NG.114 [31]
Table 7.13.4.3-2: 183 Session Progress (step 3, table 7.13.4.2-1)

b=RS: 0 GSMA NG.114 [31]
b=RR: 0
Table 7.13.4.3-3: UPDATE (step 6, table 7.13.4.2-1)

b=RR:0 GSMA NG.114 [31]

b=RS: 0 GSMA NG.114 [31]
b=RR: 0
7.14 MTSI MO Video Call with preconditions at both originating

(1)
ensure that {
when { UE is being made to initiate a video call }
then { UE sends INVITE for video call with preconditions }
}
(2)
ensure that {
when { UE receives 183 Session Progress }
}
(3)
ensure that {
when { UE receives 200 OK for PRACK }
}
ETSI
(4)
ensure that {
}
(5)
ensure that {
}
[TS 24.229, clause 6.1.1]:
...
...
For other media streams the "b=" media descriptor may be included. The value or absence of the "b=" parameter will
affect the assigned QoS which is defined in or 3GPP 29.213 [13C].
NOTE 3: In a two-party session where both participants are active, the RTCP receiver reports are not sent,
therefore, the RR bandwidth modifier will typically get the value of zero.
using 5GS).
ETSI
...
[TS 24.229, clause 6.1.2]:
SDP offer, the UE:
- shall indicate the related local preconditions for QoS as not met, using the segmented status type, as defined in
behaviours.
...
Upon generating the SDP offer for an INVITE request generated after receiving a 488 (Not Acceptable Here) response,
as described in subclause 5.1.3.1, the SDP offer shall contain a subset of the allowed media types, codecs and other
parameters from the SDP message bodies of all 488 (Not Acceptable Here) responses so far received for the same
session establishment attempt (i.e. a set of INVITE requests used for the same session establishment). For each media
line, the UE shall order the codecs in the SDP offer according to the order of the codecs in the SDP message bodies of
the 488 (Not Acceptable Here) responses.
NOTE 6: The UE can attempt a session establishment through multiple networks with different policies and
potentially can need to send multiple INVITE requests and receive multiple 488 (Not Acceptable Here)
responses from different CSCF nodes. The UE therefore takes into account the SDP message bodies of all
the 488 (Not Acceptable Here) responses received related to the same session establishment when
building a new INVITE request.
- send an SDP offer at the first possible time, selecting only one codec per media stream; or
the presence of "a=simulcast" SDP attribute(s) in the SDP answer, as defined in RFC 8853 [249]), apply the
procedures defined in 3GPP TS 26.114 [9B] annex S.
ETSI
If the UE sends an initial INVITE request that includes only an IPv6 address in the SDP offer, and receives an error
response (e.g., 488 (Not Acceptable Here) with 301 Warning header field) indicating "incompatible network address
format", the UE shall send an ACK as per standard SIP procedures. Subsequently, the UE may acquire an IPv4 address
or use an existing IPv4 address, and send a new initial INVITE request to the same destination containing only the IPv4
address in the SDP offer.
System Simulator:
UE:
Preamble:
ETSI

U-S Message
1 UE is made to attempt an IMS video call. - - - -
2A- Steps 2-8 from generic procedure specified in - - - -
2G TS 38.508-1 [21] Table 4.9.24 are performed.
3 Check: Does UE send INVITE with the first SDP --> INVITE 1 P
offer?
4 SS sends a 100 Trying provisional response. <-- 100 Trying - -
5 SS sends an SDP answer. <-- 183 Session Progress - -
6 Check: Does UE acknowledge reception of 183 --> PRACK 2 P
Session Progress?
7 SS responds to PRACK. <-- 200 OK - -
(Step 5 of Annex A.15.1a).
7A- Steps 10-12 from generic procedure specified in - - - -
7C TS 38.508-1 [21] Table 4.9.24 are performed.
8 Check: Does UE send a second SDP offer in an --> UPDATE 3 P
UPDATE request?
9 SS responds to UPDATE. <-- 200 OK - -
10 SS sends 180 Ringing reliably. <-- 180 Ringing - -
11 Check: Does UE acknowledge reception of 180 --> PRACK 4 P
Ringing?
12 SS responds to PRACK. <-- 200 OK - -
13 SS responds to INVITE. <-- 200 OK - -
14 Check: Does UE acknowledge? --> ACK 5 P
None.
7.15 MTSI MO Video call without preconditions at both

(1)
ensure that {
when { UE is being made to initiate a video call }
then { UE sends INVITE for video call without preconditions }
}
(2)
with { UE having send INVITE without preconditions }
ensure that {
ETSI
(3)
ensure that {
}
[TS 24.229, clause 6.1.1]:
For "video" and "audio" media types that utilize the RTP/RTCP, the UE shall specify the proposed bandwidth for each
media stream utilizing the "b=" media descriptor and the "AS" bandwidth modifier in the SDP.
...
If the media line in the SDP indicates the usage of RTP/RTCP, and if the UE is configured to request an RTCP
bandwidth level for the session is different than the default RTCP bandwidth as specified in RFC 3556, then in addition
to the "AS" bandwidth modifier in the media-level "b=" line, the UE shall include two media-level "b=" lines, one with
the "RS" bandwidth modifier and the other with the "RR" bandwidth modifier as described in RFC 3556 to specify the
required bandwidth allocation for RTCP. The bandwidth-value in the b=RS: and b=RR: lines may include transport
overhead as described in subclause 6.1 of RFC 3890.
affect the assigned QoS which is defined in 3GPP TS 29.208.
[TS 24.229, clause 6.1.3]:
Upon receiving an initial INVITE request that includes the SDP offer containing an IP address type (in the "c="
parameter) that is not supported by the UE, the UE shall:
- if the UE is a UE performing the functions of an external attached network and
1) if the received SDP offer contains an "altc" SDP attribute indicating an alternative and supported IP address;
and
2) the UE supports the "altc" SDP attribute;
select an IP address type in accordance with RFC 6947 [228]; or
- otherwise respond with a 488 (Not Acceptable Here) response including a 301 Warning header field indicating
"incompatible network address format".
NOTE 2: Upon receiving an initial INVITE request that does not include an SDP offer, the UE can accept the
request and include an SDP offer in the first reliable response. The SDP offer will reflect the called user's
terminal capabilities and user preferences for the session.
If the UE receives an SDP offer that specifies different IP address type for media (i.e. specify it in the "c=" parameter of
the SDP offer) that the UE is using for signalling, and if the UE supports both IPv4 and IPv6 addresses simultaneously,
the UE shall accept the received SDP offer. Subsequently, the UE shall either acquire an IP address type or use an
existing IP address type as specified in the SDP offer, and include it in the "c=" parameter in the SDP answer.
ETSI
NOTE 3: Upon receiving an initial INVITE request, that includes an SDP offer containing connection addresses (in
the "c=" parameter) equal to zero, the UE will select the media streams that is willing to accept for the
session, reserve the QoS resources for accepted media streams, and include its valid connection address in
the SDP answer.
If the terminating UE uses the precondition mechanism (see subclause 5.1.4.1), if the desired QoS resources for one or
more media streams have not been reserved at the terminating UE when constructing the SDP offer, the terminating UE
shall indicate the related local preconditions for QoS as not met, using the segmented status type, as defined in
strength-tag value either "optional" or as specified in RFC 3312 [30] and RFC 4032 [64] for the remote segment.
NOTE 7: It is out of scope of this specification which media streams are to be included in the SDP offer.
If the terminating UE uses the precondition mechanism (see subclause 5.1.4.1) and if the desired QoS resources for one
or more media streams are available at the terminating UE when the SDP offer is sent, the UE shall indicate the related
local preconditions as met, using the segmented status type, as defined in RFC 3312 [30] and RFC 4032 [64], as well as
the strength-tag value "mandatory" for the local segment and the strength-tag value either "optional" or as specified in
RFC 3312 [30] and RFC 4032 [64] for the remote segment.
If the terminating UE sends an UPDATE request to remove one or more media streams negotiated in the session for
which a final response to the INVITE request has not been sent yet, the terminating UE sets the ports of the media
streams to be removed from the session to zero in the new SDP offer.
NOTE 8: Upon receiving an initial INVITE request with one or more media streams which the terminating UE
supports and one or more media streams which the UE does not support, the UE is not expected to reject
the INVITE request just because of the presence of the unsupported media stream.
NOTE 9: Previous versions of this document mandated the use of the SDP inactive attribute in the SDP offer if the
desired QoS resources for one or more media streams had not been reserved at the originating UE when
constructing the SDP offer unless the originating UE knew that the precondition mechanism was
supported by the remote UE. The use can still occur when interoperating with devices based on earlier
versions of this document.
[TS 26.114, clause 5.2.2]:
MTSI clients in terminals offering video communication shall support:
- H.264 (AVC) [24] Constrained Baseline Profile (CBP) Level 1.2;
- H.265 (HEVC) [119] Main Profile, Main Tier, Level 3.1.
In addition they should support:
- H.264 (AVC) [24] Constrained High Profile (CHP) Level 3.1.
[TS 26.114, clause 6.2.3.2]:
If video is used in a session, the session setup shall determine the applicable bandwidth(s) as defined in clause 6.2.5,
RTP profile, video codec, profile and level. The "imageattr" attribute as specified in [76] should be supported. The
"framesize" attribute as specified in [60] shall not be used in the session setup.
An MTSI client shall offer AVPF for all media streams containing video. RTP profile negotiation shall be done as
described in clause 6.2.1a.
An MTSI client is required to support the AVPF feedback messages trr-int, NACK and PLI [40] and the CCM feedback
messages FIR, TMMBR and TMMBN [43], see Clauses 7.3.3 and 10.3. These feedback messages can only be used
together with AVPF and shall be negotiated in SDP offer/answer before they can be used in the session [40]. An MTSI
client sending an SDP offer for AVPF shall also include these AVPF and CCM feedback messages in the offer. An
MTSI client accepting an SDP offer for AVPF for video shall also accept these AVPF and CCM feedback messages if
they are offered.
If an MTSI client offers to use ECN for video in RTP streams then the MTSI client shall offer ECN Capable Transport
as defined below. If an MTSI client accepts an offer for ECN for video then the MTSI client shall declare ECN Capable
Transport in the SDP answer as defined below. The SDP negotiation of ECN Capable Transport is described in [84].
ETSI
The use of ECN for a video stream in RTP is negotiated with the "ecn-capable-rtp" SDP attribute, [84]. ECN is enabled
when both clients agree to use ECN as configured below. An MTSI client using ECN shall therefore also include the
following parameters and parameter values for the ECN attribute:
- ‘leap’, to indicate that the leap-of-faith initiation method shall be used;
- ‘ect=0’, to indicate that ECT(0) shall be set for every packet.
An MTSI client offering ECN for video shall indicate support of TMMBR [43] by including the "ccm tmmbr" value
within an "rtcp-fb" SDP attribute [40]. An MTSI client offering ECN for video may indicate support for RTCP AVPF
ECN feedback messages [84] using the "rtcp-fb" SDP attribute with the "nack" feedback parameter and the "ecn"
feedback parameter value. An MTSI client offering ECN for video may indicate support for RTCP XR ECN summary
reports [84] using the "rtcp-xr" SDP attribute and the "ecn-sum" parameter.
An MTSI client receiving an offer for ECN for video with an indication of support of TMMBR [43] within an "rtcp-fb"
attribute should accept the offer if it supports ECN. It shall then indicate support for TMMBR using an "rtcp-fb"
attribute in the SDP answer.
An MTSI client receiving an offer for ECN for video with an indication of support of RTCP AVPF ECN feedback
message but without support for TMMBR should accept the offer if it supports ECN and also the RTCP AVPF ECN
feedback message. It shall then indicate support of the RTCP AVPF ECN feedback message using the "rtcp-fb"
An MTSI client receiving an offer for ECN for video with an indication of support of RTCP XR ECN summary reports
[84] without support for TMMBR should accept the offer if it supports ECN and also the RTCP XR ECN summary
reports. It shall then indicate support of RTCP XR ECN summary reports in the SDP answer.
The use of ECN is disabled when a client sends an SDP without the "ecn-capable-rtp" SDP attribute.
An MTSI client may initiate a session re-negotiation to disable ECN to resolve ECN-related error cases. An ECN-
related error case may be, for example, detecting non-ECT in the received packets when ECT(0) was expected or
detecting a very high packet loss rate when ECN is used.
Examples of SDP offers and answers for video can be found in clause A.4. SDP examples for offering and accepting
ECT are shown in Annex A.12.2.
NOTE: For H.264 / MPEG-4 (Part 10) AVC, the optional max-rcmd-nalu-size receiver-capability parameter of
RFC 6184 [25] should be set to the smaller of the MTU size (if known) minus header size or 1 400 bytes
(otherwise).
The "framerate" attribute as specified in [8] indicates the maximum frame rate the offerer wishes to receive. If the
"framerate" attribute is present in the SDP offer, its value may be modified in the SDP answer when the answerer
wishes to receive video with a different maximum frame rate than what was indicated in the offer.
An MTSI client in terminal setting up asymmetric video streams with H.264 (AVC) should use both the ‘level-
asymmetry-allowed’ parameter and the ‘max-recv-level’ parameter that are defined in the H.264 payload format, [25].
When the ‘max-recv-level’ parameter is used then the level offered for the receiving direction using the ‘max-recv-
level’ parameter must be higher than the default level that is offered with the ‘profile-level-id’ parameter.
An SDP offer-answer example showing the usage of the ‘level-asymmetry-allowed’ and ‘max-recv-level’ parameters is
included in Annex A.4.5.
An MTSI client in terminal setting up asymmetric video streams with H.265 (HEVC) should use the ‘max-recv-level-
id’ parameter that is defined in the H.265 payload format, [120]. The level offered for the receiving direction using the
‘max-recv-level-id’ parameter must be higher than the default level that is offered with the ‘level-id’ parameter.
An SDP offer-answer example showing the usage of the ‘max-recv-level-id’ parameter is included in Annex A.4.8.
The resolutions in the "imageattr" attribute correspond to the image size information in the encoded video bitstream
such that the x-component corresponds to the image width, and the y-component corresponds to the height component.
When the bit-rate is being adapted, values of image width or image height smaller than the x- or y-component(s) in the
negotiated "imageattr" attribute may be temporarily used.
ETSI
[GSMA NG.114 V1.0, clause 3.3.1]:
The entities in the IMS core network that terminate the user plane must support ITU-T Recommendation H.264 [83]
Constrained Baseline Profile (CBP) Level 1.2 implemented as specified in section 5.2.2 of 3GPP TS 26.114 [16].
The UE must support ITU-T Recommendation H.264 [83] Constrained High Profile (CHP) Level 3.1 as specified in
section 5.2.2 of 3GPP TS 26.114 [16].
The UE must support ITU-T Recommendation H.265 [84] Main Profile, Main Tier Level 3.1 as specified in section
5.2.2 of 3GPP TS 26.114 [16].
For backward compatibility, the UE must also support ITU-T Recommendation H.264 [83] Constrained Baseline
Profile (CBP) Level 3.1 as specified in section 5.2.2 of 3GPP TS 26.114 [16], and when H.264 [83] (Advanced Video
Coding (AVC)) CHP Level 3.1 is offered, then H.264 [83] CBP Level 3.1 must also be offered.
[GSMA NG.114 V1.0, clause 3.3.2.1]:
The Session Description Protocol (SDP) offer/answer for video media must be formatted as specified in section 6.2.3 of
3GPP TS 26.114 [16], along with the restrictions included in the present document.
Unless preconfigured otherwise by the home operator with the Media_type_restriction_policy parameter as specified in
Annex C.3 and when offering video media that is not already part of the session, regardless if it is at the start of the
session or at some later point in time, the UE must include in the SDP offer at least:
1. One H.265 (HEVC) Main Profile, Main Tier, Level 3.1 payload type as defined in sections 5.2.2 and 7.4.3 of
3GPP TS 26.114 [16].
2. One H.264 (AVC) Constrained High Profile Level 3.1 payload type as defined in sections 5.2.2 and 7.4.3 of
3GPP TS 26.114 [16].
3. One H.264 (AVC) Constrained Baseline Profile Level 3.1 payload type as defined in sections 5.2.2 and 7.4.3 of
3GPP TS 26.114 [16].
The payload type preference order on the SDP m= line must be as specified by the numbered list above.
Coordination of Video Orientation (CVO) as specified in 3GPP TS 26.114 [16] shall be supported with two (2) bits
granularity by the UE and the entities in the IMS core network which terminate the user plane. The support for CVO
shall be included in SDP offer and SDP answer as specified in section 6.2.3 of 3GPP TS 26.114 [16].
[GSMA NG.114 V1.0, clause 3.3.2.2]:
If an asymmetric video stream for H.265 (HEVC) is supported, the parameter ‘max-recv-level-id’ should be included in
the SDP offer and SDP answer, and the level offered with it must be higher than the default level offered with the
‘level-id’ parameter in the SDP offer/answer respectively, as specified in section 7.1 of IETF RFC 7798 [86] and
section 6.2.3 of 3GPP TS 26.114 [16].
System Simulator:
UE:
ETSI
Preamble:

U-S Message
0A UE is made to attempt an IMS video call. - - -
0B- Steps 2-8 from generic procedure specified in TS 38.508-1 - - -
0H [21] Table 4.9.24.2.2-1 are performed.
1 UE sends INVITE with the first SDP offer, without -> INVITE 1 P
preconditions. (Step 1 of Annex A.15.2)
2-3 Step 2-3 of Annex A.15.2 - - - -
4 UE acknowledges the receipt of 183 response. -> PRACK 2 P
- EXCEPTION: In parallel with step 5-9, parallel behaviour - - - -
defined in table 7.15.4.2-2 is executed
5-9 Step 5-9 of Annex A.15.2. <- - - -
10 UE acknowledges. (Step 10 of Annex A.15.2) -> ACK 3 P

U-S Message
1-3 Steps 10-12 from generic procedure specified in TS - - -
38.508-1 [21] Table 4.9.24.2.2-1 are performed.
None as fully specified in Annex A.15.2.
7.16 MTSI MT Video call with preconditions at both originating

UE and terminating UE / 5GS
(1)
ensure that {
when { UE receives INVITE for video call }
then { UE may respond with 100 Trying }
}
(2)
ensure that {
then { UE responds with 183 Session Progress including SDP }
}
(3)
ensure that {
}
ETSI
(4)
ensure that {
}
(5)
with { UE having sent 180 Ringing, possibly reliably }
ensure that {
when { 180 Ringing was sent reliably and consequently UE receives PRACK for 180 Ringing }
}
(6)
ensure that {
when { User accepts the incoming video call request }
}
(7)
ensure that {
}
[TS 24.229, clause 6.1.1]:
...
[TS 24.229, clause 6.1.3]:
ETSI
and
the SDP answer.
[TS 26.114, clause 5.2.2]:
ETSI
[TS 26.114, clause 6.2.3.2]:
they are offered.
(otherwise).
ETSI
[GSMA NG.114 V1.0, cluse 3.3.1]:
section 5.2.2 of 3GPP TS 26.114 [16].
5.2.2 of 3GPP TS 26.114 [16].
[GSMA NG.114 V1.0, cluse 3.3.2.1]:
3GPP TS 26.114 [16].
3GPP TS 26.114 [16].
3GPP TS 26.114 [16].
[GSMA NG.114 V1.0, cluse 3.3.2.2]:
ETSI
section 6.2.3 of 3GPP TS 26.114 [16].
System Simulator:
UE:
Preamble:
ETSI

U-S Message
0A- Steps 1-8 of generic procedure specified in Table - - - -
1 SS sends INVITE with the first SDP offer. <- INVITE - -
2 Check: (Optional) Does the UE respond with a 100 Trying -> 100 Trying 1 -P
provisional response? (Step 2 of Annex A.16.1)
3 Check: Does the UE send 183 response reliably with the -> 183 Session Progress 2 P
SDP answer to the offer in INVITE? (Step 3 of Annex
A.16.1)
4 SS acknowledges the receipt of 183 response from the <- PRACK - -
UE. (Step 4 of Annex A.16.1)
5 Check: Does the UE responds to PRACK with 200 OK. -> 200 OK 3 P
5A SS triggers resource reservation by executing steps 10-12 - - - -
of generic procedure specified in Table 4.9.26.2.2-1 of TS
38.508-1 [21].
6 SS sends an UPDATE with SDP offer indicating SS <- UPDATE
reserved resources. (Step 6 of Annex A.16.1)
7 Check: Does the UE acknowledges the UPDATE with 200 -> 200 OK 4 P
OK and includes SDP answer to acknowledge its current
precondition status. (Step 7 of Annex A.16.1)
8 Check: (Optional) Does the UE responds to INVITE with -> 180 Ringing - -
180 Ringing? (Step 8 of Annex A.16.1)
9 (Optional) SS shall send PRACK only if the 180 response <- PRACK - -
contains 100rel option tag within the Require header?
10 Check: (Optional) Does the UE acknowledges the PRACK -> 200 OK 5 P
with 200 OK? (Step 10 of Annex A.16.1)
11 UE is made to answer the call. - - - -
12 Check: Does the UE responds to INVITE with a 200 OK -> 200 OK 6 P
final response after the user answers the call?
13 The SS acknowledges the receipt of 200 OK for INVITE. <- ACK - -
14 The SS releases the call with BYE. (Step 1 of Annex A.8) <- BYE - -
15 Check: Does the UE sends 200 OK for BYE. -> 200 OK 7 P
None as fully specified in A.16.1 and A.8.
7.17 MTSI MT Video call without preconditions at both

(1)
ensure that {
then { UE may respond with 100 Trying and then sends 183 Session Progress with SDP without
preconditions }
}
ETSI
(2)
ensure that {
}
(3)
ensure that {
}
[TS 24.229, clause 6.1.1]:
...
[TS 24.229, clause 6.1.3]:
and
ETSI
the SDP answer.
[TS 26.114, clause 5.2.2]:
[TS 26.114, clause 6.2.3.2]:
they are offered.
ETSI
(otherwise).
ETSI
[GSMA NG.114 V1.0, cluse 3.3.1]:
section 5.2.2 of 3GPP TS 26.114 [16].
5.2.2 of 3GPP TS 26.114 [16].
[GSMA NG.114 V1.0, cluse 3.3.2.1]:
3GPP TS 26.114 [16].
3GPP TS 26.114 [16].
3GPP TS 26.114 [16].
[GSMA NG.114 V1.0, cluse 3.3.2.2]:
section 6.2.3 of 3GPP TS 26.114 [16].
System Simulator:
UE:
ETSI
Preamble:

U-S Message
0A- Steps 1-8 of generic procedure specified in Table - - - -
1 SS sends INVITE with the first SDP offer. <- INVITE - -
2 Check: (Optional) Does The UE respond with a 100 Trying -> 100 Trying 1 -P
provisional response?
3 The UE sends 183 response reliably with the SDP answer -> 183 Session Progress - -
to the offer in INVITE
4 SS acknowledges the receipt of 183 response from the <- PRACK - -
UE.
5 Check: Does the UE respond to PRACK with 200 OK? -> 200 OK 2 P
5A SS triggers resource reservation by executing steps 10-12 - - - -
of generic procedure specified in Table 4.9.26.2.2-1 of TS
38.508-1 [21].
6 Check: Does the UE respond to INVITE with 180 Ringing? -> 180 Ringing 3 P
7 (Conditional) If the 180 response contains 100rel option <- PRACK - -
tag within the Require header, then the SS shall send
PRACK.
8 (Conditional) If the SS sent PRACK, then the UE -> 200 OK - -
acknowledges the PRACK with 200 OK.
9 Make UE accept the video call. - - - -
10 The UE responds to INVITE with a 200 OK final response -> 200 OK - -
after the user answers the call.
11 The SS acknowledges the receipt of 200 OK for INVITE. <- ACK - -
None as fully specified in A.16.2.
7.18 MTSI MO Voice Call / EVS / AMR-WB / 5GS

(1)
ensure that {
}
(2)
ensure that {
when { UE receives 183 Session Progress indicating AMR-WB }
then { UE sends PRACK for 183 Session Progress and, after receiving 200 OK for PRACK, agrees to
AMR-WB via UPDATE }
}
ETSI
[TS 24.229, clause 5.1.3.1]:
Where multiple domains exist for initiating a call/session, before sending an initial INVITE request, the UE shall
perform access domain selection in accordance with the appropriate specification for the IP-CAN in use, taking into
account the media to be requested. Access domain selection allows the policy of the network operator to be taken into
account before the initial INVITE request is sent. Access dependent aspects of access domain selection are defined in
the access technology specific annexes for each access technology.
Upon generating an initial INVITE request, the UE shall include the Accept header field with "application/sdp", the
MIME type associated with the 3GPP IM CN subsystem XML body (see subclause 7.6.1) and any other MIME type the
UE is willing and capable to accept.
INVITE request and:
field,
ETSI
establishment.
If the UE wishes to receive early media authorization indications, as described in RFC 5009 [109], the UE shall add the
P-Early-Media header field with the "supported" parameter to the initial INVITE request.
A UE supporting the Session Timer extension as described in RFC 4028 [58] may support the extension being
configured using Session_Timer_Support node specified in 3GPP TS 24.167 [8G].
If the UE supports the Session Timer extension, the UE shall include the option-tag "timer" in the Supported header
field and should either insert a Session-Expires header field with the header field value set to the configured session
timer interval value, or should not include the Session-Expires header field in the initial INVITE request. The header
field value of the Session-Expires header field may be configured using local configuration or using the
Session_Timer_Initial_Interval node specified in 3GPP 24.167 [8G]. If the UE is configured with both the local
configuration and the Session_Timer_Initial_Interval node specified in 3GPP 24.167 [8G], then the local configuration
shall take precedence.
If the UE inserts the Session-Expires header field in the initial INVITE request, the UE may also include the "refresher"
parameter with the "refresher" parameter value set to "uac".
The UE may include a "cic" tel URI parameter in a tel URI, or in the userinfo part of a SIP URI with user=phone, in the
Request-URI of an initial INVITE request if the UE wants to identify a user-dialled carrier, as described in
RFC 4694 [112].
NOTE 8: The method whereby the UE determines when to include a "cic" tel-URI parameter and what value it
should contain is outside the scope of this document (e.g. the UE could use a locally configured digit map
to look for special prefix digits that indicate the user has dialled a carrier).
NOTE 9: The value of the "cic" tel-URI parameter reported by the UE is not dependent on UE location (e.g. the
reported value is not affected by roaming scenarios).
[TS 24.229, clause 6.1.1]:
In order to support accurate bandwidth calculations, the UE may include the "a=ptime" attribute for all "audio" media
lines as described in RFC 4566 [39]. If a UE receives an "audio" media line with "a=ptime" specified, the UE should
transmit at the specified packetization rate. If a UE receives an "audio" media line which does not have "a=ptime"
specified or the UE does not support the "a=ptime" attribute, the UE should transmit at the default codec packetization
rate as defined in RFC 3551 [55A]. The UE will transmit consistent with the resources available from the network.
ETSI
NOTE 2: The above is the minimum requirement for all UEs. Additional requirements can be found in other
specifications.
For "video" and "audio" media types that use the RTP/RTCP and where the port number is not zero, the UE may
include for each RTP payload type "a=bw-info" SDP attribute(s) (defined in clause 19 of 3GPP TS 26.114 [9B]) to
indicate the additional bandwidth information. The "a=bw-info" SDP attribute line(s) shall be specified in accordance
with 3GPP TS 26.114 [9B]. The value of the "a=bw-info" SDP attribute(s) may affect the assigned QoS which is
defined in 3GPP TS 29.213 [13C].
For "video" and "audio" media types that utilize the RTP/RTCP, in addition to the "b=AS" parameter, the UE may
specify the "b=TIAS", and "a=maxprate" parameters in accordance with RFC 3890 [152]. The value of the parameter
shall be determined as described in RFC 3890 [152]. The value or absence of the "b=" parameter(s) may affect the
assigned QoS which is defined in 3GPP TS 29.213 [13C].
If a UE receives a media line which contains both a=ptime and a=maxprate, the UE should use the a=maxprate value, if
this attribute is supported.
If multiple codecs are specified on the media line, "a=maxprate" (or "a=ptime" if "a=maxprate" is not available or not
supported) should be used to derive the packetization time used for all codecs specified on the media line. Given that
not all codecs support identical ranges of packetization, the UE should ensure that the packetization derived by
"a=maxprate" (or "a=ptime" if "a=maxprate" is not available or not supported) is a valid packetization time for each
codec specified in the list.
[TS 26.114, clause 5.2.1.1]:
communication. The only exception to this requirement is for the MTSI client in constrained terminal offering speech
communication, in which case the MTSI client in constrained terminal shall support narrowband and wideband, and
should support super-wideband communication.
- .AMR speech codec (3GPP TS 26.071 [11], 3GPP TS 26.090 [12], 3GPP TS 26.073 [13] and
ETSI
MTSI clients in terminals offering super-wideband or fullband speech communication shall support:
TS 26.442 [122], TS 26.452 [165] and TS 26.443 [123]) as described below including functions for backwards
compatibility with AMR-WB ( TS 26.446 [126]) and discontinuous transmission ( TS 26.449 [129] and
TS 26.450 [130]). More detailed codec requirements for the EVS codec are defined in clause 5.2.1.4.
Encoding of DTMF is described in Annex G.
[TS 26.114, clause 6.2.2.1]:
For AMR or AMR-WB encoded media, the session setup shall determine the applicable bandwidth(s) as defined in
clause 6.2.5, what RTP profile to use; if all codec modes can be used or if the operation needs to be restricted to a
subset; if the bandwidth-efficient payload format can be used or if the octet-aligned payload format must be used; if
codec mode changes shall be restricted to be aligned to only every other frame border or if codec mode changes can
occur at any frame border; if codec mode changes must be restricted to only neighbouring modes within the negotiated
codec mode set or if codec mode changes can be performed to any mode within the codec mode set; the number of
speech frames that should be encapsulated in each RTP packet and the maximum number of speech frames that may be
encapsulated in each RTP packet. For EVS encoded media, the session setup shall determine the RTP profile to use in
the session.
If the session setup negotiation concludes that multiple configuration variants are possible in the session then the default
operation should be used as far as the agreed parameters allow, see clause 7.5.2.1. It should be noted that the default
configurations are slightly different for different access types.
An MTSI client offering a speech media session for narrow-band speech and/or wide-band speech should generate an
SDP offer according to the examples in Annexes A.1 to A.3. An MTSI client offering EVS should generate an SDP
offer according to the examples in Annex A.14.
An MTSI client in terminal supporting EVS should support the RTCP-APP signalling for speech adaptation defined
clause 10.2.1, and shall support the RTCP-APP signalling when the MTSI client in terminal supports adaptation for call
cases where the RTP-based CMR cannot be used.
NOTE 1: Examples of call cases where the RTP-based CMR cannot be used are: when the RTP-based CMR is
disabled; or for uni-directional media (sendonly or recvonly).
Some of the request messages are generic for all speech codecs while other request messages are codec-specific.
Request messages that can be used in a session are negotiated in SDP, see clause 10.2.3.
[TS 26.114, clause 6.2.2.3]:
An MTSI client in terminal must understand all the payload format options that are defined in RFC 4867 [28], and in
[125]. It does not have to support operating according to all these options but must be capable to properly accepting or
rejecting all options.
The SDP answer depends on many factors, for example:
- what is included in the SDP offer and in what preference order that is defined. The SDP offer will probably be
different if it is generated by another MTSI client in terminal, by an MTSI MGW, a TISPAN client or some
other VoIP client that does not follow this specification;
- if terminal and/or network resources are available; and:
- if there are other configurations, for example defined with OMA-DM, that mandate, recommend or prevent some
configurations.
Table 6.3 describes requirements and recommendations for handling of the AMR payload format parameters and for
how to generate the SDP answer.
ETSI
NOTE 1: An MTSI client in terminal may support more features than what is required by this specification, e.g. crc,
robust sorting and interleaving. Table 6.3 describes the handling of the AMR payload format parameters when the
MTSI client implementation supports only those features that are required by this specification. Tables 6.3a-6.3c
describe the handling of the EVS payload format parameters.
ETSI
Table 6.3: Handling of the AMR-NB and AMR-WB SDP parameters in the received SDP offer and in
the SDP answer
ETSI
Parameter in the Comments Handling

received SDP
offer
Codec Wide-band speech is preferable over narrow- If both AMR-WB and AMR-NB are offered and if
band speech AMR-WB is supported by the answering MTSI
client in terminal then it shall select to use the
AMR-WB codec and include this codec in the
SDP answer, unless another preference order
is indicated in the SDP offer. If the MTSI client
in terminal only supports AMR-NB then this
codec shall be selected to be used and shall be
included in the SDP answer.
The SDP answer shall only include one RTP
Payload Type for speech, see NOTE 1.
octet-align Both the bandwidth-efficient and the octet- The offer shall not be rejected purely based on
aligned payload formats are supported by the the offered payload format variant.
MTSI client in terminal. If both bandwidth-efficient and octet-aligned are
MTSI MGWs for GERAN or UTRAN are likely to included in the received SDP offer then the
either not include the octet-align parameter or to MTSI client in terminal shall select the
offer octet-align=0. bandwidth-efficient payload format and include
The bandwidth-efficient payload format is it in the configuration in the SDP answer.
preferable over the octet-aligned payload
format.
mode-set The MTSI client in terminal can interoperate The offer shall not be rejected purely based on
properly with whatever mode-set the other end- the offered mode-set.
point offers or if no mode-set is offered. If only one mode-set is offered then the MTSI
The possibilities to use the higher bit rate codec client in terminal shall select to use this and
modes also depend on the offered bandwidth. include the same mode-set in the SDP answer.
MTSI MGWs for GERAN or UTRAN inter- If several different payload types for the same
working are likely to include the mode-set in the codec with different mode-sets (possibly
offer if in case the intention is to use TFO or including one or more payload type without
TrFO. mode set) are included in the received SDP
Mode sets that give more adaptation offer, then the MTSI client in terminal should
possibilities are preferable over mode-sets with select in the first hand the mode-set that
fewer or no adaptation possibilities. provides the largest degrees of freedom for
codec mode adaptation and in the second hand
An MTSI client in terminal may be configured the mode-set that is closest to the preferred
with a preferred mode set. Otherwise, the mode sets.
preferred mode-set for AMR-NB is {12.2, 7.4,
5.9, 4.75} and for AMR-WB it is {12.65, 8.85 If only a payload type without mode-set has
and 6.60}. been offered, or if an MTSI client in terminal
selects a payload type without mode-set from
among the offered ones, and the MTSI client in
terminal intends to use only some modes (e.g.
one of the preferred mode sets defined at left),
then the MTSI client in terminal should include
these modes as the mode-set.
There are also dependencies between the
mode-set and the SDP b=AS bandwidth
parameter; see Clause 6.2.5.2.
mode-change- The MTSI client in terminal can interoperate The offer shall not be rejected purely based on
period properly with whatever mode-change-period the the offered mode-change-period.
other end-point offers. If the received SDP offer defines mode-change-
MTSI MGWs for GERAN or UTRAN inter- period=2 then this information shall be used to
working are likely to include mode-change- determine the mode changes for AMR-NB or
period=2 in the offer if in case the intention is to AMR-WB encoded media that the MTSI client in
use TFO or TrFO. terminal sends.
The MTSI client in terminal should not include
the mode-change-period parameter in the SDP
answer since it has no corresponding
limitations.
ETSI

received SDP
offer
capability with whatever capabilities the other end-point the offered mode-change-capability.
declares. The mode-change-capability information should
be used to determine a proper value, or prevent
using an improper value, for mode-change-
period in the SDP answer, see above. If the
offer includes mode-change-capability=1, then
the MTSI client in terminal shall not offer mode-
change-period=2 in the answer.
The MTSI client in terminal shall include mode-
change-capability=2 in the SDP answer since it
is required to support restricting mode changes
to every other frame.
neighbor with whatever limitations the other end-point the offered mode-change-neighbor.
offers. The MTSI client in terminal shall use this
information to determine how mode changes
can be performed for AMR-NB or AMR-WB
encoded media that the MTSI client in terminal
sends.
The MTSI client in terminal shall not include the
mode-change-neighbor parameter in the SDP
answer since it has no corresponding
limitations.
maxptime The MTSI client in terminal can interoperate The offer shall not be rejected purely based on
with whatever value that is offered. the offered maxptime.
The MTSI client in terminal may also use this The MTSI client in terminal shall use this
information to determine a suitable value for information to control the packetization when
max-red in the SDP answer. sending RTP packets to the other end-point,
see also clause 7.4.2.
The maxptime parameter shall be included in
the SDP answer and shall be an integer
multiple of 20.
If the received SDP offer includes both the max-
red and ptime parameter then the MTSI client in
terminal may choose to use this information to
define a suitable value for maxptime in the SDP
answer, see NOTE 2. The MTSI client in
terminal may also choose to set the maxptime
value to 240, regardless of the ptime and/or
max-red parameters in the SDP offer.
The maxptime value in the SDP answer shall
not be smaller than ptime value in the SDP
answer. The maxptime value should be
selected to give at least some room for
adaptation.
crc The MTSI client in terminal is not required to The MTSI client in terminal may have to reject
support this option. offered RTP payload types including this option.
robust-sorting The MTSI client in terminal is not required to The MTSI client in terminal may have to reject
interleaving The MTSI client in terminal is not required to The MTSI client in terminal may have to reject
ETSI

received SDP
offer
ptime The MTSI client in terminal can interoperate The offer shall not be rejected purely based on
with whatever value that is offered. the offered ptime.
The MTSI client in terminal should use this
information and should use the requested
packetization when sending RTP packets to the
other end-point. The MTSI client should use the
ptime value to determine how many non-
redundant speech frames that can be packed
into the RTP packets. The requirements in
clause 7.4.2 shall be followed even if ptime in
the SDP offer is larger than 80.
The ptime parameter shall be included in the
SDP answer and shall be an integer multiple of
20.
If the received SDP offer includes the ptime
parameters then the MTSI client in terminal may
choose to use this information to define a
suitable value for ptime in the SDP answer, see
NOTE 3. The MTSI client in terminal may also
choose to set the ptime value in the SDP
answer according to Table 7.1, regardless of
the ptime parameter in the SDP offer.
The ptime value in the SDP answer shall not be
larger than the maxptime value in the SDP
answer.
channels The number of channels may either be explicitly When the MTSI client in terminal accepts an
indicated in the SDP by including '/1', '/2', etc. offer for single-channel audio then the SDP
on the a=rtpmap line, but the number of answer shall either explicitly indicate '/1' or omit
channels may also be omitted. When the the channels parameter.
number of channels is omitted then the default When the MTSI client in terminal accepts an
rule is that one channel is being offered. offer for multi-channel audio then the number of
The MTSI client in terminal is only required to channels shall be included in the SDP answer.
support audio media using one channel.
Offered RTP payload types with more than one
channel may therefore have to be rejected.
max-red The MTSI client in terminal may use this The max-red parameter shall be included in the
information to bound the delay for receiving SDP answer and shall be an integer multiple of
redundant frames. 20.
The MTSI client in terminal may also use this If the received SDP offer includes both the
information to determine a suitable value for ptime and maxptime parameters then the MTSI
maxptime in the SDP answer. client in terminal may choose to use this
information to define a suitable value for max-
red in the SDP answer, see NOTE 2. The MTSI
client in terminal may also choose to set the
max-red value to 220.
The max-red value in the SDP answer should
be selected to give at least some room for
adaptation.
ecn-capable-rtp: An MTSI client in terminal uses this SDP Shall be included in the SDP answer if
leap ect=0 attribute to offer ECN for RTP-transported accepting an offer to use ECN and if the
media session setup allows for bit-rate adaptation
NOTE 1: An MTSI client may include both a speech coded, e.g. AMR-NB or AMR-WB, and ‘telephone-events’ for
DTMF in the SDP answer, see 3GPP TS 24.229 Clause 6.1, [7].
NOTE 2: It is possible to use the following relationship between maxptime, ptime and max-red:
maxptime = ptime + max-red.
There is however no mandatory requirement that these parameters must be aligned in this way.
NOTE 3: It may be wise to use the same ptime value in the SDP answer as was given in the SDP offer, especially if
the ptime in the SDP offer is larger than 20, since a value larger than the frame length indicates that the
other end-point is somehow packet rate limited.
ETSI
If an SDP offer is received from another MTSI client in terminal using the AMR-NB or AMR-WB codec, then the SDP
offer will include configurations as described in Table 6.1 and Table 6.2. If the MTSI client in terminal chooses to
accept the offer for using the AMR-NB or AMR-WB codec, as configured in Table 6.1 or Table 6.2 then the MTSI
client in terminal shall support a configuration where the MTSI client in terminal creates an SDP answer containing an
RTP payload type for the AMR-NB and AMR-WB codec as shown in Table 6.4.
ETSI
Table 6.3b: Handling of the EVS Primary SDP parameters in the received SDP offer and in the SDP
answer
Parameter Comments Handling
br An MTSI client in terminal supporting the EVS
codec is required to support the entire bit-rate
range but may offer a smaller bit-rate range or
even a single bit-rate.
br-send
br-recv
bw The session should start with the maximum Both the offerer and the answerer shall send
bandwidth supported by the initial bit-rate up to according to the bandwidth parameter in the
the maximum negotiated bandwidth. If a range answer.
of bandwidth is negotiated, the codec can
operate in any bandwidth in the session but the
maximum bandwidth in the range should be
used after the start of or update of the session.
If a single audio bandwidth higher than
narrowband is negotiated, the codec operates
in the negotiated bandwidth but can use lower
bandwidth(s) in the session, depending on the
input signal.
bw-send
bw-recv
ch-send
ch-recv
cmr In EVS AMR-WB IO mode, CMR to the bit-rates If cmr=-1 and the session is in the EVS Primary
of EVS AMR-WB IO mode and NO_REQ is mode, MTSI client in terminal shall not transmit
always enabled. CMR. If cmr=-1 and the session is in the EVS
AMR-WB IO, MTSI client in terminal shall
restrict CMR to values of EVS AMR-WB-IO bit-
rates and NO_REQ in the session.
MTSI client in terminal is required to accept
CMR even when cmr=-1. MTSI client in terminal
is required to accept RTP payload without CMR
even when cmr=1.
ch-aw-recv If a positive (2, 3, 5, or 7) value of ch-aw-recv is
declared for a payload type and the payload
type is accepted, the receiver of the parameter
shall send partial redundancy (channel-aware
mode) at the start of the session using the value
as the offset. If ch-aw-recv=0 is declared or not
present for a payload type and the payload type
is accepted, the receiver of the parameter shall
not send partial redundancy (channel-aware
mode) at the start of the session. If ch-aw-
recv=-1 is declared for a payload type and the
payload type is accepted, the receiver of the
parameter shall not send partial redundancy
(channel-aware mode) in the session. If not
present or a non-negative (0, 2, 3, 5, or 7) value
of ch-aw-recv is declared for a payload type and
the payload type is accepted, partial
redundancy (channel-aware mode) can be
activated or deactivated during the session
based on the expected or estimated channel
condition through adaptation signalling, such as
CMR (see Annex A.2 of [125]) or RTCP based
signalling (see clause 10.2). If not present or a
non-negative (0, 2, 3, 5, or 7) value of ch-aw-
recv is declared for a payload type and the
payload type is accepted, the partial
redundancy offset value can also be adjusted
during the session based on the expected or
estimated channel condition through adaptation
signalling.
ETSI
Table 6.4: SDP parameters for AMR-NB or AMR-WB for SDP answer when the SDP offer is received
from another MTSI client in terminal
Parameter Usage
octet-align Shall not be included
mode-set See Table 6.3
mode-change-period Shall not be included
mode-change-capability May be included. If it is included then it shall be set
to 2
mode-change-neighbor Shall not be included
maxptime Shall be set to 240, see also Table 7.1
crc Shall not be included
robust-sorting Shall not be included
interleaving Shall not be included
ptime Shall be set according to Table 7.1
channels Shall either be set to 1 or be omitted
max-red Shall be included and shall be set to 220 or less
ecn-capable-rtp: leap ect=0 Shall be included in the SDP answer if accepting an
offer to use ECN and if the session setup allows for
bit-rate adaptation
System Simulator:
UE:
- UE is configured to use the precondition mechanism.
Preamble:
ETSI

U-S Message
1 UE is made to attempt an IMS voice call. - -
Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
place
9 Step 2 of Annex A.4.1 happens <-- 100 Trying
10 Step 3 of Annex A.4.1 happens <-- 183 Session Progress
11 Step 4 of Annex A.4.1 happens --> PRACK
12B- Steps 11-12 of generic procedure specified in
12C Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
13 Step 6 of Annex A.4.1 happens --> UPDATE 2 P
15 Step 8 of Annex A.4.1 happens <-- 180 Ringing
16 Step 9 of Annex A.4.1 happens --> PRACK
19 Step 12 of Annex A.4.1 happens --> ACK

U-S Message
ETSI
183 Session Progress (Step 10)
Use the default message "183 Session Progress" in annex A.4.1 with the following exceptions:
Header/param Value/Remark
Require
Message-body The following SDP types and values.
v=0
o=- 1111111111 1111111111 IN (addrtype) (unicast-address for SS)
s=-
b=AS:38
Time description:
t=0 0
Media description:
b=AS:38

a=rtpmap: (payload type) AMR-WB/16000/1 [Note 1]
a=fmtp: (format) mode-change-capability=2; max-red=220 [Note 1]
a=ptime:20
a=maxptime:240

a=crypto:1
AES_CM_128_HMAC_SHA1_80inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^
20|1:4 [Note 5]
Attributes for preconditions:

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
Note 1: The values for fmt, payload type and format are copied from step 2.
Note 2: Transport port is the port number of the SS (see RFC 3264 clause 6).
Note 4: Attributes for ECN Capability are present if the UE supports Explicit Congestion
Notification.
Note 5: Attributes for media plane security are present if the use of end-to-access-edge security is
supported by UE.
UPDATE (Step 13)
Use the default message "UPDATE" in annex A.4.1 with the following exceptions:
ETSI
Require
Message-body The following SDP types and values shall be present.
v=0
o=(username) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE) [Note 2]
s=(session name)
Time description:
t=0 0
Media description:
m=audio (transport port) RTP/AVP (fmt) [Note 3]
b=RS: (bandwidth-value)
b=RR: (bandwidth-value)

a=rtpmap: (payload type) AMR-WB/16000 [Note 3] [Note 5]
a=fmtp: (format) [Note 3] [Note 4]

a=curr:qos local sendrecv
a=des:qos optional remote sendrecv or a=des:qos mandatory remote sendrecv

Note 2: "o=" line identical to previous SDP sent by UE except that sess-version is incremented by
one
Note 3: The value for fmt, payload type and format is not checked
Note 4: Parameters for the AMR codec are not checked
Note 5: The AMR channel number shall be "/1" or omitted.
7.19 MTSI MT Voice Call / EVS / AMR-WB IO mode / 5GS

(1)
with { UE having set up a voice call using EVS and being configured to use preconditions }
ensure that {
when { UE receives INVITE indicating to switch to EVS AMR-WB IO mode }
then { UE responds by accepting this switch }
}
[TS 26.114, clause 5.2.1.1]:
communication. The only exception to this requirement is for the MTSI client in constrained terminal offering speech
communication, in which case the MTSI client in constrained terminal shall support narrowband and wideband, and
should support super-wideband communication.
- .AMR speech codec (3GPP TS 26.071 [11], 3GPP TS 26.090 [12], 3GPP TS 26.073 [13] and
ETSI
MTSI clients in terminals offering super-wideband or fullband speech communication shall support:
TS 26.442 [122], TS 26.452 [165] and TS 26.443 [123]) as described below including functions for backwards
compatibility with AMR-WB ( TS 26.446 [126]) and discontinuous transmission ( TS 26.449 [129] and
TS 26.450 [130]). More detailed codec requirements for the EVS codec are defined in clause 5.2.1.4.
Encoding of DTMF is described in Annex G.
[TS 26.114, clause 5.2.1.4]:
When the EVS codec is supported, the MTSI client in terminal may support dual-mono encoding and decoding.
When the EVS codec is supported, EVS AMR-WB IO may serve as an alternative implementation of the AMR-WB
codec, [125]. In this case, the requirements and recommendations defined in this specification for the AMR-WB codec
also apply to EVS AMR-WB IO.
NOTE: The DTX operation of EVS Primary and AMR-WB IO can be configured in sending direction with either
a fixed SID update interval (from 3 to 100 frames) or an adaptive SID update interval - more details can
be found in clauses 4.4.3 and 5.6.1.1 of TS 26.445 [125]. Implementers of MTSI clients are advised to
take into account this SID flexibility of EVS.
[TS 26.114, clause 6.2.2.3]:
An MTSI client in terminal must understand all the payload format options that are defined in RFC 4867 [28], and in
[125]. It does not have to support operating according to all these options but must be capable to properly accepting or
rejecting all options.
ETSI
Table 6.3a: Handling of SDP parameters common to EVS Primary and EVS AMR-WB IO in the
received SDP offer and in the SDP answer
ptime
maxptime
dtx MTSI client in terminal shall not include dtx in
the initial SDP offer. MTSI MGW may modify
SDP offer to include dtx in order to disable DTX
in the session.
dtx-recv MTSI client in terminal shall not include dtx-
recv. MTSI MGW may modify SDP offer or
answer in order to disable DTX for the send
direction of the receiver of dtx-recv.
hf-only -
evs-mode-switch This parameter is used by MTSI MGW either MTSI client in terminal shall not include evs-
when starting in EVS AMR-WB IO mode mode-switch in the initial SDP offer. When
instead of EVS Primary mode or when including evs-mode-switch in the SDP offer
switching between EVS Primary mode and EVS during a session, the offerer shall use the
AMR-WB IO mode, e.g., for SRVCC. requested mode when sending EVS packets.
However, if a media stream is already being
received, the offerer needs to be prepared to
receive packets in both EVS primary and EVS
AMR-WB IO modes until receiving the answer.
When including evs-mode-switch in the SDP
answer during a session, the answerer shall
use the requested mode when sending EVS
packets. When receiving SDP answer including
evs-mode-switch during a session, the offerer
shall use the requested mode when sending
EVS packets.
max-red See Table 6.3
channels See Table 6.3
ETSI
Table 6.3b: Handling of the EVS Primary SDP parameters in the received SDP offer and in the SDP
answer
br An MTSI client in terminal supporting the EVS
codec is required to support the entire bit-rate
range but may offer a smaller bit-rate range or
even a single bit-rate.
br-send
br-recv
bw The session should start with the maximum Both the offerer and the answerer shall send
bandwidth supported by the initial bit-rate up to according to the bandwidth parameter in the
the maximum negotiated bandwidth. If a range answer.
of bandwidth is negotiated, the codec can
operate in any bandwidth in the session but the
maximum bandwidth in the range should be
used after the start of or update of the session.
If a single audio bandwidth higher than
narrowband is negotiated, the codec operates
in the negotiated bandwidth but can use lower
bandwidth(s) in the session, depending on the
input signal.
bw-send
bw-recv
ch-send
ch-recv
cmr In EVS AMR-WB IO mode, CMR to the bit-rates If cmr=-1 and the session is in the EVS Primary
of EVS AMR-WB IO mode and NO_REQ is mode, MTSI client in terminal shall not transmit
always enabled. CMR. If cmr=-1 and the session is in the EVS
AMR-WB IO, MTSI client in terminal shall
restrict CMR to values of EVS AMR-WB-IO bit-
rates and NO_REQ in the session.
MTSI client in terminal is required to accept
CMR even when cmr=-1. MTSI client in terminal
is required to accept RTP payload without CMR
even when cmr=1.
ch-aw-recv If a positive (2, 3, 5, or 7) value of ch-aw-recv is
declared for a payload type and the payload
type is accepted, the receiver of the parameter
shall send partial redundancy (channel-aware
mode) at the start of the session using the value
as the offset. If ch-aw-recv=0 is declared or not
present for a payload type and the payload type
is accepted, the receiver of the parameter shall
not send partial redundancy (channel-aware
mode) at the start of the session. If ch-aw-
recv=-1 is declared for a payload type and the
payload type is accepted, the receiver of the
parameter shall not send partial redundancy
(channel-aware mode) in the session. If not
present or a non-negative (0, 2, 3, 5, or 7) value
of ch-aw-recv is declared for a payload type and
the payload type is accepted, partial
redundancy (channel-aware mode) can be
activated or deactivated during the session
based on the expected or estimated channel
condition through adaptation signalling, such as
CMR (see Annex A.2 of [125]) or RTCP based
signalling (see clause 10.2). If not present or a
non-negative (0, 2, 3, 5, or 7) value of ch-aw-
recv is declared for a payload type and the
payload type is accepted, the partial
redundancy offset value can also be adjusted
during the session based on the expected or
estimated channel condition through adaptation
signalling.
ETSI
Table 6.3c: SDP parameters for the EVS AMR-WB IO parameters in the received SDP offer and in the
SDP answer
mode-set See Table 6.3
mode-change-
period
mode-change-
neighbor
mode-change- The default value is re-defined in comparison to As the default and the only allowed value of
capability that in [28]. mode-change-capability is 2 in EVS AMR-WB
IO, it is not required to include this parameter in
the SDP offer or answer.
NOTE 2: ECN-triggered adaptation is currently undefined for EVS. This does not prevent ECN-triggered
adaptation from being negotiated and used for AMR or AMR-WB.
[TS 26.114, clause 6.2.5.2]:
If an MTSI client includes an AMR or AMR-WB mode-set, or EVS Primary mode br or br-recv parameter in the SDP
offer or answer, the MTSI client shall set the b=AS parameter to a value matching the maximum codec mode in the
mode-set or the highest bit-rate in the br or br-recv, the packetization time (ptime), and the intended redundancy level.
For example, b=AS for AMR-WB at IPv6 should be set to 38 if mode-set includes {6.60, 8.85, 12.65}, the
packetization time is 20, and if no extra bandwidth is allocated for redundancy. Likewise, b=AS for EVS Primary mode
at IPv4 should be set to 42 if br=7.2-24.4, the packetization is header-full payload format, ptime=20, and no extra
bandwidth is allocated for redundancy.
If an MTSI client does not include an AMR or AMR-WB mode-set, or EVS Primary mode br or br-recv parameter in
the SDP offer or answer, the MTSI client shall set the b=AS parameter in the SDP to a value matching the highest
AMR/AMR-WB mode, i.e., AMR 12.2 and AMR-WB 23.85, or the highest bit-rate of EVS Primary mode depending
on negotiated bandwidth(s), i.e., EVS 24.4 for NB and EVS 128 for WB, SWB and FB, respectively.
NOTE 1: When no mode-set is defined, then this should be understood as that the offerer or answerer is capable of
sending and receiving all codec modes of AMR or AMR-WB. An MTSI client in terminal will not
include the mode-set parameter in SDP offer in the initial offer-answer negotiation. See Clause 6.2.2.2,
Tables 6.1 and 6.2. It is however expected that the mode-set is defined when an SDP offer is received
from an MTSI MGW inter-working with CS GERAN/UTRAN, see Clause 6.2.2.3, Table 6.5.
The bandwidth to use for b=AS for AMR and AMR-WB, and EVS Primary mode should be computed as shown in
Annexes K and Q respectively. Tables 6.7 and 6.8 shows the bandwidth for the respective AMR and AMR-WB codec
when the packetization time is 20 and no extra bandwidth is allocated for redundancy. The b=AS value is computed
without taking statistical variations, e.g., the effects of DTX, into account. Such variations can be considered in the
scheduling and call admission control. Detailed procedures to compute b=AS of AMR and AMR-WB, and EVS
Primary mode can be found in Annexes K and Q.
NOTE 2: For any payload format, b=AS of EVS Primary mode at 5.9 kbps source controlled variable bit-rate (SC-
VBR) coding is computed as the b=AS of its highest component bit-rate, 8 kbps.
NOTE 3: b=AS of EVS AMR-WB IO mode can be computed as in the octet-aligned payload format of AMR-WB
as shown in Annex K.
b=AS of EVS shall be equal to the maximum of b=AS of the highest included EVS primary mode and b=AS of the
highest included EVS AMR-WB IO mode, regardless of the presence and configuration of evs-mode-switch.
Table 6.7: b=AS for each codec mode of AMR when ptime is 20
Codec mode
Payload format
4.75 5.15 5.9 6.7 7.4 7.95 10.2 12.2
Bandwidth- IPv4 22 22 23 24 24 25 27 29
efficient IPv6 30 30 31 32 32 33 35 37
ETSI
Octet- IPv4 22 22 23 24 25 25 28 30
aligned IPv6 30 30 31 32 33 33 36 38
Table 6.8: b=AS for each codec mode of AMR-WB when ptime is 20
Codec Mode
Payload format
6.6 8.85 12.65 14.25 15.85 18.25 19.85 23.05 23.85
Bandwidth- IPv4 24 26 30 31 33 35 37 40 41
efficient IPv6 32 34 38 39 41 43 45 48 49
Octet- IPv4 24 26 30 32 33 36 37 40 41
aligned IPv6 32 34 38 40 41 44 45 48 49
Table 6.9: b=AS for each bit-rate of EVS Primary mode when ptime is 20
Bit-rate
Payload format
7.2 8 9.6 13.2 16.4 24.4 32 48 64 96 128
IPv4 24 25 27 30 34 42 49 65 81 113 145
Header-full
IPv6 32 33 35 38 42 50 57 73 89 121 153
System Simulator:
UE:
Preamble:
ETSI

U-S Message
Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed
place
8 Step 1 of Annex A.4.1a happens --> INVITE - -
9 Step 2 of Annex A.4.1a happens <-- 100 Trying - -
10 Step 3 of Annex A.4.1a happens <-- 183 Session Progress - -
11 Step 4 of Annex A.4.1a happens --> PRACK - -
12 Step 5 of Annex A.4.1a happens <-- 200 OK - -
12C Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
13 Step 6 of Annex A.4.1a happens --> UPDATE - -
15 Step 8 of Annex A.4.1a happens <-- 180 Ringing - -
16 Step 9 of Annex A.4.1a happens --> PRACK - -
19 Step 12 of Annex A.4.1a happens --> ACK - -
20 Step 1 of Annex A.5.1a happens <-- INVITE - -
21 Step 2 of Annex A.5.1a happens --> 100 Trying - -
22 Step 11 of Annex A.5.1a happens --> 200 OK 1 P
23 Step 12 of Annex A.5.1a happens <-- ACK - -

U-S Message
INVITE (Step 20)
Use the default message "INVITE (Step 1)" in annex A.5.1a with the following exceptions:
Header/param Value/remark
Supported
Message-body SDP body copied from the previous 200 OK (step 12 or 14) and modified as follows:
- "o=" line identical to previous SDP sent by SS except that sess-version is

incremented.
- "a=fmtp" line identical to previous SDP sent by SS except that "evs-mode-
switch=1" is added.
ETSI
200 OK (Step 22)
Use the default message "200 OK (Step 11)" in annex A.5.1a with the following exceptions:
Require precondition
option-tag
Content-Type
media-type application/sdp
Content-Length
value length of message-body
v=0
o=(user-name) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE) [Note
4]
s=(session name)
Time description:
t=0 0
Media description:

a=rtpmap:(payload type) EVS/16000 [Note 2]
a=fmtp:(format) evs-mode-switch=1; [Note 2, 3]

a=curr:qos remote sendrecv

Note 2: The values for fmt, payload type and format are not checked.
Note 3: The evs-mode-switch is checked, but no other codec parameters.
Note 4: "o=" line identical to previous SDP sent by UE except that sess-version is
incremented by one.
7.20 MTSI MO Voice Call / add video and remove video / with
preconditions at both originating UE and terminating UE /
5GS
(1)
with { UE is configured to use preconditions and has set up a voice call with preconditions }
ensure that {
when { UE is made to add video to the voice call }
then { UE sends re-INVITE with SDP media for both voice and video }
}
ETSI
(2)
with { UE having sent re-INVITE }
ensure that {
when { UE receives 100 Trying and 183 Session in Progress with SDP answer }
then { UE acks with PRACK }
}
(3)
ensure that {
when { UE receives 200 OK for PRACK and indication that resources are reserved }
then { UE sends UPDATE with SDP offer indicating reserved resources }
}
(4)
ensure that {
when { UE receives 200 OK for UPDATE followed by 200 OK for re-INVITE }
}
(5)
with { UE having successfully added video }
ensure that {
when { UE is made to remove video again }
then { UE sends re-INVITE with SDP indicating that video is being removed from the call }
}
(6)
ensure that {
when { UE receives 100 Trying followed by 200 OK and indication that video resources have been
removed }
}
[TS 24.173, clause 5.2]:
The IMS multimedia telephony communication service can support different types of media, including media types
listed in 3GPP TS 22.173 [2]. The session control procedures for the different media types shall be in accordance with
3GPP TS 24.229 [13] and 3GPP TS 24.247 [14], with the following additions:
a) Multimedia telephony is an IMS communication service and the P-Preferred-Service and P-Asserted-Service
headers shall be treated as described in 3GPP TS 24.229 [13]. The coding of the ICSI value in the P-Preferred-
Service and P-Asserted-Service headers shall be according to subclause 5.1.
[TS 24.229, clause 5.1.2A.1]:
If this is a request within an existing dialog, and the request includes a Contact header field, then the UE should insert
the previously used Contact header field.
...
After the dialog is established the UE may change the dialog capabilities (e.g. add a media or request a supplementary
service) if defined for the IMS communication service as identified by the ICSI value using the same dialog. Otherwise,
the UE shall initiate a new initial request to the other user.
[TS 24.229, clause 5.1.3]:
ETSI
mechanism.
The UE may initiate a session without the precondition mechanism if the originating UE does not require local resource
reservation.
NOTE 1: The originating UE can decide if local resource reservation is required based on e.g. application
INVITE request and:
field,
ETSI
establishment.
[TS 24.229, clause 5.1.4A.1]:
If the precondition mechanism was used during the session establishment, as described in subclause 5.1.3.1 or 5.1.4.1,
the UE shall indicate support of the precondition mechanism during a session modification. If the precondition
mechanism was not used during the session establishment, the UE shall not indicate support of the precondition
mechanism during a session modification.
In order to indicate support of the precondition mechanism during a session modification, upon generating a reINVITE
request, an UPDATE request with an SDP body, or a PRACK request with an SDP body, the UE shall:
a) indicate the support for the precondition mechanism using the Supported header field;
b) not indicate the requirement for the precondition mechanism using the Require header field; and
c) if a re-INVITE request is being generated, indicate the support for reliable provisional responses using the
Supported header field
[TS 24.229, clause 5.1.4A.2]:
Upon receiving a reINVITE request, an UPDATE request, or a PRACK request that indicates support for the
precondition mechanism by using the Supported header field or requires use of the precondition mechanism by using
the Require header field, the UE shall:
a) if the precondition mechanism was used during the session establishment, as described in subclause 5.1.3.1 or
5.1.4.1, use the precondition mechanism for the session modification; and
If the precondition mechanism is used for the session modification, the UE shall indicate support for the preconditions
mechanism, using the Require header field, in responses that include an SDP body, to the session modification request.
[TS 24.229, clause 6.1]:
...
...
ETSI
using 5GS).
In order to fulfil the QoS requirements of one or more media streams, the UE may re-use previously reserved resources.
In this case the UE shall indicate as met the local preconditions related to the media stream, for which resources are re-
used.
[TS 24.229, clause 6.1.2]:
SDP offer, the UE:
behaviours.
ETSI
...
send an SDP offer at the first possible time, selecting only one codec per media stream; or
[TS 26.114, clause 6.2.1a.1]
MTSI clients should support SDPCapNeg to be able to negotiate RTP profiles for all media types where AVPF is
supported. MTSI clients supporting SDPCapNeg shall support the complete SDPCapNeg framework.
SDPCapNeg is described in [69]. This clause only describes the SDPCapNeg attributes that are directly applicable for
the RTP profile negotiation, i.e. the tcap, pcfg and acfg attributes. TS 24.229 [7] may outline further requirements
needed for supporting SDPCapNeg in SDP messages.
NOTE: This clause describes only how to use the SDPCapNeg framework for RTP profile negotiation using the
tcap, pcfg and acfg attributes. Implementers may therefore (incorrectly) assume that it is sufficient to
implement only those specific parts of the framework that are needed for RTP profile negotiation. Doing
so would however not be future proof since future versions may use other parts of the framework and
there are currently no mechanisms for declaring that only a subset of the framework is supported. Hence,
MTSI clients are required to support the complete framework.
[TS 26.114, clause 6.2.1a.2]
For voice and real-time text, SDPCapNeg shall be used when offering AVPF the first time for a new media type in the
session since the support for AVPF in the answering client is not known at this stage. For video, an MTSI client shall
either offer AVPF and AVP together using SDPCapNeg, or the MTSI client shall offer only AVPF without using
SDPCapNeg. If an MTSI client has offered only AVPF for video, and then receives as response either an SDP answer
where the video media component has been rejected, or an SIP 488 or 606 failure response with an SDP body indicating
that only AVP is supported for video media, the MTSI client should send a new SDP offer with AVP as transport for
video. Subsequent SDP offers, in a re-INVITE or UPDATE, may offer AVPF without SDPCapNeg if it is known from
an earlier re-INVITE or UPDATE that the answering client supports this RTP profile. If the offer includes only AVP
then SDPCapNeg does not need to be used, which can occur for: text; speech if RTCP is not used; and in re-INVITEs or
UPDATEs where the RTP profile has already been negotiated for the session in a preceding INVITE or UPDATE.
When offering AVP and AVPF using SDPCapNeg, the MTSI client shall offer AVP on the media (m=) line and shall
offer AVPF using SDPCapNeg mechanisms. The SDPCapNeg mechanisms are used as follows:
the support for AVPF is indicated in an attribute (a=) line using the transport capability attribute ‘tcap’. AVPF shall
be preferred over AVP.
at least one configuration using AVPF shall be listed using the attribute for potential configurations ‘pcfg’.
[TS 26.114, clause 6.2.3.2]:
ETSI
[TS 26.114, clause 6.2.5.1]:
An MTSI client in terminal should include the ‘a=bw-info’ attribute in the SDP offer. When accepting a media type
where the ‘a=bw-info’ attribute is included the MTSI client in terminal shall include the ‘a=bw-info’ attribute in the
SDP answer if it supports the attribute. The ‘a=bw-info’ attribute and the below used bandwidth properties are defined
in clause 19.
[TS 26.114, clause 6.3]:
During session renegotiation for adding or removing media components, the SDP offerer should continue to use the
same media (m=) line(s) from the previously negotiated SDP for the media components that are not being added or
removed.
An MTSI client in terminal may support multiple media components including media components of the same media
type. An MTSI client in terminal may support adding one or more media components to an on-going session which
already contains a media component of the same media type. If an MTSI client in terminal needs to have multiple media
components of the same media type in a single MTSI session, then the MTSI client in terminal should use the SDP
content attributes as defined in [81] for identifying different media components.
[TS 26.114, clause 7.3.1]
System Simulator:
UE:
Preamble:
- UE has registered to IMS services and set up the MO call, by executing annex A.4.1a.
ETSI

U-S Message
1 Make UE add video to the voice call - -
2 Check: Does the UE send re-INVITE with an SDP offer -> INVITE 1 P
containing media lines for both voice and video?
3 The SS responds with a 100 Trying provisional response <- 100 Trying - -
4 SS responds with an SDP answer indicating that SS has <- 183 Session in Progress - -
not reserved its resources for video
5 Check: Does the UE acknowledge the receipt of 183 -> PRACK 2 P
response with PRACK?
6 The SS responds PRACK with 200 OK. <- 200 OK - -
6A SS reserves resources for video by executing TS 38.508-1 - - - -
cl 4.9.27
7 Check: Does the UE send an UPDATE after having -> UPDATE 3 P
reserved the resources for video if meeting the
preconditions indicated in step 4?
8 The SS responds UPDATE with 200 OK and indicates <- 200 OK - -
having reserved the resources
9 The SS responds re-INVITE with 200 OK <- 200 OK - -
10 Check: Does the UE acknowledge the receipt of 200 OK -> ACK 4 P
for re-INVITE?
11 Make UE release video from the media call - -
12 Check: Does the UE send re-INVITE with a SDP offer -> INVITE 5 P
indicating that the video component is removed from the
call?
13 The SS responds with a 100 Trying provisional response <- 100 Trying - -
14 SS releases the QoS flow for video by executing TS - -
38.508-1 cl 4.9.28.
15 The SS responds re-INVITE with 200 OK <- 200 OK - -
16 Check: Does the UE acknowledge the receipt of 200 OK -> ACK 6 P
for re-INVITE?
17 Make the UE release the call. - - - -
18- UE releases the call -- - - -
19 (Annex A.7)
Table 7.20.3.3-1: re-INVITE (step 2, table 7.20.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.2.1, conditions A1, A5 and A28.
Supported
Message-body Same SDP body as in Step 6 (UPDATE) of Annex TS 24.229 [7]
A.15.1a, with following differences: TS 26.114 [33]
For preconditions of audio media:

For preconditions of video media:

Table 7.20.3.3-2: 100 Trying (step 3, table 7.20.3.2-1)
Derivation Path: Annex A.15.1, Step 2
ETSI
Table 7.20.3.3-3: 183 Session in Progress (step 4, table 7.20.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.2.3, Condition A1

Require
Message-body Same SDP body as in Step 3 (183 Session in Progress) of TS 24.229 [7]
Annex A.15.1a, with following exceptions: TS 26.114 [33]

"o=" line identical to previous SDP sent by SS except that
sess-version is incremented by one
Table 7.20.3.3-4: PRACK (step 5, table 7.20.3.2-1)
Derivation Path: Annex A.15.1a, Step 4
Table 7.20.3.3-5: 200 OK for PRACK (step 6, table 7.20.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.2.5, conditions A1 and A6.

Supported
Message-body Same contents as specified in step 6 (UPDATE) of TS 24.229 [7]
A.15.1a with the following exceptions: TS 26.114 [33]

Table 7.20.3.3-7: 200 OK for UPDATE (step 8, table 7.20.3.2-1)
Derivation Path: Annex A.15.1a Step 7
Table 7.20.3.3-8: 200 OK for re-INVITE (step 9, table 7.20.3.2-1)
Table 7.20.3.3-9: ACK for re-INVITE (step 10, table 7.20.3.2-1)
ETSI
Supported
Message-body Same SDP body as in Step 2 (re-INVITE), with following TS 24.229 [7]
exceptions and no requirements on b-, c- or a-lines on the TS 26.114 [33]
video stream:
Media description:
m=video 0 RTP/AVPF (fmt)
Derivation Path: Annex A.15.1a, step 2
Table 7.20.3.3-12: 200 OK for INVITE (step 15, table 7.20.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.3.1, Conditions A2, A5, A11, A20 and A22
Require
Content-Type
Content-Length header shall be present if UE uses TCP to send this
message and if there is a message body
Message-body SDP body copied from the received re-INVITE in step 12
and modified as follows:
- IP address on "c=" lines and transport port on "m=" lines

changed to indicate to which IP address and port the UE
should start sending the media;
- "o=" line identical to previous SDP sent by SS except
that sess-version is incremented
Table 7.20.3.3-13: ACK (step 16, table 7.20.3.2-1)
7.21 MTSI MO Voice Call / add video and remove video / without
5GS
(1)
with { UE is configured to not use preconditions and has set up a voice call without preconditions }
ensure that {
when { UE receives re-INVITE indicating addition of video to voice call }
then { UE may send 100 Trying and sends 183 Session Progress with SDP answer or sends 2OO OK
with SDP answer for re-INVITE }
}
ETSI
(2)
with { UE having optionally sent 183 Session Progress }
ensure that {
then { UE sends 200 OK for PRACK followed by 200 OK for re-INVITE }
}
(3)
with { UE receiving ACK }
ensure that {
when { UE is made to remove video again }
then { UE sends re-INVITE with SDP indicating that video is being removed from the call }
}
(4)
ensure that {
when { UE receives 100 Trying followed by 200 OK and indication that video resources have been
removed }
}
[TS 24.173, clause 5.2]:
[TS 24.229, clause 5.1.2A.2]:
[TS 24.229, clause 5.1.4A.1]:
[TS 24.229, clause 5.1.4A.2]:
5.1.4.1, use the precondition mechanism for the session modification; and
b) if the precondition mechanism was not used during the session establishment, and:
1) if the use of the precondition mechanism is required using the Require header field, reject the request by
sending a 420 (Bad Extension) response; and
ETSI
2) if the support of the precondition mechanism is indicated using the Supported header field, not use the
precondition mechanism for the session modification.
[TS 24.229, clause 6.1]:
...
...
using 5GS).
used.
[TS 24.229, clause 6.1.2]:
SDP offer, the UE:
ETSI
behaviours.
...
[TS 26.114, clause 6.2.1a.1]
[TS 26.114, clause 6.2.1a.2]
ETSI
[TS 26.114, clause 6.2.3.2]:
[TS 26.114, clause 6.2.5.1]:
in clause 19.
[TS 26.114, clause 6.3]:
removed.
[TS 26.114, clause 7.3.1]
System Simulator:
UE:
ETSI
- UE is configured to not use preconditions.
Preamble:
- UE registered to IMS services and set up the MO call, by executing annex A.4.2.

U-S Message
1 SS sends re-INVITE with an SDP offer containing media <-- INVITE - -
lines for both voice and video
2 Optional: UE may respond with a 100 Trying provisional --> 100 Trying - -
response
2A SS starts a timer (2 seconds) to wait for an optional 183 - - - -
Session in Progress from UE.
NOTE: If the UE does not send 183 Session in Progress
before timer expiry, proceed to step 3b1.
- EXCEPTION: Steps 3a1 to 3b4 describe behaviour that - - - -
depends on UE implementation; the “lower case letter”
identifies a step sequence that takes place if such
implementation take place.
3a1 Check: Does the UE respond 183 Session in Progress --> 183 Session in Progress 1 P
with an SDP answer?
3a2 Timer from step 2A is stopped. - - - -
3a3 SS acknowledges the receipt of 183 response with <-- PRACK - -
PRACK
3a4 Check: Does the UE respond PRACK with 200 OK? --> 200 OK 2 P
3a5 SS reserves resources for video by executing TS 38.508-1 - - - -
cl 4.9.27
3a6 Make UE accept the call modification (Note 1). - - - -
3a7 UE responds re-INVITE with 200 OK --> 200 OK 2 P
3a8 SS acknowledges the receipt of 200 OK for re-INVITE <-- ACK - -
3b1 Make UE accept the call modification (Note 1). - - - -
3b2 Check: Does the UE respond to re-INVITE with 200 OK --> 200 OK 1, 2 P
with SDP answer?
3b3 SS reserves resources for video by executing TS 38.508-1 - - - -
cl 4.9.27
3b4 SS acknowledges the receipt of 200 OK for re-INVITE <-- ACK - -
4-7 Void - - - -
8 Make UE release video from the media call (Note 2). - - - -
9 Check: Does the UE send re-INVITE with a SDP offer --> INVITE 3 P
indicating that the video component is removed from the
call?
10 The SS responds with a 100 Trying provisional response <-- 100 Trying - -
11 SS releases the QoS flow for video by executing TS - - - -
38.508-1 cl 4.9.28.
12 The SS responds re-INVITE with 200 OK <-- 200 OK - -
13 Check: Does the UE acknowledge the receipt of 200 OK --> ACK 4 P
for re-INVITE?
14 Make the UE release the call - - - -
15 UE sends BYE --> BYE - -
16 SS sends 200 OK for BYE <-- 200 OK - -
NOTE 1: This could be done by e.g. MMI or AT command (AT+CCMMD).
NOTE 2: This could be done by e.g. MMI or AT command (AT+CCMMD).
ETSI
Derivation Path: TS 34.229-1 [2], Table in annex A.2.9, conditions A1 and A5.
Content-Type
Content-Length
Message-body Same SDP body as in Step 1 (INVITE) of Annex A.16.2, TS 24.229 [7]
with following exceptions: TS 26.114 [33]
o=line identical to previous SDP sent by SS except that
Media description for audio:

Same as in previous SDP sent by the SS in the 183
Session Progress at step 3 of A.4.2

Derivation Path: Annex A.16.2, step 2
Table 7.21.3.3-3: 183 Session Progress (step 3a1, table 7.21.3.2-1)
Derivation Path: Annex A.16.2 step 3

Content-Type
Content-Length
Value length of message-body
Message-body Same SDP body as of Annex A.16.2, step 3, with the
following clarifications:

a=fmtp: (format) br=(br-val); bw=(bw-val); max-
red=(att-field) [Note 1]
Note 1: br-val and bw-val are the values as negotiated
at call establishment (i.e. the same values as sent by the
SS in the 183 Session Progress of A.4.2 Step 3).
Table 7.21.3.3-4: PRACK (step 3a3, table 7.21.3.2-1)
Table 7.21.3.3-5: 200 OK for PRACK (step 3a4, table 7.21.3.2-1)

Table 7.21.3.3-6: 200 OK for re-INVITE (step 3a7, table 7.21.3.2-1)
ETSI
Table 7.21.3.3-6A: 200 OK for re-INVITE (step 3b2, table 7.21.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in annex A.3.1, conditions A8, A11 and A5.
Content-Type
Content-Length
Message-body Same SDP body as of Annex A.16.2, step 3, with the
following clarifications:

a=fmtp: (format) br=(br-val); bw=(bw-val); max-
red=(att-field) [Note 1]
Note 1: br-val and bw-val are the values as negotiated at call establishment (i.e. the same values as sent by the SS
in the 183 Session Progress of A.4.2 Step 3).
Table 7.21.3.3-7: ACK for re-INVITE (step 3a8, 3b3, table 7.21.3.2-1)
Content-Type
Content-Length
Message-body Same SDP body as specified for Step 3a1 or 3b2 (183 or TS 24.229 [7]
200 with SDP answer), with following exceptions and no TS 26.114 [33]
requirements on b-, c- or a-lines on the video stream:
Media description:
m=video 0 RTP/AVPF (fmt)

Content-Type
Message-body SDP body copied from the received re-INVITE in step 12
and modified as follows:

that sess-version is incremented
ETSI
Table 7.21.3.3-12: BYE (step 15, table 7.21.3.2-1)
Derivation Path: Annex A.7, step 1
Table 7.21.3.3-13: 200 OK for BYE (step 16, table 7.21.3.2-1)
Derivation Path: Annex A.7, step 2
7.22 MTSI MT Voice Call / add video and remove video / with
5GS
(1)
with { UE being configured to use preconditions and having been invited to voice call and voice call
being set up successfully }
ensure that {
}
(2)
ensure that {
then { UE sends PRACK }
}
(3)
ensure that {
when { UE receives 200 OK for PRACK and resources being reserved }
then { UE sends UPDATE with SDP offer indicating reserved resources }
}
(4)
ensure that {
when { UE receives 200 OK for UPDATE followed by 200 OK for re-INVITE }
}
(5)
with { UE having sent ACK }
ensure that {
when { UE receives re-INVITE indicating removal of video }
then { UE may send 100 Trying and sends 200 OK for re-INVITE }
}
ETSI
[TS 24.229, clause 5.1.2A.1.1]
[TS 24.229, clause 5.1.3.1]
[TS 24.229, clause 5.1.4A.1]
[TS 24.229, clause 5.1.4A.2]
5.1.4.1, use the precondition mechanism for the session modification;
If the precondition mechanism is used for the session modification, the UE shall indicate support for the preconditions
mechanism, using the Require header field, in responses that include an SDP body, to the session modification request.
[TS 24.229, clause 6.1.1]
ETSI
"telephone-event", to indicate support of in-band DTMF as described in RFC 4733[23].
[TS 24.229, clause 6.1.4.2]
If the precondition mechanism is used for the session modification, the following applies:
a) if the session modification does not increase the QoS requirement of the already established media stream (e.g.,
all the media streams in a call hold procedure, audio stream in a call upgrade procedure), in the SDP body of the
request (re-INVITE, UPDATE, or PRACK), both local and remote QoS of this media shall be indicated as met;
and
b) if the session modification increases the QoS requirement of some already established media stream(s) (e.g.,
request of using a different audio/video codec that requires higher bandwidth), or if the session modification
adds a new media stream (e.g., call upgrade), the setting of the current and desired QoS status of the modified or
added media stream shall be the same as specified in subclause 6.1.2. If the network fails to modify or reserve
the required resources, the UE shall send a CANCEL request to terminate the session modification.
[TS 26.114, clause 5.2.1.1]
MTSI clients in terminals offering super-wideband or full band speech communication shall support:
- EVS codec ( TS 26.441 [121], TS 26.444 [124], TS 26.445 [125], TS 26.447 [127], TS 26.451 [131], TS 26.442
[122], TS 26.452 [165], and TS 26.443 [123] ) as described below including functions for backwards compatibility with
AMR-WB ( TS 26.446 [126]) and discontinuous transmission ( TS 26.449 [129] and TS 26.450 [130]).
[TS 26.114, clause 5.2.2]
- H.265 (HEVC) [119] Main Profile, Main Tier, Level 3.1. The only exception to this requirement is for the MTSI
client in constrained terminal offering video communication, in which case the MTSI client in constrained
terminal should support H.265 (HEVC) Main Profile, Main Tier, Level 3.1.
In addition they should support:- H.264 (AVC) [24] Constrained High Profile (CHP) Level 3.1.
For backwards compatibility to previous releases, if H.264 (AVC) [24] Constrained High Profile Level 3.1 is supported,
then H.264 (AVC) [24] Constrained Baseline Profile (CBP) Level 3.1 should also be offered.
[TS 26.114, clause 6.2.1a.1]
ETSI
[TS 26.114, clause 6.2.1a.2]
- The support for AVPF is indicated in an attribute (a=) line using the transport capability attribute ‘tcap’. AVPF
shall be preferred over AVP.
- At least one configuration using AVPF shall be listed using the attribute for potential configurations ‘pcfg’.
[TS 26.114, clause 6.2.3.2]
RTP profile, video codec, profile and level. The "imageattr" attribute as specified in IETF RFC 6236 [76] should be
supported. The "framesize" attribute as specified in [60] shall not be used in the session setup.
[TS 26.114, clause 6.2.5.1]
[TS 26.114, clause 6.3]
Addition and removal of media components shall be performed based on the SDP-based offer-answer model as
specified in RFC 3264 [58].
During session renegotiation for adding or removing media components, the SDP offeror should continue to use the
removed.
[TS 26.114, clause 7.3.1]
as specified by RFC 3556 [42]. Therefore, an MTSI client shall include the "b=RS:" and "b=RR:" fields in SDP, and
shall be able to interpret them.
ETSI
System Simulator:
UE:
- UE is configured to use preconditions
Preamble:
- The UE has registered to IMS and MT voice call is set up by executing the generic test procedure in clause
4.9.16 of TS 38.508-1 [21] up to the last step.

U-S Message
- Make UE add video to the ongoing voice call - - - -
1 Check: does the UE send re-INVITE with an --> INVITE 1 P
SDP offer containing media lines for both voice
and video?
2 SS responds with 100 Trying <-- 100 Trying - -
3 SS responds with 183 session Progress <-- 183 Session Progress - -
including SDP answer
4 Check: does the UE acknowledge the receipt of --> PRACK 2 P
183 response with PRACK?
5 SS responds to PRACK with 200 OK <-- 200 OK - -
5A SS reserves resources for video by executing - - - -
TS 38.508-1 cl 4.9.27
6 Check: does the UE send UPDATE? --> UPDATE 3 P
7 SS responds UPDATE with 200 OK indicating <-- 200 OK - -
reservation of resources
8 SS responds to re-INVITE with 200 OK <-- 200 OK - -
9 Check: does the UE acknowledge the receipt of --> ACK 4 P
200 OK for re-INVITE?
10 SS sends re-INVITE with SDP offer indicating <-- INVITE - -
that video component is removed from the call.
11 Optional: UE may send 100 Trying. --> 100 Trying - -
12 Check: does the UE responds to re-invite with --> 200 OK 5 P
200 OK final response?
13 SS releases the QoS flow for video by - - - -
executing TS 38.508-1 cl 4.9.28.
14 The SS acknowledges the receipt of 200 OK for <-- ACK - -
re-INVITE.
ETSI
Derivation Path: TS 34.229-1 [2], Annex A.2.1, Conditions A1, A3, A5, A28, A30 and A31
Supported
Message-body SDP body of INVITE copied from Annex A.15.1 Step 6 TS 24.229 [7]
and modified as follows: TS 26.114 [33]

SDP values for video media as mentioned in A.15.1 Step

1 and modified as follows:
For preconditions of video media:a=des:qos optional

remote sendrecv or a=des:qos mandatory remote
sendrecv


Require
Message-body SDP body of 183 Session Progress copied from Annex TS 24.229 [7]
A.15.1 Step 7 and modified as follows: TS 26.114 [33]
For preconditions of video media:

a=curr:qos local none and a=curr:qos remote none
- Video media attribute “a=acfg:1 t=1” present if tcap/pcfg
attributes were included in INVITE
Derivation Path: TS 34.229-1 [2], Annex A.2.4, Conditions A1 and A7
Derivation Path: Annex A.15.1 Step 6 with following exceptions

Supported
Message-body For preconditions of audio media: TS 24.229 [7]
Table 7.22.3.3-7: 200 OK for UPDATE (step 7, table 7.22.3.2-1)
Derivation Path: Annex A.15.1 Step 7
ETSI
Derivation Path: TS 34.229-1 [2], Annex A.3.1, Conditions A1, A10, A19 and A22
Derivation Path: TS 34.229-1 [2], Annex A.2.7, Conditions A1, A3 and A5

Supported
Message-body Same SDP body as in Step 7 (200 OK), but setting the port TS 24.229 [7]
for video to zero on the m-line, and incrementing sess- TS 26.114 [33]
version on the o-line.
Require
Content-Type
Message-body SDP body not checked other than that sess-version on o-
line is incremented by one compared to previous SDP
body sent by the UE and that port is set to zero on m-line
for video
7.23 MTSI MT Voice Call / add video and remove video / without
5GS
(1)
with { UE configured to not use preconditions and having been invited to a voice call and voice call
being set up successfully }
ensure that {
ETSI
(2)
ensure that {
then { UE sends PRACK }
}
(3)
ensure that {
when { UE receives 200 OK for PRACK followed by 200 OK for INVITE and resources are reserved }
}
(4)
ensure that {
when { UE receives re-INVITE indicating that video is being removed from the call }
}
[TS 24.173, clause 5.2]:
[TS 24.229, clause 5.1.2A.2]:
[TS 24.229, clause 5.1.4A.1]:
and follow the SDP procedures in clause 6 for the precondition mechanism.
[TS 24.229, clause 6.1]:
ETSI
...
...
using 5GS).
used.
[TS 24.229, clause 6.1.2]:
SDP offer, the UE:
ETSI
behaviours.
...
[TS 26.114, clause 6.2.1a.1]
[TS 26.114, clause 6.2.1a.2]
ETSI
[TS 26.114, clause 6.2.3.2]:
[TS 26.114, clause 6.2.5.1]:
in clause 19.
[TS 26.114, clause 6.3]:
removed.
[TS 26.114, clause 7.3.1]
System Simulator:
UE:
ETSI
Preamble:
- The UE has registered to IMS and MT voice call is set up by executing the generic test procedure in clause
4.9.16 of TS 38.508-1 [21] up to the last step.

U-S Message
1 Make UE add video to the ongoing voice call. - -
2 Check: Does the UE send re-INVITE with an SDP offer --> INVITE 1 P
containing media lines for both voice and video?
3 SS responds with a 100 Trying provisional response <-- 100 Trying - -
4 SS responds with an SDP answer indicating that SS has <-- 183 Session in Progress - -
not reserved its resources for video
5 Check: Does the UE acknowledge the receipt of 183 --> PRACK 2 P
response with PRACK?
6 SS responds PRACK with 200 OK <-- 200 OK - -
6A SS reserves resources for video by executing TS 38.508-1 - - - -
cl 4.9.27
7 SS responds re-INVITE with 200 OK <-- 200 OK - -
8 Check: Does the UE acknowledge the receipt of 200 OK --> ACK 3 P
for re-INVITE?
9 SS sends re-INVITE with a SDP offer indicating that the <-- INVITE - -
video component is removed from the call
10 Check: Does the UE optionally respond with a 100 Trying -> 100 Trying 4 P
provisional response?
11 UE responds to re-invite with 200 OK final response. --> 200 OK - -
12 SS releases the QoS flow for video by executing TS - - - -
38.508-1 cl 4.9.28.
13 The SS acknowledges the receipt of 200 OK for re- <-- ACK - -
INVITE.
15- UE releases the call - - -
16 (Annex A.7)
Derivation Path: TS 34.229-1 [2], Annex A.2.1, conditions A1, A5 and A28
Message-body Same SDP body as in Step 1 (INVITE) of Annex A.15.2, TS 24.229 [7]
with following exceptions: TS 26.114 [33]
"o=" line identical to previous SDP sent by UE except that
Table 7.23.3.3-3: 183 Session in Progress (step 4, table 7.23.3.2-1)
Derivation Path: Annex A.15.2, Step 3, using additional condition A15 of Annex A.2.3 of TS 34.229-1 [2]
ETSI
Derivation Path: TS 34.229-1 [2], Annex A.2.1, conditions A1 and A5

Message-body Same SDP body as in Step 4 (183 Session Progress),, TS 24.229 [7]
but setting the port for video to zero on the m-line, and TS 26.114 [33]
incrementing sess-version on the o-line.
Derivation Path: TS 34.229-1, Annex A.2.2, condition A2.
Derivation Path: TS 34.229-1 [2], Annex A.3.1, conditions A2, A5, A8, A11, and A22
Message-body SDP body not checked other than that sess-version on o- TS 24.229 [7]
line is incremented by one compared to previous SDP TS 26.114 [33]
body sent by the UE and that port is set to zero on m-line
for video.
Derivation Path: TS 34.229-1, Annex A.2.7, conditions A2 and A5
7.24 MTSI MT Voice Call / Forking / UE receives CANCEL

request for a forked MT voice call / 5GS
(1)
with { UE being registered to IMS and configured to use preconditions and having received INVITE for
voice call and having proceeded the call initiation until before accepting the voice call }
ensure that {
when { UE receives a CANCEL request }
then { UE sends 200 OK for CANCEL and 487 Request Terminated for INVITE }
}
ETSI
[TS 24.229, clause 5.1.4.1]:
If the UE sends a CANCEL request to cancel an initial INVITE request, the UE shall when applicable include in the
CANCEL request a Reason header field with a protocol value set to "RELEASE_CAUSE" and a "cause" header field
parameter as specified in subclause 7.2A.18.11.2. The UE may also include the "text" header field parameter with
reason-text as specified in subclause 7.2A.18.11.2.
7.24.3 Profile Requirements (Informative)
[GSMA NG.114 V1.0, clause 2.3.7]:
The IMS core network can support sending and the UE must support receiving a SIP CANCEL request including a
Reason header field with values of:
1. SIP; cause=200; text="Call completed elsewhere"
2. SIP; cause=603; text="Declined"
3. SIP; cause=600; text=” Busy Everywhere”
for forked calls as defined in 3GPP TS 24.229 [8].
System Simulator:
UE:
Preamble:
ETSI

U-S Message
1-8 Steps 1-8 of generic procedure specified in Table 4.9.16.2.2-1 - - - -
of TS 38.508-1 [21] are performed
9-13 MT voice call setup is initiated and proceeds until before UE is - - - -
made to accept the voice call
(Steps 1--5 of Annex A.5.1a)
13A- Steps 10-12 of generic procedure specified in Table 4.9.16.2.2- - - - -
13C 1 of TS 38.508-1 [21] are performed
14-18 MT voice call setup proceeds until before SS sends UPDATE - - - -
(Steps 6--10 of Annex A.5.1a)
19 SS sends a CANCEL request <-- CANCEL - -
EXCEPTION: In parallel to the event described in step 20, the - - - -
step specified in Table 7.24.4.2-2 takes place.
20 UE sends 200 OK for CANCEL --> 200 OK 1 P

U-S Message
1 UE sends 487 Request Terminated response for INVITE --> 487 Request 1 P
Terminated
Table 7.24.4.3-1: CANCEL (step 19, table 7.24.4.2-1)

Reason RFC 3326 [42]
protocol SIP
protocol-cause cause=200
reason-text text=”Call completed elsewhere”
Table 7.24.4.3-3: 487 Request Terminated (step 1, table 7.24.4.2-2)
ETSI
7.24a MTSI MO Voice Call / Forking / UE receives two preliminary

responses and one early dialog termination / 5GS
(1)
with { UE being registered to IMS and configured to use preconditions and to not use GRUU and to not
suppress forking }
ensure that {
when { UE is made to start a voice call, processes the call setup until before completion, and
then receives another early dialog indication }
then { UE processes the second early dialog until before completion }
}
(2)
with { UE having proceeded two early dialogs }
ensure that {
when { UE receives 199 Early Dialog Terminated for the first dialog, followed by 200 OK for the
second dialog }
then { UE sends ACK on the second dialog and maintains it }
}
[TS 24.229, clause 5.1.3.1]:
Upon receiving a 199 (Early Dialog Terminated) provisional response to an established early dialog the UE shall release
resources specifically related to that early dialog.
7.24a.3 Profile Requirements (Informative)
[GSMA NG.114 V1.0, clause 2.3.7]:
It is also possible that the network or the terminating UE will need to release an early dialog using the 199 (Early
Dialog Terminated) response defined in IETF RFC 6228 [85]. To support this, the originating UE must include the
"199" option tag in the Supported header field in the initial INVITE request and must understand a 199 (Early Dialog
Terminated) response code and act as specified in section 5.1.3.1 of 3GPP TS 24.229 [8].
System Simulator:
UE:
- UE is configured to not use GRUU.
- UE is configured to not suppress forking via the no-fork directive.
ETSI
Preamble:

U-S Message
1 UE is made to start a voice call. - - - -
of TS 38.508-1 [21] are performed.
9-12 UE continues call setup (dialog 1) - - - -
(steps 2-5 of Annex A.4.1a)
13 SS triggers resource reservation: Step 10 of generic procedure - - - -
specified in Table 4.9.15.2.2-1 of TS 38.508-1 [21] is performed.
- EXCEPTION: In parallel to steps 14 and 15 below, step 16 - - - -
occurs.
14-15 SS triggers resource reservation: Steps 11-12 of generic - - - -
procedure specified in Table 4.9.15.2.2-1 of TS 38.508-1 [21]
are performed.
(steps 6-10 of A.4.1a)
21 SS sends 183 Session Progress with a different to-tag <-- 183 Session - -
(dialog 2) Progress
(step 3 of Annex A.4.1a)
22 Check: Does the UE send PRACK message? (dialog 2) --> PRACK 1 P
- EXCEPTION: Steps 23A-23B describe behaviour that takes - - - -
place if the UE doesn't include QOS confirmation in the PRACK
message in step 22.
23A Check: Does the UE initiate a second SDP offer in an UPDATE --> UPDATE 1 P
request? (dialog 2)
23B SS responds to UPDATE including an SDP answer. (dialog 2) <-- 200 OK - -
23 SS responds to PRACK (step 5 of Annex A.4.1a) <-- 200 OK - -
24 SS sends 180 Ringing reliably (step 8 of A.4.1a) <-- 180 Ringing - -
25 UE acknowledges reception of 180 Ringing (step 9 of A.4.1a) --> PRACK - -
27 SS sends 199 Early Dialog Terminated (dialog 1) <-- 199 Early Dialog - -
Terminated
28 SS sends 200 OK for INVITE (dialog 2) <-- 200 OK - -
29 Check: Does the UE send ACK? (dialog 2) --> ACK 2 P
30 UE maintains dialog 2 by not sending BYE - - 2 F
31-32 SS waits 5 seconds and releases the call (dialog 2) - - - -
(Annex A.8)
Table 7.24a.4.3-1: INVITE (in steps 2-8, table 7.24a.4.2-1)

Supported
option-tag 199 RFC 6228 [49]
ETSI
Table 7.24a.4.3-2: 183 Session Progress (step 21, table 7.24a.4.2-1)

To RFC 3261 [6]
addr-spec same value as received in INVITE message
tag any value different from the one used for dialog 1
Contact RFC 3261 [6]
addr-spec px_IMS_CalleeContactUri2
Message-body o=- 1111111112 1111111111 IN (addrtype) (unicast- RFC 4566 [38]
address for SS)
Table 7.24a.4.3-2A: PRACK (step 22 table 7.24a.4.2-1)
Derivation Path: TS 34.229-1 [2], Table in annex A.2.4, Conditions A1 and A7

Require (present, if Message-Body is present)
Message-body (if present) TS 24.229 [7]
Contents is copied from step 6 of annex A.4.1a with the
following exceptions:

a=des:qos optional remote sendrecv or a=des:qos
mandatory remote sendrecv
Table 7.24a.4.3-2B: 200 OK (step 23, table 7.24a.4.2-1)
To
tag Same value as used in step 9
Content-Type (present, if content-type was present in PRACK at step
22)
Content-Length
Message-body (present, if Message-Body was present in PRACK at step TS 24.229 [7]
22)
SDP body of the 200 OK response copied from the
received PRACK and modified as follows:

that sess-version is incremented;
- Attributes for preconditions: a=curr:qos remote sendrecv.
Table 7.24a.4.3-3: 199 Early Dialog Terminated (step 27, table 7.24a.4.2-1)
Table 7.24a.4.3-4: 200 OK (step 28, table 7.24a.4.2-1)
Derivation Path: Annex A.4.1a, step 11, with same to tag as used in step 21 of Test procedure sequence
ETSI
Table 7.24a.4.3-5: ACK (step 29, table 7.24a.4.2-1)
7.24b MTSI MO Voice Call / Forking / UE receives two preliminary

responses and one final response / 5GS
7.24b.1 Test Purpose (TP)
(1)
with { UE being registered to IMS and configured to use preconditions and to not use GRUU and to not
suppress forking }
ensure that {
when { UE is made to start a voice call, processes the call setup until before completion, and
then receives another early dialog indication }
then { UE processes the second early dialog until before completion }
}
(2)
with { UE having processed two early dialogs until before completion }
ensure that {
when { one of the early dialog moves to established state and the other early dialog is then
indicated to be ready for establishment as well }
then { UE sends ACK for this other dialog and terminates it right away by sending BYE }
}
7.24b.2 Conformance Requirements
[TS 24.229, clause 5.1.3.1]:
When a final answer is received for one of the early dialogs, the UE proceeds to set up the SIP session. The UE shall
not progress any remaining early dialogs to established dialogs. Therefore, upon the reception of a subsequent final 200
(OK) response for an INVITE request (e.g., due to forking), the UE shall:
1) acknowledge the response with an ACK request; and
2) send a BYE request to this dialog in order to terminate it.
7.24b.3 Profile Requirements (Informative)
[GSMA NG.114 V1.0, clause 2.2.7]:
It is also possible that the network or the terminating UE will need to release an early dialog using the 199 (Early
Dialog Terminated) response defined in IETF RFC 6228 [85]. To support this, the originating UE must include the
"199" option tag in the Supported header field in the initial INVITE request and must understand a 199 (Early Dialog
Terminated) response code and act as specified in section 5.1.3.1 of 3GPP TS 24.229 [8].
Note 1: An early dialog that is maintained is one where a SIP 18x response has been received and the early dialogue
has not been terminated (e.g. by receipt of a SIP 199 response) prior to receiving a SIP 2xx response.
Note 2: Multiple early dialogs can occur as a result of forking or for other reasons such as announcements or
services.
ETSI
7.24b.4 Test description
7.24b.4.1 Pre-test conditions
System Simulator:
UE:
- UE is configured to not use GRUU.
- UE is configured to not suppress forking via the no-fork directive.
Preamble:
ETSI
7.24b.4.2 Test procedure sequence
Table 7.24b.4.2-1: Main Behaviour

U-S Message
1 UE is made to start a voice call - - - -
of TS 38.508-1 [21] are performed
(steps 2-5 of Annex A.4.1a)
13 SS triggers resource reservation: Step 10 of generic procedure - - - -
specified in Table 4.9.15.2.2-1 of TS 38.508-1 [21] is performed.
- EXCEPTION: In parallel to steps 14 and 15 below, step 16 - - - -
occurs.
14-15 SS triggers resource reservation: Steps 11-12 of generic - - - -
procedure specified in Table 4.9.15.2.2-1 of TS 38.508-1 [21]
are performed.
(steps 6-10 of A.4.1a)
21 SS sends 183 Session Progress with a different to-tag <-- 183 Session - -
(dialog 2) Progress
22 UE sends PRACK, including an SDP answer as specified in --> PRACK - -
A.4.1 step 6 (dialog 2)
23 SS responds to PRACK (dialog 2) <-- 200 OK - -
24 SS sends 180 Ringing reliably (dialog 2) <-- 180 Ringing - -
(step 8 of A.4.1a)
25 Check: Does the UE acknowledge reception of 180 Ringing by --> PRACK 1 P
sending PRACK message? (dialog 2)
(step 9 of A.4.1a)
26 SS responds to PRACK (dialog 2) <-- 200 OK - -
(step 10 of A.4.1a)
- EXCEPTION: Steps 26A-26B describe behaviour that takes - - - -
place if the UE do'sn't include QOS confirmation in the PRACK
message in step 25.
26A Check: Does the UE initiate a second SDP offer in an UPDATE --> UPDATE 1 P
request? (dialog 2)
26B SS responds to UPDATE including an SDP answer. (dialog 2) <-- 200 OK - -
27 SS sends 200 OK for dialog 1 <-- 200 OK - -
28 UE sends ACK for dialog 1 --> ACK - -
29 SS sends 200 OK for dialog 2 <-- 200 OK - -
- EXCEPTION: Steps 30 and 31 may occur in any order. - - - -
Note: the UE will issue ACK before BYE but, due to network
delays, these messages might arrive in reverse order at the SS
30 Check: Does the UE send an ACK message for dialog 2? --> ACK 2 P
31 Check: Does the UE send a BYE message for dialog 2? --> BYE 2 P
33-34 SS releases the established call (dialog 1) - - - -
(Annex A.8)
ETSI
7.24b.4.3 Specific message contents
Table 7.24b.4.3-1: INVITE (in steps 2-8, table 7.24b.4.2-1)

Supported
option-tag 199 RFC 6228 [49]
Table 7.24b.4.3-2: 183 Session Progress (step 21, table 7.24b.4.2-1)

To RFC 3261 [6]
addr-spec same value as received in INVITE message
tag any value different from the one used for dialog 1
address for SS)
Table 7.24b.4.3-2A: PRACK (step 25 table 7.24b.4.2-1)

option-tag Precondition

Table 7.24b.4.3-2B: 200 OK (step 26, table 7.24b.4.2-1)
To
25)
Content-Length
25)

ETSI
Table 7.24b.4.3-3: 200 OK (step 29, table 7.24b.4.2-1)
Table 7.24b.4.3-4: ACK (step 30, table 7.24b.4.2-1)
7.25 MTSI MT Voice Call without SDP offer in INVITE / 5GS

(1)
ensure that {
when { UE receives INVITE for voice call without SDP offer }
then { UE responds with 183 Session Progress including SDP offer and completes call initiation }
}
[TS 24.229, Rel-15, clause 6.1.3]
7.25.2A Profile Requirements (Informative)
[GSMA NG.114 V1.0]
The UE must be able to accept a SIP INVITE request without a Session Description Protocol (SDP) offer, and the UE
must then include an SDP offer in the first non-failure reliable response to a SIP INVITE request without SDP offer.
The SDP offer must contain all codecs (for audio only or for both audio and video) that the UE is currently able and
willing to use.
Note 1: Other media than audio can be included in the SDP offer in the first non-failure reliable response.
[GSMA NG.114 V1.0 cl 3.2.2.3]
The UE that sends the SDP offer for voice media must include in this SDP offer at least one EVS payload type with one
of the following EVS configurations:
3. EVS Configuration B0: br=13.2; bw=swb.
System Simulator:
ETSI
UE:
Preamble:
- UE is in state 1N-A (TS 38.508-1[21]) and registered to IMS.

U-S Message
Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
2 SS sends INVITE. <-- INVITE - -
3 UE may send 100 Trying. --> Optional step: 100 Trying - -
Progress reliably and containing an SDP offer?
5 SS sends PRACK containing an SDP answer. <-- PRACK - -
6 UE sends 200 OK response for PRACK. --> 200 OK - -
6A- SS triggers resource reservation: Steps 10-12 - - - -
6C of generic procedure specified in Table
4.9.16.2.2-1 of TS 38.508-1 [21] are performed.
7 SS sends UPDATE containing an SDP offer. <-- UPDATE - -
8 UE sends 200 OK response for UPDATE, --> 200 OK - -
containing an SDP answer.
9 UE sends 180 Ringing response. --> 180 Ringing - -
10 If UE sent 180 Ringing response reliably, the <-- Conditional step: PRACK - -
SS sends PRACK.
11 If UE sent 180 Ringing reliably, UE responds to --> Conditional step: 200 OK - -
PRACK by sending 200 OK.
12 Make the UE accept the voice call - - - -
13 UE sends 200 OK for INVITE. --> 200 OK 1 P
14 SS sends ACK. <-- ACK - -
Derivation Path: TS 34.229-1 [2], Table in subclause A.2.9, Conditions A1, A3, and A4
Supported
Content-Type not present
Message-body not present

ETSI
Require
shown in Annex A.4.1a, Step 1, apart from video media:
the UE may include addition video media description.
Such description shall be accepted but not checked.
v=0
s=(session name)
Time description:
Media description:

a=rtpmap: (payload type) EVS/16000 [Note 3, 9]
field) [Note 4, 5]
a=fmtp: (format)
a=fmtp: (format)
a=ptime:20
a=maxptime:240

a=crypto:1
AES_CM_128_HMAC_SHA1_80inline:WVNfX19zZW1jdG
wgKCkgewkyMjA7fQp9CnVubGVz|2^20|

a=des:qos optional remote sendrecv

Note 2: The RR value shall be greater than 0. The RS
value can be any value.
ETSI
Note 5: The parameters dtx, dtx-recv and evs-mode-

switch shall not be present.
Note 6: The parameters mode-set, mode-change-period,
mode-change-neighbor, crc, robust-sorting and
interleaving shall not be included.
Note 7: Attributes for ECN Capability may be present if the
UE supports Explicit Congestion Notification.
UE.
Note 9: The ordering of payload types shall be as listed.
Table 7.25.3.3-4: PRACK with an SDP answer (step 5, table 7.25.3.2-1)

Require
shown in Annex A.4.1a, Step 3, apart from the video media
description: if the UE included such description, SS copies
the video media description and changes the port number
to zero.
v=0
address for SS)
s=-
b=AS:65
Time description:
t=0 0
Media description:
b=AS:65

a=rtpmap: (payload type) EVS/16000/1 [Note 1]
a=fmtp: (format) br=5.9-24.4; bw=nb-swb; max-red=220
a=ptime:20
a=maxptime:240

a=crypto:1
AES_CM_128_HMAC_SHA1_80inline:PS1uQCVeeCFCan
VmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 [Note 5]

ETSI
copied from step 4.
RFC 3264 clause 6).
UE.
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.1, Conditions A5, A8, A11, and A22
Table 7.25.3.3-6: UPDATE with an SDP offer (step 7, table 7.25.3.2-1)

Require
Message-body NOTE: if the SS included a video media description with TS 24.229 [7]
port number zero in step 5, it includes the same video
media description again.
v=0
address for SS)
s=-
b=AS:65
Time description:
t=0 0
Media description:
m=audio (transport port) RTP/AVP 96
b=AS:65
b=RS:0
b=RR:2000

a=rtpmap:96 EVS/16000/1
a=fmtp:96 br=(att-field); bw=(att-field); max-red=220 [Note
2]
a=ptime:20
a=maxptime:240

a=curr:qos remote none or curr:qos remote sendrecv
[Note 1]
Note 1: Use the value (none/sendrecv) received from 183

Session Progress and attribute a=curr:qos local.
Note 2: The br and bw values are taken from step 3.
ETSI
Table 7.25.3.3-7: 200 OK with an SDP answer (step 8, table 7.25.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in annex A.3.1, conditions A2, A11, and A22
Require
Content-Type
application/sdp
Message-body NOTE: if the UE included a video media description with TS 24.229 [7]
port number zero in step 4, it includes an m-line for video,
with port set to zero, and possibly a number of attribute
lines, the latter ones not being checked
v=0
o=(user-name) (sess-id) (sess-version) IN (addrtype)
(unicast-address for UE) [Note 4]
s=(session name)
Time description:
t=0 0
Media description:

a=fmtp:(format) [Note 2, 3]


Note 2: The value for fmt, payload type and format is not
checked
Note 3: Parameters for the codec are not checked
Note 4: "o=" line identical to previous SDP sent by UE
except that sess-version is incremented by one.
Table 7.25.3.3-8: 180 Ringing (step 9, table 7.25.3.2-1)
ETSI
ETSI
7.26 Mobile Originating CAT / Forking Model / MO Voice Call /

5GS
(1)
with { UE being registered to IMS and configured to use preconditions and having initiated an MO
voice call with preconditions up to the last step before 180 Ringing }
ensure that {
when { UE receives 183 Session Progress on a forked dialog indicating Customized Alerting Tones }
then { UE moves forked dialog forward until up to the last step before 180 Ringing }
}
(2)
with { UE having moved both dialogs forward up to the last step before 180 Ringing }
ensure that {
when { UE receives 200 OK for INVITE for the first dialog }
then { UE acks reception of 200 OK for INVITE }
}
[TS 24.182, clause 4.5.5.1.1]:
The UE shall follow the procedures specified in 3GPP TS 24.229 [4] for session initiation and termination.
[TS 24.628, clause 4.7.2.1]:
Procedures according to 3GPP TS 24.229 [1] shall apply.
Certain services require the usage of the Alert-Info header field, Call-Info header field and Error-Info header field
according to procedures specified by IETF RFC 3261 [4].
If the UE detects that in-band information is received from the network as early media, the in-band information received
from the network shall override locally generated communication progress information.
NOTE 1: In-band information received from the network overrides any locally generated communication progress
information also when the most recently received P-Early-Media header fields of all early dialogs contain
"inactive" or "recvonly".
NOTE 2: When multiple early dialogs exist with authorization as "sendrecv" or "sendonly", the mechanism used by
the UE to associate the received early media with the correct early dialog is unspecified in this version of
this specification.
The UE shall not generate the locally generated communication progress information if an early dialog exists where the
last received P-Early-Media header field as described in IETF RFC 5009 [12] contains "sendrecv" or "sendonly".
If an early dialog exists where a SIP 18x response to the SIP INVITE request other than 183 (Session Progress)
response was received, no early dialog exists where the last received P-Early-Media header field as described in
IETF RFC 5009 [12] contained "sendrecv" or "sendonly" and in-band information is not received from the network,
then the UE is expected to render the locally generated communication progress information.
NOTE 3: According to 3GPP TS 22.173 [23] the UE for an MMTel session generates the communication progress
information specified in clause F.2 of 3GPP TS 22.001 [24], with parameters applicable for the home
network of the UE.
If the UE supports the P-Early-Media header field as defined in IETF RFC 5009 [12], and at least one P-Early-Media
header field has been received on at least one early dialog, then the UE shall send any available user generated media,
e.g. speech or DTMF, on media stream(s) associated with the early dialog for which the most recent P-Early-Media
header field, as described in IETF RFC 5009 [12], contained a "sendrecv" header field value. If there is more than one
such early dialog, the UE shall use the early dialog where the P-Early-Media header field was most recently received.
ETSI
If the UE receives a re-INVITE request containing no SDP offer, the UE shall send a 200 (OK) response containing an
SDP offer according to 3GPP TS 24.229 [1] indicating the directionality used by UE as
- "sendonly" if the re-INVITE request is received on a dialog where the associated communication session has
been put on hold by the user or has been put on hold by both users at both ends; and
- "sendrecv" otherwise.
System Simulator:
UE:
Preamble:
ETSI

U-S Message
1 UE is made to initiate a voice call. - - - -
1A-1F Steps 2-7 of generic procedure specified in - - - -
Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
place
2-6 Steps 1-5 of generic procedures of MO voice - Setup dialog 1 - -
call with preconditions defined in A.4.1a.
6A Step 10 of generic procedure specified in - - - -
Table 4.9.15.2.2-1 of TS 38.508-1 [21] is
performed.
below, step 7occurs.
6B-6C Steps 11-12 of generic procedure specified in - - - -
Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
7-8 Steps 6-7 of generic procedures of MO voice - Setup dialog 1 - -
call with preconditions defined in A.4.1a.
9 SS sends an SDP answer. (dialog 2) <-- 183 Progress - -
(Step 3 of A.4.1a)
10 Check: Does the UE acknowledge reception --> PRACK 1 P
of 183 Session Progress? (dialog 2)
(Step 4 of A.4.1a)
11 SS responds to PRACK. (dialog 2) <-- 200 OK - -
(Step 5 of A.4.1a)
- EXCEPTION: Steps 11A-11B describe - - - -
behaviour that takes place if the UE doesn't
include QOS confirmation in the PRACK
message in step 10.
11A Check: Does the UE initiate a second SDP --> UPDATE 1 P
offer in an UPDATE request? (dialog 2)
11B SS responds to UPDATE including an SDP <-- 200 OK - -
answer. (dialog 2)
12-13 Void - - -
14 The SS sends 200 OK for INVITE sent in step <-- 200 OK - -
1 above
15 Check: Does the UE send the ACK to the 200 --> ACK 2 P
OK for the INVITE in step 1?
16 The UE is made to release the call - - - -
17 The UE releases the call with BYE --> BYE - -
18 The SS sends 200 OK for BYE <-- 200 OK - -

U-S Message
ETSI
Derivation Path: TS 34.229-1 [2], Table in annex A.2.3, Condition A1

To
tag any value different from what is used in steps 1-5
Contact
addr-spec <sip:cat-as.home1.net;+g.3gpp.icsi ref="urn%3Aurn-
7%3gpp-service.ims.icsi.mmtel">
P-Early-Media
em-param sendonly
Require TS 24.229 [7]
Message-body Session description: TS 24.229 [7]
v=0 RFC 4566 [38]
address for SS for early-media)
s=-
c=IN (addrtype) (connection-address for SS for early-
media)
b=AS:37

Other attributes:
a=content:g.3gpp.cat


ETSI
To
10)
Content-Length
10)
- IP address on "c=" lines and transport port on "m="

lines changed to indicate to which IP address and port the
UE should start sending the media (same as used in step
9 above);
that sess-version is incremented.
ETSI
7.27 Session Timer / MO Voice Call / UE is able to refresh the

session / 5GS
(1)
with { UE being registered to IMS and being configured to use Session Timer and preconditions }
ensure that {
then { UE sends INVITE for voice call }
}
(2)
with { UE having included Session-Expires in INVITE }
ensure that {
when { UE receives 100 Trying followed by 422 Session Interval Too Small with Min-SE value of 1860
}
then { UE sends ACK and new INVITE with Min-SE value and Session-Expires value being 1860 }
}
(3)
with { UE having send 2nd INVITE }
ensure that {
when { UE receives 100 Trying followed by 422 Session Interval Too Small with Min-SE value of 1920
}
then { UE sends ACK and new INVITE with Min-SE value and Session-Expires value being 1920 }
}
(4)
with { UE having sent 3rd INVITE }
ensure that {
when { UE receiving 100 Trying followed by 183 Session Progress }
then { UE concludes voice call set up procedure up until sending ACK, with Session-Expires
having value 1920 and refresher being set to uac }
}
(5)
with { UE having been chosen as refresher for established voice call }
ensure that {
when { voice call has been going on for 960 seconds }
then { UE sends UPDATE to refresh the session }
}
(6)
with { UE having been chosen as refresher for established voice call }
ensure that {
when { voice call has been going on for another 960 seconds }
}
[TS 24.229 clause 5.1.2A.1.1]
A UE supporting RFC 4028 [58], when it receives a 422 (Session Interval Too Small) to an INVITE request where the
response contains a Min-SE header field, shall retry the request in accordance with RFC 4028 [58] subclause 7.4.
[TS 24.229 clause 5.2.7.2]
ETSI
When the P-CSCF receives from the UE an INVITE request, the P-CSCF may require the periodic refreshment of the
session to avoid hung states in the P-CSCF. If the P-CSCF requires the session to be refreshed, then the P-CSCF shall
apply the procedures described in RFC 4028 [58] clause 8.
NOTE 1: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality
cannot automatically be granted, i.e. at least one of the involved UEs needs to support it.
[TS 24.229 clause 5.2.7.3]
When the P-CSCF receives an INVITE request destined for the UE the P-CSCF may require the periodic refreshment of
the session to avoid hung states in the P-CSCF. If the P-CSCF requires the session to be refreshed, then the P-CSCF
shall apply the procedures described in RFC 4028 [58] clause 8.
cannot automatically be granted, i.e. at least one of the involved UEs needs to support it in order to make
it work.
[TS 24.229 clause 5.4.5.3]
If the S-CSCF requested the session to be refreshed periodically, and the S-CSCF got the indication that the session will
be refreshed, when the session timer expires, the S-CSCF shall delete all the stored information related to the dialog.
System Simulator:
UE:
- UE is configured to use Session Timer and preconditions.
Preamble:
ETSI

U-S Message
Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
place
8 UE sends INVITE with either the Session- --> INVITE 1 P
Expires value set to 1800 or no Session-Expires
header.
- EXCEPTION: Steps 9a0 to 9a7 describe - -
behaviour that depends on UE capability: the
"lower case letter" identifies a step sequence
that takes place if the UE included Session-
Expires in step 8
9a0 SS sends a 100 Trying response. <-- 100 Trying
9a1 SS sends 422 Session Interval Too Small <-- 422 Session Interval Too Small
response with Min-SE value of 1860.
9a2 UE sends ACK. --> ACK 2 P
9a3 UE sends INVITE with Min-SE value and --> INVITE 2 P
Session-Expires value being 1860.
9a4 SS sends a 100 Trying response. <-- 100 Trying
9a5 SS sends 422 Session Interval Too Small <-- 422 Session Interval Too Small
response with Min-SE value of 1920.
9a6 UE sends ACK. --> ACK 3 P
9a7 UE sends INVITE with Min-SE value and --> INVITE 3 P
Session-Expires value being 1920.
10- Steps 2-5 of Annex A.4.1a happen. - -
13
13C Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
14- Steps 6-10 of Annex A.4.1a happen. - - - -
18
19 SS sends 200 OK for INVITE with negotiated <-- 200 OK 4 P
Session-Expires value set to 1920 and
refresher value set to uac.
20 UE sends ACK. --> ACK 4 P
21 960 seconds after step 20, UE sends an --> UPDATE 5 P
UPDATE request to refresh the session.
22 SS sends 200 OK for UPDATE. <-- 200 OK
24 SS sends 200 OK for UPDATE. <-- 200 OK
25- SS releases the call. - -
26 (Steps 1-2 of Annex A.8)
ETSI

U-S Message
Derivation Path: Annex A.4.1a, Step 1, with A26 as additional condition.

Session-Expires (if present) RFC 4028 [37]
delta-seconds 1800
refresher uac (if present)
Table 7.27.3.3-2: 422 Session Interval Too Small (step 9a1, table 7.27.3.2-1)

Min-SE RFC 4028 [37]
delta-seconds 1860
Table 7.27.3.3-3: INVITE (step 9a3, table 7.27.3.2-1)

Session-Expires RFC 4028 [37]
delta-seconds 1860
delta-seconds 1860
Table 7.27.3.3-4: 422 Session Interval Too Small (step 9a5, table 7.27.3.2-1)

delta-seconds 1920
Table 7.27.3.3-5: INVITE (step 9a7, table 7.27.3.2-1)

delta-seconds 1920
delta-seconds 1920
Derivation Path: TS 34.229-1 [2], Annex A.2.3, Conditions A1

Allow INVITE, UPDATE, PRACK, ACK, OPTIONS, CANCEL, RFC 4028 [37]
BYE
ETSI

BYE
Require timer RFC 4028 [37]
Supported timer RFC 4028 [37]
delta-seconds 1920
refresher uac
delta-seconds 1920
Table 7.27.3.3-8: UPDATE (steps 21 and 23, table 7.27.3.2-1)

delta-seconds 1920
refresher uac
delta-seconds 1920
Content-Type any value if present RFC 4028 [37]
Table 7.27.3.3-9: 200 OK (steps 22 and 24, table 7.27.3.2-1)

delta-seconds 1920
refresher uac
delta-seconds 1920
ETSI
7.28 Session Timer / MO Voice Call / Remote end is refresher /

5GS
(1)
ensure that {
then { UE sends INVITE for voice call without refresher parameter }
}
(2)
with { UE having sent INVITE }
ensure that {
when { UE continues setup of voice call and finally receives 200 OK for INVITE setting refresher
to uas }
}
(3)
with { UE having completed call setup }
ensure that {
when { UE receives refresh request via an UPDATE request }
then { UE sends 200 OK for UPDATE }
}
(4)
with { UE having sent 200 OK for a refresh request }
ensure that {
when { Session expires }
then { UE releases the call }
}
[TS 24.229 clause 5.1.2A.1.1]
[TS 24.229 clause 5.2.7.2]
[TS 24.229 clause 5.2.7.3]
it work.
ETSI
[TS 24.229 clause 5.4.5.3]
System Simulator:
UE:
Preamble:

U-S Message
Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
place
8 UE sends INVITE with either the Session- --> INVITE 1 P
Expires value set to 1800 or no Session-Expires
header.
9-12 Steps 2-5 of Annex A.4.1a happen. - -
12C Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
17
18 SS sends 200 OK for INVITE with Session- <-- 200 OK
Expires value set to 1800 and refresher value
set to uas.
20 900 seconds after step 18, SS sends an <-- UPDATE
21 UE sends 200 OK for UPDATE. --> 200 OK 3 P
UE sends BYE to release the call due to --> BYE 4 P
session expiry 1800 seconds after step 21.
23 SS sends 200 OK for BYE. <-- 200 OK
ETSI

U-S Message
Derivation Path: Annex A.4.1a, step 1, with A26 as additional condition.

delta-seconds 1800
refresher not present

delta-seconds 1800
refresher uas

delta-seconds 1800
refresher uac
Content-Type not present RFC 4028 [37]

delta-seconds 1800
refresher uac
ETSI
7.29 Session Timer / MO Voice Call / Remote end does not

support Session Timer / 5GS
(1)
ensure that {
when { UE is being made to initiate the voice call }
}
(2)
with { UE having sent INVITE and continuing with the call setup }
ensure that {
when { UE receives 200 OK for INVITE without timer tag and Session-Expires }
}
(3)
ensure that {
when { 900 seconds have passed }
}
(4)
with { UE having sent received 200 OK for UPDATE }
ensure that {
when { Another 900 seconds have passed }
}
[TS 24.229 clause 5.1.2A.1.1]
[TS 24.229 clause 5.2.7.2]
[TS 24.229 clause 5.2.7.3]
it work.
[TS 24.229 clause 5.4.5.3]
ETSI
System Simulator:
UE:
Preamble:
ETSI

U-S Message
Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
place
8 UE sends INVITE indicating support for Session --> INVITE 1 P
Timer, with either the Session-Expires value set
to 1800 or no Session-Expires header.
12C Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
17
18 SS sends 200 OK for INVITE, without timer tag <-- 200 OK
in Supported and Require headers and without
Session-Expires header.
21 SS sends 200 OK for UPDATE, without timer <-- 200 OK
tag in Supported and Require headers and
without Session-Expires header.
23 SS sends 200 OK for UPDATE, without timer <-- 200 OK
tag in Supported and Require headers and
without Session-Expires header.
24- SS releases the call. - -

U-S Message
Derivation Path: Annex A.4.1a with A26 as additional condition

delta-seconds 1800
ETSI

BYE

BYE
Table 7.29.3.3-4: UPDATE (steps 20 and 22, table 7.29.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in Annex A.2.5, Conditions A1 and A6

delta-seconds 1800
refresher uac
ETSI
7.30 Session Timer / MO Voice Call / Remote end supports but

does not use Session Timer / 5GS
(1)
ensure that {
}
(2)
with { UE having sent INVITE for voice call and continuing the call setup }
ensure that {
when { UE receives 200 OK for INVITE with timer tag and without Session-Expires }
}
(3)
ensure that {
when { 1860 seconds passed without the UE refreshing the session }
then { UE receives BYE and sends 200 OK for BYE }
}
[TS 24.229 clause 5.1.2A.1.1]
[TS 24.229 clause 5.2.7.2]
[TS 24.229 clause 5.2.7.3]
it work.
[TS 24.229 clause 5.4.5.3]
ETSI
System Simulator:
UE:
Preamble:

U-S Message
Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
place
8 UE sends INVITE indicating support for Session --> INVITE 1 P
Timer, with either the Session-Expires value set
to 1800 or no Session-Expires header.
12C Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
13- Steps 6-10 of Annex A.4.1a happen. - -
17
18 SS sends 200 OK for INVITE, with timer tag in <-- 200 OK
Supported headers but without Session-Expires
header.
20 SS sends BYE to release the call 1860 seconds <-- BYE 3 P
after step 19.
21 UE sends 200 OK for BYE. --> 200 OK 3 P

U-S Message
ETSI

delta-seconds 1800

ETSI
7.31 Session Timer / MT Voice Call / Remote end supports but

does not send Session-Expires / 5GS
(1)
ensure that {
then { UE continues setup of voice call and finally sends 200 OK for INVITE with Session-Expires
being 1800 and setting refresher to uac }
}
(2)
with { Call having been set up }
ensure that {
when { 900 seconds have passed and UE receives UPDATE to refresh the session }
}
(3)
with { UE having sent 200 OK for UPDATE }
ensure that {
then { UE sends BYE }
}
[TS 24.229 clause 5.1.2A.1.1]
[TS 24.229 clause 5.2.7.2]
[TS 24.229 clause 5.2.7.3]
it work.
[TS 24.229 clause 5.4.5.3]
ETSI
System Simulator:
UE:
Preamble:

U-S Message
Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
9 SS sends INVITE. <-- INVITE - -
13
13C Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
18
19 UE sends 200 OK for INVITE with Session- --> 200 OK 1 P
set to uac.
20 Step 12 of Annex A.5.1a happens. <-- ACK - -
21 900 seconds after step 19, SS sends an <-- UPDATE - -
23 UE sends BYE to release the call due to --> BYE 3 P
session expiry 1800 seconds after step 22.
24 SS sends 200 OK for BYE. <-- 200 OK - -
ETSI

delta-seconds 1800
refresher uac

delta-seconds 1800
refresher uac

delta-seconds 1800
refresher uac
ETSI
7.32 Session Timer / MT Voice Call / Remote end sends

Session-Expires but does not choose refresher / 5GS
(1)
ensure that {
when { UE receives INVITE for voice call containing timer tag and Session-Expires value 1800 }
being 1800 and setting refresher to uac }
}
(2)
ensure that {
when { 900 seconds have passed and UE receives UPDATE to refresh the session }
}
[TS 24.229 clause 5.1.2A.1.1]
[TS 24.229 clause 5.2.7.2]
[TS 24.229 clause 5.2.7.3]
it work.
[TS 24.229 clause 5.4.5.3]
7.32.2A Profile Requirements (Informative)
The UE must support and use IETF RFC 4028 [53] as follows:
…
5. if a received SIP INVITE request indicates support of the "timer" option tag, and contains the Session-Expires header
field without "refresher" parameter, the UE must include the "refresher" parameter with the value "uac" in the Session-
Expires header field of the SIP 2xx response to the SIP INVITE request, and must set the delta-seconds portion of the
ETSI
Session-Expires header field of the SIP 2xx response to the SIP INVITE request to the value indicated in the delta-
seconds portion of the Session-Expires header field of the SIP INVITE request.
System Simulator:
UE:
Preamble:

U-S Message
Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
9 SS sends INVITE with timer tag set in <-- INVITE - -
Supported header and Session-Expires value
set to 1800.
13
13C Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
18
set to uac.
21 900 seconds after step 19, SS sends an <-- UPDATE - -
ETSI

delta-seconds 1800

delta-seconds 1800
refresher uac

Supported Timer RFC 4028 [37]
delta-seconds 1800
refresher Uac

delta-seconds 1800
refresher uac
ETSI
7.33 Session Timer / MT Voice Call / Remote end chooses UE

as refresher / 5GS
(1)
with { UE being registered to IMS and being configured to use Session Timer and being configured to
not use preconditions }
ensure that {
when { UE receives INVITE for voice call with Session-Expires value 1800 and refresher set uas and
remote UE not supporting UPDATE }
being 1800 and setting refresher to uas }
}
(2)
with { Voice call having been set up }
ensure that {
then { UE sends re-INVITE to refresh the session }
}
(3)
with { UE having refreshed the session }
ensure that {
when { Another 900 seconds have passed }
then { UE sends another re-INVITE to refresh the session }
}
[TS 24.229 clause 5.1.2A.1.1]
[TS 24.229 clause 5.2.7.2]
[TS 24.229 clause 5.2.7.3]
it work.
[TS 24.229 clause 5.4.5.3]
ETSI
System Simulator:
UE:
- UE is configured to use Session Timer
Preamble:

U-S Message
Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
9 SS sends INVITE with Session-Expires value <-- INVITE - -
set to 1800 and refresher set to uas.
13
13C Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
14- Steps 6-8A of Annex A.5.2 happen. - - - -
17
18 Void - - - -
19 UE send 200 OK for INVITE with Session- --> 200 OK 1 P
set to uas.
21 900 seconds after step 20, UE sends an INVITE --> INVITE 2 P
request to refresh the session.
22 SS sends 200 OK for INVITE. <-- 200 OK - -
23 UE sends ACK. --> ACK - -
24 900 seconds after step 23, UE sends an INVITE --> INVITE 3 P
request to refresh the session.
25 SS sends 200 OK for INVITE. <-- 200 OK - -
ETSI
Derivation Path: Step 1 of Annex A.5.2

Allow INVITE, ACK, OPTIONS, CANCEL, BYE RFC 3261 [6]
delta-seconds 1800
refresher uas

delta-seconds 1800
refresher uas
Table 7.33.3.3-3: INVITE (steps 21 and 24, table 7.33.3.2-1)
delta-seconds 1800
refresher uac
Content-Type RFC 3261 [6]
Content-Length RFC 3261 [6]
Message-body Same SDP message as the last SDP message sent by RFC 4566 [38]
the UE in the 183 Session Progress at step 11; the
session version in the origin shall not be incremented.
Table 7.33.3.3-4: 200 OK (steps 22 and 25, table 7.33.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.3.1, Conditions A2, A11, A20 and A22
delta-seconds 1800
refresher uac
Message-body Same SDP message as the last SDP message sent by
the SS in the INVITE at step 9; the session version in the
origin shall not be incremented
ETSI
7.34 Session Timer / MT Voice Call / Remote end does not

support Session Timer / 5GS
(1)
ensure that {
when { UE receives INVITE for voice call without support for Session Timer }
being 1800 and setting refresher to uas }
}
(2)
ensure that {
}
[TS 24.229 clause 5.1.2A.1.1]
[TS 24.229 clause 5.2.7.2]
[TS 24.229 clause 5.2.7.3]
it work.
[TS 24.229 clause 5.4.5.3]
System Simulator:
ETSI
UE:
Preamble:

U-S Message
Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
9 SS sends INVITE without support for Session- <-- INVITE - -
Timer.
13
13C Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
14- Steps 6-10A of Annex A.5.1a happen. - - - -
18A
set to uas.
22 SS sends 200 OK for UPDATE. <-- 200 OK - -

BYE

delta-seconds 1800
refresher uas
ETSI

delta-seconds 1800
refresher uac
ETSI
8 Supplementary Services
8.1 Originating Identification Presentation / Configuration / 5GS

(1)
ensure that {
when { UE is made to activate OIP }
then { UE authenticates itself using Digest or GBA }
}
(2)
with { UE having started authentication using Digest or GBA }
ensure that {
when { UE receives 200 OK concluding the authentication }
then { UE sends HTTP request to activate OIP }
}
(3)
with { UE having concluded activation of OIP }
ensure that {
when { UE is made to de-activate OIP }
then { UE sends HTTP request to de-activate OIP }
}
Generic requirements for Originating Identification Presentation can be found from TS 34.229-1 Annexes F.1 and F.2.
[TS 24.607, clause 4.2.1]:
The OIP service provides the terminating user with the possibility of receiving trusted (i.e. network provided) identity
information in order to identify the originating user.
In addition to the trusted identity information, the identity information from the originating user can include identity
information generated by the originating user and in general transparently transported by the network. In the particular
case where the "no screening" special arrangement does not apply, the originating network shall verify the content of
this user generated identity information. The terminating network cannot be responsible for the content of this user
generated identity information.
[TS 24.607 clause 4.10.1]:
The OIP service can be activated/deactivated using the active attribute of the <originating-identity-presentation> service
element.
[TS 24.109 clause 4.2]:
The UE shall initiate the bootstrapping procedure when:
a) the UE wants to interact with a NAF and bootstrapping is required;
b) a NAF has requested bootstrapping required indication as described in subclause 5.2.4 or bootstrapping
renegotiation indication as described in subclause 5.2.5; or
c) the lifetime of the key has expired in the UE if one or more applications are using that key.
ETSI
A UE and the BSF shall establish bootstrapped security association between them by running bootstrapping procedure.
Bootstrapping security association consists of a bootstrapping transaction identifier (B-TID) and key material Ks.
Bootstrapping session on the BSF also includes security related information about subscriber (e.g. user's private
identity). Bootstrapping session is valid for a certain time period, and shall be deleted in the BSF when the session
becomes invalid.
Bootstrapping procedure shall be based on HTTP Digest AKA as described in 3GPP TS 33.220 [1] and in RFC 3310 [6]
with the modifications described below.
The BSF address is derived from the IMPI or IMSI according to 3GPP TS 23.003 [7].
A UE shall indicate to the BSF that it supports the use of TMPI as defined in 3GPP 33.220 [1] by including a "product"
token in the "User-Agent" header field (cf. RFC 2616 [14]) that is set to a static string "3gpp-gba-tmpi" in HTTP
requests sent to the BSF.
A BSF shall indicate to the UE that it supports the use of TMPI as defined in 3GPP 33.220 [1] by including a "product"
token in the "Server" header field (cf. RFC 2616 [14]) that is set to a static string "3gpp-gba-tmpi" in HTTP responses
sent to the UE.
In the bootstrapping procedure, Authorization, WWW-Authenticate, and Authentication-Info HTTP headers shall be
used as described in RFC 3310 [6] with following exceptions:
a) the "realm" parameter shall contain the network name where the username is authenticated;
b) the quality of protection ("qop") parameter shall be "auth-int"; and
c) the "username" parameter shall contain user's private identity (IMPI).
NOTE: If the UE does not have an ISIM application with an IMPI, the IMPI will be constructed from IMSI,
according to 3GPP TS 23.003 [7].
In addition to RFC 3310 [6], the following apply:
a) In the initial request from the UE to the BSF, the UE shall include Authorization header with following
parameters:
- the username directive, set to
1) the value of the TMPI if one has been associated with the private user identity as described in
3GPP 33.220 [1]; or
2) the value of the private user identity;
- the realm directive, set to the BSF address derived from the IMPI or IMSI according to 3GPP TS 23.003 [7];
- the uri directive, set to either absoluteURL "http://<BSF address>/" or abs_path "/", and which one is used is
specified in RFC 2617 [9];
- the nonce directive, set to an empty value; and
- the response directive, set to an empty value;
b) In the challenge response from the BSF to the UE, the BSF shall include parameters to WWW-Authenticate
header as specified in RFC 3310 [6] with following clarifications:
c) In the message from the BSF to the UE, the BSF shall include bootstrapping transaction identifier (B-TID) and
the key lifetime to an XML document in the HTTP response payload. The BSF may also include additional
server specific data to the XML document. The XML schema definition of this XML document is given in
Annex C.
d) When responding to a challenge from the BSF, the UE shall include an Authorization header containing a realm
directive set to the value as received in the realm directive in the WWW-Authenticate header.
e) Authentication-Info header shall be included into the subsequent HTTP response after the BSF concluded that
the UE has been authenticated. Authentication-Info header shall include the "rspauth" parameter.
ETSI
After successful bootstrapping procedure the UE and the BSF shall contain the key material (Ks) and the B-TID. The
key material shall be derived from AKA parameters as specified in 3GPP TS 33.220 [1]. In addition, BSF shall also
contain a set of security specific attributes related to the UE.
An example flow of successful bootstrapping procedure can be found in clause A.3.
System Simulator:
- SS is configured with shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI)
configured on the UICC card equipped into the UE.
- At the SS, a HTTP Server is established at port 80 to simulate the XCAP server
- 1 NR Cell
UE:
- UE is configured with the name of the XCAP root directory on the XCAP server and the user's directory name.
- UE has activated an IPCAN bearer with SS.
Preamble:
- The steps 0a and 0b of Annex A.21 have been executed
- During these procedures the UE may request a DNS server address via NAS signalling and as parallel behaviour
the UE may resolve the IP address of the XCAP server via DNS.

U-S Message
1 The UE is triggered for activation of - - - -
supplementary service OIP
2-5b Check: Does the UE perform steps 2-5b of the - - 1 -
generic test procedure for activation of
Supplementary Services according to annex
A.21
6 Check: Does the Simservs document stored in - - 2 P
the SS contain the information supplied by UE
as according to table 8.1.3.3-2?
-<originating-identity-presentation> element
with "active" attribute being set "true"
7 Make the UE attempt deactivation of OIP - - - -
A.21?
ETSI
Table 8.1.3.3-1: Simservs document (step 4)
Derivation Path: TS 24.607 clause 4.10.2

Content Comment
<simservs>
<originating-identity-presentation active="false">
</simservs>

Content Comment
<simservs>
<originating-identity-presentation active="true"> The “active” attribute may not be
present but if present is is set to “true”.
</simservs>

Content Comment
<simservs>
<originating-identity-presentation active="false">
</simservs>
ETSI
8.2 Originating Identification Restriction / Configuration / 5GS

(1)
ensure that {
when { UE is made to activate OIR }
then { UE authenticates itself using GBA or Digest }
}
(2)
with { UE having started authentication }
ensure that {
then { UE sends HTTP request to activate OIR }
}
(3)
with { UE having concluded activation of OIR }
ensure that {
when { UE is made to de-activate OIR }
then { UE sends HTTP request to de-activate OIR }
}
[TS 24.607 clause 4.2.1]:
The OIR service is a service offered to the originating user. It restricts presentation of the originating user's identity
information to the terminating user.
When the OIR service is applicable and activated, the originating network provides the destination network with the
indication that the originating user's identity information is not allowed to be presented to the terminating user. In this
case, no originating user's identity information shall be included in the requests sent to the terminating user. The
presentation restriction function shall not influence the forwarding of the originating user's identity information within
the network as part of the simulation service procedures.
[TS 24.607 clause 4.10.1]:
The OIR service can be activated/deactivated using the active attribute of the
<originating-identity-presentation-restriction> service element. Activating the OIR service this way activates the
temporary mode OIR service. When deactivated and not overruled by operator settings, basic communication
procedures apply.
System Simulator:
- 1 NR Cell
ETSI
UE:
Preamble:

U-S Message
1 UE is triggered for activation of supplementary - - - -
service OIR
A.21
7 UE is triggered for deactivation of - - - -
supplementary service OIR
A.21?

Content Comment
<simservs>
<originating-identity-presentation-restriction active="false">
</simservs>

Content Comment
<simservs>
<originating-identity-presentation-restriction active="true"> the "active" attribute may not be
present but if present it is set to "true"
</simservs>
ETSI

Content Comment
<simservs>
<originating-identity-presentation-restriction active="false">
</simservs>
8.3 Originating Identification Restriction / Signalling / 5GS

(1)
with { UE is registered to IMS and OIR in temporary mode is activated }
ensure that {
when { UE is made to initiate a voice call }
then { UE sends INVITE with "Anonymous" in the From header }
}
[TS 24.607 clause 4.5.2.1]:
If the originating user wishes to override the default setting of "presentation not restricted" of the OIR service in
temporary mode:
- The originating UE shall include an "anonymous" From header field. The convention for configuring an
anonymous From header field described in IETF RFC 3323 [6] should be followed; i.e. From: "Anonymous"
<sip:[email protected]>;tag= xxxxxxx.
- If only the P-Asserted-Identity needs to be restricted the originating UE shall include a Privacy header field [6]
set to "id" in accordance with IETF RFC 3325 [7].
- If all headers containing private information that the UE cannot anonymize itself need to be restricted, the
originating UE shall include a Privacy header field set to "header" in accordance with IETF RFC 3323 [6].
NOTE 2: The Privacy header field value "header" does not apply to the identity in the From header field.
System Simulator:
UE:
- The UE is configured to use Telephony Originating Identification Restriction in temporary mode
ETSI
Preamble:

U-S Message
1 Make the UE attempt an IMS speech call with - - - -
originating identification restriction.
Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
8 Check: Does the UE sends INVITE with first --> INVITE 1 P
SDP offer with including an "Anonymous" From
header field?
9-12 Steps 2-5 of Annex A.4.1a are perfomed - - - -
12C Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
19
20 Make the UE release the IMS speech call. - - - -
21- Steps 1-2 defined in annex A.7 are performed - - - -
22 to MO release the IMS speech call.

U-S Message
Table 8.3.3.3-1: INVITE (step 8, Table 8.3.3.2-1)
Derivation Path: Step 1 of A.4.1a

From
addr-spec “Anonymous" <sip:[email protected]>
Privacy id or header (mutually exclusive) RFC 3323[50]
RFC 3325[51]
ETSI
8.4 Terminating Identification Presentation / Configuration /

5GS
(1)
ensure that {
when { UE is made to activate TIP }
}
(2)
ensure that {
then { UE sends HTTP request to activate TIP }
}
(3)
with { UE having concluded activation of TIP }
ensure that {
when { UE is made to de-activate TIP }
then { UE sends HTTP request to de-activate TIP }
}
[TS 24.608 clause 4.2.1]:
The Terminating Identification Presentation (TIP) service provides the originating party with the possibility of receiving
trusted information in order to identify the terminating party.
[TS 24.608 clause 4.9.1]:
The TIP service can be activated/deactivated using the active attribute of the <terminating-identity-presentation>
service element.
System Simulator:
- 1 NR Cell
UE:
ETSI
Preamble:

U-S Message
service TIP.
A.21?
6 Check: Does the Simservs document stored in - 2 P
supplementary service TIP.
A.21?

Content Comment
<simservs>
< terminating-identity-presentation active="false">
</simservs>

Content Comment
<simservs>
<terminating-identity-presentation active="true"> the "active" attribute may not be
</simservs>

Content Comment
<simservs>
< terminating-identity-presentation active="false">
</simservs>
ETSI
8.5 Terminating Identification Restriction / Configuration / 5GS

(1)
ensure that {
when { UE is made to activate TIR }
}
(2)
ensure that {
then { UE sends HTTP request to activate TIR }
}
(3)
with { UE having concluded activation of TIR }
ensure that {
when { UE is made to de-activate TIR }
then { UE sends HTTP request to de-activate TIR }
}
[TS 24.608 clause 4.2.1]:
The Terminating Identification Restriction (TIR) is a service offered to the terminating party which enables the
terminating party to prevent presentation of the terminating identity information to originating party.
[TS 24.608 clause 4.9.1]:
The TIR service can be activated/deactivated using the active attribute of the
<terminating-identity-presentation-restriction> service element. Activating the TIR service this way activates the
temporary mode TIR service. When deactivated and not overruled by operator settings, basic communication
procedures apply.
System Simulator:
- 1 NR Cell
UE:
ETSI
Preamble:

U-S Message
service TIR.
A.21?
supplementary service TIR.
A.21?

Content Comment
<simservs>
<terminating-identity-presentation-restriction active="false">
</simservs>

Content Comment
<simservs>
<terminating-identity-presentation-restriction active="true"> the "active" attribute may not be
</simservs>

Content Comment
<simservs>
<terminating-identity-presentation-restriction active="false">
</simservs>
ETSI
8.6 Terminating Identification Restriction / Signalling / 5GS

(1)
with { UE being registered to IMS and TIR in temporary mode being activated }
ensure that {
then { UE includes the Privacy header in its 183 Session Progress response and in its 180 Ringing
response and in its final 200 OK for INVITE response }
}
[TS 24.608 clause 4.2.1]:
The Terminating Identification Restriction (TIR) is a service offered to the terminating party which enables the
terminating party to prevent presentation of the terminating identity information to originating party.
[TS 24.608 clause 4.5.2.12]:
The destination UE, if the terminating user wishes to override the default setting of "presentation not restricted" of the
TIR service in temporary mode, shall include a Privacy header with privacy type of "id" in any non-100 responses it
sends upon receipt of a SIP request.
….NOTE: It is assumed that TIR subscribers support IETF RFC 3325.
System Simulator:
UE:
- The UE is configured to use Terminating Identification Restriction in temporary mode.
Preamble:
ETSI

U-S Message
Table 4.9.16.2.2-1 of TS 38.508-1 [21] are
performed.
9-10 Steps 1-2 of Annex A.5.1 are performed. - - - -
Progress response reliably, including a Privacy
header with privacy type of "id"?
(Steps 3 of Annex A.5.1))
12- Steps 4-5 of Annex A.5.1 are performed. - - - -
13
13A- SS triggers resource reservation: Steps 10-12 - - - -
13C of generic procedure specified in Table
14- Step 6-7 of Annex A.5.1 are performed - - - -
15
16 Check: Does the UE send 180 Ringing --> 180 Ringing 1 P
including a Privacy header with privacy type of
"id"?
(Steps 8 of Annex A.5.1)
17- Steps 9-10A of Annex A.5.1 are performed. - - - -
19
20 Check: Does the UE send 200 OK including a --> 200 OK 1 P
Privacy header with privacy type of "id"?
(Steps 11 of Annex A.5.1)
21 Steps 12 of Annex A.5.1 is performed. <-- ACK - -
Table 8.6.3.3-1: 183 Session Progress (step 11, Table 8.6.3.2-1)
Derivation Path: Step 3 of A.5.1

Privacy id RFC 3323[50]
RFC 3325[51]
Table 8.6.3.3-2: 180 Ringing (step 16, Table 8.6.3.2-1)

RFC 3325[51]
Table 8.6.3.3-3: 200 OK (step 11, Table 8.6.3.2-1)

RFC 3325[51]
ETSI
8.7 Communication Forwarding Unconditional / Configuration /

5GS
(1)
ensure that {
when { UE is made to activate CFU }
}
(2)
ensure that {
then { UE sends HTTP request to activate CFU }
}
(3)
with { UE having concluded activation of CFU }
ensure that {
when { UE is made to de-activate CFU }
then { UE sends HTTP request to de-activate CFU }
}
[TS 24.604, clause 4.2.1.2]:
The CFU service enables a served user to have the network redirect to another user communications which are
addressed to the served user's address. The CFU service may operate on all communication, or just those associated
with specified services. The served user's ability to originate communications is unaffected by the CFU supplementary
service. After the CFU service has been activated, communications are forwarded independent of the status of the
served user.
As a service provider option, a subscription option can be provided to enable the served user to receive an indication
that the CFU service has been activated. This indication shall be provided when the served user originates a
communication if the CFU service has been activated for the served user's address and for the service requested for the
communication.
The maximum number of diversions permitted for each communication is a service provider option. The service
provider shall define the upper limit of diversions. When counting the number of diversions, all types of diversion are
included.
System Simulator:
- 1 NR Cell
ETSI
UE:
Preamble:

U-S Message
service CFU
A.21
supplementary service CFU
8-8b Check: Does the UE perform steps 8 – 8b of - - 3 -
the generic test procedure for activation of
A.21
ETSI

Content Further restrictions/Comments
<simservs
xmlns=http://uri.etsi.org/ngn/params/xml/simservs/xcap
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:ocp="urn:oma:xml:xdm:common-policy">
<communication-diversion active="true"> the "active" attribute may not be present but if
present it is set to "true"
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<rule-deactivated/> containing a <rule-deactivated> element
</cp:conditions>
<cp:actions>
<forward-to>
<target> px_XCAP_TargetUri</target>
<notify-caller>true</notify-caller>
</forward-to>
</cp:actions>
</cp:rule>
</cp:ruleset>
</communication-diversion>
</simservs>

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions> <cp:conditions> element missing or empty as
forwarding is supposed to be unconditional and not
containing a <rule-deactivated> element
</cp:conditions>
<cp:actions>
<forward-to>
</forward-to>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
ETSI

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
</cp:conditions>
<cp:actions>
<forward-to>
</forward-to>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
8.8 Communication Forwarding Unconditional / Signalling / 5GS

(1)
with { UE being registered to IMS and being made to initiate a voice call }
ensure that {
when { UE sends INVITE and receives a 181 Call Is Being Forwarded response }
then { UE continues and completes the voice call initiation }
}
[TS 24.604, clause 4.2.1.2]:
The CFU service enables a served user to have the network redirect to another user communications which are
addressed to the served user's address. The CFU service may operate on all communication, or just those associated
with specified services. The served user's ability to originate communications is unaffected by the CFU supplementary
service. After the CFU service has been activated, communications are forwarded independent of the status of the
served user.
that the CFU service has been activated. This indication shall be provided when the served user originates a
communication if the CFU service has been activated for the served user's address and for the service requested for the
communication.
included.
ETSI
[TS 24.604, clause 4.5.2.1]:
When communication diversion has occurred on the served user side and the network option "Originating" user
receives notification that his communication has been diverted (forwarded or deflected)" is set to true, the originating
UA may receive a 181 (Call is being forwarded) response according to the procedures described in 3GPP TS 24.229.
The Information given by the History header could be displayed by the UA if it is a UE.
System Simulator:
UE:
Preamble:
ETSI

U-S Message
2-7 Steps 2-7 of generic procedure specified in Table - - - -
- EXCEPTION: In parallel with Steps 8-9, parallel - - - -
8-9 Steps 1-2 as defined in Annex A.4.1a are executed. - - - -
10 SS sends 181 response to indicate that call <-- 181 Call is being forwarded - -
forwarding has been started as the user is configured
to Communication Forwarding Unconditional.
11 SS (simulating the phone to which the call was <-- 183 Session Progress - -
forwarded) responds with 183 Session Progress
containing an SDP answer.
(Step 3 of A.4.1a)
12 Check: Does the UE send PRACK for 183 Session -->  PRACK 1 P
Progress
(Step 4 of A.4.1a)
13 SS responds to PRACK. <--  200 OK - -
(Step 5 of A.4.1a)
13B- Steps 11-12 of generic procedure specified in Table - - - -
14 Check: Does the UE send a second SDP offer in an -->  UPDATE 1 P
UPDATE request?
(Step 6 of A.4.1a)
15 SS responds to UPDATE. <--  200 OK - -
(Step 7 of A.4.1a)
16 The SS sends 180 Ringing response to the UE <-- 180 Ringing - -
(Step 8 of A.4.1a)
17 UE acknowledges the receipt of 180 response by --> PRACK - -
sending PRACK.
(Step 9 of A.4.1a)
18 The SS responds PRACK with 200 OK. <-- 200 OK - -
(Step 10 of A.4.1a)
19 The SS responds INVITE with 200 OK to indicate <-- 200 OK - -
that the virtual remote UE had answered the call
(Step 11 of A.4.1a)
20 The UE acknowledges the receipt of 200 OK for --> ACK - -
INVITE
(Step12 of A.4.1a)
22 UE releases the voice call. - - - -
(Steps 1-2 of Annex A.7.)

U-S Message
ETSI
8.8.3.3 Specific message content
Table 8.8.3.3-1: 181 Call is being forwarded for INVITE (Step 10, table 8.8.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in subclause A.2.14.
Table 8.8.3.3-2: 180 Ringing for INVITE (Step 16, table 8.8.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in subclause A.2.4 with conditions A1 and A7
History-Info
hi-targeted-to- Same value as in the 181 response of step 10
uri
hi-index Same value as in the 181 response of step 10
Table 8.8.3.3-3: 200 OK for INVITE (Step 19, table 8.8.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.1, conditions A1, A10, and A19
History-Info
uri
8.9 Communication Forwarding on Not Logged-in /

Configuration / 5GS
(1)
ensure that {
when { UE is made to activate CFNL }
}
(2)
ensure that {
then { UE sends HTTP request to activate CFNL }
}
(3)
with { UE having concluded activation of CFNL }
ensure that {
when { UE is made to de-activate CFNL }
then { UE sends HTTP request to de-activate CFNL }
}
[TS 24.604, clause 4.2.1.7]:
The Communication Forwarding on Not Logged-in (CFNL) service enables a served user to redirect incoming
communications which are addressed to the served user's address, to another user (forwarded-to address) in case the
ETSI
served user is not registered (logged-in). The CFNL service may operate on all communications, or just those associated
with specified basic services.
that the CFNL service has been activated. This indication shall be provided when the served user logs out according to
procedures described in RFC 3261
included.
System Simulator:
- 1 NR Cell
UE:
Preamble:

U-S Message
service CFNL
A.21
supplementary service CFNL
A.21
ETSI


<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<not-registered/>
<rule-deactivated/>
</cp:conditions>
<cp:actions>
<forward-to>
</forward-to>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions> not containing a <rule-deactivated> element
<not-registered/>
</cp:conditions>
<cp:actions>
<forward-to>
</forward-to>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
ETSI

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<not-registered/>
</cp:conditions>
<cp:actions>
<forward-to>
</forward-to>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
8.10 Void
8.11 Communication Forwarding on Busy / Configuration / 5GS

(1)
ensure that {
when { UE is made to activate CFB }
}
(2)
ensure that {
then { UE sends HTTP request to activate CFB }
}
(3)
with { UE having concluded activation of CFB }
ensure that {
when { UE is made to de-activate CFB }
then { UE sends HTTP request to de-activate CFB }
}
[TS 24.604, clause 4.2.1.3]:
ETSI
The CFB service enables a served user to have the network redirect to another user communications which are
addressed to the served user's address and meet busy. The CFB service may operate on all communications, or just
those associated with specified services. The served user's ability to originate communications is unaffected by the CFB
supplementary service.
that the CFB service has been activated. This indication shall be provided when the served user originates a
communication if the CFB service has been activated for the served user's address and for the service requested for the
communication.
included.
System Simulator:
- At the SS, a HTTP Server is established at port 80 to simulate the XCAP server.
- 1 NR Cell
UE:
Preamble:

U-S Message
service CFB.
A.21?
supplementary service CFB.
ETSI
A.21?

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<busy/>
</cp:conditions>
<cp:actions>
<forward-to>
</forward-to>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<busy/>
</cp:conditions>
<cp:actions>
<forward-to>
</forward-to>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
ETSI

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<busy/>
</cp:conditions>
<cp:actions>
<forward-to>
</forward-to>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
8.12 Void
8.13 Communication Forwarding on Subscriber Not Reachable /

Configuration / 5GS
(1)
ensure that {
when { UE is made to activate CFNRc }
}
(2)
ensure that {
then { UE sends HTTP request to activate CFNRc }
}
(3)
with { UE having concluded activation of CFNRc }
ensure that {
when { UE is made to de-activate CFNRC }
then { UE sends HTTP request to de-activate CFNRc }
}
ETSI
Communication Forwarding on Subscriber Not Reachable (CFNRc)
The CFNRc service enables an user to have the network redirect all incoming communications, when the user is not
reachable (e.g. there is no IP connectivity to the user's terminal), to another user. The CFNRc service may operate on all
communications, or just those associated with specified services. The user's ability to originate communications is
unaffected by the CFNRc simulation service.
As a service provider option, a subscription option can be provided to enable the user to receive an indication that the
CFNRc service has been activated. This indication may be provided when the user originates a communication if the
CFNRc service has been activated for the user and for the service requested for the communication.
included.
System Simulator:
- 1 NR Cell
UE:
Preamble:

U-S Message
service CFNRC
A.21
6 Check: Does the Simservs document stored in - 2 P
supplementary service CFNRC
ETSI

A.21

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<not-reachable/>
</cp:conditions>
<cp:actions>
<forward-to>
</forward-to>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<not-reachable/>
</cp:conditions>
<cp:actions>
<forward-to>
</forward-to>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
ETSI

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<not-reachable/>
</cp:conditions>
<cp:actions>
<forward-to>
</forward-to>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
8.14 Void
8.15 Communication Forwarding on No Reply / Configuration /

5GS
(1)
ensure that {
when { UE is made to activate CFNR }
}
(2)
ensure that {
then { UE sends HTTP request to activate CFNR }
}
(3)
with { UE having concluded activation of CFNR }
ensure that {
when { UE is made to de-activate CFNR }
then { UE sends HTTP request to de-activate CFNR }
}
ETSI
[TS 24.604, clause 4.2.1.4]:
The CFNR service enables a served user to have the network redirect to another user communications which are
addressed to the served user's address, and for which the connection is not established within a defined period of time.
The CFNR service may operate on all communications, or just those associated with specified services. The served
user's ability to originate communications is unaffected by the CFNR supplementary service.
The CFNR service can only be invoked by the network after the communication has been offered to the served user and
an indication that the called user is being informed of the communication has been received.
that the CFNR service has been activated. This indication shall be provided when the served user originates a
communication if the CFNR service has been activated for the served user's address and for the service requested for the
communication.
included.
System Simulator:
- 1 NR Cell
UE:
Preamble:

U-S Message
service CFNR
A.21
ETSI

supplementary service CFNR
8-8b Check: Does the UE perform steps 8 – 8b of the - - 3 -
A.21

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<no-answer/>
</cp:conditions>
<cp:actions>
<forward-to>
</forward-to>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
ETSI

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<no-answer/>
</cp:conditions>
<cp:actions>
<forward-to>
</forward-to>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<no-answer/>
</cp:conditions>
<cp:actions>
<forward-to>
</forward-to>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
ETSI
8.16 Void
8.17 Barring of All Incoming Calls / Configuration / 5GS

(1)
ensure that {
when { UE is made to activate incoming communication barring for all calls (ICB) }
}
(2)
ensure that {
then { UE sends HTTP request to activate ICB }
}
(3)
with { UE having concluded activation of ICB }
ensure that {
when { UE is made to de-activate ICB }
then { UE sends HTTP request to de-activate ICB }
}
[TS 24.611, clause 4.9.1.4]:
The following conditions are allowed by the XML Schema for the communication barring service.
presence-status: This condition evaluates to true when the called user's current presence activity status is equal to the
value set for this condition. In all other cases the condition evaluates to false.
cp:identity: This condition evaluates to true when a provided user's identity matches with the value of the identity
element. The interpretation of all the elements of this condition is described in the common policy draft
(see IETF RFC 4745 [16]). In all other cases the condition evaluates to false.
anonymous: To comply with the requirements as set for simulation of the ACR service, the anonymous element only
evaluate to true when the conditions as set out in clause 4.5.2.6.2 for asserted originating public user identity apply.
request-name: This condition evaluates to true when the incoming SIP request name matches with the value of the
request-name element.
NOTE 1: The absence of this condition means that the barring rules apply to all initial incoming requests.
The condition elements that are not taken from the common policy draft (see IETF RFC 4745 [16]) or OMA common
policy schema ETSI TS 183 038 [4] are defined in the simservs document schema specified in 3GPP TS 24.623 [6].
Information of which of the above mentioned conditions the user is allowed to use can be obtained from the network by
using the schema defined in clause 4.9.3.
The "serv-cap-media" element lists the elements that can be used in the "media" rule condition.
ETSI
System Simulator:
- 1 NR Cell
UE:
Preamble:

U-S Message
service ICB
A.21?
supplementary service ICB
A.21?
ETSI

<simservs
< incoming-communication-barring active="true" > the "active" attribute may not be present but if
<cp:ruleset>
<cp:rule id=rule1> first rule
<cp:conditions>
</cp:conditions>
<cp:actions>
<allow>false</allow>
</cp:actions>
</cp:rule>
</cp:ruleset>
</incoming-communication-barring>
</simservs>

<simservs
<cp:ruleset>
<cp:conditions> the <conditions> element may not be present if
present it is set to empty
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
ETSI

<simservs
<cp:ruleset>
<cp:conditions>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
8.18 Barring of All Incoming Calls / except for a specific user /

Configuration / 5GS
(1)
ensure that {
when { UE is made to activate incoming communication barring except for a specific user (ICBESU) }
then { UE authenticates itself using Digest or GBA}
}
(2)
with { UE having started authentication using Digest or GBA}
ensure that {
then { UE sends HTTP request to activate ICBESU }
}
(3)
with { UE having concluded activation of ICBESU }
ensure that {
when { UE is made to de-activate ICBESU }
then { UE sends HTTP request to de-activate ICBESU }
}
References: Conformance requirements for activating and deactivating Communication Barring are specified in TS
34.229-1 Annexes F.1 and F.5; TS 24.611, clause 4.9.1.4; TS 24.109, clause 4.2
[TS 24.611, clause 4.9.1.4]:
cp:identity: This condition evaluates to true when the remote user's identity matches with the value of the identity
element. The interpretation of all the elements of this condition is described in the in the common policy draft (see
RFC 4745). In all other cases the condition evaluates to false.
ETSI
...
ocp:other-identity: If present in any rule, the "other-identity" element, which is empty, matches all identities that are not
referenced in any rule. It allows for specifying a default policy. The exact interpretation of this condition is specified in
OMA-TS-XDM_Core.
[TS 24.109 clause 4.2]:
becomes invalid.
sent to the UE.
parameters:
3GPP 33.220 [1]; or
ETSI
Annex C.
System Simulator:
- SS is configured shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI)
- 1 NR Cell
UE:
Preamble:
ETSI

U-S Message
1 UE is triggered for activation of - - - -
supplementary service ICBESU
2-5b Check: Does the UE perform steps 2-5b of - - 1 -
A.21?
6 Check: Does the Simservs document stored - 2 P
in the SS contain the information supplied by
UE as according to table 8.18.3.3-2 or table
8.18.3.3-3?
supplementary service ICBESU
8-8b Check: Does the UE perform steps 8-8b of - - 3 -
A.21?
9 Check: Does the Simservs document stored - - 3 P
in the SS contain the information supplied by
UE as according to table 8.18.3.3-4 or table
8.18.3.3-5?

<simservs
<incoming-communication-barring active="true">
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<cp:identity>
<cp:many>
<cp:except id= px_XCAP_TargetUri />
<rule-deactivated/>
</cp:many>
</cp:identity>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
ETSI
Table 8.18.3.3-2: Simservs document (step 6) – Option 1

<simservs
<incoming-communication-barring active="true"> the "active" attribute may not be present but if
<cp:ruleset>
<cp:rule id=any value>
<cp:conditions> list of conditions not containing a <rule-deactivated>
element
<cp:identity>
<cp:many>
<cp:except id= px_XCAP_TargetUri />
</cp:many>
</cp:identity>
</cp:conditions>
<cp:actions>
<allow>true</allow>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>

<simservs
<cp:ruleset>
<cp:rule id=any value> first rule
<cp:conditions> list of conditions for first rule not containing a <rule-
deactivated> element
<cp:identity>
<cp:one id= px_XCAP_TargetUri />
</cp:identity>
</cp:conditions>
<cp:actions>
<allow>true</allow>
</cp:actions>
</cp:rule>
<cp:rule id=any value> second rule
<cp:conditions> list of conditions for second rule not containing a
<rule-deactivated> element
<ocp:other-identity/>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
ETSI

<simservs
<incoming-communication-barring active=false>
… any content
</simservs>

<simservs
<cp:ruleset>
… list of rules with each <rule> element having a
<rule-deactivated> condition in the <conditions>
element
</cp:ruleset>
</simservs>
8.19 Barring of All Incoming Calls from anonymous users /

Configuration / 5GS
(1)
ensure that {
when { UE is made to activate ACR }
}
(2)
ensure that {
then { UE sends HTTP request to activate ACR }
}
(3)
with { UE having concluded activation of ACR }
ensure that {
when { UE is made to de-activate ACR }
then { UE sends HTTP request to de-activate ACR }
}
ETSI
[TS 24.611, clause 4.2.1]:
The Anonymous Communication Rejection (ACR) service allows the served user to reject incoming communications
on which the asserted public user identity of the originating user is restricted. In case the asserted public user identity of
the originating user is not provided then the communication shall be allowed by the ACR service.
An example where the originating user restricts presentation of the asserted public user identity is when he activated the
OIR service 3GPP TS 24.607.
The originating user is given an appropriate indication that the communication has been rejected due to the application
of the ACR service.
The Anonymous Communication Rejection (ACR) simulation service is a special case of the ICB service, which is
highlighted here because it is a regulatory service in many countries. The ACR service can be activated for a specific
subscriber by configuring an ICB service barring rule where the conditional part contains the "Condition=anonymous"
and the action part "allow=false".
[TS 24.611, clause 4.5.2.6.2]:
The AS providing the ACR service shall reject all incoming communications where the incoming SIP request:
1) includes the P-Asserted-Identity header field AND includes the Privacy header field indicating "id" as specified
in RFC 3325; or
2) includes the P-Asserted-Identity header field AND includes the Privacy header field indicating "header" as
specified in RFC 3323; or
3) includes the P-Asserted-Identity header field AND includes the Privacy header field indicating "user" as
specified in RFC 3323; or
4) includes the P-Asserted-Identity header field AND includes the Privacy header field indicating "critical" as
specified in RFC 3323.
[TS 24.611, clause 4.9.1.4]:
anonymous: To comply with the requirements as set for simulation of the ACR service, the anonymous element shall
only evaluate to true when the conditions as set out in clause 4.5.2.6.2 for asserted originating public user identity
apply.
System Simulator:
- 1 NR Cell
UE:
ETSI
Preamble:

U-S Message
service ACR.
A.21?
supplementary service ACR.
A.21?

<simservs
<incoming-communication-barring active=true> the "active" attribute may not be present but if
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<anonymous/>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
ETSI

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions> list of conditions not containing a <rule-deactivated>
element
<anonymous/>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<anonymous/>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
8.20 Void
8.21 Barring of all Outgoing Calls / Configuration / 5GS

(1)
ensure that {
when { UE is made to activate barring of all Outgoing Calls (OCB) }
}
ETSI
(2)
ensure that {
then { UE sends HTTP request to activate OCB }
}
(3)
with { UE having concluded activation of OCB }
ensure that {
when { UE is made to de-activate OCB }
then { UE sends HTTP request to de-activate OCB }
}
[TS 24.611, clause 4.2.1]:
The Outgoing Communication Barring (OCB) service makes it possible for a user to have barring of certain categories
of outgoing communications according to a provisioned or user configured barring program and is valid for all outgoing
communications. A barring program is expressed as a set of rules in which the rules have a conditional part and an
action part. An example condition is whether the request uri matches a specific public user identity. The action part can
specify for a rule that contains a matching condition that the specific outgoing communication it to be barred. The
complete set of conditions and actions that apply to this service and their semantics is described in clause 4.9.
[TS 24.611, clause 4.5.2.4.1]:
The AS providing the OCB service shall operate as either an AS acting as a SIP proxy as specified in clause 5.7.4 of
3GPP TS 24.229 [2] or an AS providing 3rd party call control, and specifically as a routeing B2BUA, as specified in
clause 5.7.5 of 3GPP TS 24.229 [2]. An AS providing the OCB service and rejecting the request shall operate as a
terminating UA, as specified in clause 5.7.2 of 3GPP TS 24.229 [2].
NOTE: For the case when the session is not subject to OCB according the requirements in this document, and is
the only service being applied by the AS, then the AS only needs to act as a SIP proxy. If additional
services are applied, then the AS might need to act as a routeing B2BUA.
The AS providing the OCB service shall reject outgoing communications when the evaluation of the served users
outgoing communication barring rules according to the algorithm as specified in clause 4.9.1.2 evaluates to
(allow="false"),.Outgoing communications towards emergency services are always allowed irrespective of what barring
settings the user has defined. To allow emergency calls to go through, the operator creates an allow list, as described in
clause 4.9.1.3, including emergency numbers in any useful format including emergency service URNs specified in RFC
5031[23]. For the purpose of OCB, the AS shall evaluate the "cp:identity" and "ocp:external-list" conditions against the
called party identity taken from Request-URI or additionally taken from the To header field.
When the AS providing the OCB service rejects a communication, the AS shall send an indication to the calling user by
sending a 603 (Decline) response Additionally, before terminating the communication the AS can provide an
announcement to the originating user. The procedure of invoking an announcement is described within 3GPP TS 24.628
[10].
[TS 24.611, clause 4.9.1.4]:
The following conditions are allowed by the XML Schema for the communication barring service.
The condition elements that are not taken from the common policy draft (see IETF RFC 4745 [16]) or OMA common
policy schema ETSI TS 183 038 [4] are defined in the simservs document schema specified in 3GPP TS 24.623 [6].
Information of which of the above mentioned conditions the user is allowed to use can be obtained from the network by
using the schema defined in clause 4.9.3.
ETSI
The "serv-cap-media" element lists the elements that can be used in the "media" rule condition.
System Simulator:
- 1 NR Cell
UE:
Preamble:

U-S Message
service OCB
A.21?
supplementary service OCB.
A.21?
ETSI

<simservs
< outcoming-communication-barring active="true" > the "active" attribute may not be present but if
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</outcoming-communication-barring>
</simservs>

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions> the <conditions> element may not be present if
present it is set to empty
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
ETSI

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
8.22 Barring of Outgoing International Calls / Configuration / 5GS

(1)
ensure that {
when { UE is made to activate barring of all Outgoing Calls (OCB intl) }
}
(2)
ensure that {
then { UE sends HTTP request to activate OCB intl }
}
(3)
with { UE having concluded activation of OCB intl }
ensure that {
when { UE is made to de-activate OCB intl }
then { UE sends HTTP request to de-activate OCB intl }
}
[TS 24.611, clause 4.2.1]:
ETSI
[TS 24.611, clause 4.5.2.4.1]:
[10].
[TS 24.611, clause 4.9.1.4]:
international: This condition evaluates to true when the request URI of the outgoing SIP request:
- corresponds to a telephone number, i.e. a SIP URI with a "user" URI parameter set to "phone" or a tel URI; and
- does not point to a destination served by a network within the country where the originating user is located when
initiating the communication.
System Simulator:
- 1 NR Cell
UE:
Preamble:
ETSI

U-S Message
service OCB intl.
A.21?
supplementary service OCB intl.
A.21?

<simservs
<outcoming-communication-barring active=true> the "active" attribute may not be present but if
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<international/>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
ETSI

<simservs
<cp:ruleset>
<cp:rule id=rule1> list of conditions not containing a <rule-deactivated>
element
<cp:conditions>
<international/>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<international/>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
ETSI
8.23 Barring of Outgoing International Calls / ex Home Country /

Configuration / 5GS
(1)
ensure that {
when { UE is made to activate Barring of Outgoing International Calls ex Home Country (OCB intl
exHC) }
}
(2)
ensure that {
then { UE sends HTTP request to activate OCB intl exHC }
}
(3)
with { UE having concluded activation of OCB intl exHC }
ensure that {
when { UE is made to de-activate OCB intl exHC }
then { UE sends HTTP request to de-activate OCB intl exHC }
}
[TS 24.611, clause 4.2.1]:
[TS 24.611, clause 4.5.2.4.1]:
ETSI
[10].
[TS 24.611, clause 4.9.1.4]:
international-exHC: This condition for international barring, excluding the home country, evaluates to true when the
request URI of the outgoing SIP request:
- corresponds to a telephone number, i.e. a SIP URI with a "user" URI parameter set to "phone" or a tel URI;
initiating the communication; and
- does not point to a destination served within the served users home network.
NOTE 4: In case of international and international-exHC, called users subscribed to a network in the country in
which the served user roams, can be called irrespective where they roam. Subscribers, subscribed to any
network in another country than the one in which the served user is located cannot be called even if they
roam in the same network area as the served users or in the served user's home network. The condition
elements that are not taken from the common policy draft (see IETF RFC 4745 [16]) or OMA common
policy schema ETSI TS 183 038 [4] are defined in the simservs document schema specified in 3GPP TS
24.623 [6].
System Simulator:
- 1 NR Cell
UE:
Preamble:

U-S Message
service OCB intl exHC.
ETSI
A.21?
supplementary service OCB intl exHC.
A.21?

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<international-exHC />
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
ETSI

<simservs
<cp:ruleset>
element
<cp:conditions>
<international-exHC/>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
8.24 Barring of Outgoing International Calls / When Roaming /

Configuration / 5GS
(1)
ensure that {
when { UE is made to activate Barring of Outgoing International Calls when roaming (OCB intl roam)
}
}
ETSI
(2)
ensure that {
then { UE sends HTTP request to activate OCB intl roam }
}
(3)
with { UE having concluded activation of OCB intl roam }
ensure that {
when { UE is made to de-activate OCB intl roam }
then { UE sends HTTP request to de-activate OCB intl roam }
}
[TS 24.611, clause 4.2.1]:
[TS 24.611, clause 4.5.2.4.1]:
[10].
[TS 24.611, clause 4.9.1.4]:
roaming: This condition evaluates to true when the served user is registered from an access network other than the
served users home network.
NOTE 3: Whether the served user is registered from another network then the served users home network can be
determined from the P-Visited-Network-ID header field specified in IETF RFC 7315 [15] and the P-
Access-Network-Info header field specified in IETF RFC 7315 [15] both are provided during the
registration process, see 3GPP TS 24.229 [2], clause 5.7.1.3.
rule-deactivated: This condition always evaluates to false. This can be used to deactivate a rule, without losing
information. By removing this condition the rule can be activated again.
ETSI
international: This condition evaluates to true when the request URI of the outgoing SIP request:
- corresponds to a telephone number, i.e. a SIP URI with a "user" URI parameter set to "phone" or a tel URI; and
initiating the communication.
System Simulator:
- 1 NR Cell
UE:
Preamble:

U-S Message
service OCB intl roam.
A.21?
supplementary service OCB intl roam.
A.21?
ETSI

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<roaming/>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>

<simservs
<cp:ruleset>
element
<cp:conditions>
<international-exHC/>
<roaming/>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
ETSI

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<roaming/>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
8.25 Barring of Incoming Calls / When Roaming / Configuration /

5GS
(1)
ensure that {
when { UE is made to activate Barring of Incoming Calls When Roaming (ICB roam) }
}
(2)
ensure that {
then { UE sends HTTP request to activate ICB roam }
}
(3)
with { UE having concluded activation of ICB roam }
ensure that {
when { UE is made to de-activate ICB roam }
then { UE sends HTTP request to de-activate ICB roam }
}
[TS 24.611, clause 4.2.1]:
The Incoming Communication Barring (ICB) service makes it possible for a user to have barring of certain categories
of incoming communications according to a provisioned or user configured barring program and is valid for all
incoming communications. A barring program is expressed as a set of rules in which the rules have a conditional part
ETSI
and an action part. Examples of conditions are whether the asserted originating public user identity matches a specific
public user identity or whether the originating public user identity is restricted (anonymous). The action part could
specify for a rule that contains a matching condition that the specific incoming communication is barred. The complete
set of conditions and actions that apply to this service and their semantics is described in subclause 4.9.
[TS 24.611, clause 4.9.1.4]:
roaming: This condition evaluates to true when the served user is registered from an access network other than the
served users home network.
NOTE 3: Whether the served user is registered from another network then the served users home network can be
determined from the P-Visited-Network-ID header field specified in IETF RFC 7315 [15] and the P-
Access-Network-Info header field specified in IETF RFC 7315 [15] both are provided during the
registration process, see 3GPP TS 24.229 [2], clause 5.7.1.3.
System Simulator:
- 1 NR Cell
UE:
Preamble:

U-S Message
service ICB roam.
A.21?
supplementary service ICB roam.
ETSI

A.21?

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<roaming/>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>

<simservs
<incoming-communication-barring active="true" > the "active" attribute may not be present but if
<cp:ruleset>
element
<cp:conditions>
<roaming/>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
ETSI

<simservs
<cp:ruleset>
<cp:rule id=rule1>
<cp:conditions>
<roaming/>
</cp:conditions>
<cp:actions>
</cp:actions>
</cp:rule>
</cp:ruleset>
</simservs>
8.26 MO Voice Call Hold without announcement / 5GS

(1)
with { UE being registered to IMS and being configured to use preconditions and having set up a
voice call }
ensure that {
when { UE is being made to hold the call }
then { UE sends re-INVITE or UPDATE, and completes the call hold procedure }
}
(2)
with { UE having put the voice call on hold }
ensure that {
when { UE is being made to resume the call }
then { UE sends re-INVITE or UPDATE, and completes the call resume procedure }
}
[TS 24.610 clause 4.5.2.1]:
In addition to the application of procedures according to 3GPP TS 24.229 [1], the following procedures shall be applied
at the invoking UE in accordance with RFC 3264 [4].
A UE shall not invoke the HOLD service on a dialog associated with an emergency call the UE has initiated.
If not all the media streams are affected, the invoking UE shall generate a new SDP offer where:
1) for each media stream that is to be held, the SDP offer contains:
- an "inactive" SDP attribute if the stream was previously set to "recvonly"; or
- a "sendonly" SDP attribute if the stream was previously set to "sendrecv";
ETSI
NOTE 1: If the directionality attribute of the media stream is currently "sendonly" or "inactive", then that media
stream is not put on hold and, in the SDP offer, the directionality for that media stream remains
unchanged.
2) for each held media stream that is to be resumed, the SDP offer contains:
- a "recvonly" SDP attribute if the stream was previously an inactive media stream; or
- a "sendrecv" SDP attribute if the stream was previously a sendonly media stream, or the attribute may be
omitted, since sendrecv is the default; and
3) for each media stream that is unaffected, the media parameters in the SDP offer remain unchanged from the
previous SDP.
If all the media streams are to be held:
- if they all have identical directionality, the invoking UE shall generate an SDP offer containing a session level
direction attribute, or separate media level direction attributes, in the SDP that is set to:
1) "inactive" if the streams were previously set to "recvonly"; or
2) "sendonly" if the streams were previously set to "sendrecv"; and
NOTE 2: If the directionality attribute of all the media streams is currently "sendonly" or "inactive", then all these
media streams are not put on hold and, in the SDP offer, the directionality for these media streams will
remain unchanged.
- if they all do not have identical directionality, then for each media stream in the session, the invoking UE shall
follow the procedure listed above for individual media streams.
If all the media streams were previously on hold and are to be resumed:
- if they all have identical directionality, the invoking UE shall generate a session level direction attribute, or
separate media level direction attributes, in the SDP that is set to:
1) "recvonly" if the streams were previously inactive media streams; or
2) "sendrecv" if the streams were previously sendonly media streams, or the attribute may be omitted, since
sendrecv is the default; and
If, in the generated SDP offer, there is at least one media stream whose directionality has changed from the previous
SDP, the UE shall send the generated SDP offer in a re-INVITE request (or UPDATE request) to the remote UE.
[TS 26.114 clause 7.3.1]:
RTCP packets should be sent for all types of multimedia sessions to enable synchronization with other RTP transported
media, remote end-point aliveness information, monitoring of the transmission quality, and carriage of feedback
messages such as TMMBR for video and RTCP APP for speech. The RR value should be set greater than zero to enable
RTCP packets to be sent when media is put on hold and during active RTP media transmission, including real-time text
sessions which may have infrequent RTP media transmissions.
[TS 24.229 clause 6.1.1]:
ETSI
System Simulator:
UE:
Preamble:
- The UE has registered to IMS and set up the MO call, by executing the generic test procedure in Annex A.2 up
to the last step and thereafter executing the generic test procedure in A.4.1a.
ETSI

U-S Message
1 The UE is made to hold the call - -
2 Check: Does the UE send INVITE or UPDATE --> INVITE or UPDATE 1 P
with a SDP offer to hold the call?
3 The SS responds to the INVITE with a 100 <-- 100 Trying
Trying provisional response.
4 The SS responds to INVITE or UPDATE with <-- 200 OK
200 OK to indicate that the remote UE is no
more sending any media (call hold) or resumes
sending media (call resume)
5 If the UE sent INVITE in step 1 then UE --> ACK
acknowledges the receipt of 200 OK for INVITE.
6 The UE is made to resume the call - -
with a SDP offer to resume the call?
8 The SS responds to the INVITE with a 100 <-- 100 Trying
Trying provisional response.
9 The SS responds to INVITE or UPDATE with <-- 200 OK
200 OK to indicate that the remote UE is no
more sending any media (call hold) or resumes
sending media (call resume)
Optional: If the UE sent INVITE in step 1 then --> ACK
10 UE acknowledges the receipt of 200 OK for
INVITE. (Step 4 of Annex A.17)
11 The SS releases the call with BYE. <-- BYE - -
12 The UE sends 200 OK for BYE. --> 200 OK - -
None as fully specified in Annex A.17 and Annex A.8.
8.27 MO Video Call Hold without announcement / 5GS

(1)
with { UE being registered to IMS and being registered to use preconditions and having set up a
video call }
ensure that {
when { UE is being made to hold the call }
then { UE sends re-INVITE or UPDATE, and completes the call hold procedure }
}
(2)
with { UE having put the video call on hold }
ensure that {
when { UE is being made to resume the call }
then { UE sends re-INVITE or UPDATE, and completes the call resume procedure }
ETSI
[TS 24.610 clause 4.5.2.1]:
In addition to the application of procedures according to 3GPP TS 24.229 [1], the following procedures shall be applied
at the invoking UE in accordance with RFC 3264 [4].
A UE shall not invoke the HOLD service on a dialog associated with an emergency call the UE has initiated.
If not all the media streams are affected, the invoking UE shall generate a new SDP offer where:
1) for each media stream that is to be held, the SDP offer contains:
- an "inactive" SDP attribute if the stream was previously set to "recvonly"; or
- a "sendonly" SDP attribute if the stream was previously set to "sendrecv";
NOTE 1: If the directionality attribute of the media stream is currently "sendonly" or "inactive", then that media
stream is not put on hold and, in the SDP offer, the directionality for that media stream remains
unchanged.
2) for each held media stream that is to be resumed, the SDP offer contains:
- a "recvonly" SDP attribute if the stream was previously an inactive media stream; or
- a "sendrecv" SDP attribute if the stream was previously a sendonly media stream, or the attribute may be
omitted, since sendrecv is the default; and
3) for each media stream that is unaffected, the media parameters in the SDP offer remain unchanged from the
previous SDP.
If all the media streams are to be held:
- if they all have identical directionality, the invoking UE shall generate an SDP offer containing a session level
direction attribute, or separate media level direction attributes, in the SDP that is set to:
1) "inactive" if the streams were previously set to "recvonly"; or
2) "sendonly" if the streams were previously set to "sendrecv"; and
NOTE 2: If the directionality attribute of all the media streams is currently "sendonly" or "inactive", then all these
media streams are not put on hold and, in the SDP offer, the directionality for these media streams will
remain unchanged.
If all the media streams were previously on hold and are to be resumed:
- if they all have identical directionality, the invoking UE shall generate a session level direction attribute, or
separate media level direction attributes, in the SDP that is set to:
1) "recvonly" if the streams were previously inactive media streams; or
2) "sendrecv" if the streams were previously sendonly media streams, or the attribute may be omitted, since
sendrecv is the default; and
If, in the generated SDP offer, there is at least one media stream whose directionality has changed from the previous
SDP, the UE shall send the generated SDP offer in a re-INVITE request (or UPDATE request) to the remote UE.
ETSI
[TS 26.114 clause 7.3.1]:
[TS 24.229 clause 6.1.1]:
lines, one with the "RS" bandwidth modifier and the other with the "RR" bandwidth modifier as described in RFC 3556
[56] to specify the required bandwidth allocation for RTCP. The bandwidth-value in the b=RS: and b=RR: lines may
include transport overhead as described in subclause 6.1 of RFC 3890 [152].
System Simulator:
UE:
Preamble:
- The UE has registered to IMS and set up the MO Video call, by executing the generic test procedure in Annex
A.2 up to the last step and thereafter executing the generic test procedure in A.15.1a.
ETSI

U-S Message
1 The UE is made to hold the call - - - -
with a SDP offer to hold the call?
(step 1 in annex A.24)
3-5 Steps 2-4 in annex A.24 are performed. - - - -
6 The UE is made to resume the call - - - -
with a SDP offer to resume the call?
(step 1 in annex A.24)
8-10 Steps 2-4 in annex A.24 are performed. - - - -
12- UE releases the call - - - -
13 (Annex A.7)
None as fully described in Annex A.24.
ETSI
8.28 MT Voice Call Hold without announcement / 5GS

(1)
with { UE being registered to IMS being configured to using preconditions and having set up an MO
voice call }
ensure that {
when { UE receives re-INVITE including call hold instructions }
}
(2)
with { UE having responded to re-INVITE for call hold }
ensure that {
when { UE receives ACK followed by re-INVITE including call resume instructions }
}
(3)
with { UE having concluded the call resume procedure }
ensure that {
when { UE is being made to release the call }
}
[TS 24.610 clause 4.5.2.9]:
3GPP TS 24.229 [1] shall apply.
[TS 26.114 clause 7.3.1]:
[TS 24.229 clause 6.1.1]:
ETSI
System Simulator:
UE:
Preamble:
to the last step and thereafter executing the generic test procedure in A.4.1a.

U-S Message
1 SS sends INVITE with a SDP offer to hold the <-- INVITE - -
call
2 Optional: The UE responds with a 100 Trying --> 100 Trying - -
provisional response
3 Check: Does the UE respond to INVITE with --> 200 OK 1 P
200 OK to indicate that the UE is no more
expecting to receive any media?
INVITE
5 SS sends INVITE with a SDP offer to resume <-- INVITE - -
the call
INVITE
9 UE is made to release the call - - - -
Check: Does the UE send BYE to release the --> BYE 3 P
10 call?
The SS sends 200 OK for BYE <-- 200 OK - -
11
None as fully specified in Annex A.18 and A.7.
ETSI
8.29 MT Video Call Hold without announcement / 5GS

(1)
with { UE being registered to IMS and configured to use preconditions and having set up an MO video
call }
ensure that {
when { UE receives re-INVITE including call hold instructions }
}
(2)
with { UE having responded to re-INVITE for call hold }
ensure that {
when { UE receives ACK followed by re-INVITE including call resume instructions }
}
(3)
with { UE having concluded the call resume procedure }
ensure that {
when { UE is being made to release the call }
}
[TS 24.610 clause 4.5.2.9]:
3GPP TS 24.229 [1] shall apply.
[TS 26.114 clause 7.3.1]:
[TS 24.229 clause 6.1.1]:
ETSI
System Simulator:
UE:
Preamble:
- The UE has registered to IMS and set up the MO Video call, by executing the generic test procedure in Annex
A.2 up to the last step and thereafter executing the generic test procedure in A.15.1a.

U-S Message
1 SS sends INVITE with a SDP offer to hold the <-- INVITE - -
video call.
INVITE.
(Step 4of Annex A.28)
5 SS sends INVITE with a SDP offer to resume <-- INVITE - -
the call
200 OK to indicate that the UE resumes
sending media (call resume)?
INVITE.
Check: Does the UE send BYE to release the --> BYE 3 P
10 call?
The SS sends 200 OK for BYE. <-- 200 OK - -
11
None as fully described in Annex A.28 and A.7
ETSI
ETSI
8.30 Subscription to the MWI event package / 5GS

(1)
with { UE being configured to subscribe to MWI }
ensure that {
when { UE registers to IMS }
then { UE subscribes to MWI and to reg event }
}
(2)
with { UE being registered to MWI and reg event }
ensure that {
when { UE receives initial NOTIFY for MWI }
then { UE sends 200 OK }
}
(3)
ensure that {
when { UE receives second NOTIFY for MWI indicating one voice message waiting }
}
(4)
ensure that {
when { UE receives NOTIFY for reg event }
}
[TS 24.606, clause 4.1]:
The Message Waiting Indication (MWI) service enables the network, upon the request of a controlling user to indicate
to the receiving user, that there is at least one message waiting.
[TS 24.606, clause 4.6]:
The application/simple-message-summary MIME type used to provide Message Summary and Message Waiting
Indication Information is defined in subclause 5 of RFC 3842 [3].
The coding of the message types in the message-context-class values is defined in the specifications listed in the
"reference" column of table 1.
Table 1: Coding requirements

Value Reference
voice-message RFC 3458 [5]
video-message RFC 3938 [6]
fax-message RFC 3458 [5]
pager-message RFC 3458 [5]
multimedia-message RFC 3458 [5]
text-message RFC 3458 [5]
none RFC 3458 [5]
ETSI
The coding of the additional information about deposited messages in the application/simple-message-summary MIME
body is defined in subclause 25 of RFC 3261 [11] for SIP extension-header (subclause 3.5 of RFC 3842 [3]) and follow
the rules defined in the specifications listed in the "reference" column of table 2.
Table 2: Additional information

Header Description Reference
To: Indicates the subscriber's public user identity used by correspondent subclause 3.6.3 of RFC 2822
to deposit a message. [7]
From: Indicates the correspondent's public user identity, if available. subclause 3.6.2 of RFC 2822
[7]
Subject: Indicates the topic of the deposited message as provided by subclause 3.6.5 of RFC 2822
correspondent. [7]
Date: Indicates the time and date information about message deposit. subclause 3.6.1 of RFC 2822
[7]
Priority: Indicates the message priority as provided by correspondent. RFC 2156 [8]
Message-ID: Indicates a single unique message identity. subclause 3.6.4 of RFC 2822
[7]
Message-Context: Indicates a type or context of message. RFC 3458 [5]
[TS 24.606, clause 4.7.1]:
The MWI service is immediately activated after the SUBSCRIBE request from the MSUA is successfully processed,
see subclause 4.7.2.
The MWI service is deactivated after subscription expiry or after unsuccessful attempt to deliver a notification about
message waiting.
[TS 24.606, clause 4.7.2.1]:
When the MSUA intends to subscribe for status information changes of a message account, the MSUA shall generate a
SUBSCRIBE request in accordance with RFC 6665 [4] and RFC 3842 [3] and in alignment with the procedures
described in 3GPP TS 24.229 [2]. If the UE receives a 489 (Bad Event) response or a 405 (Method Not Allowed)
response to the SUBSCRIBE request, the UE shall not re-try the SUBSCRIBE request until de-registration of the public
user identity from IMS.
NOTE: 489 (Bad Event) response or 405 (Method Not Allowed) response to the SUBSCRIBE request indicates
that MWI is not supported in the network.
The MSUA will address the SUBSCRIBE request to one of the subscriber's public user identities (see subclause 4.5.1).
The MSUA shall implement the "application/simple-message-summary" content type as described in RFC 3842 [3].
System Simulator:
UE:
- The UE is pre-configured to autonomously subscribe to the Message Waiting Indication package.
- The UE is configured with the public service identity of the message account. (Otherwise the phone is expected
to use the public identity of the user when subscribing to the Message Waiting Indication package.)
ETSI
Preamble:
- The UE is in test state 1N-A (TS 38.508-1 [21]) and processed IMS registration as described in Annex A.2 up to
step 4.

U-S Message
1 Check: Does the UE subscribe to the Message --> SUBSCRIBE 1 P
Waiting Indication event package?
2 The SS responds SUBSCRIBE with 200 OK <-- 200 OK - -
3 The UE subscribes to the registration event --> SUBSCRIBE - -
package
4 The SS responds with 200 OK <-- 200 OK - -
5 The SS sends initial NOTIFY for Message <-- NOTIFY - -
Waiting Indication event package
6 Check: Does the UE respond the NOTIFY with --> 200 OK 2 P
200 OK?
7 The SS sends another NOTIFY for Message <-- NOTIFY - -
Waiting Indication event package, now referring
to one voice message waiting
8 Check: Does the UE respond the NOTIFY with --> 200 OK 3 P
200 OK?
The SS sends initial NOTIFY for registration <-- NOTIFY - -
event package, containing full registration state
9
information for the registered public user
identity in the XML body
10 Check: Does the UE respond with 200 OK? --> 200 OK 4 P
Table 8.30.3.3-1: SUBSCRIBE (step 1, table 8.30.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.6.1, Conditions A1, A6

Table 8.30.3.3-2: 200 OK for SUBSCRIBE (step 2/4, table 8.30.3.2-1)
Table 8.30.3.3-3: SUBSCRIBE (step 3, table 8.30.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.1.4, Conditions A1, A7
Table 8.30.3.3-4: NOTIFY for Message Waiting Indication package (step 5, table 8.30.3.2-1)
Table 8.30.3.3-5: 200 OK (step 6/8/10, table 8.30.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.3.1, Conditions A5, A11, A22
ETSI
Table 8.30.3.3-6: NOTIFY for Message Waiting Indication package (step 7/9, table 8.30.3.2-1)

Message-body Messages-Waiting: yes
Message-Account: same IMPU as in From header
Voice-Message: 1/0 (0/0)
To: <same IMPU as sent by the UE in the From header of

the SUBSCRIBE in step 1>
From: <[email protected]>
Subject: call me back!
Date: Fri 05 Feb 2021 14:24 +0100
Priority: urgent
Message-ID: 27775334485@home domain name
Message-Context: voice-message
Table 8.30.3.3-7: NOTIFY for reg-event package (step 8, table 8.30.3.2-1)
ETSI
8.31 Creating and leaving a conference / 5GS

(1)
ensure that {
when { UE is made to start a conference call }
then { UE sends INVITE to the conference factory and completes the conference call initiation
and subscribes to conference event }
}
(2)
with { Conference call going on }
ensure that {
when { UE is made to leave the call }
then { UE sends BYE and processes notification for conf event if any }
}
[TS 24.147, clause 5.3.1.3.1]:
A conference can be created by means of SIP, as described in subclause 5.3.1.3.2 or subclause 5.3.1.3.3.
NOTE: Additionally, creation of a conference can be provided by other means.
The conference participant shall make use of the procedures for session establishment as described in subclauses 5.1.2A
and 5.1.3 of 3GPP TS 24.229 [5] when creating conferences by means of SIP.
[TS 24.147, clause 5.3.1.3.2]:
Upon a request to create a conference with a conference factory URI, the conference participant shall:
1) generate an initial INVITE request in accordance with subclause 5.1.3.1 of 3GPP TS 24.229 [5]; and
2) set the request URI of the INVITE request to the conference factory URI.
On receiving a 200 (OK) response to the INVITE request with the "isfocus" feature parameter indicated in Contact
header, the conference participant shall store the content of the received Contact header as the conference URI. In
addition to this, the conference participant may subscribe to the conference event package as described in
RFC 4575 [11] by using the stored conference URI.
NOTE 1: A conference participant can decide not to subscribe to the conference event package for conferences with
a large number of attendees, due to, e.g. the signalling traffic caused by the notifications about users
joining or leaving the conference.
NOTE 2: A conference can also be created with a conference URI. The procedures for this case at the conference
participant are identical to those for joining a conference, as described in subclause 5.3.1.4.1. It is not
assumed that the conference participant is aware that the conference gets created in this case.
NOTE 3: The UE can discover the conference factory URI from the Management Object as defined in
3GPP TS 24.166 [38]. Further discovery mechanisms for the conference factory URI are outside the
scope of the present document.
ETSI
System Simulator:
UE:
Preamble:
- The UE is in test state 1N-A (TS 38.508-1) and registered to IMS.

U-S Message
1 Make the UE attempt an IMS Conference call - - - -
2 Check: Does the UE send INVITE with the --> INVITE 1 P
first SDP offer?
(Step 1 of annex A.19)
3-14 UE and SS continue the procedures of - - - -
conference call. (Steps 2-13 of annex A.19)
EXCEPTION: steps 11 – 14 (conference - - - -

event subscription) describe optional
behaviour depending on UE configuration.
The SS shall wait up to 3s for the
SUBSCRIBE of step 11
15 The UE is made to leave the conference - - - -
16 The UE leaves the conference with BYE --> BYE 2 P
17-19 The SS and UE continue to finish the - - - -
procedures of leaving a conference.
(Steps 2-4 of annex A.27)
None as fully specified in annex A.19 and A.27.
ETSI
8.32 Inviting user to conference by sending a REFER request to

the conference focus / 5GS
(1)
ensure that {
when { UE is made to start a conference call }
}
(2)
ensure that {
when { UE is made to invite another user to the conference call }
then { UE sends REFER to the conference focus }
}
(3)
with { UE having invited another user to the conference call }
ensure that {
when { UE receives 202 Accepted followed by notification messages for the REFER request, the
confirmation on the other user and conditional conference event package }
then { UE sends 200 OK for each received NOTIFY request }
}
(4)
ensure that {
}
[TS 24.147, clause 5.3.1.5.3]:
Upon generating a REFER request in accordance with the procedures specified in 3GPP TS 24.229 [5],
IETF RFC 3515 [17] as updated by IETF RFC 6665 [10] and IETF RFC 7647 [39] that is destined to the conference
focus in order to invite another user to a specific conference, the conference participant shall:
1) set the request URI of the REFER request to the conference URI to which the user is invited to;
2) set the Refer-To header of the REFER request to the SIP URI or tel URL of the user who is invited to the
conference;
3) either include the "method" URI parameter with the value "INVITE" or omit the "method" URI parameter in the
Refer-To header; and
NOTE: Other headers of the REFER request will be set in accordance with 3GPP TS 24.229 [5].
4) send the REFER request towards the conference focus that is hosting the conference.
The UE may additionally include the Referred-By header to the REFER request and set it to the URI of the conference
participant that is sending the REFER request.
In case of an active session the UE may additionally include the Replaces header in the header portion of the SIP URI
of the Refer-to header field of the REFER request. If the user involved in the active session is identified by a tel URI,
ETSI
the UE shall convert the tel URI to an SIP URI as described in RFC 3261 [7] before including the Replaces header field.
The included Replaces header field shall refer to the active dialog that is replaced by the ad-hoc conference. The
Replaces header field shall comply with RFC 3891 [33].
Afterwards the UE shall treat incoming NOTIFY requests that are related to the previously sent REFER request in
accordance with RFC 3515 [17] as updated by RFC 6665 [10] and may indicate the received information to the user.
System Simulator:
- SS has performed AKAv1-MD5 authentication with the UE and accepted the registration.
UE:
Preamble:
ETSI

U-S Message
1 The UE is made to attempt an IMS Conference call - - - -
2 Check: Does the UE send INVITE with the first SDP offer?
--> INVITE 1 P
3-14 UE and SS continue the procedures of conference call.
- - - -
15 The UE is made to invite another user to the conference - - - -
16 The UE sends REFER to SS referring to the conference
--> REFER 2 P
17-18 The SS responds with a 202 final response and sends initial
NOTIFY for the implicit subscription created by the REFER
- - - -
request.
19 The UE responds the NOTIFY with 200 OK
--> 200 OK 3 P
20 The SS sends a NOTIFY related to REFER request to confirm
that the invited user was able to join the conference <-- NOTIFY
--> 200 OK 3 P
22 Conditional: If the UE has subscribed the conference event
package, the SS sends a NOTIFY for conference event
package to inform that the invited user was able to join the <-- NOTIFY - -
conference
23 Conditional: The UE responds the NOTIFY with 200 OK (if
NOTIFY sent by SS) --> 200 OK 3 P
25 The UE sends BYE to leave the conference
BYE 4 P
26-28 The SS and UE continue to finish the procedures of leaving a - - - -
conference.
None as fully specified in annex A.19, A.20 and A.27.
8.33 Inviting user to conference by sending a REFER request to

the conference focus / Video / 5GS
(1)
ensure that {
when { UE is made to start a video conference call }
}
(2)
with { Video Conference call going on }
ETSI
ensure that {
when { UE is made to invite another user to the conference call }
then { UE sends REFER to the conference focus }
}
(3)
with { UE having invited another user to the Video conference call }
ensure that {
confirmation on the other user and conditional conference event package }
}
(4)
with {Video Conference call going on }
ensure that {
}
[TS 24.147, clause 5.3.1.5.3]:
Upon generating a REFER request in accordance with the procedures specified in 3GPP TS 24.229 [5],
IETF RFC 3515 [17] as updated by IETF RFC 6665 [10] and IETF RFC 7647 [39] that is destined to the conference
focus in order to invite another user to a specific conference, the conference participant shall:
1) set the request URI of the REFER request to the conference URI to which the user is invited to;
2) set the Refer-To header of the REFER request to the SIP URI or tel URL of the user who is invited to the
conference;
3) either include the "method" URI parameter with the value "INVITE" or omit the "method" URI parameter in the
Refer-To header; and
NOTE: Other headers of the REFER request will be set in accordance with 3GPP TS 24.229 [5].
4) send the REFER request towards the conference focus that is hosting the conference.
The UE may additionally include the Referred-By header to the REFER request and set it to the URI of the conference
participant that is sending the REFER request.
In case of an active session the UE may additionally include the Replaces header in the header portion of the SIP URI
of the Refer-to header field of the REFER request. If the user involved in the active session is identified by a tel URI,
the UE shall convert the tel URI to an SIP URI as described in RFC 3261 [7] before including the Replaces header field.
The included Replaces header field shall refer to the active dialog that is replaced by the ad-hoc conference. The
Replaces header field shall comply with RFC 3891 [33].
Afterwards the UE shall treat incoming NOTIFY requests that are related to the previously sent REFER request in
accordance with RFC 3515 [17] as updated by RFC 6665 [10] and may indicate the received information to the user.
System Simulator:
- SS has performed AKAv1-MD5 authentication with the UE and accepted the registration.
ETSI
UE:
Preamble:

U-S Message
1 The UE is made to attempt an IMS Conference call - - - -
2 The UE sends INVITE with the first SDP offer.
--> INVITE 1 P
(Step 1 in annex A.25 )
3-14 Steps 2-13 of annex A.25 happen. - - - -
15 The UE is made to invite another user to the conference - - - -
16 The UE sends REFER to SS referring to the conference
--> REFER 2 P
17 The SS responds with a 202 final response
<-- 202 Accepted - -
18 The SS sends initial NOTIFY for the implicit subscription
created by the REFER request <-- NOTIFY - -
--> 200 OK 3 P
20 The SS sends a NOTIFY related to REFER request to confirm
that the invited user was able to join the conference <-- NOTIFY - -
--> 200 OK 3 P
22 Optional: If the UE has subscribed the conference event
package, the SS sends a NOTIFY for conference event
package to inform that the invited user was able to join the <-- NOTIFY - -
conference.
23 Optional: The UE responds the NOTIFY with 200 OK
--> 200 OK 3 P
The UE sends BYE to ler leaving the conference
25 --> BYE 4 P
The SS sends 200 OK for BYE
26 <-- 200 OK - -
If the UE had subscribed to the conference event package, the
SS notifies the UE that its subscription to conference event
27 --> NOTIFY - -
package is terminated
The UE sends 200 OK for NOTIFY (if sent by SS)
28 --> 200 OK - -
None as fully described in Annex A.25, A.26 and A.27.
ETSI
8.34 Three way session creation / Voice / 5GS

(1)
with { UE being registered to IMS and being configured to use preconditions having set up an MO
voice call with A }
ensure that {
when { UE is made to start a three way voice call }
then { UE sends re-INVITE or UPDATE, and completes the call hold procedure with A }
}
(2)
with { UE being in the process of starting a three way voice call }
ensure that {
when { UE having put A on hold }
then { UE initiates a voice call with B }
}
(3)
ensure that {
when { UE having initiated a voice call with B }
then { UE sends re-INVITE or UPDATE, and completes the call hold procedure with B }
}
(4)
ensure that {
when { UE having put both A and B on hold }
}
(5)
ensure that {
when { UE having created a call at the conference factory }
then { UE sends REFER to the conference focus in order to invite A }
}
(6)
with { UE having invited A to the conference call }
ensure that {
confirmation on A and conditional conference event package }
}
(7)
ensure that {
when { UE having completed the invitation of A }
then { UE sends REFER to the conference focus in order to invite B }
}
(8)
with { UE having invited B to the conference call }
ensure that {
confirmation on B and conditional conference event package }
}
ETSI
When a user is participating in two or more SIP sessions and wants to join together two of these active sessions to a so-
called three-way session, the user shall perform the following steps.
1) create a conference at the conference focus by sending an INVITE request with the conference factory URI for
the three-way session towards the conference focus, as described in subclause 5.3.1.3.2;
2) decide and perform for each of the active sessions that are requested to be joined to the three-way session, how
the remote user shall be invited to the three-way session, which can either be:
a) by performing the procedures for inviting a user to a conference by sending an REFER request to the user, as
described in subclause 5.3.1.5.2; or
b) by performing the procedures for inviting a user to a conference by sending a REFER request to the
conference focus, as described in subclause 5.3.1.5.3;
3) release the active session with the user, by applying the procedures for session release in accordance with
RFC 3261 [7], provided that a BYE request has not already been received, after a NOTIFY request has been
received, indicating that the user has successfully joined the three-way session, i.e. including:
a) a body of content-type "message/sipfrag" that indicates a "200 OK" response; and,
b) a Subscription-State header set to the value "terminated"; and,
4) treat the created three-way session as a normal conference, i.e. the conference participant shall apply the
applicable procedures of subclause 5.3.1 for it.
Reference(s)
3GPP TS 24.147 [35] clause 5.3.1.3.3.
System Simulator:
UE:
Preamble:
- The UE has registered to IMS and set up the MO voice call, by executing the generic test procedure in Annex
A.2 up to the last step and thereafter executing the generic test procedure in A.4.1.
ETSI
ETSI

U-S Message
0 UE is made to put the first call on hold. - - - -
1-4 Steps 1-4 of A.17 are used to put the first call on - Messages in Annex A.17 1 P
hold.
5 UE is made to initiate a second MTSI voice call. - - - -
6-10 Steps 1-5 of A.4.1 are performed. - Messages in in Annex 2 P
A.4.1
- EXCEPTION: Step 11-12 describes behaviour that - - - -
takes place if the UE doesn't include QOS
confirmation in the PRACK message in step 9.
11 UE sends a second SDP offer in an UPDATE --> UPDATE 2 P
request.
12 SS responds to UPDATE, including an SDP answer. <-- 200 OK 2 P
13-17 Steps 8-12 of A.4.1 are performed. - Messages in Annex A.4.1 2 P
18 UE is made to start a Multiparty Call - - - -
19-22 Steps 1-4 of A.17 are used to put the second call on - - 3 P
hold.
23-35 Steps 1-13 of A.19 are used to create a conference. - - 4 P
36 UE sends REFER to invite user A to the conference. --> REFER 5 P
(Step 1 of A.20)
37-38 SS responds with a 202 final response and NOTIFY - - - -
for the subscription created by the REFER.
(Steps 2-3 of A.20)
39 The UE responds the NOTIFY request with 200 OK. --> 200 OK 6 P
(Step 4 of A.20)
40 SS responds with a NOTIFY to confirm the user the - NOTIFY - -
invited user was able to join the conference.
(Steps 5 of A.20)
41 UE responds the NOTIFY request with 200 OK --> 200 OK 6 P
(Steps 6 of A.20)
42-43 Conditional: If the UE has subscribed to the - - - -
conference event package, then the SS sends a
NOTIFY for conference event package and UE
responds with 200 OK.
(Steps 7-8 of A.20)
44 UE sends REFER to invite user B to the conference. --> REFER 7 P
(Step 1 of A.20)
(Steps 2-3 of A.20)
47 The UE responds the NOTIFY request with 200 OK. --> 200 OK 8 P
(Step 4 of A.20)
(Steps 5 of A.20)
49 UE responds the NOTIFY request with 200 OK --> 200 OK 8 P
(Steps 6 of A.20)
50-51 Conditional: If the UE has subscribed to the - - - -
conference event package, then the SS sends a
NOTIFY for conference event package and UE
responds with 200 OK.
(Steps 7-8 of A.20)
52-53 Steps 1-2 of A.7 are used to release the first call. - - - -
54-55 Steps 1-2 of A.7 are used to release the second call. - - - -
56-57 Steps 1-2 of A.8 are used to release the active - - - -
session.
58 Conditional: If the UE has subscribed the conference <-- NOTIFY - -
event package, then the SS notifies the UE that its
subscription to conference event package is
terminated
59 Conditional: If the SS sent NOTIFY, then the UE --> 200 OK - -
sends 200 OK for NOTIFY.
(Steps 8 of A.20)
ETSI
Table 8.34.3.3-1: INVITE (Step 6, table 8.34.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in subclause A.2.1, Conditions A1, A3, A5 and A28.
Request-Line
Request-URI px_IMS_CalleeUri2
px_IMS_CalleeUri2 is used to invite another user to the

session.
px_IMS_CalleeUri2 may be either SIP or Tel URI. It may
contain a dialstring and phone-context parameter, when
calling to dialstring. When calling to dialstring SIP URI
must also contain user=phone or user=dialstring
parameter.
The dialstring, if used, may be global, home local number

or geo-local number. For home local numbers the value of
phone-context parameter must equal the home domain
name i.e. px_IMS_HomeDomainName. For geo-local
numbers the home domain name must be prefixed by
string “geo-local.” or access technology specific prefix, if
the UE supports that option.
Note: The way how the UE determines whether numbers

in a non-international format are geo-local, home-local or
relating to another network, is UE implementation specific.
For instance the UE might have a UI setting.
To
addr-spec px_IMS_CalleeUri2
Table 8.34.3.3-2: 183 Session in Progress for INVITE (Step 8, table 8.34.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in subclause A.2.3, Condition A1.

Contact
address for SS)
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.1, Condition A1, A10 and A19.
Contact

Contact
ETSI

address for SS)
Table 8.34.3.3-6: NOTIFY for conference event package (Step 58, table 8.34.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in subclause A.5.3, Conditions A1 and A4.
Contact

Contents is copied from step 6 of annex A.4.1 with the

To
Content-Type (present, if content type was present in PRACK at step 9)
Content-Length
Message-body (present, if message-body was present in PRACK at step TS 24.229 [7]
9)

ETSI
8.35 Three way session creation / Video / 5GS

(1)
with { UE being registered to IMS being configured to use preconditions and having set up an MO
video call with A }
ensure that {
when { UE is made to start a three way video call }
then { UE sends re-INVITE or UPDATE, and completes the call hold procedure with A }
}
(2)
with { UE being in the process of starting a three way video call }
ensure that {
when { UE having put A on hold }
then { UE initiates a video call with B }
}
(3)
ensure that {
when { UE having initiated a video call with B }
then { UE sends re-INVITE or UPDATE, and completes the call hold procedure with B }
}
(4)
ensure that {
when { UE having put both A and B on hold }
}
(5)
ensure that {
when { UE having created a call at the conference factory }
then { UE sends REFER to the conference focus in order to invite A }
}
(6)
with { UE having invited A to the conference video call }
ensure that {
confirmation on A and conditional conference event package }
}
(7)
ensure that {
when { UE having completed the invitation of A }
then { UE sends REFER to the conference focus in order to invite B }
}
(8)
with { UE having invited B to the conference video call }
ensure that {
confirmation on B and conditional conference event package }
ETSI

}
[TS 24.147 clause 5.3.1.3.3]:
When a user is participating in two or more SIP sessions and wants to join together two of these active sessions to a so-
called three-way session, the user shall perform the following steps.
1) create a conference at the conference focus by sending an INVITE request with the conference factory URI for
the three-way session towards the conference focus, as described in subclause 5.3.1.3.2;
2) decide and perform for each of the active sessions that are requested to be joined to the three-way session, how
the remote user shall be invited to the three-way session, which can either be:
a) by performing the procedures for inviting a user to a conference by sending an REFER request to the user, as
described in subclause 5.3.1.5.2; or
b) by performing the procedures for inviting a user to a conference by sending a REFER request to the
conference focus, as described in subclause 5.3.1.5.3;
3) release the active session with the user, by applying the procedures for session release in accordance with
RFC 3261 [7], provided that a BYE request has not already been received, after a NOTIFY request has been
received, indicating that the user has successfully joined the three-way session, i.e. including:
a) a body of content-type "message/sipfrag" that indicates a "200 OK" response; and,
b) a Subscription-State header set to the value "terminated"; and,
4) treat the created three-way session as a normal conference, i.e. the conference participant shall apply the
applicable procedures of subclause 5.3.1 for it.
System Simulator:
UE:
Preamble:
- The UE has registered to IMS and set up the MO video call, by executing the generic test procedure in Annex
A.2 up to the last step and thereafter executing the generic test procedure in A. 15.1.
ETSI
ETSI

U-S Message
0 UE is made to put the first call on hold. - - - -
1-4 Steps 1-4 of A.24 are used to put the first call on - - 1 P
hold.
5 UE is made to initiate a MTSI video call. - - - -
6-10 Steps 1-5 of A.15.1 are performed. - - 2 P
- EXCEPTION: Step 11-12 describes behaviour that - - - -
takes place if the UE doesn't include QOS
confirmation in the PRACK message in step 9.
11 UE sends a second SDP offer in an UPDATE --> UPDATE 2 P
request.
12 SS responds to UPDATE, including an SDP answer. <-- 200 OK 2 P
13-17 Steps 8-12 of A.15.1 are performed. - - 2 P
18 UE is made to start a Multiparty Call - - - -
19-22 Steps 1-4 of A.24 are used to put the second call on - - 3 P
hold.
23-35 Steps 1-13 of A.25 are used to create a conference. - - 4 P
36 UE sends REFER to invite user A to the conference. -> REFER 5 P
(Step 1 of A.26)
(Steps 2-3 of A.26)
39 The UE responds the NOTIFY request with 200 OK. -> 200 OK 6 P
(Step 4 of A.26)
(Steps 5 of A.26)
41 UE responds the NOTIFY request with 200 OK -> 200 OK 6 P
(Steps 6 of A.26)
42-43 Conditional: If the UE has subscribed the conference - - - -
event package, then the SS sends a NOTIFY for
conference event package and UE responds with
200 OK.
(Steps 7-8 of A.26)
44 UE sends REFER to invite user B to the conference. -> REFER 7 P
(Step 1 of A.26)
(Steps 2-3 of A.26)
47 The UE responds the NOTIFY request with 200 OK. -> 200 OK 8 P
(Step 4 of A.26)
(Steps 5 of A.26)
49 UE responds the NOTIFY request with 200 OK -> 200 OK 8 P
(Steps 6 of A.26)
50-51 Conditional: If the UE has subscribed the conference - - - -
event package, then the SS sends a NOTIFY for
conference event package and UE responds with
200 OK.
(Steps 7-8 of A.26)
52-53 Steps 1-2 of A.7 are used to release the first call. - - - -
54-55 Steps 1-2 of A.7 are used to release the second call. - - - -
56-57 Steps 1-2 of A.8 are used to release the active - - - -
session.
58 Conditional: If the UE has subscribed the conference <- NOTIFY - -
event package, then the SS notifies the UE that its
subscription to conference event package is
terminated
59 Conditional: If the SS sent NOTIFY, then the UE -> 200 OK - -
sends 200 OK for NOTIFY.
(Steps 8 of A.26)
ETSI
Derivation Path: TS 34.229-1 [2], Annex A.2.1, Conditions A1, A3, A4, A28, A29, A30, and A31,.
Request-Line
px_IMS_CalleeUri2 is used to invite another user to the

session.
px_IMS_CalleeUri2 may be either SIP or Tel URI. It may
contain a dialstring and phone-context parameter, when
calling to dialstring. When calling to dialstring SIP URI
must also contain user=phone or user=dialstring
parameter.
The dialstring, if used, may be global, home local

number or geo-local number. For home local numbers
the value of phone-context parameter must equal the
home domain name i.e. px_IMS_HomeDomainName.
For geo-local numbers the home domain name must be
prefixed by string “geo-local.” or access technology
specific prefix, if the UE supports that option.
Note: The way how the UE determines whether numbers

in a non-international format are geo-local, home-local or
relating to another network, is UE implementation
specific. For instance the UE might have a UI setting.
To
Derivation Path: TS 34.229-1 [2], Annex A.2.3, Condition A1.

Contact
address for SS)
Derivation Path: TS 34.229-1 [2], Annex A.3.1, Condition A1, A10 and A19.
Contact

Contact
Table 8.35.3.3-4a: 183 Session in Progress for INVITE (Step 25, table 8.35.3.2-1)

address for SS)
ETSI
Table 8.35.3.3-5: NOTIFY for conference event package (Step 58, table 8.35.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.5.3, Conditions A1 and A4.

Contact

Attributes for preconditions (Audio):

Attributes for preconditions (video):

To
Content-Type (present, if content-type was present in PRACK at step 9)
Content-Length
Message-body (present, if Message-body was present in PRACK at step TS 24.229 [7]
9)

ETSI
8.36 MO Voice Call Explicit Communication Transfer /

Consultative Call Transfer / 5GS
(1)
with { UE being registered to IMS and being configured to use preconditions and having established a
voice call with A (the transferee) }
ensure that {
when { UE is being made to attempt Consultative Call Transfer }
then { UE puts A on hold and sets up voice call with B (the transfer target) and puts B on hold
and sends REFER to the transferee }
}
(2)
with { UE having initiated consultative call transfer }
ensure that {
when { UE receives NOTIFY }
then { UE sends 200 OK response for NOTIFY }
}
(3)
with { UE having processed the NOTIFY exchange }
ensure that {
when { UE receives instruction to be put on hold by A }
then { UE processes call hold instruction and responds to it }
}
(4)
with { UE having been put on hold by A }
ensure that {
when { UE receives BYE from B }
}
(5)
with { Call with B having ended }
ensure that {
when { UE receives NOTIFY from A }
then { UE sends 200 OK for NOTIFY and may send BYE }
}
[TS 24.629, clause 4.5.2.1]:
A UE that has initiated an emergency call, shall not perform any transfer operation involving the dialog associated with
the emergency call.
A UE that initiates a transfer operation shall if the Contact address of the transferee is a GRUU:
- issue a REFER outside an existing dialog as specified in RFC 3515 [2] as updated by IETF RFC 6665 [14] and
IETF RFC 7647 [16], where:
a) the request URI shall contain the SIP URI of the transferee as received in the Contact header field:
b) the Refer-To header field shall indicate the public address of the transfer target;
c) in case of Consultative transfer, the transferor UE has a consultation communication with the transfer target,
a Replaces header field parameter shall be added to the Refer-To URI together with a Require=replaces
header field parameter;
ETSI
d) the Referred-By header field can be used to indicate the identity of the transferor. When privacy was required
in the original communications dialog and a Referred-By header field is included, the UE shall include a
Privacy header field set to "user"; and
e) the Target-Dialog header field identifies the dialog to be transferred;
otherwise the UE shall:
- issue a REFER request in the original communications dialog as specified in RFC 3515 [2], where:
a) the request URI shall contain the SIP URI of the transferee as received in the Contact header field;
b) the Refer-To header field shall indicate the public address of the transfer target;
c) in case of consultative transfer, the transferor UE has a consultation communication with the transfer target, a
Replaces header field parameter shall be added to the Refer-To URI together with a Require=replaces header
field parameter; and
d) the Referred-By header field can be used to indicate the identity of the transferor. When privacy was required
in the original communications dialog and a Referred-By header field is included, the UE shall include a
Privacy header field set to "user".
If assured transfer is requested, the UE may include an Expires header field in the Refer-To URI of the REFER request.
NOTE 1: The value of the Expires header field indicates the maximum duration of the transfer attempt. If the
transfer does not succeed within this duration, the UE will receive a NOTIFY request indicating the
transfer failure.
After the REFER request is accepted by the other end with a 2xx response, the transferor UE gets notifications of how
the transferee's communication setup towards the transfer Target is progressing.
When a NOTIFY request is received on the REFER dialog that indicates that the transferee and the transfer Target have
successfully setup a communication, the transferor UE may terminate the original communication with the transferee
UE, by sending a BYE request on the original dialog.
If an assured transfer attempt is not completed (i.e. the UE has not received a NOTIFY request with a "message/sipfrag"
body’s status line containing a final response code indicating the end of the transfer operation), the UE may request to
terminate the transfer attempt by:
- sending a REFER request in the same communications dialog as the previous REFER request as specified in
RFC 3515 [2] as updated by IETF RFC 6665 [14] and IETF RFC 7647 [16], where:
a) the request URI shall contain the SIP URI of the transferee as received in the Contact header field; and
b) the Refer-To header field shall indicate the public address of the transfer target and shall contain the method
parameter set to "CANCEL"; and
c) if applicable include a Target-Dialog header field that identifies the dialog under transfer.
If the UE receives a NOTIFY request indicating that the assured transfer attempt failed, followed by a re-INVITE or an
UPDATE request taking the UE off HOLD the UE may decide to retrieve the original communication by sending a re-
INVITE request in the original SIP dialog.
NOTE 2: If the user requests the retrieval of the original communication while the transfer attempt has not been
completed, the UE needs to first request the termination of the transfer attempt before retrieving the
original communication via a re-INVITE request.
Reference(s)
3GPP TS 24.629 [36], clause 4.5.2.1.
ETSI
System Simulator:
UE:
Preamble:
to the last step and thereafter executing the generic test procedure in A.4.1.
- The SS has accepted the UE’s MO call.
ETSI

U-S Message
1 Make the UE put the call on hold (Note 1) - - - -
with a SDP offer to hold the call with A by
running step 1 of A.17 for MO Call Hold?
3-5 Remaining steps 2-4 of A.17 for MO Call Hold - - - -
happen.
6 Void - - - -
6A Make the UE initiate a new MTSI voice call. - - - -
7 Check: Does the UE initiate a voice call with B --> INVITE 1 P
by exercising step 1 of Annex A.4.1?
8-11 Steps 2-5 of A.4.1 happen - - - -
- EXCEPTION: Step 12-13 describes behaviour - - - -
that takes place if the UE doesn't include
QOS confirmation in the PRACK message in
step 10.
12 UE sends a second SDP offer in an UPDATE --> UPDATE - -
request.
13 SS responds to UPDATE, including an SDP <-- 200 OK - -
answer.
14-18 Steps 8-12 of A.4.1 are performed. - - - -
19 Void - -
19A Make the UE confirm the Consultative Call
Transfer (Note 2)
with a SDP offer to hold the call with B by
running step 1 of A.17 for MO Call Hold?
21-23 Remaining steps 2-4 of A.17 for MO Call Hold - - - -
happen
Check: Does the UE send REFER to SS, --> REFER 1 P
24 simulating the transferee, referring to the
transfer target
25 The SS responds to REFER with 200 OK <-- 200 OK
The SS, simulating the transferee, sends <-- NOTIFY
26 initial NOTIFY for the implicit subscription
created by the REFER request
27 The UE responds to NOTIFY with 200 OK --> 200 OK 2 P
The SS, simulating the transferee, puts the - - 3 P
UE on hold by executing the MT Call Hold
28-31
procedure of Annex A.18, but setting the
direction attribute to inactive.
The SS, simulating the transfer target, <-- BYE - -
32 releases the call between UE and the transfer
target with BYE
33 The UE responds to BYE with 200 OK --> 200 OK 4 P
The SS, simulating the transferee, sends a <-- NOTIFY - -
34 NOTIFY request to confirm that the call
transfer has been completed
35 The UE responds to NOTIFY with 200 OK --> 200 OK - -
Optional: UE may send a BYE request to --> BYE - -
36
release call with the transferee within 3s.
If the UE has sent BYE in step 36 then SS <-- 200 OK 5 P
37
sends 200 OK for BYE
Note1: This could be done by e.g. MMI or AT command (AT+CHLD=2).
Note2: This could be done by e.g. MMI or AT command (AT+CHLD=4).
ETSI
Derivation Path: TS 34.229-5, Step 1 in A.4.1

Request-Line
To

Contact
address for SS)

Contact

Contact
Table 8.36.3.3-5: INVITE/UPDATE (step 20, table 8.36.3.2-1)

Request-Line
Table 8.36.3.3-6: REFER (step 24, table 8.36.3.2-1)
Derivation Path: TS 34.229-1 [2], Step 1 in A.2.10

Refer-To
value <public address of transfer target?Replaces=(dialog id of
the dialog between the UE and the transfer
target)&Require=replaces>
Referred-By
value same value as addr-spec field in From header in the first
INVITE during initial call setup, if header present
Privacy
value user (shall be included if privacy was required during
original communication dialog and Referred-By header
field is included)
ETSI
Table 8.36.3.3-7: NOTIFY (step 26, table 8.36.3.2-1)

Message-body SIP/2.0 100 Trying
Table 8.36.3.3-8: 200 OK for NOTIFY (step 27, table 8.36.3.2-1)
Derivation Path: TS 34.229-5, Step 1 of A.19

Message-body Each media line carries direction attribute “a=inactive”
Derivation Path: TS 34.229-5, Step 4 of A.19

Message-body Each media line carries direction attribute “a=inactive”
Table 8.36.3.3-11: NOTIFY (step 34, table 8.36.3.2-1)

Subscription-State
Substate-value terminated
expires omitted from request
reason noresource
Message-body SIP/2.0 200 OK
Table 8.36.3.3-12: 200 OK for NOTIFY (step 35, table 8.36.3.2-1)


ETSI
To
10)
Content-Length
10)

8.37 Communication Waiting and answering the voice call / 5Gs

(1)
with { UE being registered to IMS and having initiated an MO voice call with preconditions }
ensure that {
when { UE receives INVITE for MT voice call with preconditions }
then { UE continues voice call initiation until 180 Ringing (including conditional PRACK/200 OK)
}
}
(2)
with { UE having continued initiation of incoming voice call until 180 Ringing }
ensure that {
when { UE is being made to terminate the MO voice call }
then { UE sends BYE for the MO voice call }
}
(3)
with { UE having terminated the MO voice call }
ensure that {
when { UE is being made to accept the incoming MT voice call }
}
[TS 24.615 subclause 4.5.5.3.2]:
Upon receipt of an INVITE request containing:
- a Content-Type header field set to "application/vnd.3gpp.cw+xml";
ETSI
- a MIME body according to subclause 4.4.1 with the with the <communication-waiting-indication> element
contained in the <ims-cw> root element; and
- if the maximum number of waiting communications is not reached (i.e. UDUB condition has not occurred), the
UE shall:
- provide a CW indication to the user;
- send a 180 (Ringing) response to the INVITE request according to the provisional response procedures
described in 3GPP TS 24.229 [2];
- optionally, if the INVITE includes an Expires header field, use the value of this header field to provide the
time to expiry information of the communication waiting to the user; and
- optionally start timer TUE-CW;
NOTE 1: The timer TUE-CW is used in order to limit the duration of the CW condition at the UE. For terminals that
can provide an indication to the user that a CW condition is occurring without disturbing the active
communication, this timer is not needed.
NOTE 2: RFC 5621 [9] describes conditions under which a 415 (Unsupported Media Type) response is returned.
The UE may insert an Alert-Info header field set to "<urn:alert:service:call-waiting>" according to RFC 7462 [131] in
the 180 (Ringing) response, according to the provisional response procedures described in 3GPP TS 24.229 [2].
[TS 24.615 subclause 4.5.5.3.3]:
Case A
If user B accepts the waiting communication and holds (per procedures in 3GPP TS 24.610 [5]) or releases (per
procedures in 3GPP TS 24.229 [2]) the active communication and timer TUE-CW has not expired, user B's UE shall:
- stop timer TUE-CW (if it has been started);
- stop providing the CW indication to User B; and
- apply the procedures for answering the waiting communication to User B as described in 3GPP TS 24.229 [2].
Case B
If TUE-CW was started and expires, user B's UE shall:
- send a 480 (Temporarily Unavailable) response towards User C, optionally including a Reason header field set to
cause 19, in accordance with RFC 6432 [130].
[TS 24.615 subclause 4.5.5.3.4]:
If user B's UE receives a CANCEL request or BYE request from User C during a CW condition, user B's UE shall:
- stop timer TUE-CW (if necessary);
- apply the terminating UE procedures upon receipt of CANCEL or BYE as described in 3GPP TS 24.229 [2].
If user B's UE receives a CANCEL request or BYE request from User A and during a CW condition, user B's UE shall:
- stop providing the CW indication to User B;
- apply the terminating UE procedures upon receipt of CANCEL request or BYE request as described in 3GPP TS
24.229 [2]; and
ETSI
- optionally apply the procedure for accepting the waiting communication as described in 3GPP TS 24.229 [2].
System Simulator:
UE:
Preamble:
- The UE has registered to IMS and set up the MO voice call, by executing the generic test procedure in Annex
A.2 up to the last step and thereafter executing the generic test procedure in A.4.1.

U-S Message
1-7 Steps 1-7 of A.5.1 are executed. - - - -
8 Check: Does the UE responds to INVITE with 180 --> 180 Ringing 1 P
Ringing with an Alert-Info header field set to
"<urn:alert:service:call-waiting>"
9 (Conditional) The SS shall send PRACK only if the <-- PRACK - -
180 response contains 100rel option tag within the
Require header.
10 (Conditional) The UE acknowledges the PRACK with --> 200 OK - -
200 OK.
11 The UE is made to end the MO call - - - -
12 Check: Does the UE send a BYE to terminate its --> BYE 2 P
previous session?
(step 1 in Annex A.7)
13 The SS responds to the BYE request with a valid 200 <-- 200 OK - -
OK response.
(step 2 in Annex A.7)
14 UE is made to accept the incoming call - - - -
15 Check: Does the UE responds to INVITE with a 200 --> 200 OK 3 P
OK final response after the user answers the call.
INVITE.

address for SS)
ETSI
Table 8.37.3.3-2: UPDATE (Step 6, table 8.37.3.2-1)

address for SS)
Table 8.37.3.3-3: 180 Ringing (Step 8, table 8.37.3.2-1)

Alert-Info <urn:alert:service:call-waiting>
Table 8.37.3.3-4: PRACK (Step 9, table 8.37.3.2-1)

Content-Length
value 0
Message-body not present
Table 8.37.3.3-5: 200 OK (Step 10, table 8.37.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.3.1, Conditions A2, A11 and A20.
Table 8.37.3.3-6: 200 OK (Step 15, table 8.37.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.3.1, Conditions A1, A10 and A19.
Table 8.37.3.3-7: ACK (Step 16, table 8.37.3.2-1)
ETSI
8.38 Communication Waiting and cancelling the voice call / 5GS

(1)
with { UE being registered to IMS and having initiated an MO voice call with preconditions }
ensure that {
when { UE receives INVITE for MT voice call with preconditions }
then { UE continues voice call initiation until 180 Ringing (including conditional PRACK/200 OK)
}
}
(2)
with { UE having continued initiation of incoming voice call until 180 Ringing }
ensure that {
when { UE receives CANCEL for incoming voice call }
then { UE responds with 200 OK and 487 Request Terminated responses }
}
[TS 24.615 clause 1]:
The Communication Waiting (CW) service enables a user to be informed, that very limited resources are available for
an incoming communication. The user then has the choice of accepting, rejecting or ignoring the waiting call (as per
basic call procedures).
[TS 24.615 clause 4.2.1]:
When a communication arrives at the destination user, the UE validates the status of the user. If the user is already
involved in one or more communications, the terminal notifies the served user of a communication waiting situation.
[TS 24.615 clause 4.5.5.3.2]:
The UE shall insert an Alert-Info header field set to "<urn:alert:service:call-waiting>", specified in RFC 7462 [8] in the
180 (Ringing) response, in accordance with the provisional response procedures described in 3GPP TS 24.229.
[TS 24.615 clause 4.5.5.3.4]:
If user B's UE receives a CANCEL request or BYE request from User C during a CW condition, user B's UE shall:
- apply the terminating UE procedures upon receipt of CANCEL or BYE as described in 3GPP TS 24.229.
System Simulator:
UE:
ETSI
Preamble:
- UE is in state 1N-A, registered to IMS and has set up an MO call with preconditions, by executing the generic
test procedure in Table 4.9.15.2.2-1 of TS 38.508-1 [21].

U-S Message
1-7 MT Voice call setup takes place according to - - - -
steps 1-7 of Annex A.5.1
8 Step 8 of Annex A.5.1 happens --> 180 Ringing 1 P
9 Conditional Step: if UE sent 180 Ringing <-- PRACK - -
reliably, Step 9 of Annex A.5.1 happens
10 Conditional Step: if UE sent 180 Ringing --> 200 OK - -
reliably, Step 10 of Annex A.5.1 happens
11 SS sends CANCEL request to terminate INVITE <-- CANCEL - -
transaction
12 UE acknowledges CANCEL with 200 OK --> 200 OK - -
13 The UE responds to INVITE with a 487 Request --> 487 Request Terminated 2 P
Terminated final response after transaction was
terminated.
14 SS acknowledges the receipt of 487 Request <-- ACK - -
Terminated
16- UE releases the original MO call - - - -
17 (Annex A.7)

address for SS)
Table 8.38.3.3-2: UPDATE (Step 6, table 8.38.3.2-1)

address for SS)
Derivation path: Step 8 of Annex A.5.1

Alert-Info <urn:alert:service:call-waiting> RFC 7462 [39]
Table 8.38.3.3-4: CANCEL (step 11, table 8.38.3.2-1)
ETSI
Derivation path: TS 34.229-1 [2], Table in subclause A.3.1 applying conditions A5 and A11
Table 8.38.3.3-6: 487 Request Terminated (step 13, table 8.38.3.2-1)
Derivation path: TS 34.229-1 [2], Table in subclause A.2.7 applying conditions A2 and A4
8.39 GBA Authentication / 5GS

(1)
with { UE being registered to IMS and configured to use GBA authentication }
ensure that {
then { UE authenticates itself using GBA }
}
[TS 24.109, clause 4.2]:
becomes invalid.
sent to the UE.
ETSI
parameters:
3GPP 33.220 [1]; or
Annex C.
System Simulator:
UE:
ETSI
Preamble:

U-S Message
1 UE is made to attempt to attempt activation of - - - -
supplementary service Originating Identification
Presentation
2 UE sends an initial HTTP Request --> GET/PUT/DELETE - -
(Step 2 of A.21)
3 Conditional (according to A.21): <-- 401 Unauthorized - -
SS sends 401 Unauthorized
(Step 3a of A.21)
4 UE sends HTTP request --> GET - -
(Step 1 of A.22)
5 SS sends 401 Unauthorized <-- 401 Unauthorized - -
(Step 2 of A.22)
6 UE sends HTTP request with valid authorization --> GET 1 P
credentials
(Step 3 of A.22)
7 SS sends 200 OK <-- 200 OK - -
(Step 4 of A.22)
8 Conditional (according to A.21): --> GET/PUT/DELETE - -
UE sends HTTP request with valid authorization
credentials
(Step 3b of A.21)
9 SS sends 200 OK <-- 200 OK - -
(Step 4 of A.21)
10-14 UE and SS complete the activation of the - - - -
supplementary service and then de-activate it again
(Steps 5-9 of A.21)
None as fully specified in Annex A.21 and A.22.
8.39a HTTP Digest Authentication / 5GS

(1)
with { UE being registered to IMS and configured to use Digest authentication }
ensure that {
then { UE authenticates itself using Digest }
}
[TS 24.623, clause 5.2.3.2.1]:
ETSI
On receiving an HTTP request that does not contain an Authorization header the AS shall:
a) challenge the user by generating a 401 Unauthorized response that contains the proper Digest authentication
parameters (e.g. realm), according to IETF RFC 2617 [3]. Provisioning of credentials to authenticate the user is
outside the scope of the present document; and
b) forward the 401 Unauthorized response to the sender of the HTTP request.
On receiving an HTTP request that contains an Authorization header, the AS shall:
a) apply the authentication procedures defined in IETF RFC 2617 [3]; and
b) authorize or deny authorization depending on the authenticated identity.
System Simulator:
UE:
Preamble:

U-S Message
1 UE is made to attempt to attempt activation of - - - -
supplementary service Originating Identification
Presentation
2 UE sends an initial HTTP Request --> GET/PUT/DELETE - -
(Step 2 of A.21)
3 Conditional (according to A.21): <-- 401 Unauthorized
SS sends 401 Unauthorized
(Step 3a of A.21)
4 Conditional (according to A.21): --> GET/PUT/DELETE 1 P
UE sends HTTP request with valid authorization
credentials
(Step 3b of A.21)
5 SS sends 200 OK <-- 200 OK - -
(Step 4 of A.21)
6-10 UE and SS complete the activation of the - - - -
supplementary service and then de-activate it again
(Steps 5-9 of A.21)
8.39a.3.3 Specific message content
None as fully specified in Annex A.21.
ETSI
8.40 User initiated USSI / 5GS

(1)
ensure that {
when { UE is being made to attempt user initiated USSI }
then { UE sends INVITE with SDP and ussd+xml bodies }
}
(2)
ensure that {
when { UE receiving 100 Trying followed by 200 OK }
then { UE completes session initiation by sending ACK }
}
(3)
with { Session initiation being completed }
ensure that {
when { UE receives BYE containing ussd+xml body with ussd string and language element }
then { UE sends 200 OK response for BYE }
}
[TS 24.390, clause 4.5.1]:
In the IM CN subsystem USSD messages can be transported in SIP INFO requests, SIP INVITE requests and SIP BYE
requests, using an application/vnd.3gpp.ussd+xml MIME body.
Figure 4.1, figure 4.2, figure 4.3 and figure 4.4 give an overview of the supported USSD operations:
UE USSI AS
INVITE
------------------------------------------------------------------------------------------------------------------------>
language, ussd-String
BYE
<------------------------------------------------------------------------------------------------------------------------
language, ussd-String
BYE
<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Error
Figure 4.1: UE initiated USSD operation, network does not request further information
[TS 24.390, clause 4.5.2]:
When a UE sends an initial INVITE request, in order to establish a USSD session, it shall include an SDP offer with
one media description, according to subclause 6.1.2 of 3GPP TS 24.229 [6]. The UE shall add a zero port number value
to the media descriptions of the SDP offer, in order to inform network entities that media resources are not requested for
the session.
A pre-existing network initiated USSD session cannot be used to carry a user initiated USSD session.
ETSI
When the USSI AS sends an SDP answer, it shall also add a zero port number value to any media description received
in the associated SDP offer.
[TS 24.390, clause 4.5.3]:
If:
1) the domain selection for originating voice calls specified in 3GPP TS 23.221 [y] determines that the UE uses the
IMS to originate voice calls; and
2) the UE is not configured with HPLMN operator preference for invocation of originating USSD requests using
CS domain (e.g. see 3GPP TS 24.391 [13]);
or if the UE does not support the CS domain, then the UE can invoke the procedures in subclause 4.5.4, otherwise the
UE shall not invoke the procedures in subclause 4.5.4.
[TS 24.390, clause 4.5.4.1]:
NOTE 1: The Content-Language SIP header field is not used to determine the language of the USSD string. Only
the <language> XML element is used.
In order to send the initial USSD message, the UE shall send an initial INVITE request, according to 3GPP TS 24.229
[6]. The UE shall populate the request as follows:
1) Request-URI set to a SIP URI with user part including the USSD string and a "phone-context" parameter set to
the home network domain name used in REGISTER request according to TS 24.229 [6], a host part set to the
home network domain name used in REGISTER request as defined in TS 24.229 [6] a "user" URI parameter set
to value "dialstring" as specified in RFC 4967 [7];
2) Recv-Info header field containing the g.3gpp.ussd info-package name;
3) Accept header field containing the application/vnd.3gpp.ussd+xml, application/sdp and multipart/mixed MIME
types;
4) the Content-Type header, which shall contain "multipart/mixed";
5) SDP offer as described in subclause 4.5.2; and
6) application/vnd.3gpp.ussd+xml MIME body as described in subclause 5.1.3 with a Content-Disposition header

field set to "render" and with "handling" header field parameter set to "optional". The XML document shall
contain a single <ussd-string> element and may contain a <language> element.
When receiving a BYE request containing application/vnd.3gpp.ussd+xml MIME body, the UE shall, in addition to the
procedures specified in 3GPP TS 24.229 [6], handle the application/vnd.3gpp.ussd+xml MIME body.
NOTE 2: According to 3GPP TS 24.229 [6], the UE can receive a BYE request without the
application/vnd.3gpp.ussd+xml MIME body and in this case the dialog is terminated immediately.
When receiving a 404 (Not Found) response to INVITE request, the UE shall determine that an attempt to deliver the
USSD request using IMS fails due to missing network support.
NOTE 3: 3GPP TS 23.221 [14] gives requirements related to failure of the USSD request using IMS due to missing
network support.
[TS 24.390, clause 4.5.4.2]:
In addition to the procedures specified in this subclause, the USSI AS shall support the procedures specified in 3GPP
TS 24.229 [6] for an AS.
NOTE 1: The Content-Language SIP header field is not used to determine the language of the USSD string. Only
the <language> XML element is used.
Upon receiving an initial INVITE request with Request-URI containing the SIP URI including the USSD string and a
"user" URI parameter set to value "dialstring" as specified in RFC 4967 [7], if the application/vnd.3gpp.ussd+xml
MIME body contained in the request is accepted by the USSI AS, the USSI AS shall:
ETSI
2) send 200 (OK) response to the request following the procedures specified for AS acting as a terminating UA in
3GPP TS 24.229 [6]. The USSI AS shall populate the 200 (OK) response to the request as follows:
a) Recv-Info header field containing the g.3gpp.ussd info-package name;
b) Accept header field containing the application/vnd.3gpp.ussd+xml, application/sdp and multipart/mixed

MIME types; and
c) SDP answer as described in subclause 4.5.2.
Upon receiving an ACK request associated with the INVITE request, the USSI AS shall:
2) if the network successfully performed the USSD information and does not need any further information, send a
BYE request in order to terminate the dialog. The USSI AS shall populate the BYE request with
application/vnd.3gpp.ussd+xml MIME body, as described in subclause 5.1.3 including a <ussd-string> element
and a <language> element; and
3) if the network informs the UE that the network is unable to process the USSD request or the network informs the
UE that the network rejects the USSD request, send a BYE request in order to terminate the dialog. The USSI
AS shall populate the BYE request with application/vnd.3gpp.ussd+xml MIME body, as described in subclause
5.1.3, including, a <error-code> element.
System Simulator:
UE:
Preamble:
- The UE has registered to IMS, by executing the generic test procedure in Annex A.2 up to the last step.

U-S Message
1 Make the UE attempt an user initiated USSI with - - - -
USSD string “*#60#”.
2 Check: Does the UE send INVITE message? --> INVITE 1 P
3 SS sends a 100 Trying provisional response. <-- 100 Trying - -
4 SS sends a 200 OK. <-- 200 OK - -
5 Check: Does the acknowledge reception of 200 OK --> ACK 2 P
6 SS sends BYE to release the session. <-- BYE - -
7 Check: Does the UE sends 200 OK for BYE --> 200 OK 3 P
ETSI

Request-Line
Request-URI Request-URI set to a SIP URI with user part including
the percent-encoded USSD string as used at step 1 and
a "phone-context" parameter set to the home network
domain name used in REGISTER request, a host part
set to the home network domain name used in
REGISTER request and a "user" URI parameter set to
value "dialstring"
Note: In USSD string *#60#, * may or may not be
percent-encoded.
To
addr-spec same as Request URI
tag not present
Supported
option-tag timer – may or may not be present RFC 4028 [37]
Note: this does not affect regulation of any other option-
tags in the Supported header
Recv-Info
Info-package- g.3gpp.ussd
type
Accept application/vnd.3gpp.ussd+xml, application/sdp,
multipart/mixed
(additional medias can be added in any order)
Content-Type
media-type multipart/mixed;boundary=any value
--boundary value (as provided in SIP hdr Content-Type)

Content-Type: application/sdp
v=0
s=(session name)
Time description:
Media description:
m=(media) 0 [Note2]
--boundary value (as provided in SIP hdr Content-Type)

Content-Type: application/vnd.3gpp.ussd+xml
<?xml version="1.0" encoding="UTF-8"?>
<ussd-data>
<language>(language)</language> [Note 3]
<ussd-string>( USSD string as used at step 1)</ussd-
string>
</ussd-data>
--boundary value-- (as provided in SIP hdr Content-Type)

Note 2: media is the type of media like audio.
Note 3: language is the type of USSD language coded
as defined in IETF RFC 5646 [153]
ETSI
Table 8.40.3.3-1A: 100 Trying (Step 3, table 8.40.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.2.2, condition A1.
Derivation Path: TS 34.229-1 [2], Annex A.3.1, conditions A1, A10, and A19
Recv-Info
Info-package- g.3gpp.ussd
type
Accept application/vnd.3gpp.ussd+xml, application/sdp,
multipart/mixed MIME types
Content-Type
Message-body SDP body of the 200 response copied from the received
INVITE and modified as follows:
- o=- 1111111111 1111111111 IN (addrtype) (unicast-

address for SS)
- IP address on "c=" line changed to indicate to which

IP address and port the UE should start sending the
media;
- "a=" lines are all removed.
Table 8.40.3.3-2A: ACK (Step 5, table 8.40.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.2.7, conditions A1 and A3.
Table 8.40.3.3-3: BYE (Step 6, table 8.40.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.2.8.

Content-Type
media-type application/vnd.3gpp.ussd+xml
Message-body <?xml version="1.0" encoding="UTF-8"?>
<ussd-data>
<language>en</language>
<ussd-string>148*7#</ussd-string>
</ussd-data>
Table 8.40.3.3-4: 200 OK for BYE (Step 7, table 8.40.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.3.1, conditions A5, A8, and A22.
8.41 Communication Forwarding on No Reply: MO Voice Call

initiation with preconditions
(1)
with { UE being registered to IMS and configured to use preconditions and being made to initiate a
voice call }
ensure that {
when { Voice call initiation progressed until 180 Ringing (including PRACK/200 OK) and UE receives
181 Call is being forwarded followed by 183 Session Progress }
ETSI
then { UE completes call initiation with forwarded to UE by restarting from PRACK for 183 Session
Progress }
}
[TS 24.604, clause 4.2.1.4]:
The CFNR service enables a served user to have the network redirect to another user communications which are
addressed to the served user's address, and for which the connection is not established within a defined period of time.
The CFNR service may operate on all communications, or just those associated with specified services. The served
user's ability to originate communications is unaffected by the CFNR supplementary service.
The CFNR service can only be invoked by the network after the communication has been offered to the served user and
an indication that the called user is being informed of the communication has been received.
[TS 24.604, clause 4.5.2.1]:
When communication diversion has occurred on the served user side and the network option "Originating" user
receives notification that his communication has been diverted (forwarded or deflected)" is set to true, the originating
UA may receive a 181 (Call is being forwarded) response according to the procedures described in 3GPP TS 24.229.
The Information given by the History header could be displayed by the UA if it is a UE.
[TS 24.229, clause 9.2.3]:
Since the UE does not know that forking has occurred until a second provisional response arrives, the UE will request
the radio/bearer resources as required by the first provisional response. For each subsequent provisional response that
may be received, different alternative actions may be performed depending on the requirements in the SDP answer:
- the UE has sufficient radio/bearer resources to handle the media specified in the SDP of the subsequent
provisional response, or
- the UE must request additional radio/bearer resources to accommodate the media specified in the SDP of the
subsequent provisional response.
NOTE 1: When several forked responses are received, the resources requested by the UE is the "logical OR" of the
resources indicated in the multiple responses to avoid allocation of unnecessary resources. The UE does
not request more resources than proposed in the original INVITE request.
NOTE 2: When service-based local policy is applied, the UE receives the same authorization token for all forked
requests/responses related to the same SIP session.
When an 199 (Early Dialog Terminated) response for the INVITE request is received for an early dialogue, the UE shall
release reserved radio/bearer resources associated with that early dialogue.
When the first final 200 (OK) response for the INVITE request is received for one of the early dialogues, the UE
proceeds to set up the SIP session using the radio/bearer resources required for this session. Upon the reception of the
first final 200 (OK) response for the INVITE request, the UE shall release all unneeded radio/bearer resources.
GIBA:
NOTE 1: GIBA does not allow SIP requests to be protected using an IPsec security association because it does not
perform a key agreement procedure.
System Simulator:
ETSI
UE:
Preamble:

U-S Message
2-7 Steps 2-7 of generic procedure specified in Table - - - -
- EXCEPTION: In parallel with Step 8-12, parallel - - - -
8-12 Steps 1-5 as defined in Annex A.4.1a are executed. - - - -
12B- Steps 11-12 of generic procedure specified in Table - - - -
13-17 Steps 6-10 of Annex A.4.1a happen. - - - -
18 SS sends 181 response to indicate that call <-- 181 Call is being forwarded - -
forwarding has been started as the user did not
answer to the phone
19 SS (simulating the phone to which the call was <-- 183 Session Progress - -
forwarded) responds with 183 Session Progress
containing an SDP answer indicating support for
AMR-WB codec and state of the local preconditions.
20 Check: Does the UE send PRACK for 183 Session -->  PRACK 1 P
Progress containing an SDP offer for negotiation with
the UE which the call was forwarded to?
21 SS responds to PRACK containing an SDP answer. <--  200 OK
22 The SS sends 180 Ringing response to the UE <-- 180 Ringing - -
23 UE acknowledges the receipt of 180 response by --> PRACK - -
sending PRACK.
24 The SS responds PRACK with 200 OK. <-- 200 OK - -
25 The SS responds INVITE with 200 OK to indicate <-- 200 OK - -
that the virtual remote UE had answered the call
26 The UE acknowledges the receipt of 200 OK for --> ACK - -
INVITE
28-29 Steps 1-2 in Annex A.7 are performed. - - - -

U-S Message
ETSI
Table 8.41.3.3-1: 181 Call is being forwarded for INVITE (Step 18, table 8.41.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.2.14.
Table 8.41.3.3-2: 183 Session Progress for INVITE (Step 19, table 8.41.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.2.3, condition A1

To
tag different tag must be used than the one used in steps 8-
17 as this response is now from another UE and belongs
to another dialog instance. Note that this new tag must
be used within the rest of the steps (18-29) in this test
case instead of the tag used within steps 8-17
Contact
addr-spec different URI must be used than the one used in step 9
as this is supposed now to represent another UE to
which the call is being forwarded. Note that this new
Contact must be used within the rest of the steps (20-21)
in this test case.
Require
Message-body Same contents as specified in step 3 annex A.4.1a RFC 4566 [38]
except for o-line:
address for new remote UE).
Table 8.41.3.3-3: PRACK (Step 20, table 8.41.3.2-1)
Derivation Path: Annex A.4.1a, step 6 UPDATE with o-line not being checked
Table 8.41.3.3-4: 200 OK for PRACK (Step 21 and 24, table 8.41.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.3.1, conditions A10 and A22
Require
Content-Type
Content-Length
Message-body SDP body of the 200 response copied from the received
PRACK and modified as follows:
- IP address on "c=" lines and transport port on "m="

lines changed to indicate to which IP address and port
the UE should start sending the media;
- Attributes for preconditions: a=curr:qos remote
sendrecv
ETSI
Derivation Path: TS 34.229-1 [2], Annex A.2.4 with conditions A1 and A7

Contact
addr-spec Same value as in the 183 response of step 19
History-Info
uri
Table 8.41.3.3-5a: PRACK (Step 23, table 8.41.3.2-1)
Derivation Path: Annex A.4.1a, step 9.
Derivation Path: TS 34.229-1 [2], Annex A.3.1, conditions A1, A10, and A19
Contact
addr-spec Same value as in the 183 response of step 19
History-Info
uri
Table 8.41.3.3-7: ACK (Step 26, table 8.41.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.2.7, conditions A1
ETSI
9 SMS
9.1 Mobile Originating SMS / 5GS

(1)
ensure that {
when { UE is made to send an SMS over IP }
then { UE sends a SIP MESSAGE request containing a short message }
}
(2)
with { UE having sent a SIP MESSAGE request containing a short message }
ensure that {
when { UE receives a 202 Accepted response, followed by a SIP MESSAGE request containing a
submission report }
then { UE sends a 200 OK response }
}
(3)
with { UE having sent a 200 OK response for submission report }
ensure that {
when { UE receives a SIP MESSAGE request containing a status report }
then { UE sends a 200 OK response, followed by a SIP MESSAGE request containing a delivery
report for status report }
}
[TS 24.341, clause 5.3.1.2]:
When an SM-over-IP sender wants to submit an SM over IP, the SM-over-IP sender shall send a SIP MESSAGE
request with the following information:
a) the Request-URI, which shall contain the PSI of the SC of the SM-over-IP sender;
NOTE 1: The PSI of the SC can be SIP URI or tel URI based on operator policy. The PSI of the SC can be obtained
using one of the following methods in the priority order listed below:
1) provided by the user;
2) if UICC is used, then:
- if present in the ISIM, then the PSI of the SC is obtained from the EFPSISMSC in DF_TELECOM of
the ISIM as per 3GPP TS 31.103 [18];
- if not present on the ISIM, then the PSI of the SC is obtained from the EFPSISMSC in
DF_TELECOM of the USIM as per 3GPP TS 31.102 [19]; or
- if neither present on the ISIM nor on the USIM, then the PSI of the SC contains the TS-Service-
Centre-Address stored in the EFSMSP in DF_TELECOM as per 3GPP TS 31.102 [19]. If the PSI of
the SC is based on the E.164 number from the TS-Service-Centre-Address stored in the EFSMSP in
DF_TELECOM then the URI constructed can be either a tel URI or a SIP URI (using the
"user=phone" SIP URI parameter format).
3) if SIM is used instead of UICC, then the PSI of the SC contains the TS-Service Centre Address stored
in the EFSMSP in DF_TELECOM as per 3GPP TS 51.011 [20]. If the PSI of the SC is based on the
ETSI
E.164 number from the TS-Service-Centre-Address stored in the EFSMSP in DF_TELECOM then the
URI constructed can be either a tel URI or a SIP URI (using the "user=phone" SIP URI parameter
format); or
4) if neither the UICC nor SIM is used, then how the PSI of the SC is configured and obtained is through
means outside the scope of this specification.
b) the From header, which shall contain a public user identity of the SM-over-IP sender;
NOTE 2: The IP-SM-GW will have to use an address of the SM-over-IP sender that the SC can process (i.e. an
E.164 number). This address will come from a tel URI in a P-Asserted-Identity header (as defined in
RFC 3325 [13]) placed in the SIP MESSAGE request by the P-CSCF or S-CSCF.
NOTE 3: The SM-over-IP sender has to store the Call-ID of the SIP MESSAGE request, so it can associate the
appropriate SIP MESSAGE request including a submit report with it.
c) the To header, which shall contain the SC of the SM-over-IP sender;
d) the Content-Type header, which shall contain "application/vnd.3gpp.sms"; and
e) the body of the request shall contain an RP-DATA message as defined in 3GPP TS 24.011 [8], including the
SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3].
NOTE 4: The address of the SC is included in the RP-DATA message content. The address of the SC included in
the RP-DATA message content is stored in the EFSMSP in DF_TELECOM of the (U)SIM of the SM-over-
IP sender.
NOTE 5: The SM-over-IP sender will use content transfer encoding of type "binary" for the encoding of the SM in
the body of the SIP MESSAGE request.
NOTE 6: Both the address of the SC and the PSI of the SC can be configured in the EFPSISMSC in DF_TELECOM of
the USIM and ISIM respectively using the USAT as per 3GPP TS 31.111 [21].
The SM-over-IP sender may request the SC to return the status of the submitted message. The support of status report
capabilities is optional for the SC.
When a SIP MESSAGE request including a submit report in the "vnd.3gpp.sms" payload is received, the SM-over-IP
sender shall:
- if SM-over-IP sender supports In-Reply-To header usage and the In-Reply-To header indicates that the request
corresponds to a short message submitted by the SM-over-IP sender, generate a 200 (OK) SIP response
according to RFC 3428 [14].
if SM-over-IP sender supports In-Reply-To header usage and the In-Reply-To header indicates that the request
does not correspond to a short message submitted by the SM-over-IP sender, a 488 (Not Acceptable here) SIP
response according to RFC 3428 [14].
- if SM-over-IP sender does not support In-Reply-To header usage, generate a 200 (OK) SIP response according
to RFC 3428 [14]; and extract the payload encoded according to 3GPP TS 24.011 [8] for RP-ACK or RP-
ERROR.
[TS 24.341 clause 5.3.1.3]:
When a SIP MESSAGE request including a status report in the "vnd.3gpp.sms" payload is delivered, the SM-over-IP
sender shall:
- generate a SIP response according to RFC 3428 [14];
- extract the payload encoded according to 3GPP TS 24.011 [8] for RP-DATA; and
- create a delivery report for the status report as described in subclause 5.3.2.4. The content of the delivery report
is defined in 3GPP TS 24.011 [8].
[TS 24.341 clause 5.3.2.4]:
ETSI
When an SM-over-IP receiver wants to send an SM delivery report over IP, the SM-over-IP receiver shall send a SIP
MESSAGE request with the following information:
a) the Request-URI, which shall contain the IP-SM-GW;
NOTE 1: The address of the IP-SM-GW is received in the P-Asserted-Identity header in the SIP MESSAGE
request including the delivered short message.
b) the From header, which shall contain a public user identity of the SM-over-IP receiver.
c) the To header, which shall contain the IP-SM-GW;
b) the Content-Type header shall contain "application/vnd.3gpp.sms"; and
c) the body of the request shall contain the RP-ACK or RP-ERROR message for the SM delivery report, as defined
in 3GPP TS 24.011 [8].
System Simulator:
UE:
Preamble:
ETSI

U-S Message
1 UE is made to attempt a Mobile Originating - - - -
SMS over IMS
1F Table 4.9.19.2.2-1 of TS 38.508-1 [21] are
performed.
2 Check: Does UE send a SIP MESSAGE --> SIP MESSAGE 1 P
request including a vnd.3gpp.sms payload that
contains a short message?
3 SS responds with 202 Accepted <-- 202 Accepted - -
4 SS sends a SIP MESSAGE request including a <-- SIP MESSAGE - -
vnd.3gpp.sms payload that contains the short
message submission report indicating a positive
acknowledgement of the short message sent by
the UE at Step 2
5 Check: Does UE respond with 200 OK? --> 200 OK 2 P
6 SS sends a SIP MESSAGE request including a <-- SIP MESSAGE - -
vnd.3gpp.sms payload that contains a status
report
7 Check: Does UE respond with 200 OK? --> 200 OK 3 P
8 Check: Does UE send a SIP MESSAGE --> SIP MESSAGE 3 P
request including a vnd.3gpp.sms payload that
contains an acknowledgement for the status
report received at Step 6?
9 SS responds with 202 Accepted <-- 202 Accepted - -

U-S Message
Table 9.1.3.3-1: SIP MESSAGE (step 2, table 9.1.3.2-1)
Table 9.1.3.3-2: 202 Accepted (step 3 and 9, table 9.1.3.2-1)
Table 9.1.3.3-4: 200 OK (step 5 and 7, table 9.1.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.1, Condition A5 and A22
ETSI
Table 9.1.3.3-5: SIP MESSAGE (step6, table 9.1.3.2-1)
ETSI
9.2 Mobile Terminating SMS / 5GS

(1)
ensure that {
when { UE receives a SIP MESSAGE request containing a short message }
report }
}
[TS 24.341, clause 5.3.2.3]
When a SIP MESSAGE request including a short message in the "vnd.3gpp.sms" payload is delivered, the SM-over-IP
receiver shall:
- generate a SIP response according to RFC 3428;
- extract the payload encoded according to 3GPP TS 24.011 for RP-DATA; and
- create a delivery report as described in subclause 5.3.2.4. The content of the report is defined in
3GPP TS 24.011.
[TS 24.341, clause 5.3.2.4]
in 3GPP TS 24.011 [8].
System Simulator:
UE:
ETSI
Preamble:

U-S Message
0H Table 4.9.20.2.2-1 of TS 38.508-1 [21] are
performed.
1 The SS sends a Short Message. <-- SIP MESSAGE - -
2 Check: Does the UE send a 200 OK response? --> 200 OK 1 P
3 Check: Does the UE respond with a delivery --> SIP MESSAGE 1 P
report?
4 The SS sends a 202 ACCEPTED response. <-- 202 ACCEPTED - -
Table 9.2.3.3-2: 200 OK (step 2 table 9.2.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.1, Condition A5 and A22
Table 9.2.3.3-4: 202 Accepted (step 4, table 9.2.3.2-1)
ETSI
9.3 Mobile Originating Concatenated SMS / 5GS

(1)
ensure that {
when { UE is made to send a concatenated SMS over IP }
then { UE sends a SIP MESSAGE request containing the first segment of the concatenated SMS }
}
(2)
with { UE having sent a SIP MESSAGE request containing the first segment of the concatenated SMS }
ensure that {
submission report for the first segment }
then { UE sends a 200 OK response, followed by a SIP MESSAGE request containing the second
segment of the concatenated SMS }
}
(3)
with { UE having sent a SIP MESSAGE request containing the second segment of the concatenated SMS }
ensure that {
submission report for the second segment }
then { UE sends a 200 OK response, followed by a SIP MESSAGE request containing the third segment
of the concatenated SMS }
}
(4)
with { UE having sent a SIP MESSAGE request containing the third segment of the concatenated SMS }
ensure that {
submission report for the third segment }
}
[TS 23.040, clause 9.2.3.23]:
The TP-User-Data-Header-Indicator is a 1 bit field within bit 6 of the first octet of the following six PDUs:
- SMS-SUBMIT,
- SMS-SUBMIT-REPORT,
- SMS-DELIVER,
- SMS-DELIVER-REPORT,
- SMS-STATUS-REPORT,
- SMS-COMMAND.
TP-UDHI has the following values.
Bit no. 6 0 The TP-UD field contains only the short message
1 The beginning of the TP-UD field contains a Header in addition to the short message.
[TS 23.040, clause 9.2.3.24]:
ETSI
The length of the TP-User-Data field is defined in the PDU’s of the SM-TL (see clause 9.2.2).
The TP-User-Data field may comprise just the short message itself or a Header in addition to the short message
depending upon the setting of TP-UDHI.
Where the TP-UDHI value is set to 0 the TP-User-Data field comprises the short message only, where the user data can
be 7 bit (default alphabet) data, 8 bit data, or 16 bit (UCS2 [24]) data.
Where the TP-UDHI value is set to 1 the first octets of the TP-User-Data field contains a Header in the following order
starting at the first octet of the TP-User-Data field.
Irrespective of whether any part of the User Data Header is ignored or discarded, the MS shall always store the entire
TPDU exactly as received.
FIELD LENGTH
Length of User Data Header 1 octet
Information-Element-Identifier "A" 1 octet
Length of Information-Element "A" 1 octet
Information-Element "A" Data 0 to "n" octets
Information-Element-Identifier "B" 1 octet
Length of Information-Element "B" 1 octet
Information-Element "B" Data 0 to "n" octets
Information-Element-Identifier "X" 1 octet
Length of Information-Element "X" 1 octet
Information-Element "X" Data 0 to "n" octets
The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for uncompressed GSM 7 bit
default alphabet data. The UDHL field is the first octet of the TP-User-Data content of the Short Message.
Octets Octets
UDL UDHL IEIa IEIDLa IEDa IEIb ......... IEIn IEDLn IEDn Fill bits SM (7bit data)
Total number of Octets Septet Boundary
Length Indicator
Total number of Septets
Length Indicator
Figure 9.2.3.24 (a)
The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for uncompressed 8 bit data or
uncompressed UCS2 data. The UDHL field is the first octet of the TP-User-Data content of the Short Message.
ETSI
Octets Octets
UDL UDHL IEIa IEIDLa SM (8 bit data

IEDa IEIb ......... IEIn IEDLn IEDn
or UCS-2 data)
Total number of Octets Octet Boundary
Length Indicator
Total number of Octets
Length Indicator
Figure 9.2.3.24 (b)
The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for compressed GSM 7 bit
default alphabet data, compressed 8 bit data or compressed UCS2 data. The UDHL field is the first octet of the
TP-User-Data content of the Short Message.
Octets Octets
UDL UDHL IEIa IEIDLa IEDa IEIb ......... IEIn IEDLn IEDn Compressed SM (octets)
Length Indicator
Length Indicator
Figure 9.2.3.24 (c)
The definition of the TP-User-Data-Length field which immediately precedes the "Length of User Data Header" is
unchanged and shall therefore be the total length of the TP-User-Data field including the Header, if present. (see
9.2.3.16).
The "Length-of-Information-Element" fields shall be the integer representation of the number of octets within its
associated "Information-Element-Data" field which follows and shall not include itself in its count value.
The "Length-of-User-Data-Header" field shall be the integer representation of the number of octets within the
"User-Data-Header" information fields which follow and shall not include itself in its count or any fill bits which may
be present (see text below).
Information Elements may appear in any order and need not follow the order used in the present document. Information
Elements are classified into 3 categories as described below.
ETSI
- SMS Control – identifies those IEIs which have the capability of dictating SMS functionality.
- EMS Control – identifies those IEIs which manage EMS Content IEIs.
- EMS Content – identifies those IEIs containing data of a unique media format.
It is permissible for certain IEs to be repeated within a short message, or within a concatenated message. There is no
restriction on the repeatability of IEs in the EMS Content classification. The repeatability of SMS Control and EMS
Control IEs is determined on an individual basis. See the IE table below for the repeatability of each IE.
In the event that IEs determined as not repeatable are duplicated, the last occurrence of the IE shall be used. In the event
that two or more IEs occur which have mutually exclusive meanings (e.g. an 8bit port address and a 16bit port address),
then the last occurring IE shall be used.
If the length of the User Data Header is such that there are too few or too many octets in the final Information Element
then the whole User Data Header shall be ignored.
If any reserved values are received within the content of any Information Element then that part of the Information
Element shall be ignored.
The support of any Information Element Identifier is optional unless otherwise stated.
ETSI
The Information Element Identifier octet shall be coded as follows:
VALUE MEANING Classification Repeatability

(hex)
00 Concatenated short messages, 8-bit reference number SMS Control No
01 Special SMS Message Indication SMS Control Yes
02 Reserved N/A N/A
03 Value not used to avoid misinterpretation as <LF> character N/A N/A
04 Application port addressing scheme, 8 bit address SMS Control No
06 SMSC Control Parameters SMS Control No
07 UDH Source Indicator SMS Control Yes
08 Concatenated short message, 16-bit reference number SMS Control No
09 Wireless Control Message Protocol SMS Control Note 3
0A Text Formatting EMS Control Yes
0B Predefined Sound EMS Content Yes
0C User Defined Sound (iMelody max 128 bytes) EMS Content Yes
0D Predefined Animation EMS Content Yes
0E Large Animation (16*16 times 4 = 32*4 =128 bytes) EMS Content Yes
0F Small Animation (8*8 times 4 = 8*4 =32 bytes) EMS Content Yes
10 Large Picture (32*32 = 128 bytes) EMS Content Yes
11 Small Picture (16*16 = 32 bytes) EMS Content Yes
12 Variable Picture EMS Content Yes
13 User prompt indicator EMS Control Yes
14 Extended Object EMS Content Yes
15 Reused Extended Object EMS Control Yes
16 Compression Control EMS Control No
17 Object Distribution Indicator EMS Control Yes
18 Standard WVG object EMS Content Yes
19 Character Size WVG object EMS Content Yes
1A Extended Object Data Request Command EMS Control No
1B-1F Reserved for future EMS features (see subclause 3.10) N/A N/A
20 RFC 5322 E-Mail Header SMS Control No
21 Hyperlink format element SMS Control Yes
22 Reply Address Element SMS Control No
23 Enhanced Voice Mail Information SMS Control No
24 National Language Single Shift SMS Control No
25 National Language Locking Shift SMS Control No
26 – 6F Reserved for future use N/A N/A
70 – 7F (U)SIM Toolkit Security Headers SMS Control Note 1
80 – 9F SME to SME specific use SMS Control Note 2
A0 – BF Reserved for future use N/A N/A
C0 – DF SC specific use SMS Control Note 2
E0 – FF Reserved for future use N/A N/A
Note 1: The functionality of these IEIs is defined in 3GPP TSG 31.115 [28], and therefore, the repeatability
is not within the scope of this document and will not be determined here.
Note 2: The functionality of these IEIs is used in a proprietary fashion by different SMSC vendors, and
therefore, are not within the scope of this technical specification.
Note 3: The functionality of these IEIs is defined by the WAP Forum and therefore the repeatability is not
within the scope of this document and will not be determined here.
A receiving entity shall ignore (i.e. skip over and commence processing at the next information element) any
information element where the IEI is Reserved or not supported. The receiving entity calculates the start of the next
information element by looking at the length of the current information element and skipping that number of octets.
The SM itself may be coded as 7, 8 or 16 bit data.
If 7 bit data is used and the TP-UD-Header does not finish on a septet boundary then fill bits are inserted after the last
Information Element Data octet up to the next septet boundary so that there is an integral number of septets for the
entire TP-UD header. This is to ensure that the SM itself starts on an septet boundary so that an earlier Phase mobile
shall be capable of displaying the SM itself although the TP-UD Header in the TP-UD field may not be understood.
ETSI
It is optional to make the first character of the SM itself a Carriage Return character encoded according to the default 7
bit alphabet so that earlier Phase mobiles, which do not understand the TP-UD-Header, shall over-write the displayed
TP-UD-Header with the SM itself.
If 16 bit (USC2) data is used then padding octets are not necessary. The SM itself shall start on an octet boundary.
If 8 bit data is used then padding is not necessary. An earlier Phase mobile shall be able to display the SM itself
although the TP-UD header may not be understood.
It is also possible for mobiles not wishing to support the TP-UD header to check the value of the TP-UDHI bit in the
SMS-Deliver PDU and the first octet of the TP-UD field and skip to the start of the SM and ignore the TP-UD header.
[TS 23.040, clause 9.2.3.24.1]:
This facility allows short messages to be concatenated to form a longer message.
In the case of uncompressed 8-bit data, the maximum length of the short message within the TP-UD field is 134 (140-6)
octets.
In the case of uncompressed GSM 7 bit default alphabet data, the maximum length of the short message within the
TP-UD field is 153 (160-7) characters. A character represented by an escape-sequence shall not be split in the middle.
In the case of 16 bit uncompressed USC2 data, the maximum length of the short message within the TP-UD field is 67
((140-6)/2) characters. A UCS2 character shall not be split in the middle; if the length of the User Data Header is odd,
the maximum length of the whole TP-UD field is 139 octets.
In the case of compressed GSM 7 bit default alphabet data, 8 bit data or UCS2 the maximum length of the compressed
short message within the TP-UD field is 134 (140-6) octets including the Compression Header and Compression Footer,
both or either of which may be present (see clause 3.9).
The maximum length of an uncompressed concatenated short message is 39015 (255*153) default alphabet characters,
34170 (255*134) octets or 17085 (255*67) UCS2 characters.
The maximum length of a compressed concatenated message is 34170 (255*134) octets including the Compression
Header and Compression Footer (see clause 3.9 and figure 9.2.3.24.1(a) below).
Compression Header Compressed Data (CD) Compression Footer
Segmentation / De-segmentation
TP-UDH CH CD TP-UDH CD TP-UDH CD CF
First segment Intermediate segments Final segment
Figure 9.2.3.24.1 (a): Concatenation of a Compressed short message
The Information-Element-Data field contains information set by the application in the SMS-SUBMIT so that the
receiving entity is able to re-assemble the short messages in the correct order. Each concatenated short message
contains a reference number which together with the originating address and Service Centre address allows the
receiving entity to discriminate between concatenated short messages sent from different originating SMEs and/or SCs.
In a network which has multiple SCs, it is possible for different segments of a concatenated SM to be sent via different
SCs and so it is recommended that the SC address should not be checked by the MS unless the application specifically
requires such a check.
The TP elements in the SMS-SUBMIT PDU, apart from TP-MR, TP-SRR, TP-UDL and TP-UD, should remain
unchanged for each SM which forms part of a concatenated SM, otherwise this may lead to irrational behaviour. TP-
MR must be incremented for every segment of a concatenated message as defined in clause 9.2.3.6. A SC shall handle
segments of a concatenated message like any other short message. The relation between segments of a concatenated
message is made only at the originator, where the message is segmented, and at the recipient, where the message is
reassembled. SMS-COMMANDs identify messages by TP-MR and therefore apply to only one segment of a
ETSI
concatenated message. It is up to the originating SME to issue SMS-COMMANDs for all the required segments of a
concatenated message.
The Information-Element-Data octets shall be coded as follows.
Octet 1 Concatenated short message reference number.
This octet shall contain a modulo 256 counter indicating the reference number for a particular
concatenated short message. This reference number shall remain constant for every short message which
makes up a particular concatenated short message.
Octet 2 Maximum number of short messages in the concatenated short message.
This octet shall contain a value in the range 0 to 255 indicating the total number of short messages within
the concatenated short message. The value shall start at 1 and remain constant for every short message
which makes up the concatenated short message. If the value is zero then the receiving entity shall ignore
the whole Information Element.
Octet 3 Sequence number of the current short message.
This octet shall contain a value in the range 0 to 255 indicating the sequence number of a particular short
message within the concatenated short message. The value shall start at 1 and increment by one for every
short message sent within the concatenated short message. If the value is zero or the value is greater than
the value in octet 2 then the receiving entity shall ignore the whole Information Element.
The IEI and associated IEI length and IEI data shall be present in every segment of the concatenated SM.
[TS 24.341, clause 5.3.2.3]
receiver shall:
- generate a SIP response according to RFC 3428;
- extract the payload encoded according to 3GPP TS 24.011 for RP-DATA; and
3GPP TS 24.011.
[TS 24.341, clause 5.3.2.4]
in 3GPP TS 24.011 [8].
ETSI
System Simulator:
UE:
- SMS over IP is enabled.
Preamble:
ETSI

U-S Message
1 UE is made to send a Concatenated SMS - - - -
over IP (The length of SMS text is determined
so that the amount of segments of the
concatenated SMS is three).
Table 4.9.19.2.2-1 of TS 38.508-1 [21] are
performed.
place
2 Check: Does the UE send a SIP MESSAGE --> SIP MESSAGE request 1 P
request including a vnd.3gpp.sms payload
that contains the first segment of the
concatenated SMS?
3 SS responds with 202 Accepted. <-- 202 Accepted - -
4 SS sends a SIP MESSAGE request including <-- SIP MESSAGE request - -
a vnd.3gpp.sms payload that contains the
short message submission report indicating a
positive acknowledgement of the first
segment of the concatenated SMS sent by
the UE at Step 2.
that contains the second segment of the
concatenated SMS?
positive acknowledgement of the second
the UE at Step 6.
that contains the final segment of the
concatenated SMS?
positive acknowledgement of the final
the UE at Step 10.

U-S Message
ETSI
Table 9.3.3.3-1: MESSAGE for MO SMS (step 2, table 9.3.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in annex A.7.3

Message-body - TP-UDHI=’1’B (The beginning of the TP UD field TS 24.011 [25]
contains a Header in addition to the short message.) TS 23.040 [24]
- TP-MR=any allowed value
- TP-UD
- Length of User Data Header (UDHL)=5
- Information Element Identifier (IEI)=0x00
(Concatenated short messages, 8-bit reference number)
- Length of Information Element (IEIDL)=3
- Concatenated short message reference number=any
allowed value
- Maximum number of short messages in the
concatenated short message=3
- Sequence number of the current short message=1
Table 9.3.3.3-2: 202 ACCEPTED (step 3, table 9.3.3.2-1)
Table 9.3.3.3-3: Short message submission report for MO SMS (step 4, table 9.3.3.2-1)
Table 9.3.3.3-4: 200 OK for other requests than REGISTER or SUBSCRIBE (step 5, table 9.3.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.1, Condition A5, A22

- TP-MR= The value sent in the step1 + 1 (incremented)
- TP-UD
- Concatenated short message reference number=
The same value sent in the step1
ETSI

- TP-MR= The value sent in the step5 + 1 (incremented)
- TP-UD
- Concatenated short message reference number=
The same value sent in the step5
ETSI
9.4 Mobile Terminating Concatenated SMS / 5GS

(1)
ensure that {
when { UE receives a SIP MESSAGE request containing a first segment of a concatenated SMS }
then { UE sends a 200 OK response, followed by a SIP MESSAGE request containing a delivery report
for the first segment }
}
(2)
with { UE having sent a SIP MESSAGE request containing a delivery report for the first segment }
ensure that {
when { UE receives a 202 Accepted response, followed by a SIP MESSAGE request containing a second
segment of a concatenated SMS }
report for the second segment }
}
(3)
with { UE having sent a SIP MESSAGE request containing a delivery report for the second segment }
ensure that {
when { UE receives a 202 Accepted response, followed by a SIP MESSAGE request containing a third
segment of a concatenated SMS }
report for the third segment }
}
[TS 23.040, clause 9.2.3.23]:
The TP-User-Data-Header-Indicator is a 1 bit field within bit 6 of the first octet of the following six PDUs:
- SMS-SUBMIT,
- SMS-SUBMIT-REPORT,
- SMS-DELIVER,
- SMS-DELIVER-REPORT,
- SMS-STATUS-REPORT,
- SMS-COMMAND.
TP-UDHI has the following values.
Bit no. 6 0 The TP-UD field contains only the short message
1 The beginning of the TP-UD field contains a Header in addition to the short message.
[TS 23.040, clause 9.2.3.24]:
The length of the TP-User-Data field is defined in the PDU’s of the SM-TL (see clause 9.2.2).
The TP-User-Data field may comprise just the short message itself or a Header in addition to the short message
depending upon the setting of TP-UDHI.
Where the TP-UDHI value is set to 0 the TP-User-Data field comprises the short message only, where the user data can
be 7 bit (default alphabet) data, 8 bit data, or 16 bit (UCS2 [24]) data.
ETSI
Where the TP-UDHI value is set to 1 the first octets of the TP-User-Data field contains a Header in the following order
starting at the first octet of the TP-User-Data field.
Irrespective of whether any part of the User Data Header is ignored or discarded, the MS shall always store the entire
TPDU exactly as received.
FIELD LENGTH
Length of User Data Header 1 octet
Information-Element-Identifier "A" 1 octet
Length of Information-Element "A" 1 octet
Information-Element "A" Data 0 to "n" octets
Information-Element-Identifier "B" 1 octet
Length of Information-Element "B" 1 octet
Information-Element "B" Data 0 to "n" octets
Information-Element-Identifier "X" 1 octet
Length of Information-Element "X" 1 octet
Information-Element "X" Data 0 to "n" octets
The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for uncompressed GSM 7 bit
default alphabet data. The UDHL field is the first octet of the TP-User-Data content of the Short Message.
Octets Octets
UDL UDHL IEIa IEIDLa IEDa IEIb ......... IEIn IEDLn IEDn Fill bits SM (7bit data)
Total number of Octets Septet Boundary
Length Indicator
Total number of Septets
Length Indicator
Figure 9.2.3.24 (a)
The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for uncompressed 8 bit data or
uncompressed UCS2 data. The UDHL field is the first octet of the TP-User-Data content of the Short Message.
ETSI
Octets Octets
UDL UDHL IEIa IEIDLa SM (8 bit data

IEDa IEIb ......... IEIn IEDLn IEDn
or UCS-2 data)
Length Indicator
Length Indicator
Figure 9.2.3.24 (b)
The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for compressed GSM 7 bit
default alphabet data, compressed 8 bit data or compressed UCS2 data. The UDHL field is the first octet of the
TP-User-Data content of the Short Message.
Octets Octets
UDL UDHL IEIa IEIDLa IEDa IEIb ......... IEIn IEDLn IEDn Compressed SM (octets)
Length Indicator
Length Indicator
Figure 9.2.3.24 (c)
The definition of the TP-User-Data-Length field which immediately precedes the "Length of User Data Header" is
unchanged and shall therefore be the total length of the TP-User-Data field including the Header, if present. (see
9.2.3.16).
The "Length-of-Information-Element" fields shall be the integer representation of the number of octets within its
associated "Information-Element-Data" field which follows and shall not include itself in its count value.
The "Length-of-User-Data-Header" field shall be the integer representation of the number of octets within the
"User-Data-Header" information fields which follow and shall not include itself in its count or any fill bits which may
be present (see text below).
Information Elements may appear in any order and need not follow the order used in the present document. Information
Elements are classified into 3 categories as described below.
ETSI
- SMS Control – identifies those IEIs which have the capability of dictating SMS functionality.
- EMS Control – identifies those IEIs which manage EMS Content IEIs.
- EMS Content – identifies those IEIs containing data of a unique media format.
It is permissible for certain IEs to be repeated within a short message, or within a concatenated message. There is no
restriction on the repeatability of IEs in the EMS Content classification. The repeatability of SMS Control and EMS
Control IEs is determined on an individual basis. See the IE table below for the repeatability of each IE.
In the event that IEs determined as not repeatable are duplicated, the last occurrence of the IE shall be used. In the event
that two or more IEs occur which have mutually exclusive meanings (e.g. an 8bit port address and a 16bit port address),
then the last occurring IE shall be used.
If the length of the User Data Header is such that there are too few or too many octets in the final Information Element
then the whole User Data Header shall be ignored.
If any reserved values are received within the content of any Information Element then that part of the Information
Element shall be ignored.
The support of any Information Element Identifier is optional unless otherwise stated.
ETSI
The Information Element Identifier octet shall be coded as follows:
VALUE MEANING Classification Repeatability

(hex)
00 Concatenated short messages, 8-bit reference number SMS Control No
01 Special SMS Message Indication SMS Control Yes
02 Reserved N/A N/A
03 Value not used to avoid misinterpretation as <LF> character N/A N/A
06 SMSC Control Parameters SMS Control No
07 UDH Source Indicator SMS Control Yes
08 Concatenated short message, 16-bit reference number SMS Control No
09 Wireless Control Message Protocol SMS Control Note 3
0A Text Formatting EMS Control Yes
0B Predefined Sound EMS Content Yes
0C User Defined Sound (iMelody max 128 bytes) EMS Content Yes
0D Predefined Animation EMS Content Yes
0E Large Animation (16*16 times 4 = 32*4 =128 bytes) EMS Content Yes
0F Small Animation (8*8 times 4 = 8*4 =32 bytes) EMS Content Yes
10 Large Picture (32*32 = 128 bytes) EMS Content Yes
11 Small Picture (16*16 = 32 bytes) EMS Content Yes
12 Variable Picture EMS Content Yes
13 User prompt indicator EMS Control Yes
14 Extended Object EMS Content Yes
15 Reused Extended Object EMS Control Yes
16 Compression Control EMS Control No
17 Object Distribution Indicator EMS Control Yes
18 Standard WVG object EMS Content Yes
19 Character Size WVG object EMS Content Yes
1A Extended Object Data Request Command EMS Control No
1B-1F Reserved for future EMS features (see subclause 3.10) N/A N/A
20 RFC 5322 E-Mail Header SMS Control No
21 Hyperlink format element SMS Control Yes
22 Reply Address Element SMS Control No
23 Enhanced Voice Mail Information SMS Control No
24 National Language Single Shift SMS Control No
25 National Language Locking Shift SMS Control No
26 – 6F Reserved for future use N/A N/A
70 – 7F (U)SIM Toolkit Security Headers SMS Control Note 1
80 – 9F SME to SME specific use SMS Control Note 2
A0 – BF Reserved for future use N/A N/A
C0 – DF SC specific use SMS Control Note 2
E0 – FF Reserved for future use N/A N/A
Note 1: The functionality of these IEIs is defined in 3GPP TSG 31.115 [28], and therefore, the repeatability
is not within the scope of this document and will not be determined here.
Note 2: The functionality of these IEIs is used in a proprietary fashion by different SMSC vendors, and
therefore, are not within the scope of this technical specification.
Note 3: The functionality of these IEIs is defined by the WAP Forum and therefore the repeatability is not
within the scope of this document and will not be determined here.
A receiving entity shall ignore (i.e. skip over and commence processing at the next information element) any
information element where the IEI is Reserved or not supported. The receiving entity calculates the start of the next
information element by looking at the length of the current information element and skipping that number of octets.
The SM itself may be coded as 7, 8 or 16 bit data.
If 7 bit data is used and the TP-UD-Header does not finish on a septet boundary then fill bits are inserted after the last
Information Element Data octet up to the next septet boundary so that there is an integral number of septets for the
entire TP-UD header. This is to ensure that the SM itself starts on an septet boundary so that an earlier Phase mobile
shall be capable of displaying the SM itself although the TP-UD Header in the TP-UD field may not be understood.
ETSI
It is optional to make the first character of the SM itself a Carriage Return character encoded according to the default 7
bit alphabet so that earlier Phase mobiles, which do not understand the TP-UD-Header, shall over-write the displayed
TP-UD-Header with the SM itself.
If 16 bit (USC2) data is used then padding octets are not necessary. The SM itself shall start on an octet boundary.
If 8 bit data is used then padding is not necessary. An earlier Phase mobile shall be able to display the SM itself
although the TP-UD header may not be understood.
It is also possible for mobiles not wishing to support the TP-UD header to check the value of the TP-UDHI bit in the
SMS-Deliver PDU and the first octet of the TP-UD field and skip to the start of the SM and ignore the TP-UD header.
[TS 23.040, clause 9.2.3.24.1]:
This facility allows short messages to be concatenated to form a longer message.
In the case of uncompressed 8-bit data, the maximum length of the short message within the TP-UD field is 134 (140-6)
octets.
In the case of uncompressed GSM 7 bit default alphabet data, the maximum length of the short message within the
TP-UD field is 153 (160-7) characters. A character represented by an escape-sequence shall not be split in the middle.
In the case of 16 bit uncompressed USC2 data, the maximum length of the short message within the TP-UD field is 67
((140-6)/2) characters. A UCS2 character shall not be split in the middle; if the length of the User Data Header is odd,
the maximum length of the whole TP-UD field is 139 octets.
In the case of compressed GSM 7 bit default alphabet data, 8 bit data or UCS2 the maximum length of the compressed
short message within the TP-UD field is 134 (140-6) octets including the Compression Header and Compression Footer,
both or either of which may be present (see clause 3.9).
The maximum length of an uncompressed concatenated short message is 39015 (255*153) default alphabet characters,
34170 (255*134) octets or 17085 (255*67) UCS2 characters.
The maximum length of a compressed concatenated message is 34170 (255*134) octets including the Compression
Header and Compression Footer (see clause 3.9 and figure 9.2.3.24.1(a) below).
Compression Header Compressed Data (CD) Compression Footer
Segmentation / De-segmentation
TP-UDH CH CD TP-UDH CD TP-UDH CD CF
First segment Intermediate segments Final segment
Figure 9.2.3.24.1 (a): Concatenation of a Compressed short message
The gNB-DU controlling a UE-associated logical F1-connection initiates the procedure by generating a UE The
Information-Element-Data field contains information set by the application in the SMS-SUBMIT so that the receiving
entity is able to re-assemble the short messages in the correct order. Each concatenated short message contains a
reference number which together with the originating address and Service Centre address allows the receiving entity to
discriminate between concatenated short messages sent from different originating SMEs and/or SCs. In a network
which has multiple SCs, it is possible for different segments of a concatenated SM to be sent via different SCs and so it
is recommended that the SC address should not be checked by the MS unless the application specifically requires such a
check.
The TP elements in the SMS-SUBMIT PDU, apart from TP-MR, TP-SRR, TP-UDL and TP-UD, should remain
unchanged for each SM which forms part of a concatenated SM, otherwise this may lead to irrational behaviour. TP-
MR must be incremented for every segment of a concatenated message as defined in clause 9.2.3.6. A SC shall handle
segments of a concatenated message like any other short message. The relation between segments of a concatenated
message is made only at the originator, where the message is segmented, and at the recipient, where the message is
ETSI
reassembled. SMS-COMMANDs identify messages by TP-MR and therefore apply to only one segment of a
concatenated message. It is up to the originating SME to issue SMS-COMMANDs for all the required segments of a
concatenated message.
The Information-Element-Data octets shall be coded as follows.
Octet 1 Concatenated short message reference number.
This octet shall contain a modulo 256 counter indicating the reference number for a particular
concatenated short message. This reference number shall remain constant for every short message which
makes up a particular concatenated short message.
Octet 2 Maximum number of short messages in the concatenated short message.
This octet shall contain a value in the range 0 to 255 indicating the total number of short messages within
the concatenated short message. The value shall start at 1 and remain constant for every short message
which makes up the concatenated short message. If the value is zero then the receiving entity shall ignore
the whole Information Element.
Octet 3 Sequence number of the current short message.
This octet shall contain a value in the range 0 to 255 indicating the sequence number of a particular short
message within the concatenated short message. The value shall start at 1 and increment by one for every
short message sent within the concatenated short message. If the value is zero or the value is greater than
the value in octet 2 then the receiving entity shall ignore the whole Information Element.
The IEI and associated IEI length and IEI data shall be present in every segment of the concatenated SM.
[TS 24.341, clause 5.3.2.3]
receiver shall:
3GPP TS 24.011 [8].
[TS 24.341, clause 5.3.2.4]
d) the In-Reply-To header which shall contain the Call-Id of the SIP MESSAGE request that was received in the
received short message;
e) the Content-Type header shall contain "application/vnd.3gpp.sms"; and
f) the body of the request shall contain the RP-ACK or RP-ERROR message for the SM delivery report, as defined
in 3GPP TS 24.011 [8].
ETSI
System Simulator:
UE:
Preamble:

U-S Message
0A-0H Steps 1-8 of generic procedure specified in - - - -
Table 4.9.20.2.2-1 of TS 38.508-1 [21] are
performed.
1 SS sends a first segment of a concatenated <-- SIP MESSAGE request
SMS in the message-body of SIP_MESSAGE.
2 Check: Does the UE respond with a 200 OK? --> 200 OK 1 P
3 Check: When the payload is extracted, does --> SIP MESSAGE request 1 P
the UE respond with a delivery report included
in the message-body of MESSAGE?
4 SS responds with a 202 ACCEPTED. <-- 202 ACCEPTED
5 SS sends a second segment of a <-- SIP MESSAGE request
concatenated SMS in the message-body of
SIP_MESSAGE.
9 SS sends a final segment of a concatenated <-- SIP MESSAGE request
SMS in the message-body of SIP_MESSAGE.
ETSI
Table 9.4.3.3-1: MESSAGE for MT SMS (step 1, table 9.4.3.2-1)

Message-body - TP-RP=’0’B (TP Reply Path parameter is not set in this TS 24.011 [25]
SMS SUBMIT/DELIVER) TS 23.040 [24]
- TP-MMS=’0’B (More messages are waiting for the MS in
this SC)
- TP-UDHI=’1’B (The beginning of the TP UD field
contains a Header in addition to the short message.)
- TP-PID=’00000000’B
- TP-UD
- Concatenated short message reference number=any
allowed value
Table 9.4.3.3-2: 200 OK for other requests than REGISTER or SUBSCRIBE (step 2/6/10, table 9.4.3.2-1)
Table 9.4.3.3-3: MESSAGE for delivery report (step 3/7/11, table 9.4.3.2-1)
Table 9.4.3.3-4: 202 ACCEPTED (step 4/8, table 9.4.3.2-1)

this SC)
- TP-PID=’00000000’B
- TP-UD
- Concatenated short message reference number=The
same value sent in the step1
ETSI

this SC)
- TP-PID=’00000000’B
- TP-UD
- Concatenated short message reference number=The
same value sent in the step1
ETSI
9.5 Mobile Originating SMS / RP-ERROR / 5GS

(1)
ensure that {
when { UE is made to send an SMS over IP }
then { UE sends a SIP MESSAGE request containing a short message }
}
(2)
with { UE having sent a SIP MESSAGE request containing a short message }
ensure that {
when { UE receives a 202 Accepted response, followed by a SIP MESSAGE request containing an RP-
ERROR message }
}
[TS 24.341, clause 5.3.1.1]:
In addition to the procedures specified in subclause 5.3.1, the SM-over-IP sender shall support the procedures specified
in 3GPP TS 24.229 [10] appropriate to the functional entity in which the SM-over-IP sender is implemented. The SM-
over-IP sender shall build and populate RP-DATA message, containing all the information that a mobile station
submitting an SM according to 3GPP TS 24.011 [8] would place, for successful delivery. The SM-over-IP sender shall
parse and interpret RP- DATA, RP-ACK and RP-ERROR messages, containing all the information that a mobile station
receiving an SM according to 3GPP TS 24.011 [8] would see, in a SM submission or status report.
NOTE 1: If the SM-over-IP sender uses SMR entity timers as specified in 3GPP TS 24.011 [8], then TR1M is set to
a value greater than timer F (see 3GPP TS 24.229 [10]).
NOTE 2: If the SM-over-IP sender expects to receive a SM submit report will include the "+g.3gpp.smsip"
parameter in the Contact header field when sending a REGISTER request.
[TS 24.341, clause 5.3.1.2]:
When an SM-over-IP sender wants to submit an SM over IP, the SM-over-IP sender shall send a SIP MESSAGE
request with the following information:
a) the Request-URI, which shall contain the PSI of the SC of the SM-over-IP sender;
NOTE 1: The PSI of the SC can be SIP URI or tel URI based on operator policy. The PSI of the SC can be obtained
using one of the following methods in the priority order listed below:
1) provided by the user;
2) if UICC is used, then:
- if an ISIM is present, then the PSI of the SC is obtained from the EFPSISMSC in DF_TELECOM as
per 3GPP TS 31.103 [18];
- if an ISIM is not present, then the PSI of the SC is obtained from the EFPSISMSC in DF_TELECOM
as per 3GPP TS 31.102 [19]; or
- if the PSI of the SC is not available in EFPSISMSC in DF_TELECOM, then the PSI of the SC
contains the TS-Service-Centre-Address stored in the EFSMSP in DF_TELECOM as per
3GPP TS 31.102 [19]. If the PSI of the SC is based on the E.164 number from the TS-Service-
Centre-Address stored in the EFSMSP in DF_TELECOM then the URI constructed can be either a
tel URI or a SIP URI (using the "user=phone" SIP URI parameter format).
ETSI
3) if SIM is used instead of UICC, then the PSI of the SC contains the TS-Service Centre Address stored
in the EFSMSP in DF_TELECOM as per 3GPP TS 51.011 [20]. If the PSI of the SC is based on the
E.164 number from the TS-Service-Centre-Address stored in the EFSMSP in DF_TELECOM then the
URI constructed can be either a tel URI or a SIP URI (using the "user=phone" SIP URI parameter
format); or
4) if neither the UICC nor SIM is used, then how the PSI of the SC is configured and obtained is through
means outside the scope of this specification.
b) the From header, which shall contain a public user identity of the SM-over-IP sender;
NOTE 2: The IP-SM-GW will have to use an address of the SM-over-IP sender that the SC can process (i.e. an
E.164 number). This address will come from a tel URI in a P-Asserted-Identity header (as defined in
RFC 3325 [13]) placed in the SIP MESSAGE request by the P-CSCF or S-CSCF.
NOTE 3: The SM-over-IP sender has to store the Call-ID of the SIP MESSAGE request, so it can associate the
appropriate SIP MESSAGE request including a submit report with it.
c) the To header, which shall contain the PSI of the SC of the SM-over-IP sender;
d) the Content-Type header, which shall contain "application/vnd.3gpp.sms"; and
e) the body of the request shall contain an RP-DATA message as defined in 3GPP TS 24.011 [8], including the
SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3].
NOTE 4: The address of the SC is included in the RP-DATA message content. The address of the SC included in
the RP-DATA message content is stored in the EFSMSP in DF_TELECOM of the (U)SIM of the SM-over-
IP sender.
NOTE 6: Both the address of the SC and the PSI of the SC can be configured in the EFPSISMSC in DF_TELECOM of
the USIM and ISIM respectively using the USAT as per 3GPP TS 31.111 [21].
The SM-over-IP sender may request the SC to return the status of the submitted message. The support of status report
capabilities is optional for the SC.
When a SIP MESSAGE request including a submit report in the "vnd.3gpp.sms" payload is received, the SM-over-IP
sender shall:
- if SM-over-IP sender supports In-Reply-To header usage and the In-Reply-To header indicates that the request
corresponds to a short message submitted by the SM-over-IP sender, generate a 200 (OK) SIP response
according to RFC 3428 [14].
if SM-over-IP sender supports In-Reply-To header usage and the In-Reply-To header indicates that the request
does not correspond to a short message submitted by the SM-over-IP sender, a 488 (Not Acceptable here) SIP
response according to RFC 3428 [14].
- if SM-over-IP sender does not support In-Reply-To header usage, generate a 200 (OK) SIP response according
to RFC 3428 [14]; and extract the payload encoded according to 3GPP TS 24.011 [8] for RP-ACK or RP-
ERROR.
[TS 24.341 clause 5.3.1.3]:
When a SIP MESSAGE request including a status report in the "vnd.3gpp.sms" payload is delivered, the SM-over-IP
sender shall:
- create a delivery report for the status report as described in subclause 5.3.2.4. The content of the delivery report
is defined in 3GPP TS 24.011 [8].
[TS 24.341 clause 5.3.2.4]:
ETSI
d) the In-Reply-To header which shall contain the Call-Id of the SIP MESSAGE request that was received in the
received short message;
e) the Content-Type header shall contain "application/vnd.3gpp.sms"; and
f) the body of the request shall contain the RP-ACK or RP-ERROR message for the SM delivery report, as defined
in 3GPP TS 24.011 [8].
[TS 24.011 clause 8.2.5.4]:
This element is a variable length element always included in the RP-ERROR message, conveying a negative result of a
RP-DATA message transfer attempt or RP-SMMA notification attempt. The element contains a cause value and
optionally a diagnostic field giving further details of the error cause.
The coding of the cause value is given in table 8.4/3GPP TS 24.011. The mapping between error causes in
3GPP TS 24.011 and 3GPP TS 29.002 (MAP) is specified in 3GPP TS 23.040. Parameters included in the return error
from MAP (e.g. System Failure) are mapped directly into the diagnostic field.
8 7 6 5 4 3 2 1
0 1 0 0 0 0 1 0
RP-Cause IEI 1 octet
Length indicator 1 octet
0 ext Cause value 1 octet
Diagnostic field 1 octet *
Figure 8.8/3GPP TS 24.011: RP-Cause element layout
ETSI
Table 8.4/3GPP TS 24.011 (part 1): Cause values that may be contained in an RP-ERROR message
in a mobile originating SM-transfer attempt
Cause value Cause Cause

number
7654321 #
0000001 1 Unassigned (unallocated) number
0001000 8 Operator determined barring
0001010 10 Call barred
0001011 11 Reserved
0010101 21 Short message transfer rejected
0011011 27 Destination out of order
0011100 28 Unidentified subscriber
0011101 29 Facility rejected
0011110 30 Unknown subscriber
0100110 38 Network out of order
0101001 41 Temporary failure
0101010 42 Congestion
0101111 47 Resources unavailable, unspecified
0110010 50 Requested facility not subscribed
1000101 69 Requested facility not implemented
1010001 81 Invalid short message transfer reference value
1011111 95 Semantically incorrect message
1100000 96 Invalid mandatory information
1100001 97 Message type non-existent or not implemented
1100010 98 Message not compatible with short message protocol
state
1100011 99 Information element non-existent or not implemented
1101111 111 Protocol error, unspecified
1111111 127 Interworking, unspecified
Note: All other cause values shall be treated as cause number 41, "Temporary Failure"
System Simulator:
UE:
- SMS over IP is enabled.
Preamble:
ETSI

U-S Message
1 UE is made to send an SMS over IP.
Table 4.9.19.2.2-1 of TS 38.508-1 [21] are
performed.
place
that contains a short message?
3 SS responds with 202 Accepted. <-- 202 ACCEPTED
4 SS sends a SIP MESSAGE request including <-- SIP MESSAGE request
a vnd.3gpp.sms payload and RP-ERROR
message.

U-S Message
Table 9.5.3.3-1: Message for MO SMS (step 2, table 9.5.3.2-1)
Derivation Path: TS 34.229-1 [2], Table in annex A.7.3, Condition A2, A5

Message-body RP-ERROR message with RP-Cause Data: TS 24.011 [25]
Length: 2, Length indicator = 1 TS 23.040 [24]
Extension: not extended
Cause value: 38 (Network out of order)
ETSI
10 Emergency Calls
10.1 Emergency Call with emergency registration / Success /

Location information available / 5GS
(1)
ensure that {
when { UE is being made to initiate an emergency call }
then { UE sends a correctly composed initial REGISTER request for IMS emergency registration }
(2)
ensure that {
}
(3)
ensure that {
when { UE receiving a valid 200 OK response for the REGISTER sent for authentication }
then { UE sends a correctly composed INVITE request }
}
(4)
ensure that {
when { UE receiving 100 Trying, followed by 180 Ringing, followed by 200 OK }
}
(5)
with { Emergency call being established }
ensure that {
when { UE receives BYE }
}
[TS 24.229 clause 4.7.5]:
A number of mechanisms also exist for providing location in support of emergency calls, both for routeing to a PSAP,
and for use by the PSAP itself, in the IM CN subsystem:
a) by the inclusion by the UE of the Geolocation header field containing a location by reference or by value (see
RFC 6442 [89]);
b) by the inclusion by the UE of a P-Access-Network-Info header field, which contains a cell identifier or location
identifier, which is subsequently mapped, potentially by the recipient, into a real location;
...
ETSI
Which means of providing location is used depends on local regulatory and operator requirements. One or more
mechanisms can be used. Location can be subject to privacy constraints.
[TS 24.229 clause 5.1.6.2]:
When the user initiates an emergency call, if emergency registration is needed (including cases described in
subclause 5.1.6.2A), the UE shall perform an emergency registration prior to sending the SIP request related to the
emergency call.
...
When a UE performs an initial emergency registration the UE shall perform the actions as specified in subclause 5.1.1.2
with the following additions and modifications:
a) the UE shall include a "sos" SIP URI parameter in the Contact header field as described in subclause 7.2A.13,
indicating that this is an emergency registration and that the associated contact address is allowed only for
emergency service; and
b) the UE shall populate the From and To header fields of the REGISTER request with:
- the first entry in the list of public user identities provisioned in the UE;
- the default public user identity obtained during the normal registration, if the UE is not provisioned with a list
of public user identities, but the UE is currently registered to the IM CN subsystem; and
- the derived temporary public user identity, in all other cases.
[TS 24.229 clause 5.1.6.3]
Upon receiving the 200 (OK) to the REGISTER request that completes the emergency registration, the UE shall not
subscribe to the reg event package of the public user identity specified in the REGISTER request.
[TS 24.229 clause 5.1.6.5]
When a UE performs authentication a UE shall perform the procedures as specified in subclause 5.1.1.5.
[TS 24.229 clause 5.1.6.8.3]
After a successful initial emergency registration, the UE shall apply the procedures as specified in subclause 5.1.2A and
5.1.3 with the following additions:
1) the UE shall insert in the INVITE request, a From header field that includes the public user identity registered
via emergency registration or the tel URI associated with the public user identity registered via emergency
registration, as described in subclause 4.2;
2) the UE shall include a service URN in the Request-URI of the INVITE request in accordance with
subclause 5.1.6.8.1;
3) the UE shall insert in the INVITE request, a To header field with the same emergency service URN as in the
Request-URI;
4) if available to the UE, and if defined for the access type as specified in subclause 7.2A.4, the P-Access-Network-
Info header field shall contain a location identifier such as the cell id, line id or the identity of the WLAN access
node, which is relevant for routeing the IMS emergency call;
NOTE 1: The IMS emergency specification in 3GPP TS 23.167 [4B] describes several methods how the UE can get
its location information from the access network or from a server. Such methods are not in the scope of
this specification.
5) the UE shall insert in the INVITE request, one or two P-Preferred-Identity header field(s) that include the public
user identity registered via emergency registration or the tel URI associated with the public user identity
registered via emergency registration as described in subclause 4.2;
NOTE 2: Providing two P-Preferred-Identity header fields is usually supported by UE acting as enterprise network.
6) void;
ETSI
7) if the UE has its location information available, or a URI that points to the location information, then the UE
shall include a Geolocation header field in the INVITE request in the following way:
- if the UE is aware of the URI that points to where the UE's location is stored, include the URI as the
Geolocation header field value, as described in RFC 6442 [89]; or
[Rel-15]
- if the UE is aware of its location information, include the location information in a PIDF location object, in
accordance with RFC 4119 [90], include the location object in a message body with the content type
application/pidf+xml, and include a Content ID URL, referring to the message body, as the Geolocation
header field value, as described RFC 6442 [89], and include a Content-Disposition header field with a
disposition type "render" value and a "handling" header field parameter with an "optional" value, as
described in RFC 3261 [26];
[Rel-16]
accordance with RFC 4119 [90] and RFC 5491 [267], include the location object in a message body with the
content type application/pidf+xml, and include a Content ID URL, referring to the message body, as the
Geolocation header field value, as described RFC 6442 [89], and include a Content-Disposition header field
with a disposition type "render" value and a "handling" header field parameter with an "optional" value, as
8) if the UE includes a Geolocation header field, the UE shall also include a Geolocation-Routing header field with
a "yes" header field value, which indicates that the location of the UE can be used by other entities to make
routing decisions, as described in RFC 6442 [89];
NOTE 3: It is suggested that UE's only use the option of providing a URI when the domain part belongs to the
current P-CSCF or S-CSCF provider. This is an issue on which the network operator needs to provide
guidance to the end user. A URI that is only resolvable to the UE which is making the emergency call is
not desirable.
9) if the UE has neither geographical location information available, nor a URI that points to the location
information, the UE shall not insert a Geolocation header field in the INVITE request; and
10) if support of the current location discovery during an emergency call is allowed in the IP-CAN specific annex
and the UE supports the current location discovery during an emergency call, the UE shall include a Recv-Info
header field as described in RFC 6086 [25], indicating the g.3gpp.current-location-discovery info package name
and shall include an Accept header field indicating the "application/vnd.3gpp.current-location-discovery+xml"
MIME type.
NOTE 4: RFC 3261 [26] provides for the use of the Priority header field with a suggested value of "emergency". It
is not precluded that emergency sessions contain this value, but such usage will have no impact on the
processing within the IM CN subsystem.
[TS 24.237 clause 7.2]:
When originating an emergency call as specified in 3GPP TS 24.229 [2] and if the SC UE has an IMEI, then the SC UE
shall include the sip.instance media feature tag as specified in IETF RFC 5626 [22] with value based on the IMEI as
defined in 3GPP TS 23.003 [12] in the Contact header field of the SIP INVITE request according to
IETF RFC 3840 [53].
[TS 23.003 clause 13.8]:
An instance-id is a SIP Contact header parameter that uniquely identifies the SIP UA performing a registration.
When an IMEI is available, the instance-id shall take the form of a IMEI URN (see RFC 7254 [79]). The format of the
instance-id shall take the form "urn:gsma:imei:<imeival>" where by the imeival shall contain the IMEI encoded as
defined in RFC 7254 [79]. The optional <sw-version-param> and <imei-version-param> parameters shall not be
included in the instance-id. RFC 7255 [104] specifies additional considerations for using the IMEI as an instance-id. An
example of such an instance-id is as follows:
EXAMPLE: urn:gsma:imei:90420156-025763-0
ETSI
If no IMEI is available, the instance-id shall take the form of a string representation of a UUID as a URN as defined in
IETF RFC 4122 [80]. An example of such an instance-id is as follows:
EXAMPLE: urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
For more information on the instance-id and when it is used, see 3GPP TS 24.229 [81].
System Simulator:
- Test environment shall be set up to provide the needed input to the UE, in order for the UE to derive its location,
if the UE uses Geolocation header for providing its geographical location. This shall be done by use of the test
function Update UE Location Information defined in TS 38.509 [48], if supported by the UE according to
pc_UpdateUE_LocationInformation. Otherwise, or in addition any other suitable method may also be used.
UE:
Preamble:
ETSI

U-S Message
1 UE is made to make an emergency call - - - -
1A-1J Steps 1-10 of test procedure specified in Table - - - -
2 Step 1 of annex A.3 (emergency registration) --> REGISTER 1 P
Check: Does the UE send a correctly composed
initial REGISTER request for IMS emergency
registration?
3 Step 2 of annex A.3 (emergency registration) <-- 401 Unauthorized - -
4 Step 3 of annex A.3 (emergency registration) --> REGISTER 2 P
Check: Does the UE correctly authenticate itself
by sending another REGISTER request with a
correctly composed Authorization header using
the AKAv1-MD5 algorithm?
5 Step 4 of annex A.3 (emergency registration) <-- 200 OK - -
- EXCEPTION: In parallel to steps 6-10 below, - - - -
steps 11-13 of test procedure specified in Table
4.9.11.2.2-1 of TS 38.508-1 [21] takes place.
6 Step 1 of annex A.6 (emergency call) --> INVITE 3 P
Check: Does the UE send a correctly composed
INVITE request?
7 Step 2 of annex A.6 (emergency call) <-- 100 Trying - -
8 Step 3 of annex A.6 (emergency call) <-- 180 Ringing - -
9 Step 4 of annex A.6 (emergency call) <-- 200 OK - -
10 Step 5 of annex A.6 (emergency call) --> ACK 4 P
Check: Does the UE send ACK?
11 Step 1 of annex A.8 (MT Release of Voice Call) <-- BYE - -
12 Step 2 of annex A.8 (MT Release of Voice Call) --> 200 OK 5 P
Check: Does the UE send 200 OK for the BYE
request and ends the call?
Derivation Path: Annex A.6, Step 1, with Conditions A7, A8, and A28 of TS 34.229-1 [2] cl A.2.1
10.2 Emergency Call with emergency registration / Success /

Location information not available / 5GS
(1)
ensure that {
(2)
ensure that {
}
ETSI
(3)
ensure that {
when { UE receiving a valid 200 OK response for the REGISTER sent for authentication }
then { UE sends a correctly composed INVITE request without location information }
}
(4)
ensure that {
}
(5)
ensure that {
}
[TS 24.229 clause 5.1.6.1]:
If the IM CN subsystem is selected and the UE is currently attached to its home operator's network (e.g. HPLMN) and
the UE is currently registered and the IP-CAN defines emergency bearers and the core network has indicated that it
supports emergency bearers, the UE shall:
1) perform an initial emergency registration, as described in subclause 5.1.6.2; and
2) attempt an emergency call as described in subclause 5.1.6.8.3.
[TS 24.229 clause 5.1.6.2]:
[TS 24.229 clause 5.1.6.8.1]:
When an initial request for a dialog or a standalone transaction, or an unknown method transmitted as part of UE
detected emergency call procedures as defined in subclause 5.1.6 is initiated:
the Request-URI of the initial request for a dialog or the standalone transaction, or the unknown method transmitted as
part of UE detected emergency call procedures as defined in subclause 5.1.6 shall include one of the following service
URNs:
ETSI
- "urn:service:sos", "urn:service:sos.ambulance", "urn:service:sos.police", "urn:service:sos.fire",

"urn:service:sos.marine", "urn:service:sos.mountain", "urn:service:sos.ecall.manual",
"urn:service:sos.ecall.automatic". If the UE can determine the type of emergency service the UE shall use an
emergency service URN with a sub-service type corresponding to the type of emergency service.
[TS 24.229 clause 5.1.6.8.3]:
Request-URI;
this specification.
6) void;
not desirable.
ETSI

MIME type.
[TS 24.229 annex U.2.2.6]:
For the purposes of this document, an emergency PDU session is the equivalent of emergency bearers; i.e. the 5GS
defines emergency bearers for the support of emergency calls. Emergency PDU session is defined for use in emergency
calls in 5GS and core network support of emergency PDU session is indicated to the UE in NAS signalling. Where the
UE recognises that a call request is an emergency call and the core network supports emergency PDU session, the UE
shall use emergency PDU session for both signalling and media for emergency calls made using the IM CN subsystem.
To perform emergency registration, the UE shall request to establish an emergency PDU session as described in
3GPP TS 24.501 [258]. The procedures for PDU session establishment and P-CSCF discovery, as described in
subclause U.2.2.1 of this specification apply accordingly.
[TS 24.237 clause 7.2.1]:
IETF RFC 3840 [53].
[TS 23.003 clause 13.8]:
System Simulator:
- Test environment shall ensure that UE cannot access any information (such as GPS signal) from which the UE
would be able to derive its geographical location. The UE shall only be able to read the global cell ID as
provided by the SS.
UE:
ETSI
- UE is either not able to obtain location information or is configured to not obtain location information when
setting up an emergency session.
Preamble:
Same as test procedure sequence in clause 10.1.3.2
Derivation Path: Annex A.6 Step 1, with Conditions A7, A28 and NOT A8 of 34.229-1 [2] A.2.1
10.3 Emergency call with emergency registration / Emergency

SIP signalling and media in parallel with another ongoing IM
CN subsystem signalling and media / 5GS
(1)
with { UE being registered to IMS, having set up a voice call, and having it put on hold }
ensure that {
then { UE initiates and completes IMS emergency registration }
}
(2)
with { UE being made to initiate an emergency call }
ensure that {
when { UE having completed IMS emergency registration }
then { UE sends correctly composed INVITE request for emergency call }
}
(3)
ensure that {
}
(4)
ensure that {
}
(5)
with { Emergency call being terminated }
ETSI
ensure that {
when { UE having sent 200 OK for BYE }
then { UE sends re-INVITE and completes resumption of the original voice call }
}
[TS 24.229 clause 5.1.6.1]:
2) attempt an emergency call as described in subclause 5.1.6.8.3.[TS 24.229 clause 5.1.6.2]:
[TS 24.229 clause 5.1.6.8.1]:
When an initial request for a dialog or a standalone transaction, or an unknown method transmitted as part of UE
detected emergency call procedures as defined in subclause 5.1.6 is initiated:
the Request-URI of the initial request for a dialog or the standalone transaction, or the unknown method transmitted as
part of UE detected emergency call procedures as defined in subclause 5.1.6 shall include one of the following service
URNs:
- "urn:service:sos", "urn:service:sos.ambulance", "urn:service:sos.police", "urn:service:sos.fire",

"urn:service:sos.marine", "urn:service:sos.mountain", "urn:service:sos.ecall.manual", "urn:service:sos.ecall.automatic".
If the UE can determine the type of emergency service the UE shall use an emergency service URN with a sub-service
type corresponding to the type of emergency service.
[TS 24.229 clause 5.1.6.8.3]:
Request-URI;
ETSI
this specification.
6) void;
not desirable.
MIME type.
[TS 24.229 annex U.2.2.6]:
For the purposes of this document, an emergency PDU session is the equivalent of emergency bearers; i.e. the 5GS
defines emergency bearers for the support of emergency calls. Emergency PDU session is defined for use in emergency
calls in 5GS and core network support of emergency PDU session is indicated to the UE in NAS signalling. Where the
UE recognises that a call request is an emergency call and the core network supports emergency PDU session, the UE
shall use emergency PDU session for both signalling and media for emergency calls made using the IM CN subsystem.
To perform emergency registration, the UE shall request to establish an emergency PDU session as described in
3GPP TS 24.501 [258]. The procedures for PDU session establishment and P-CSCF discovery, as described in
subclause U.2.2.1 of this specification apply accordingly.
ETSI
[TS 24.237 clause 7.2.1]:
IETF RFC 3840 [53].
[TS 23.003 clause 13.8]:
System Simulator:
UE:
Preamble:
- The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS and thereafter executing the generic test
procedure in Annex A.4.1 up to and including its last step for a non-emergency voice call defined in Table
4.9.15.2.2-1 of TS 38.508-1 [21].
ETSI

U-S Message
1 UE is made to hold the ongoing call - - - -
2-5 Ongoing call is put on hold by UE - - - -
(Steps 1-4 of Annex A.17)
6 UE is made to initiate an emergency call - - - -
6A Steps 1-8 of generic procedure specified in
Table 4.9.11.2.2-1 of TS 38.508-1 [21] are
performed.
- EXCEPTION: In parallel with steps 7-10, steps - - - -
9-10 of generic procedure specified in Table
4.9.11.2.2-1 of TS 38.508-1 [21] take palce.
7-10 Check: Does the UE initiate and complete the - - 1 P
IMS emergency registration?
- EXCEPTION: In parallel to steps 11-15 below, - - - -
steps 11-13 of generic procedure specified in
Table 4.9.11.2.2-1 of TS 38.508-1 [21] takes
place.
11 Check: Does the UE send correctly composed --> INVITE 2 P
INVITE request for emergency call?
12-14 SS sends 100 Trying, followed by 180 Ringing, - - - -
followed by 200 OK.
15 Check: Does the UE acknowledge? --> ACK 3 P
16 SS sends BYE to release the emergency call. <-- BYE - -
17 Check: Does the UE send 200 OK response? --> 200 OK 4 P
17A- Steps 3b1-3b3 of generic procedure specified in - - - -
17C Table 4.9.12B.2.2-1 of TS 38.508-1 [21] are
performed.
18 UE is made to resume the original voice call - - - -
19-22 Check: Does the UE send re-INVITE and - - 5 P
completes resumption of the original voice call?
23 UE is made to release the original voice call - - - -
24 The UE sends BYE for the original voice call --> BYE - -
None as fully specified in Annex A.17, A.3, A.6, A.8, and A.7, except for the following:
Derivation Path: A.6, step 1, conditions A7 and A28 of TS 34.229-1 [2] cl A.2.1
ETSI
10.4 Non-UE detectable emergency call / IM CN sends a 1xx

response / UE geographical location information available
or not / 5GS
(1)
with { UE being registered to IMS}
ensure that {
when { UE is being made to initiate a voice call it does not recognize as an emergency call }
then { UE sends a correctly composed INVITE request }
}
(2)
with { UE having sent INVITE for a non-UE detectable emergency call }
ensure that {
when { UE receives 183 Session Progress containing a P-Asserted-Identity header }
then { UE sends (after PRACK/200 OK) a correctly composed UPDATE request and completes the call
setup }
}
[TS 24.229 clause 5.1.6.10]
If the UE receives a 1xx or 200 (OK) response to an initial request for a dialog, the response containing a P-Asserted-
Identity header field set to an emergency number as specified in 3GPP TS 22.101 [1A], and:
- if a public GRUU value (pub-gruu) has been saved associated with the public user identity, the public GRUU
value has not been included in the Contact header field of the initial request for a dialog as specified in
RFC 5627 [93];
- if a public GRUU value (pub-gruu) has not been saved and a protected server port was not included in the
address in the Contact header field of the initial request for a dialog; or
- if the UE has its geographical location information available, or a URI that points to the location information,
and the geographical location information or URI has not been included in the initial request for a dialog;
then the UE shall send an UPDATE request according to RFC 3311 [29]; and:
1) if available to the UE, and if defined for the access type as specified in subclause 7.2A.4, the UE shall include in
the UPDATE request a P-Access-Network-Info header field and it shall contain a location identifier such as the
cell id or the identity of the WLAN access node;
2) if the UE has its geographical location information available, or a URI that points to the location information,
then the UE shall include it in the UPDATE request in the following way:
I) if the UE is aware of the URI that points to where the UE's location is stored, include the URI as the
II) if the UE is aware of its location information, include the location information in a PIDF location object, in
ETSI
information, the UE shall not insert a Geolocation header field in the UPDATE request; and
5) if a public GRUU value ("pub-gruu" header field parameter) has been saved associated with the public user
identity, then the UE shall insert the public GRUU ("pub-gruu" header field parameter) value in the Contact
header field of the UPDATE request as specified in RFC 5627 [93]; otherwise the UE shall include the address
in the Contact header field set in accordance with subclause 5.1.6.8.4, item 8.
this specification.
NOTE 2: It is suggested that UEs only use the option of providing a URI when the domain part belongs to the
not desirable.
different cells). The UE will populate the P-Access-Network-Info header field in any request (except
CANCEL requests) or response (except CANCEL responses) within a dialog with the current point of
attachment to the IP-CAN (e.g. the current cell information).
NOTE 4: In this version of the specification, only requests creating a dialog can request emergency services.
System Simulator:
UE:
- The test environment shall be set up to provide the needed input to the UE, in order for the UE to derive its
location, if the UE is capable of obtaining location information. This shall be done by use of the test function
Update UE Location Information defined in TS 38.509 [48], if supported by the UE according to
pc_UpdateUE_LocationInformation (Item 3 in Table A.4.3-2 in TS 36.523-2 [XX]). Otherwise, or in addition
any other suitable method may also be used.
Preamble:
ETSI

U-S Message
1 Make the UE attempt an IMS voice call. - -
2-7 Steps 2-7 of test procedure specified in Table - - - -
4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
- EXCEPTION: In parallel to step 8 below, step - - - -
8 of test procedure specified in Table
4.9.15.2.2-1 of TS 38.508-1 [21] takes place.
8 Check: Does the UE send an INVITE --> INVITE 1 P
(Step 1 of Annex A.4.1)?
10-12 Steps 10 -12 of test procedure specified in - - - -
Table 4.9.15.2.2-1 of TS 38.508-1 [21] are
performed.
14 UE acks 183 Session Progress --> PRACK - -
16 Check: Does the UE send an UPDATE? --> UPDATE 2 P
17 SS responds to UPDATE <-- 200 OK - -
17A SS sends 180 Ringing reliably. <-- 180 Ringing - -
17B UE acknowledges reception of 180 Ringing. --> PRACK - -
17C SS responds to PRACK. <-- 200 OK - -
(Step10 of Annex A.4.1)
17D SS responds to INVITE. <-- 200 OK - -
18 UE acks 200 OK for INVITE --> ACK - -
19-20 Steps 1-2 of the procedure A.8 are executed - - - -
for MT release of speech call
21-23 Steps 3-5 of test procedure specified in Table - - - -
4.9.18.2.2-1 of TS 38.508-1 [21] are
performed.
ETSI
Derivation Path: TS 34.229-1 [2], Table in annex A.2.3, Conditions A1, A5

Message-body
The following SDP types and values.
v=0
address for SS)
s=-
b=AS:65
Time description:
t=0 0
Media description:
b=AS:65

a=fmtp: (format) br=13.2; bw=swb; mode-set=0,1,2; max-
red=220 [Note 8]
a=fmtp: (format) br=5.9-13.2; bw=nb-swb; mode-
set=0,1,2; max-red=220 [Note 9]
a=ptime:20
a=maxptime:240

a=crypto:1
AES_CM_128_HMAC_SHA1_80inline:PS1uQCVeeCFCa
nVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 [Note 7]
copied from step 1.
RFC 3264 clause 6).
Note 4: Void
Note 5: Void
UE.
Note 8: This EVS configuration is sent if UE sent it as the
first of its EVS configurations in INVITE.
Note 9: This EVS configuration is sent if UE did not send
"br=13.2; bw=swb" as the first of its EVS configurations in
INVITE.
ETSI

Derivation Path: TS 34.229-1 [2], Table in annex A.2.5, Conditions A1, A6
Header/param Cond Value/Remark
Geolocation B1
locationURI cid-url indicating the Content-Id of the PIDF-LO within the
multipart MIME body of INVITE request.
(Note that location-by-reference URI is not allowed as the SS
does not provide any external storage for location info for the UE
to refer.)
Geolocation- B1 “yes”
Routing
Contact SIP URI with IP address or FQDN and protected server port of
addr-spec UE
Content-Type If condition A1 applies: multipart/mixed
media-type If condition A1 application/sdp
Message-body If condition A1 applies, the multipart-mime body shall also
contain a PIDF-LO element mapped to the same Content-ID
which can be found from the Geolocation header
The PIDF-LO shall contain at least the following elements:

- One or more ‘geopriv’ elements, each containing:
- One ‘location-info’ element describing the location of the UE;
and
- One ‘usage-rules’ element describing the limitations of the
usage of the location info.
Condition Explanation
B1 UE is capable of obtaining location information
10.5 Void
10.6 Non-UE detectable emergency call / IM CN sends 380 with

an Alternative Service / Previous emergency IMS
registration not expired / 5GS
(1)
ensure that {
when { UE is made to start an emergency call }
then { UE performs IMS registration and sets up emergency call }
}
(2)
with { Emergency call ongoing }
ensure that {
when { Network sends BYE }
ETSI

}
(3)
with { Emergency call being terminated }
ensure that {
when { UE is made to initiate a non UE detectable emergency call }
then { UE sends correctly composed INVITE request for normal voice call }
}
(4)
with { UE having sent INVITE for normal voice call }
ensure that {
when { UE receives 380 Alternative Service response }
then { UE acknowledges and initiates an emergency call }
}
(5)
ensure that {
}
[TS 24.229 clause 5.1.3.1]:
In the event the UE receives a 380 (Alternative Service) response to an initial INVITE request the response containing a
P-Asserted-Identity header field with a value equal to the value of the last entry of the Path header field value received
during registration and the response containing a 3GPP IM CN subsystem XML body that includes an <ims-3gpp>
element, including a version attribute, with an <alternative-service> child element with the <type> child element set to
"emergency" (see table 7.6.2), the UE shall select a domain in accordance with the conventions and rules specified in
3GPP TS 22.101 [1A] and 3GPP TS 23.167 [4B], and:
- if the CS domain is selected, the UE behaviour is defined in subclause 7.1.2 of 3GPP TS 23.167 [4B] and, where
appropriate, in the access technology specific annex; and
- if the IM CN subsystem is selected, the UE shall apply the procedures in subclause 5.1.6 with the exception of
selecting a domain for the emergency call attempt.
NOTE 10: The last entry on the Path header field value received during registration is the value of the SIP URI of
the P-CSCF. If there are multiple registration flows associated with the registration, then the UE has
received from the P-CSCF during registration multiple sets of Path header field values. The last entry of
the Path header field value corresponding to the flow on which the 380 (Alternative Service) response
was received is checked.
[TS 24.229 clause 5.1.6.2A]:
The UE shall perform a new initial emergency registration, as specified in subclause 5.1.6.2, if the UE determines that:
- it has previously performed an emergency registration which has not yet expired; and
- it has obtained an IP address from the serving IP-CAN, as specified in subclause 9.2.1, different than the IP
address used for the emergency registration.
ETSI
System Simulator:
UE:
Preamble:
ETSI

U-S Message
Table 4.9.11.2.2-1 of TS 38.508-1 [21] are
performed.
- EXCEPTION: In parallel to the events - - - -
described in steps 12-16 below the events
specified in 11-13 of Table 4.9.11.2.2-1 of TS
38.508-1 [21] are performed.
12- Steps 1-4 of Annex A.6 happens - - - -
15
16 Step 5 of Annex A.6 happens --> ACK 1 P
Check: Does the UE send an ACK?
17 Step 1 of Annex A.8 happens <-- BYE - -
18 Step 2 of Annex A.8 happens --> 200 OK 2 P
18A- Steps 3b1-3b34 of generic procedure specified - - - -
18C in Table 4.9.12B.2.2-1 of TS 38.508-1 [21] are
performed to release emergency speech bearer
and Keep emergency PDU session.
19 UE is made to attempt an IMS voice call - - - -
20 UE sends INVITE with the first SDP offer --> INVITE 3 P
Check: Does the UE send correctly composed
INVITE request for normal voice call?
21 SS responds with 380 Alternative Service <-- 380 Alternative Service - -
22 UE acknowledges the receipt of 380 Alternative --> ACK - -
Service response
specified in 11-13 of Table 4.9.11.2.2-1 of TS
38.508-1 [21] are performed.
23 Step 1 of Annex A.6 happens --> INVITE 4 P
Check: Does UE send INVITE message for
emergency call?
24- Steps 2-5 of Annex A.6 happens - - - -
27
ETSI
Table 10.6.3.3-1: INVITE for non UE detectable emergency call (step 20, table 10.6.3.2-1)
Derivation path: TS 34.229-1 [2], Annex A.2.1, Conditions A1, A3, A4, A28, A29, and A30
Message-body The following SDP types and values. TS 24.229 [7]
v=0
s=(session name)
Time description:
Media description:
m=audio (transport port) [Note 2]

Note 2: EVS codec shall be present in the media
attributes, optionally including channel number "/1".
Table 10.6.3.3-2: 380 Alternative Service (step 21, table 10.6.3.2-1)
Derivation path: TS 34.229-1 [2], Annex A.4.1

Message-body <?xml version="1.0" encoding="UTF-8"?> TS 24.229 [7]
<ims-3gpp version="1">
<alternative-service>
<type>emergency</type>
<reason/>
<action>emergency-registration</action>
</alternative-service>
</ims-3gpp>
10.7 Void
10.8 Void
10.9 Emergency call without emergency registration / UE

credentials are not accepted / 5GS
(1)
with { UE being registered to IMS and being made to initiate an emergency call }
ensure that {
when { UE attempts IMS emergency registration and network declines by sending 403 Forbidden }
ETSI
then { UE initiates and completes IMS emergency calls on non-protected ports }

}
[TS 33.203 clause 7.1]
The P-CSCF is allowed to receive only REGISTER messages, messages relating to emergency services in
accordance with TS 23.167 [31] and TS 24.229 [8], and error messages related to unprotected messages on
unprotected ports. All other messages not arriving on a protected port shall be either discarded or rejected by
the P-CSCF.
4. The UE is allowed to receive only the following messages on an unprotected port:
- responses to unprotected REGISTER messages;
- messages relating to emergency services in accordance with TS 23.167 [31] and TS 24.229 [8];
- error messages related to unprotected messages.
All other messages not arriving on a protected port shall be rejected or silently discarded by the UE.
[TS 24.229 clause 5.1.6.1]
2) attempt an emergency call as described in subclause 5.1.6.8.3.
System Simulator:
UE:
Preamble:
ETSI

U-S Message
1 Make the UE to initiate an emergency call. - - - -
2-9 Steps 1-8 of Table 4.9.11.2.2-1 of TS 38.508-1[21] are - - - -
performed.
EXCEPTION: In parallel to the events described in steps - - - -
10-11 below the events specified in steps 1a1 of Table
4.9.11.2.2-2 of TS 38.508-1 [21] take place.
10-11 Steps 9-10 of Table 4.9.11.2.2-1 of TS 38.508-1 [21] are - - - -
performed.
12 UE sends REGISTER --> REGISTER - -
13 SS sends 401 Unauthorized <-- 401 Unauthorized - -
15 SS sends 403 Forbidden <-- 403 Forbidden
The following messages are exchanged on non

protected port.
- EXCEPTION: In parallel to steps 16-20 below, steps 16- - - - -
18 of generic procedure specified in Table 4.9.12.2.2-1
of TS 38.508-1 [21] takes place.
16 Check: Does the UE send a correctly composed INVITE --> INVITE 1 P
request?
17 SS sends 100 Trying. <-- 100 Trying - -
18 SS sends 180 Ringing. <-- 180 Ringing - -
19 SS sends 200 OK. <-- 200 OK - -
20 Check: Does the UE send ACK? --> ACK 1 P
21 SS sends BYE. <-- BYE - -
22 UE sends 200 OK. --> 200 OK - -
Table 10.9.3.3-1: 403 Forbidden (step 15, table 10.9.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.3.2, Conditions A1.
Derivation Path: Annex A.6, Step 1, Conditions A6, A28 of TS 34.229-1 [2] cl A.2.1
Derivation Path: TS 34.229-1 [2], Annex A.2.6, Conditions A4, A7, A14.
ETSI
Derivation Path: Annex A.6, Step 4, Conditions A7, A10, A22 of TS 34.229-1 [2] cl A.3.1.
Derivation Path: TS 34.229-1 [2], Annex A.2.8, Conditions A3, A6.
10.10 Emergency call without emergency registration / Failure of

registration / Rejected by 403(Forbidden)
(1)
with { UE being registered to IMS in V-PLMN and being made to initiate an emergency call }
ensure that {
when { UE attempts IMS emergency registration and visited network declines by sending 403
Forbidden }
then { UE initiates and completes anonymous IMS emergency calls on non-protected ports }
}
[TS 24.229, clause 5.1.1.2.1]
On sending an unprotected REGISTER request, the UE shall populate the header fields as follows:
1) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, the main
URI of the UE; else
1) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, the main
URI of the UE; else
c) a Contact header field set to include SIP URI(s) containing the IP address or FQDN of the UE in the hostport
parameter. If the UE:
2) supports multiple registrations;
4) has an MEID available;
the UE shall include a "+sip.instance" header field parameter containing the instance ID. Only the IMEI shall
be used for generating an instance ID for a multi-mode UE that supports both 3GPP and 3GPP2 defined radio
access networks.
ETSI
If the UE supports multiple registrations it shall include a "reg-id" header field parameter as described in RFC
5626 [92].
The UE shall include all supported ICSI values (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref
media feature tag as defined in subclause 7.9.2 and RFC 3840 [62] for the IMS communication services it
intends to use, and IARI values (coded as specified in subclause 7.2A.9.2), for the IMS applications it intends to
use in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3840 [62].
The UE shall include the media feature tags as defined in RFC 3840 [62] for all supported streaming media
types.
If the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the
registration of bulk number contacts the UE shall include a Contact URI without a user portion and containing
the "bnc" URI parameter.
If the UE has no specific reason not to include a user part in the URI of the contact address (e.g. some UE
performing the functions of an external attached network), the UE should include a user part in the URI of the
contact address such that the user part is globally unique and does not reveal any private information;
NOTE 3: A time-based UUID (Universal Unique Identifier) generated as per subclause 4.2 of RFC 4122 [154] is
globally unique and does not reveal any private information.
d) a Via header field set to include the sent-by field containing the IP address or FQDN of the UE and the port
number where the UE expects to receive the response to this request when UDP is used. For TCP, the response is
received on the TCP connection on which the request was sent. For the UDP, the UE shall also include a "rport"
header field parameter with no value in the Via header field. Unless the UE has been configured to not send
keep-alives, and unless the UE is directly connected to an IP-CAN for which usage of NAT is not defined, it
shall include a "keep" header field parameter with no value in the Via header field, in order to indicate support of
sending keep-alives associated with the registration, as described in RFC 6223 [143];
NOTE 4: When sending the unprotected REGISTER request using UDP, the UE transmit the request from the same
IP address and port on which it expects to receive the response to this request.
e) a registration expiration interval value of 600 000 seconds as the value desired for the duration of the
registration;
request;
g) the Supported header field containing the option-tag "path", and
2) if multiple registrations is supported, the option-tag "outbound".
h) if a security association or TLS session exists, and if available to the UE (as defined in the access technology
specific annexes for each access technology), a P-Access-Network-Info header field set as specified for the
access network technology (see subclause 7.2A.4);
i) a Security-Client header field to announce the media plane security mechanisms the UE supports, if any, labelled
with the "mediasec" header field parameter specified in subclause 7.2A.7;
and
k) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the
"gin".
ETSI
[TS 24.229, clause 5.1.6.2]
If:
1) the UE receives a 403 (Forbidden) response to the REGISTER request for initial emergency registration
containing an "sos" SIP URI parameter in the Contact header field; and
2) the response contains a 3GPP IM CN subsystem XML body that includes an <ims-3gpp> element, including a
version attribute, with an <alternative-service> child element with the <type> child element set to "emergency"
(see table 7.6.2) and <action> child element set to "anonymous-emergencycall" (see table 7.6.3);
the UE shall attempt an emergency call as described in subclause 5.1.6.8.2.
[TS 24.229, clause 5.1.6.8.2]
The UE shall apply the procedures as specified in subclause 5.1.2A.1 and subclause 5.1.3 with the following
additions:
1) the UE shall set the From header field of the INVITE request to "Anonymous" as specified in RFC 3261
[26];
2) the UE shall include a service URN in the Request-URI of the initial INVITE request in accordance with
NOTE 1: Other specifications make provision for emergency service identifiers, which are not specifically the
emergency service URN, to be recognised in the UE. Emergency service identifiers which the UE
does not detect will be treated as a normal call by the UE.
Request-URI;
4) if available to the UE (as defined in the access technology specific annexes for each access technology), the
UE shall include in the P-Access-Network-Info header field in any request for a dialog, any subsequent
request (except CANCEL requests) or response (except CANCEL responses) within a dialog or any request.
Insertion of the P-Access-Network-Info header field into the ACK request is optional. The UE shall populate
the P-Access-Network-Info header field with the current point of attachment to the IP-CAN as specified for
the access network technology (see subclause 7.2A.4). The P-Access-Network-Info header field contains the
location identifier such as the cell id, the line id or the identity of the WLAN access node, which is relevant
for routeing the emergency call;
5) if defined by the access technology specific annex, the UE shall populate the P-Preferred-Identity header
field in the INVITE request with an equipment identifier as a SIP URI. The special details of the equipment
identifier to use depend on the IP-CAN;
6) a Contact header field set to include SIP URI that contains in the hostport parameter the IP address of the UE
and an unprotected port where the UE will receive incoming requests belonging to this dialog. The UE shall
also include a "sip.instance" media feature tag containing Instance ID as described in RFC 5626 [92]. The
UE shall not include either the public or temporary GRUU in the Contact header field;
7) a Via header field set to include the IP address of the UE in the sent-by field and for the UDP the unprotected
server port value where the UE will receive response to the emergency request, while for the TCP, the
response is received on the TCP connection on which the emergency request was sent. For the UDP, the UE
shall also include "rport" header field parameter with no value in the top Via header field. Unless the UE has
been configured to not send keep-alives, and unless the UE is directly connected to an IP-CAN for which
usage of NAT is not defined, it shall include a "keep" header field parameter with no value in the Via header
field, in order to indicate support of sending keep-alives associated with, and during the lifetime of, the
emergency session, as described in RFC 6223 [143];
NOTE 2: The UE inserts the same IP address and port number into the Contact header field and the Via header
field, and sends all IP packets to the P-CSCF from this IP address and port number.
8) if the UE has its location information available, or a URI that points to the location information, the UE shall
include a Geolocation header field in the INVITE request in the following way:
ETSI
- if the UE is aware of its location information, include the location information in a PIDF location object,
in accordance with RFC 4119 [90], include the location object in a message body with the content type
9) if the UE includes a Geolocation header field, the UE shall also include a Geolocation-Routing header field
with a "yes" header field value, which indicates that the location of the UE can be used by other entities to
make routing decisions, as described in RFC 6442 [89];
guidance to the end user. A URI that is only resolvable to the UE which is making the emergency call
is inapplicable in this area.
and the UE supports the current location discovery during an emergency call, the UE shall include a Recv-
Info header field as described in RFC 6086 [25], indicating the g.3gpp.current-location-discovery info
package name and shall include an Accept header field indicating the "application/vnd.3gpp.current-location-
discovery+xml" MIME type.
different cells). The UE will populate the P-Access-Network-Info header field in any request or
response within a dialog with the current point of attachment to the IP-CAN (e.g. the current cell
information).
Reference(s)
TS 24.229 [10] clauses 5.1.1.2.1, 5.1.6.2 and 5.1.6.8.2.
System Simulator:
- NR Cell 12 as specified in TS 38.508-1 [4] table 4.4.2-3 is configured and connected to 5GC, default parameters.
UE:
Preamble:
ETSI

U-S Message
0 UE is made to initiate an emergency call. - - - -
1-8 Steps 1-8of Table 4.9.11.2.2-1 of TS 38.508-1 [21] are - - - -
performed.
EXCEPTION: In parallel to the events described in steps - -- - -
9-10 below the events specified in steps 1a1 of Table
4.9.11.2.2-2 of TS 38.508-1 [21] take place.
9-10 Steps 9-10 of Table 4.9.11.2.2-1 of TS 38.508-1 [21] are - - - -
performed.
12 SS sends 403 Forbidden <-- 403 Forbidden - -
The following messages are exchanged on non

protected port.
- EXCEPTION: In parallel to steps 13-17 below, steps 16- - - - -
18 of generic procedure specified in Table 4.9.12.2.2-1
of TS 38.508-1 [21] takes place.
13 Check: Does the UE send a correctly composed INVITE --> INVITE 1 P
request?
14 SS sends 100 Trying. <-- 100 Trying - -
15 SS sends 180 Ringing <-- 180 Ringing - -
16 SS sends 200 OK. <-- 200 OK - -
18 SS sends BYE. <-- BYE - -
19 UE sends 200 OK. --> 200 OK - -
Table 10.10.3.3-1: 403 Forbidden (step 12, table 10.10.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.3.2, Conditions A1.
ETSI

Message-body The following SDP types and values. TS 24.229 [7]
v=0
s=(session name)
Time description:
Media description:

Note 2: EVS codec shall be present in the media
attributes, optionally including channel number "/1".
Derivation Path: TS 34.229-1 [2], Annex A.2.6, Conditions A4, A7, A14.
Derivation Path: Annex A.6, Step 4, Conditions A7, A10, A22 of TS 34.229-1 [2] cl A.3.1.
10.11 Void
10.12 User-initiated emergency reregistration / UE has emergency

related ongoing dialog / 5GS
(1)
ensure that {
then { UE performs IMS emergency registration and sets up an emergency call }
}
(2)
ensure that {
when { IMS emergency registration passes half of the expiring time }
then { UE performs IMS emergency re-registration }
ETSI
[TS 24.229 clause 5.1.6.4]:
The UE shall perform user-initiated emergency reregistration as specified in subclause 5.1.1.4 if half of the time for the
emergency registration has expired and:
- the UE has emergency related ongoing dialog;
- standalone transactions exist; or
- the user initiates an emergency call.
The UE shall not perform user-initiated emergency reregistration in any other cases.
[TS 24.229 clause 5.1.1.4.1]:
When sending a protected REGISTER request, the UE shall use a security association or TLS session associated either
with the contact address or with the registration flow and the associated contact address used to send the request, see
3GPP TS 33.203 [19], established as a result of an earlier initial registration.
On sending a REGISTER request that does not contain a challenge response, the UE shall populate the header fields as
follows:
of the UE; else
of the UE; else
c) a Contact header field set to include SIP URI(s) that contain(s) in the hostport parameter the IP address or FQDN
of the UE, and containing the instance ID of the UE in the "+sip.instance" header field parameter, if the UE:
4) has an MEID available.
Only the IMEI shall be used for generating an instance ID for a multi-mode UE that supports both 3GPP and
3GPP2 defined radio access networks.
If the UE support multiple registrations, it shall include "reg-id" header field as described in RFC 5626 [92]. The
UE shall include all supported ICSI values (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref media
feature tag as defined in subclause 7.9.2 and RFC 3840 [62] for the IMS communication it intends to use, and
IARI values (coded as specified in subclause 7.2A.9.2), for the IMS applications it intends to use in a
g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3840 [62].
ETSI
If a user part has previously been included in an initial REGISTER request, the UE shall use the user part which
was previously used to create the binding being refreshed or removed;
d) a Via header field set to include the IP address or FQDN of the UE in the sent-by field. For the TCP, the
response is received on the TCP connection on which the request was sent. If the UE previously has previously
negotiated sending of keep-alives associated with the registration, it shall include a "keep" header field parameter
with no value in the Via header field, in order to indicate continuous support to send keep-alives, as described in
RFC 6223 [143];
e) a registration expiration interval value, set to 600 000 seconds as the value desired for the duration of the
registration;
request;
g) the Supported header field containing the option-tag "path", and:
2) if multiple registrations is supported, the option-tag "outbound";
h) if available to the UE (as defined in the access technology specific annexes for each access technology), a P-
and
"gin".
a) bind the new expiration time of the registration for this public user identity found in the To header field value
either to the contact address or to the registration flow and the associated contact address used in this
registration;
NOTE 4: If the UE supports RFC 6140 [191] and performs the functions of an external attached network, the To
header field will contain the main URI of the UE.
b) store the list of service route values contained in the Service-Route header field and bind the list either to the
mechanism is used);
NOTE 5: The stored list of service route values will be used to build a proper preloaded Route header field for new
dialogs and standalone transactions (other than REGISTER method) when using either the respective
mechanism is used).
NOTE 6: If the list of Service-Route headers saved from a previous registration and bound either to this contact
address or to the registration flow and the associated contact address (if the multiple registration mechanism is
ETSI
used), and the associated set of security associations or TLS session already exist, then the received list of
Service-Route headers replaces the old list.
NOTE 7: The UE can utilize additional URIs contained in the P-Associated-URI header field, e.g. for application
purposes.
c) if the UE indicated support for GRUU in the Supported header field of the REGISTER request then:
- if the UE did not use the procedures specified in RFC 6140 [191] for registration find the Contact header
was registered; and
- if the UE used the procedures specified in RFC 6140 [191]for registration then find the Contact header field
within the response that matches the one included in the REGISTER request. If this contains a "pub-gruu"
header field parameter then store the value of the "pub-gruu" header field parameter for use for generating
public GRUUs for registering UAs as specified in RFC 6140 [191]. If this contains a "temp-gruu-cookie"
header field parameter then store the value of the "temp-gruu-cookie" header field parameter for use for
generating temporary GRUUs for registering UAs as specified in RFC 6140 [191];
RFC 6140 [191].
d) store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports received in
the Security-Server header field and labelled with the "mediasec" header field parameter specified in
subclause 7.2A.7, if any. Once the UE chooses a media security mechanism from the list received in the
e) if the Via header field contains a "keep" header field parameter with a value, continue to send keep-alives as
described in RFC 6223 [143], towards the P-CSCF;
f) if the 200 (OK) response contains the Authentication-Info header field including a nextnonce field, store the
contained nonce as a nonce for authentication associated to the same registration or registration flow (if the
multiple registration mechanism is used) and shall delete any other previously stored nonce value for
authentication for this registration or registration flow (if the multiple registration mechanism is used);
NOTE 10: The related registration flow or registration is identified by the couple instance-id and reg-id if the
multiple registration mechanism is used or by contact address if not.
g) if a Feature-Caps header field is received, a UE supporting the Feature-Caps header field shall consider the ICSI
values received in the Feature-Caps header field of 200 (OK) response as supported for the established
registration or registration flow (if the multiple registration mechanism is used) according to RFC 6809 [190];
and
NOTE 11: The UE and related applications can use the ICSI values received in the Feature-Caps header field to
improve the user experience.
h) void.
[TS 24.229 clause 5.1.1.4.2]:
as follows:
- the "username" header field parameter set to the value of the private user identity;
ETSI
- the "realm" header field parameter directive, set to the value as received in the "realm" WWW-Authenticate
- the "response" header field parameter, set to the last calculated response value;
associations. For details on the selection of the protected port value see 3GPP TS 33.203 [19].
NOTE 3: If the UE is setting up an additional registration using procedures specified in RFC 5626 [92] and the UE
accesses the network through 3GPP or 3GPP2 systems without any NAT, the flow is considered to be
"logical flow".
b) additionally for the Contact header field, include the protected server port value in the hostport parameter;
include the protected server port value in the sent-by field;
d) a Security-Client header field, set to specify the signalling plane security mechanism it supports, the IPsec layer
algorithms for security and confidentiality protection it supports and the new parameter values needed for the
and
On receiving the 200 (OK) response to the REGISTER request, the UE shall additionally:
a) set the security association lifetime associated with either this contact address or the registration flow and the
associated contact address (if the multiple registration mechanism is used), and the associated set of security
associations to the longest of either the previously existing security association lifetime, or the lifetime of the just
completed registration plus 30 seconds.
NOTE 4: If the UE receives Authentication-Info, it will proceed as described in RFC 3310 [49].
[TS 24.229 clause 5.1.1.5.1]:
ETSI
3) store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports received in
subclause 7.2A.7, if any
field parameter;
Reference(s)
3GPP TS 24.229 [7], clauses 5.1.1.4.1, 5.1.1.4.2, 5.1.1.5.1 and 5.1.6.4.
System Simulator:
ETSI
UE:
Preamble:
- The UE is in test state 1N-A (TS 38.508-1) and registered to IMS.

U-S Message
1 UE is made to initiate an emergency call - - - -
2-4 Check: Does the UE correctly initiate emergency - - 1 P
registration?
5 SS responds 200 OK to finish the registration, <- 200 OK - -
setting the expiration time to 120 seconds.
6-10 Check: Does the UE correctly initiate and - - 1 P
complete the establishment of an emergency
voice call?
11 Check: Does the UE re-register to the --> REGISTER 2 P
emergency service 60 seconds before the
expiration time?
12 The SS responds with a valid authentication <-- 401 Unauthorized - -
challenge and security mechanisms supported
by the network.
13 Check: Does the UE complete the security --> REGISTER 2 P
negotiation procedures, set up a new temporary
set of SAs and uses those for sending another
REGISTER?
14 The SS responds with 200 OK. <-- 200 OK - -
15 SS sends BYE to release the emergency call. <-- BYE - -
16 Check: Does the UE send 200 OK for the BYE --> 200 OK - -

Contact
expires 120
ETSI

Contact
addr-spec SIP URI with IP address or FQDN and protected server port of
UE. The SIP URI shall contain the sos URI parameter.
Security-Client
spi-c new SPI number of the inbound SA at the protected client port
spi-s new SPI number of the inbound SA at the protected server port
port-c new protected client port needed for the setup of new pairs of
security associations
port-s Same value as in the previous REGISTER

Security-Server
port-s Same value as in the previous Security-Server headers
WWW-
Authenticate
nonce Base 64 encoding of a new RAND and AUTN

Contact
addr-spec The same with Step 11 above.
Security-Client
spi-c The same with Step 11 above.
spi-s The same with Step 11 above.
port-c The same with Step 11 above.
port-s The same with Step 11 above.
Authorization Recalculated based on the nonce received from SS within 401
response in Step 12 above.
10.13 User-initiated emergency reregistration / User initiates an

emergency call / 5GS
(1)
ensure that {
then { UE performs IMS emergency registration and initiates the setup of an emergency call }
}
(2)
with { Emergency call setup having proceeded until 180 Ringing }
ensure that {
when { IMS emergency registration expiring }
then { UE performs IMS emergency re-registration }
}
ETSI
[TS 24.229 clause 5.1.6.4]:
The UE shall perform user-initiated emergency reregistration as specified in subclause 5.1.1.4 if half of the time for the
emergency registration has expired and:
- the UE has emergency related ongoing dialog;
- standalone transactions exist; or
- the user initiates an emergency call.
The UE shall not perform user-initiated emergency reregistration in any other cases.
[TS 24.229 clause 5.1.1.4.1]:
When sending a protected REGISTER request, the UE shall use a security association or TLS session associated either
with the contact address or with the registration flow and the associated contact address used to send the request, see
3GPP TS 33.203 [19], established as a result of an earlier initial registration.
On sending a REGISTER request that does not contain a challenge response, the UE shall populate the header fields as
follows:
of the UE; else
of the UE; else
c) a Contact header field set to include SIP URI(s) that contain(s) in the hostport parameter the IP address or FQDN
of the UE, and containing the instance ID of the UE in the "+sip.instance" header field parameter, if the UE:
4) has an MEID available.
Only the IMEI shall be used for generating an instance ID for a multi-mode UE that supports both 3GPP and
3GPP2 defined radio access networks.
If the UE support multiple registrations, it shall include "reg-id" header field as described in RFC 5626 [92]. The
UE shall include all supported ICSI values (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref media
feature tag as defined in subclause 7.9.2 and RFC 3840 [62] for the IMS communication it intends to use, and
IARI values (coded as specified in subclause 7.2A.9.2), for the IMS applications it intends to use in a
g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3840 [62].
ETSI
If a user part has previously been included in an initial REGISTER request, the UE shall use the user part which
was previously used to create the binding being refreshed or removed;
d) a Via header field set to include the IP address or FQDN of the UE in the sent-by field. For the TCP, the
response is received on the TCP connection on which the request was sent. If the UE previously has previously
negotiated sending of keep-alives associated with the registration, it shall include a "keep" header field parameter
with no value in the Via header field, in order to indicate continuous support to send keep-alives, as described in
RFC 6223 [143];
e) a registration expiration interval value, set to 600 000 seconds as the value desired for the duration of the
registration;
request;
g) the Supported header field containing the option-tag "path", and:
2) if multiple registrations is supported, the option-tag "outbound";
h) if available to the UE (as defined in the access technology specific annexes for each access technology), a P-
and
"gin".
a) bind the new expiration time of the registration for this public user identity found in the To header field value
either to the contact address or to the registration flow and the associated contact address used in this
registration;
NOTE 4: If the UE supports RFC 6140 [191] and performs the functions of an external attached network, the To
header field will contain the main URI of the UE.
b) store the list of service route values contained in the Service-Route header field and bind the list either to the
mechanism is used);
NOTE 5: The stored list of service route values will be used to build a proper preloaded Route header field for new
dialogs and standalone transactions (other than REGISTER method) when using either the respective
mechanism is used).
NOTE 6: If the list of Service-Route headers saved from a previous registration and bound either to this contact
address or to the registration flow and the associated contact address (if the multiple registration mechanism is
ETSI
used), and the associated set of security associations or TLS session already exist, then the received list of
Service-Route headers replaces the old list.
NOTE 7: The UE can utilize additional URIs contained in the P-Associated-URI header field, e.g. for application
purposes.
c) if the UE indicated support for GRUU in the Supported header field of the REGISTER request then:
- if the UE did not use the procedures specified in RFC 6140 [191] for registration find the Contact header
was registered; and
- if the UE used the procedures specified in RFC 6140 [191]for registration then find the Contact header field
within the response that matches the one included in the REGISTER request. If this contains a "pub-gruu"
header field parameter then store the value of the "pub-gruu" header field parameter for use for generating
public GRUUs for registering UAs as specified in RFC 6140 [191]. If this contains a "temp-gruu-cookie"
header field parameter then store the value of the "temp-gruu-cookie" header field parameter for use for
generating temporary GRUUs for registering UAs as specified in RFC 6140 [191];
RFC 6140 [191].
d) store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports received in
subclause 7.2A.7, if any. Once the UE chooses a media security mechanism from the list received in the
e) if the Via header field contains a "keep" header field parameter with a value, continue to send keep-alives as
described in RFC 6223 [143], towards the P-CSCF;
f) if the 200 (OK) response contains the Authentication-Info header field including a nextnonce field, store the
contained nonce as a nonce for authentication associated to the same registration or registration flow (if the
multiple registration mechanism is used) and shall delete any other previously stored nonce value for
authentication for this registration or registration flow (if the multiple registration mechanism is used);
NOTE 10: The related registration flow or registration is identified by the couple instance-id and reg-id if the
multiple registration mechanism is used or by contact address if not.
g) if a Feature-Caps header field is received, a UE supporting the Feature-Caps header field shall consider the ICSI
values received in the Feature-Caps header field of 200 (OK) response as supported for the established
registration or registration flow (if the multiple registration mechanism is used) according to RFC 6809 [190];
and
NOTE 11: The UE and related applications can use the ICSI values received in the Feature-Caps header field to
improve the user experience.
h) void.
[TS 24.229 clause 5.1.1.4.2]:
as follows:
- the "username" header field parameter set to the value of the private user identity;
ETSI
- the "realm" header field parameter directive, set to the value as received in the "realm" WWW-Authenticate
- the "response" header field parameter, set to the last calculated response value;
associations. For details on the selection of the protected port value see 3GPP TS 33.203 [19].
NOTE 3: If the UE is setting up an additional registration using procedures specified in RFC 5626 [92] and the UE
accesses the network through 3GPP or 3GPP2 systems without any NAT, the flow is considered to be
"logical flow".
b) additionally for the Contact header field, include the protected server port value in the hostport parameter;
include the protected server port value in the sent-by field;
d) a Security-Client header field, set to specify the signalling plane security mechanism it supports, the IPsec layer
algorithms for security and confidentiality protection it supports and the new parameter values needed for the
and
On receiving the 200 (OK) response to the REGISTER request, the UE shall additionally:
a) set the security association lifetime associated with either this contact address or the registration flow and the
associated contact address (if the multiple registration mechanism is used), and the associated set of security
associations to the longest of either the previously existing security association lifetime, or the lifetime of the just
completed registration plus 30 seconds.
NOTE 4: If the UE receives Authentication-Info, it will proceed as described in RFC 3310 [49].
[TS 24.229 clause 5.1.1.5.1]:
ETSI
3) store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports received in
subclause 7.2A.7, if any
field parameter;
Reference(s)
3GPP TS 24.229 [7], clauses 5.1.1.4.1, 5.1.1.4.2, 5.1.1.5.1 and 5.1.6.4.
System Simulator:
ETSI
UE:
Preamble:
ETSI

U-S Message
1 UE is made to initiates an emergency call - - - -
complete emergency registration?
5 SS responds 200 OK to finish the registration. <- 200 OK - -
(Note: the SS sets the expiration time to 30
seconds.)
process the establishment of an emergency
voice call?
9 SS holds the 200 OK, so that the UE would re- - - - -
registers the emergency service due to
expiration.
10 Check: Does the UE re-register to the --> REGISTER 2 P
emergency service in a time span between half
of the expiration time and the full expiration
time?
(Note: in this test case, the re-registration time is
set to an untypically short value of 30 seconds.
As there are no requirements on the duration of
a re-registration procedure it is only checked that
the re-registration procedure starts between half
of the expiration time and the full expiration
time.)
11 The SS responds with a valid authentication <-- 401 Unauthorized - -
challenge and security mechanisms supported
by the network.
12 Check: Does the UE complete the security --> REGISTER 2 P
negotiation procedures, set up a new temporary
set of SAs and uses those for sending another
REGISTER?
13 The SS responds with 200 OK. <-- 200 OK - -
14 SS sends the 200 OK for INVITE sent in step 2. <-- 200 OK - -
(Note: 200 OK will be sent using previous socket
connection before using old SA)
15 Response from UE to confirm the dialog --> ACK - -
16-17 The call is released by the SS - - - -
(Steps 1-2 of annex A. 8)
Derivation Path: TS 34.229-1 [2], A.1.3, Condition A3

Contact
expires 30
ETSI
Derivation Path: TS 34.229-1 [2], A.1.1, Conditions A2 and A32

Contact
addr-spec SIP URI with IP address or FQDN and protected server port of
UE. The SIP URI shall contain the sos URI parameter.
Security-Client
port-s Same value as in the previous REGISTER
Derivation Path: TS 34.229-1 [2], A.1.2

Security-Server
port-s Same value as in the previous Security-Server headers
WWW-
Authenticate
nonce Base 64 encoding of a new RAND and AUTN
Derivation Path: TS 34.229-1 [2], A.1.1, Conditions A2 and A32

Contact
addr-spec The same with Step 10 above.
Security-Client
spi-c The same with Step 10 above.
spi-s The same with Step 10 above.
port-c The same with Step 10 above.
port-s The same with Step 10 above.
Authorization Recalculated based on the nonce received from SS within 401
response in Step 11 above.
10.14 In parallel emergency and non-emergency registrations /

5GS
(1)
ensure that {
then { UE performs IMS emergency registration and sets up an emergency call }
}
(2)
ensure that {
when { Network sends NOTIFY terminating non-emergency public user identities }
then { UE sends 200 OK without impacting ongoing emergency registration and call }
}
ETSI
[TS 24.229 clause 5.1.6.2]:
When the UE performs an initial emergency registration and whilst this emergency registration is active, the UE shall:
- handle the emergency registration independently from any other ongoing registration to the IM CN subsystem;
- handle any signalling or media related IP-CAN for the purpose of emergency calls independently from any other
established IP-CAN for IM CN subsystem related signalling or media; and
- handle all SIP signalling and all media related to the emergency call independently from any other ongoing IM
CN subsystem signalling and media.
System Simulator:
UE:
Preamble:
- The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS by executing the generic test procedure in
Annex A.2 up to the last step.

U-S Message
2-14 Steps 1 -13 in generic test procedure in TS 38.508-1 - - 1 P
[21] Table 4.9.11.2.2-1 are performed. And steps in
A.3 and step A.6 are performed in the generic test
procedure, to initiate IMS emergency registration and

IMS emergency voice call.
15 The SS sends a NOTIFY for registration event NOTIFY - -
package, containing partial registration state
information, with all previously registered non-
emergency public user identities as "terminated" and

"rejected"
16 Check: Does the UE respond the NOTIFY with 200 200 OK 2 P
OK?
17 Void - - - -

18 Wait 5 seconds. - - - -

19 The SS releases the emergency call BYE - -
20 Check: Does the UE send 200 OK for BYE? 200 OK 2 P
ETSI
Table 10.14.3.3-1: NOTIFY (Step 12, table 10.14.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.1.6 with condition A6.

CSeq
Value 2
Message-body <?xml version=”1.0” encoding="UTF-8"?>
<reginfo xmlns=”urn:ietf:params:xml:ns:reginfo”
version=”1” state=”partial”>
<registration aor=”PublicUserIdentity2 (NOTE 1)”
id=”a102” state=”terminated”>
<contact id=”980” state=”terminated”
event=”rejected”>
request</uri>
</contact>
</registration>
<registration aor=”AssociatedTelUri(NOTE 1)”
id=”a101” state=”terminated”>
<contact id=”981” state=”terminated”
event=”rejected”>
request</uri>
</contact>
</registration>
</reginfo>
NOTE 1: The public user ids and the associated TEL URI are as returned to the UE in the P-Associated-URI header
of the 200 (OK) response to the REGISTER request;
PublicUserId1 is the default public user id i.e. the first one contained in P-Associated-URI;
AssociatedTelUri is the same as used in P-Associated-URI
PublicUserId2 and PublicUserId3 are the remaining IMPUs of the P-Associated-URI header
Table 10.14.3.3-2: 200 OK for NOTIFY (Step 13, table 10.14.3.2-1)
Table 10.14.3.3-3: BYE (Step 15, table 10.14.3.2-1)
Derivation Path: TS 34.229-1 [2], Annex A.2.8 with condition A1 and A8.
Table 10.14.3.3-4: 200 OK for BYE (Step 16, table 10.14.3.2-1)
10.15 Void
ETSI
11 eCall over IMS
11.1 eCall over IMS / Manual initiation / Normal registration /

Emergency registration / Success / 200 OK with ACK / 5GS
(1)
ensure that {
when { UE is being made to initiate a manual eCall over IMS }
}
(2)
ensure that {
when { UE receives a valid 401 (Unauthorized) response for the initial REGISTER request sent }
}
(3)
ensure that {
when { UE receives a valid 200 OK response for the REGISTER sent for authentication }
then { UE sends a correctly composed INVITE request with MSD }
}
(4)
with { UE having sent INVITE with MSD for manual eCall over IMS }
ensure that {
when { UE receives 200 OK containing acknowledgement of reception of MSD }
}
(5)
with { eCall over IMS being established }
ensure that {
}
[TS 24.229 clause 5.1.6.11.1]:
If the upper layers request establishment of an IMS emergency call of the manually initiated eCall type of emergency
service, the service URN shall be "urn:service:sos.ecall.manual" as specified in RFC 8147 [244].
If the upper layers request establishment of an IMS emergency call of the automatically initiated eCall type of
emergency service, the service URN shall be "urn:service:sos.ecall.automatic" as specified in RFC 8147 [244].
NOTE 1: The manually initiated eCall type of emergency service is used when the eCall IMS emergency session is
invoked with user input. The automatically initiated eCall type of emergency service is used if the eCall
IMS emergency session is invoked without user input.
ETSI
[TS 24.229 clause 5.1.6.11.2]:
emergency service or of the manually initiated eCall type of emergency service and if allowed by IP-CAN specific
annex, the UE shall send an INVITE request as specified in the procedures in subclause 5.1.6.8 with the following
additions:
1) the UE shall set the Request-URI to "urn:service:sos.ecall.automatic" or "urn:service:sos.ecall.manual"; and
2) if the IP-CAN indicates the eCall support indication, the UE shall:
a) insert a multipart/mixed body containing an "application/EmergencyCallData.eCall.MSD" MIME body part

as defined in RFC 8147 [244], containing the MSD not exceeding 140 bytes and encoded in binary ASN.1
PER as specified in CEN EN 15722:2015 [245] and include a Content-Disposition header field with a
"handling" header field parameter with an "optional" value, as described in RFC 3261 [26];
b) insert an Accept header field indicating the UE is willing to accept an

"application/EmergencyCallData.Control+xml" MIME type as defined in RFC 8147 [244]; and
c) insert a Recv-Info header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244].
NOTE: Further content for the INVITE is as defined in RFC 8147 [244].
Then the UE shall proceed as follows:
2) if the UE receives a 200 (OK) response to the INVITE request containing:
a) a multipart/mixed body containing an "application/EmergencyCallData.Control+xml" MIME body part as

defined in RFC 8147 [244] with an "ack" element containing:
i) a "received" attribute set to "true"; and
ii) a "ref" attribute set to the Content-ID of the MIME body part containing the MSD sent by the UE;
then the UE shall consider the initial MSD transmission as successful;
System Simulator:
UE:
- UE contains either ISIM and USIM applications or only USIM application with eCall subscription on UICC.
Preamble:
ETSI

U-S Message
1 UE is triggered to start a manual eCall - - - -
Table 4.9.11.2.2-1 of TS 38.508-1 [21] with
condition ‘eCall’ are performed.
12 Step 1 of Annex A.3 happens --> REGISTER 1 P
Check: Does UE send a correctly composed
registration?
13 Step 2 of Annex A.3 happens <-- 401 Unauthorized - -
Check: Does UE send another REGISTER with
AKAv1-MD5 credentials?
15 Step 4 of Annex A.3 happens <-- 200 OK - -
described in steps 16 and 17, steps 11 to 13
specified in 38.508-1 [21] Table 4.9.11.2.2-1
takes place.
Check: Does the UE include MSD in the
message body?
Derivation path: Step 1 in Annex A.23 with Condition A20
Derivation path: Step 2 in Annex A.23 with Conditions A12 and A13
11.2 eCall over IMS / Automatic initiation / Normal registration /

Emergency registration / Success / 200 OK with ACK / 5GS
(1)
ensure that {
when { UE is being made to initiate an automatic eCall over IMS }
}
(2)
ETSI
ensure that {
when { UE receives a valid 401 (Unauthorized) response for the initial REGISTER request sent }
}
(3)
ensure that {
when { UE receives a valid 200 OK response for the REGISTER sent for authentication }
then { UE sends a correctly composed INVITE request with MSD }
}
(4)
with { UE having sent INVITE with MSD for automatic eCall over IMS }
ensure that {
}
(5)
ensure that {
}
[TS 24.229 clause 5.1.6.11.1]:
If the upper layers request establishment of an IMS emergency call of the manually initiated eCall type of emergency
service, the service URN shall be "urn:service:sos.ecall.manual" as specified in RFC 8147 [244].
emergency service, the service URN shall be "urn:service:sos.ecall.automatic" as specified in RFC 8147 [244].
NOTE 1: The manually initiated eCall type of emergency service is used when the eCall IMS emergency session is
invoked with user input. The automatically initiated eCall type of emergency service is used if the eCall
IMS emergency session is invoked without user input.
[TS 24.229 clause 5.1.6.11.2]:
emergency service or of the manually initiated eCall type of emergency service and if allowed by IP-CAN specific
annex, the UE shall send an INVITE request as specified in the procedures in subclause 5.1.6.8 with the following
additions:
1) the UE shall set the Request-URI to "urn:service:sos.ecall.automatic" or "urn:service:sos.ecall.manual"; and
2) if the IP-CAN indicates the eCall support indication, the UE shall:
a) insert a multipart/mixed body containing an "application/EmergencyCallData.eCall.MSD" MIME body part

as defined in RFC 8147 [244], containing the MSD not exceeding 140 bytes and encoded in binary ASN.1
PER as specified in CEN EN 15722:2015 [245] and include a Content-Disposition header field with a
"handling" header field parameter with an "optional" value, as described in RFC 3261 [26];
b) insert an Accept header field indicating the UE is willing to accept an

"application/EmergencyCallData.Control+xml" MIME type as defined in RFC 8147 [244]; and
c) insert a Recv-Info header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244].
NOTE: Further content for the INVITE is as defined in RFC 8147 [244].
ETSI
Then the UE shall proceed as follows:
2) if the UE receives a 200 (OK) response to the INVITE request containing:
a) a multipart/mixed body containing an "application/EmergencyCallData.Control+xml" MIME body part as

defined in RFC 8147 [244] with an "ack" element containing:
i) a "received" attribute set to "true"; and
ii) a "ref" attribute set to the Content-ID of the MIME body part containing the MSD sent by the UE;
then the UE shall consider the initial MSD transmission as successful;
System Simulator:
UE:
Preamble:

U-S Message
1 UE is triggered to start an automatic eCall - - - -
Table 4.9.11.2.2-1 of TS 38.508-1 [21] with
specified in Table 11.2.3.2-2 take place.
10- Steps 9-10 of Table 4.9.11.2.2-1 of TS 38.508-1 - - - -
11 [21] are performed.
take place.
message body?
request and end the call?
ETSI

U-S Message/PDU/SDU
- EXCEPTION: Step 1a1 describes behaviour - - - -
depending UE implementation; the "lower case
letter" identifies a step sequence that takes
1a1 The generic procedure for IP address allocation - - - -
in the user plane specified in subclause 4.5A.3
takes place.
registration?
11.3
11.4 eCall over IMS / Manual initiation / MSD transfer and 200
OK with ACK / SIP INFO for MSD Update / Success / 5GS
(1)
ensure that {
when { UE is being made to initiate a manual eCall over IMS }
then { UE performs IMS emergency registration and sends correctly composed INVITE with MSD }
}
(2)
with { UE having sent an INVITE }
ensure that {
}
(3)
ensure that {
when { UE receives SIP INFO requesting MSD update }
then { UE sends 200 OK acknowledging SIP INFO }
ETSI
(4)
with { UE having sent 200 OK for SIP INFO }
ensure that {
when { UE is able to provide the updated MSD }
then { UE sends a correctly composed SIP INFO with updated MSD information }
}
(5)
with { UE having received 200 OK acknowledging the reception of updated MSD in SIP INFO }
ensure that {
}
[TS 24.229 clause 5.1.6.11.3]:
During an emergency session established for eCall type of emergency service as described in subclause 5.1.6.11.2, if
the UE receives an INFO request with:
1) an Info-Package header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244];
2) a multipart/mixed body including:
a) an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 [244] containing

a "request" element with an "action" attribute set to "send-data" and a "datatype" attribute set to
"eCall.MSD"; and
b) a Content-Disposition header field set to "By-Reference" associated with the

"application/EmergencyCallData.Control+xml" MIME body part; and
3) a Content-Disposition header field set to "Info-Package" associated with the multipart/mixed body;
the UE shall proceed as follows:
1) if the UE is able to provide an updated MSD, the UE shall send an INFO request containing:
a) an Info-Package header field set to "EmergencyCallData.eCall.MSD" as defined in RFC 8147 [244];
b) a multipart/mixed body including:
i) an "application/EmergencyCallData.eCall.MSD" MIME body part as defined in RFC 8147 [244]

containing the MSD not exceeding 140 bytes and encoded in binary ASN.1 as specified in
CEN EN 15722:2015 [245]; and
ii) a Content-Disposition header field set to "By-Reference" associated with the

"application/EmergencyCallData.eCall.MSD" MIME body part; and
c) a Content-Disposition header field set to "Info-Package" associated with the multipart/mixed body; and
2) if the UE is not able to provide an updated MSD, the UE shall send an INFO request containing:
i) an "application/EmergencyCallData.Control+xml" MIME body part as defined in RFC 8147 [244] with

an "ack" element containing:
- a "ref" attribute set to the Content-ID of the "application/EmergencyCallData.Control+xml" MIME

body part in the INFO request received by the UE; and
ETSI
- an "actionResult" child element containing:
A) an "action" attribute set to "send-data";
B) a "success" attribute set to "false"; and
C) a "reason" attribute set to an appropriate value as defined in RFC 8147 [244]; and

c) a Content-Disposition header field set to "Info-Package" associated with the multipart/mixed body.
NOTE: Further content for the INFO request is as defined in RFC 8147 [244].
System Simulator:
UE:
Preamble:
ETSI

U-S Message
1 UE is triggered to start a manual eCall. - - - -
Table 4.9.11.2.2-1 of TS 38.508-1 [21] with
takes place.
message body?
15 Step 4 of Annex A.23 happens <-- SIP INFO - -
Check: Does the UE send 200 OK
acknowledging reception of SIP INFO?
17 Step 6 of Annex A.23 happens --> SIP INFO 4 P
SIP INFO with updated MSD information?
Table 11.4.3.3-3: SIP INFO (step 17, table 11.4.3.2-1)
11.5 eCall over IMS / Automatic initiation / MSD transfer and 200
OK with ACK / SIP INFO request for MSD update / Success
/ 5GS
(1)
ensure that {
ETSI
}
(2)
ensure that {
}
(3)
ensure that {
when { UE receives SIP INFO requesting MSD update }
}
(4)
ensure that {
when { UE is able to provide the updated MSD }
then { UE sends a correctly composed SIP INFO with updated MSD information }
}
(5)
with { UE having received 200 OK acknowledging the reception of updated MSD in SIP INFO }
ensure that {
}
[TS 24.229 clause 5.1.6.11.3]:

"eCall.MSD"; and


CEN EN 15722:2015 [245]; and
ETSI




System Simulator:
UE:
Preamble:
ETSI

U-S Message
Table 4.9.11.2.2-1 of TS 38.508-1 [21] with
specified in Table 11.5.3.2-2 take place
takes place.
message body?
SIP INFO with updated MSD information?

U-S Message/PDU/SDU
takes place.
2 Step 1 of Annex A.3 happens --> REGISTER - -
registration?
ETSI
11.6 eCall over IMS / Automatic initiation / MSD transfer and 200
OK with ACK / SIP INFO request for unsupported MSD / UE
indicates unsuccessful in SIP INFO / 5GS
(1)
ensure that {
}
(2)
ensure that {
}
(3)
with { automatic eCall over IMS being established }
ensure that {
when { UE receives SIP INFO requesting MSD update with unsupported datatype }
}
(4)
ensure that {
when { UE is unable to provide the MSD information }
then { UE sends a correctly composed SIP INFO with “success” attribute set to false in ack
element }
}
[TS 24.229 clause 5.1.6.11.3]:
ETSI

"eCall.MSD"; and


CEN EN 15722:2015 [245]; and




System Simulator:
ETSI
UE:
Preamble:

U-S Message
Table 4.9.11.2.2-1 of TS 38.508-1 [21] with
specified in Table 11.6.3.2-2 take place
takes place.
SIP INFO with ack element containing
“success” attribute set to “false”?
20 Step 2 of Annex A.8 happens --> 200 OK - -

U-S Message/PDU/SDU
takes place.
registration?
ETSI
Derivation path: Step 4 in Annex A.23

Message-body --boundaryXXX
Content-Type:
application/EmergencyCallData.Control+xml
Content-ID: <[email protected]>
Content-Disposition: by-reference
<?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.Control
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:contr
ol">
<request action="send-data"
datatype="eCall.invalidMSD"/>
</EmergencyCallData.Control>
--boundaryXXX
ETSI
Annex A (normative):
Generic Test Procedures
A.1 Introduction
This annex specifies general procedures for IMS usages as well as application specific procedures, e.g. for a MTSI
client.
A.2 IMS Registration / 5GS

Expected sequence
Step Direction Message Comment
UE SS


1 REGISTER The UE sends initial registration for IMS services.
2 401 Unauthorized The SS responds with a valid AKAv1-MD5
authentication challenge and security mechanisms

supported by the network.
3 REGISTER The UE completes the security negotiation
procedures, sets up a temporary set of SAs and
uses those for sending another REGISTER with

AKAv1-MD5 credentials.
4 200 OK The SS responds with 200 OK.
- EXCEPTION: In parallel to the events
described in steps 5-8, the steps
specified in Annex A.10 on PUBLISH

may happen.
5 SUBSCRIBE The UE subscribes to its registration event

package.

7 NOTIFY The SS sends initial NOTIFY for registration event
package, containing full registration state
information for the registered public user identity in

the XML body.
8 200 OK The UE responds with 200 OK.
ETSI
Specific Message Contents
REGISTER (Step 1)
Use the default message "REGISTER" in Annex A.1.1 of TS 34.229-1 [2] applying condition A1.
401 Unauthorized (Step 2)
Use the default message "401 Unauthorized for REGISTER" in Annex A.1.2 of TS 34.229-1 [2] applying condition A1.
REGISTER (Step 3)
Use the default message "REGISTER" in Annex A.1.1 of TS 34.229-1 [2] applying conditions A2 and A32.
200 OK (Step 4)
Use the default message "200 OK for REGISTER" in Annex A.1.3 of TS 34.229-1 [2] applying condition A2.
SUBSCRIBE (Step 5)
Use the default message "SUBSCRIBE for reg-event package" in Annex A.1.4 of TS 34.229-1 [2] applying conditions
A1 and A7.
200 OK (Step 6)
Use the default message "200 OK for SUBSCRIBE" in Annex A.1.4 of TS 34.229-1 [2] applying condition A1.
NOTIFY (Step 7)
Use the default message "NOTIFY for reg-event package" in Annex A.1.6 of TS 34.229-1 [2] applying condition A1.
200 OK (Step 8)
Use the default message "200 OK for requests other than REGISTER or SUBSCRIBE" in Annex A.3.1 of TS 34.229-1
[2] applying conditions A5, A8, and A22.
ETSI
A.3 IMS Emergency Registration / 5GS

Test procedure:
1) SS waits for the UE to send an initial REGISTER request.
2) The SS responds to the initial REGISTER request with a valid 401 Unauthorized response.
3) The SS waits for the UE to set up a temporary set of security associations and to send another REGISTER
request over those security associations.
4) The SS responds to the second REGISTER request with valid 200 OK response, sent over the same temporary
set of security associations that the UE used for sending the REGISTER request.
Expected sequence:
UE SS


1 REGISTER The UE sends initial IMS emergency registration
2 401 Unauthorized The SS responds with a valid AKAv1-MD5
authentication challenge and security mechanisms

supported by the network.
3 REGISTER The UE completes the security negotiation
procedures, sets up a temporary set of SAs and
uses those for sending another REGISTER with

AKAv1-MD5 credentials.
Specific Message Contents:
REGISTER (Step 1)
Use the default message “REGISTER” in Annex A.1.1 of TS 34.229-1 [2] with conditions A1 and A7.
401 Unauthorized (Step 2)
Use the default message “401 Unauthorized for REGISTER” in Annex A.1.2 of TS 34.229-1 [2] with condition A1.
REGISTER (Step 3)
Use the default message “REGISTER” in Annex A.1.1 of TS 34.229-1 [2] with conditions A2, A7, and A32.
200 OK for REGISTER (Step 4)
Use the default message “200 OK for REGISTER” in Annex A.1.3 of TS 34.229-1 [2] with condition A3.
ETSI
A.4 MTSI MO Voice Call / 5GS
A.4.1 MTSI MO Voice Call / with preconditions / 5GS

Expected sequence
UE SS


1 INVITE UE sends INVITE with the first SDP offer.

2 100 Trying SS sends a 100 Trying provisional response.

3 183 Session Progress SS sends an SDP answer.
4 PRACK UE acknowledges reception of 183 Session

Progress.

5 200 OK SS responds to PRACK.
6 UPDATE UE sends a second SDP offer in an UPDATE

request.

7 200 OK SS responds to UPDATE.

8 180 Ringing SS sends 180 Ringing reliably.

9 PRACK UE acknowledges reception of 180 Ringing.


11 200 OK SS responds to INVITE.
12 ACK UE acknowledges.
ETSI
INVITE (Step 1)
Use the default message "INVITE for MO Call Setup" in Annex A.2.1 of TS 34.229-1 [2] applying conditions A1, A3,
A4, A28, A29, A30, and A31, and with the following exceptions:
ETSI
Supported
ETSI
v=0
o=(username) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE)
s=(session name)
Time description:
Media description:

a=fmtp: (format) br=5.9-13.2; bw=nb-swb; max-red= (att-field) [Note 4, 5, 10, 12]
a=fmtp: (format) br=13.2; bw=swb; max-red= (att-field) [Note 4, 5, 10, 14]
a=fmtp: (format) br=9.6-13.2; bw=swb; max-red= (att-field) [Note 4, 5, 10, 15]
a=fmtp: (format) bw=nb-swb; max-red= (att-field) [Note 4, 5, 11]
a=fmtp: (format) mode-change-capability=2; max-red= (att-field) [Note 4, 6]
a=fmtp: (format)
a=fmtp: (format)
a=ptime:20
a=maxptime:240

a=crypto:1
AES_CM_128_HMAC_SHA1_80inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2
^20|


Note 2: The RR value shall be greater than 0. The RS value can be any value.
Note 5: The parameters dtx, dtx-recv and evs-mode-switch shall not be present.
Note 6: The parameters mode-set, mode-change-period, mode-change-neighbor, crc, robust-
sorting and interleaving shall not be included.
ETSI
Note 7: Attributes for ECN Capability may be present if the UE supports Explicit Congestion
Notification.
Note 8: Attributes for media plane security are present if the use of end-to-access-edge security
is supported by UE.
Note 9: The ordering of payload types shall be as listed, i.e., EVS before AMR-WB before AMR
according to NG.114 [31].
Note 10: The EVS payload type shall carry at least one of the five EVS configurations according
to NG.114 [31] clause 3.2.2.3. In addition, if there is no further EVS payload type according to
the criteria of Note 11, the following rules shall be checked:
IF the first EVS payload type is configuration B0 or B1 THEN
there shall be a second EVS payload type with configuration A1
ELSE IF the first EVS payload type is configuration B2 THEN
(NOTE: if the first EVS payload type is configuration A1 or A2 there does not need to be any
further EVS payload type)
Note 11: Further EVS payload type according to NG.114 [31] clause 3.2.2.3 with bandwidth up
to super-wideband, no br parameter and no mode-set parameter.
Note 12: EVS payload type with EVS Configuration A1 (NG.114 [31] clause 3.2.2.3).
Note 14: EVS payload type with EVS Configuration B0 (NG.114 [31] clause 3.2.2.3).
100 Trying (Step 2)
Use the default message "100 Trying for INVITE" in Annex A.2.2 of TS 34.229-1 [2] applying condition A1.
ETSI
Use the default message "183 Session Progress for INVITE" in Annex A.2.3 of TS 34.229-1 [2] applying condition A1,
and with the following exceptions:
Require
v=0
s=-
b=AS:65
Time description:
t=0 0
Media description:
b=AS:65

a=fmtp: (format) br=13.2; bw=swb; mode-set=0,1,2; max-red=220 [Note 8]
a=fmtp: (format) br=5.9-13.2; bw=nb-swb; mode-set=0,1,2; max-red=220 [Note 9]
a=ptime:20
a=maxptime:240

a=crypto:1
20|1:4 [Note 7]

Note 4: Void
Note 5: Void
Notification.
supported by UE.
Note 8: This EVS configuration is sent if UE sent it as the first of its EVS configurations in INVITE.
Note 9: This EVS configuration is sent if UE did not send "br=13.2; bw=swb" as the first of its EVS
configurations in INVITE.
PRACK (Step 4)
Use the default message "PRACK" in Annex A.2.4 of TS 34.229-1 [2] applying conditions A1 and A7.
ETSI
200 OK for PRACK (Step 5)
Use the default message "200 OK for other requests than REGISTER or SUBSCRIBE" in Annex A.3.1 of TS 34.229-1
[2] applying conditions A10 and A22.
UPDATE (Step 6)
Use the default message "UPDATE" in Annex A.2.5 of TS 34.229-1 [2] applying conditions A1 and A6, and with the
Require
v=0
s=(session name)
Time description:
t=0 0
Media description:

a=rtpmap: (payload type) EVS/16000 [Note 3] [Note 5] [Note 6]
a=fmtp: (format) br=13.2; bw=swb; max-red=(att-field) [Note 7]

a=fmtp: (format) br=5.9-13.2; bw=nb-swb; max-red=(att-field) [Note 8]


one
Note 4: Void
Note 5: The channel number shall be "/1" or omitted
Note 6: EVS shall be the only codec in UPDATE and shall come with the same configuration
parameters as sent in 183 Session Progress
Note 7: Sent by UE if it sent it as first of its EVS configurations in INVITE.
Note 8: Sent by UE if it did not send "br=13.2; bw=swb" as the first of its EVS configurations in
INVITE.
ETSI
200 OK for UPDATE (Step 7)
[2] applying conditions A1, A10 and A22, and with the following exceptions:
Require
Content-Type
Content-
Length
Message-body SDP body of the 200 response copied from the received UPDATE and modified as follows:
- IP address on "c=" lines and transport port on "m=" lines changed to indicate to which IP
address and port the UE should start sending the media;
- "o=" line identical to previous SDP sent by SS except that sess-version is incremented;
- Attributes for preconditions: a=curr:qos remote sendrecv
180 Ringing (Step 8)
Use the default message "180 Ringing for INVITE" in Annex A.2.6 of TS 34.229-1 [2] applying conditions A1 and A3.
PRACK (Step 9)
[2] applying condition A10.
200 OK for INVITE (Step 11)
ACK (Step 12)
Use the default message "ACK" in Annex A.2.7 of TS 34.229-1 [2] applying conditions A1 and A3.
ETSI
A.4.1a MTSI MO Voice Call / Default Configuration / 5GS

Expected sequence
UE SS





Progress.


request.





ETSI
INVITE (Step 1)
ETSI
Supported
v=0
s=(session name)
Time description:
Media description:

a=fmtp: (format) br=5.9-24.4; bw=nb-swb; max-red= (att-field) [Note 4, 5]
a=fmtp: (format)
a=fmtp: (format)
a=ptime:20
a=maxptime:240

a=crypto:1
^20|


Notification.
is supported by UE.
ETSI
100 Trying (Step 2)
Require
v=0
s=-
b=AS:65
Time description:
t=0 0
Media description:
b=AS:65

a=ptime:20
a=maxptime:240

a=crypto:1
20|1:4 [Note 5]

Notification.
supported by UE.
PRACK (Step 4)
ETSI
UPDATE (Step 6)
Require
v=0
s=(session name)
Time description:
t=0 0
Media description:

a=rtpmap: (payload type) EVS/16000 [Note 3,5]
a=fmtp: (format) [Note 3,4]


one.
Note 3: The value for fmt, payload type and format are not checked.
Note 4: Parameters for the codec are not checked.
ETSI
Require
Content-Type
Content-
Length
PRACK (Step 9)
ACK (Step 12)
A.4.2 MTSI MO Voice Call / without preconditions / 5GS

Expected sequence
UE SS





Progress.


6 180 Ringing SS sends 180 Ringing.

ETSI
INVITE (Step 1)
Use the default message "INVITE for MO Call" in Annex A.2.1 of TS 34.229-1 [2] applying conditions A1, A3, A4,
A28, A29, A30, and A31, and with the following exceptions:
ETSI
Supported
option-tag precondition – option tag not present
Note: this does not affect any other option tags in the Supported header as for instance
prescribed in TS 34.229-1 [2] Annex A.2.1
ETSI
v=0
s=(session name)
Time description:
Media description:

a=fmtp: (format)
a=fmtp: (format)
a=ptime:20
a=maxptime:240

a=crypto:1
^20|
Attributes for preconditions: not present

Notification.
is supported by UE.
ETSI
ETSI
100 Trying (Step 2)
Use the default message "183 Session Progress" in Annex A.2.3 of TS 34.229-1 [2] applying condition A1, and with the
v=0
s=-
b=AS:65
Time description:
t=0 0
Media description:
b=AS:65

a=ptime:20
a=maxptime:240

a=crypto:1
AES_CM_128_HMAC_SHA1_80inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|
2^20|1:4 [Note 7]
Note 4: Void
Note 5: Void
Notification.
is supported by UE.
Note 8: This EVS configuration is sent if UE sent it as the first of its EVS configurations in
INVITE.
Note 9: This EVS configuration is sent if UE did not send "br=13.2; bw=swb" as the first of its
EVS configurations in INVITE.
PRACK (Step 4)
ETSI
Use the default message "180 Ringing for INVITE" in Annex A.2.6 of TS 34.229-1 [2] applying conditions A1 and
A14.
ACK (Step 8)
ETSI
A.5 MTSI MT Voice Call / 5GS
A.5.1 MTSI MT Voice Call / with preconditions / 5GS

Expected sequence
UE SS


1 INVITE SS sends INVITE with the first SDP offer.
2 100 Trying Optional step: UE may send a 100 Trying

3 183 Session Progress UE sends 183 Session Progress response reliably,

including an SDP answer.
4 PRACK SS acknowledges reception of 183 Session

Progress.

5 200 OK UE responds to PRACK.

6 UPDATE SS sends a second SDP offer
7 200 OK UE responds to UPDATE, including an SDP

answer.

8 180 Ringing UE sends 180 Ringing.
9 PRACK Conditional step: if UE sent 180 Ringing reliably,

SS acknowledges reception of 180 Ringing
10 200 OK Conditional step: if UE sent 180 Ringing reliably,
UE responds to PRACK.

10A Make UE accept the voice call.

11 200 OK UE responds to INVITE.
12 ACK SS acknowledges.
ETSI
INVITE (Step 1)
Use the default message "INVITE for MT Call" in Annex A.2.9 of TS 34.229-1 [2] applying conditions A1, A3, and
A4, and with the following exceptions:
Supported
v=0
s=-
b=AS:65
Time description:
t=0 0
Media description:
m=audio (transport port) RTP/AVP 96 97 98 99 100 102
b=AS:65
b=RS:0
b=RR:2000

a=rtpmap: 96 EVS/16000/1
a=fmtp: 96 br=13.2; bw=swb; max-red=220
a=fmtp: 102 br=5.9-13.2; bw=nb-swb; max-red=220
a=rtpmap:97 AMR-WB/16000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=rtpmap: 98 telephone-event/16000
a=fmtp: 98 0-15
a=rtpmap:99 AMR/8000/1
a=fmtp: 100 0-15
a=ptime:20
a=maxptime:240

100 Trying (Step 2)
ETSI
Status-Line
Reason- Not checked
Phrase
Require
v=0
o=(user-name) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE)
s=(session name)
Time description:
t=0 0
Media description:

a=fmtp:(format) br=13.2; bw=swb; mode-set=0,1,2; max-red=(att-field)

a=curr:qos local none or a=curr:qos local sendrecv
PRACK (Step 4)
Use the default message "PRACK" in Annex A.2.4 of TS 34.229-1 [2] applying condition A3.
200 OK (Step 5)
[2] applying conditions A5, A8, A11, and A22.
ETSI
UPDATE (step 6)
Use the default message "UPDATE" in Annex A.2.5 of TS 34.229-1 [2] applying condition A3, and with the following
exceptions:
Require
v=0
s=-
b=AS:65
Time description:
t=0 0
Media description:
b=AS:65
b=RS:0
b=RR:2000

a=fmtp:96 br=(att-field); bw=(att-field); max-red=220 [Note 2]
a=ptime:20
a=maxptime:240

a=curr:qos remote none or curr:qos remote sendrecv [Note 1]
Note 1: Use the value (none/sendrecv) received from 183 Session Progress and attribute
a=curr:qos local.
ETSI
200 OK (step 7)
[2] applying conditions A2, A11, and A22, and with the following exceptions:
Require
Content-Type
Content- header shall be present if UE uses TCP to send this message and if there is a message body
Length
v=0
o=(user-name) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE) [Note 4]
s=(session name)
Time description:
t=0 0
Media description:



one.
Content-Type Header not present
media-type
Length
value 0
ETSI
PRACK (Step 9)
200 OK (Step 10)
200 OK (Step 11)
ACK (Step 12)
A.5.1a MTSI MT Voice Call / Default Configuration / 5GS

Expected sequence
UE SS





Progress.



answer.


9 PRACK SS acknowledges reception of 180 Ringing


ETSI
INVITE (Step 1)
Supported
v=0
s=-
b=AS:65
Time description:
t=0 0
Media description:
m=audio (transport port) RTP/AVP 96 97 98 99 100
b=AS:65
b=RS:0
b=RR:2000

a=fmtp:96 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:98 telephone-event/16000
a=fmtp:98 0-15
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:20
a=maxptime:240

100 Trying (Step 2)
ETSI
Status-Line
Reason- Not checked
Phrase
Require
v=0
s=(session name)
Time description:
t=0 0
Media description:

a=fmtp:(format) br=5.9-24.4; bw=nb-swb; max-red=(att-field)

Note 2: The values for fmt, payload type and format are not checked
PRACK (Step 4)
200 OK (Step 5)
ETSI
UPDATE (step 6)
exceptions:
Require
v=0
s=-
b=AS:65
Time description:
t=0 0
Media description:
b=AS:65
b=RS:0
b=RR:2000

a=ptime:20
a=maxptime:240

a=curr:qos local.
ETSI
200 OK (step 7)
[2] applying conditions A2, A11, and A22, and with the following exceptions:
Require
Content-Type
Length
v=0
s=(session name)
Time description:
t=0 0
Media description:



one.
Require
option-tag 100rel
media-type
Length
value 0
ETSI
PRACK (Step 9)
200 OK (Step 10)
200 OK (Step 11)
ACK (Step 12)
ETSI
A.5.2 MTSI MT Voice Call / without preconditions / 5GS

Expected sequence
UE SS





Progress.





INVITE (Step 1)
ETSI
v=0
s=-
b=AS:65
Time description:
t=0 0
Media description:
b=AS:65
b=RS:0
b=RR:2000

a=fmtp: 98 0-15
a=fmtp: 100 0-15
a=ptime:20
a=maxptime:240
100 Trying (Step 2)
ETSI
Status-Line
Not checked
Reason-
Phrase
Supported option-tag “precondition” not present in Supported header
option- precondition
tag
v=0
s=(session name)
Time description:
t=0 0
Media description:


PRACK (Step 4)
200 OK (Step 5)
media-type
Length
value 0
PRACK (Step 7)
ETSI
ACK (Step 10)
ETSI
A.6 IMS Emergency Voice Call / 5GS

Expected sequence
UE SS




3 180 Ringing SS sends a 180 Ringing.

4 200 OK SS responds INVITE with 200 OK.
INVITE (Step 1)
Use the default message "INVITE for MO Call" in Annex A.2.1 of TS 34.229-1 [2] with condition A28 and the
v=0
s=(session name)
Time description:
t=(start-time) (stop-time)
Media description:

Note 2: AMR-WB/16000 codec shall be present in the media attributes, optionally including
channel number "/1".
180 Ringing for INVITE (Step 3)
Use the default message "180 Ringing for INVITE" in Annex A.2.6 of TS 34.229-1 [2] with conditions A4 and A14.
ETSI
[2] with conditions A6 and A22 and the following exceptions:
Content-Type
Content-Length
v=0
o=- 1111111111 1111111111 IN (addrtype) (unicast-address for SS)s=-

c=IN (addrtype) (connection-address for SS)b=AS:37
Time description:
t=0 0
Media description:
m=audio (transport port) RTP/AVP (fmt) [Note 1]b=AS:37
b=RS:0
b=RR:0

a=rtpmap: (payload type) AMR-WB/16000/1 [Note 1]a=fmtp: (format) mode-change-capability=2;
max-red=220a=ptime:20
a=maxptime:240
ACK (step 5)
ETSI
A.7 MO Release of Voice or Video Call / 5GS

Expected sequence
Step Direction Message/Procedure Comment
UE SS


1 BYE The UE releases the call with BYE
2 200 OK The SS sends 200 OK for BYE
Specific message contents
BYE (Step 1)
Use the default message "BYE" in Annex A.2.8 of TS 34.229-1 [2] with conditions A1 and A8.
200 OK (Step 2)
Use the default message "200 OK for other requests than REGISTER or SUBSCRIBE" in annex A.3.1 of TS 34.229-1
[2] with condition A10.
ETSI
A.8 MT Release of Voice or Video Call / 5GS

Expected sequence
UE SS


1 BYE The SS releases the call with BYE
2 200 OK The UE sends 200 OK for BYE
BYE (Step 1)
Use the default message "BYE" in Annex A.2.8 of TS 34.229-1 [2] with conditions A3 and A8.
200 OK (Step 2)
Use the default message "200 OK for other requests than REGISTER or SUBSCRIBE" in annex A.3.1 of TS 34.229-1
[2] with conditions A5, A8, and A22.
ETSI
A.9 EPS Fallback for Voice Call / 5GS
A.9.1 EPS Fallback for Voice Call / steps before fallback / 5GS
Expected sequence
UE SS


1 INVITE UE sends INVITE including an SDP offer.

3 183 Session Progress SS sends 183 Session Progress including an SDP

answer.

Progress.
5 200 OK SS sends 200 OK for PRACK.
INVITE (Step 1)
Use the default message "INVITE for MO Call Setup" in Annex A.2.1 of TS 34.229-1 [2] with conditions A1, A3, A4,
and A28 and the following exceptions:
Supported
option-tagprecondition
Note1: the precondition option-tag is only required when the UE is configured to use preconditions.
Note 2: the precondition option-tag being required does not affect any other option tags in the Supported
header as for instance prescribed in TS 34.229-1 [2] Annex A.2.1
Message-body SDP body present but contents not checked
100 Trying (Step 2)
Use the default message "100 Trying for INVITE" in Annex A.2.2 of TS 34.229-1 [2] with condition A1.
ETSI
Use the default message "183 Session Progress for INVITE" in Annex A.2.3 of TS 34.229-1 [2] with condition A1 and
the following exceptions:
Require present if UE is configured to use preconditions
- v=0
- o=- 1111111111 1111111111 IN (addrtype) (unicast-address for SS)
- s=-
- c=IN (addrtype) (connection-address for SS)
- b=AS:37
Time description:
- t=0 0
Media description:
- m=audio (transport port) RTP/AVP (fmt) [Note 1, 4]
- b=AS:37
- b=RS:0
- b=RR:2000

- a=rtpmap: (payload type) AMR-WB/16000/1 [Note 1]
- a=fmtp: (format) mode-change-capability=2; max-red=220 [Note 1]
- a=ecn-capable-rtp: leap ect=0 [Note 2]
- a=rtcp-fb:* nack ecn [Note 2]
- a=rtcp-xr:ecn-sum [Note 2]
- a=ptime:20
- a=maxptime:240

- a=3ge2ae: requested [Note 3]
- a=crypto:1
AES_CM_128_HMAC_SHA1_80inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
[Note 3]
Attributes for preconditions: [Note 5]

Note 1: The value for fmt, payload type (AMR) and format is copied from Step 1.
Note 2: Attributes for ECN Capability are present if the UE supports Explicit Congestion Notification.
supported by UE.
Note 4: transport port is the port number of the SS (see RFC 3264 clause 6).
Note 5: present if UE is configured to use preconditions
PRACK (Step 4)
Use the default message "PRACK" in Annex A.2.4 of TS 34.229-1 [2] with conditions A1 and A7.
200 OK (Step 5)
[2] with conditions A10 and A22.
ETSI
A.9.2 EPS Fallback for Voice Call / steps after fallback / 5GS
Expected sequence
UE SS
1 SS starts a timer (5 seconds) to wait for
an optional REGISTER request from UE.
NOTE: if the UE does not send
REGISTER and is configured to use
preconditions, it may send UPDATE right
away. In that case, the timer is stopped
upon arrival of UPDATE.
- EXCEPTION: Steps 2a1-2a3 describes
behaviour that depends on UE
implementation.
The “lower case letter” identifies a step
sequence that takes place if such
implementation was applied.
2a1 --> REGISTER Optional step: the UE may register for IMS on
EPS.
2a2 <-- 200 OK Conditional step: if the UE sent REGISTER, the
SS responds with 200 OK.
2a3 Timer from step 1 is stopped.
- - EXCEPTION: Steps 3a1 to 3a2 describe -
behaviour that depends on UE
configuration; the “lower case letter”
identifies a step sequence that takes
place if such configuration was
conducted.
3a1 --> IF the UE is configured to use UPDATE contains a second SDP offer.
preconditions THEN the UE sends
UPDATE
3a2 <-- 200 OK for UPDATE Conditional step: if the UE sent UPDATE, the SS
sends 200 OK for UPDATE containing a second
SDP answer.
4 <-- 180 Ringing 180 Ringing is sent unreliably.
5 <-- SS sends 200 OK for INVITE -
6 --> ACK -
REGISTER (Step 2a1)
Use the default message "REGISTER" in Annex A.1.1 of TS 34.229-1 [2] applying conditions A2 and A31.
200 OK (Step 2a2)
Use the default message "200 OK for REGISTER" in Annex A.1.3 of TS 34.229-1 [2] with condition A2.
UPDATE (Step 3a1)
Use the default message "UPDATE" in Annex A.2.5 of TS 34.229-1 [2] with conditions A1 and A5 and the following
exceptions:
ETSI
Require
Note1: the precondition option-tag is only required when the UE is configured to use
preconditions.
Note 2: the precondition option-tag being required does not affect any other option
tags in the Require header as for instance prescribed in TS 34.229-1 [2] Annex A.2.6
- v=0
- o=(username) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE)
[Note 2]
- s=(session name)
- c=IN (addrtype) (connection-address for UE) [Note 1]
- b=AS: (bandwidth-value)
Time description:
- t=0 0
Media description:
- m=audio (transport port) RTP/AVP (fmt) [Note 2]
- b=RS: (bandwidth-value)
- b=RR: (bandwidth-value)

- a=rtpmap: (payload type) AMR-WB/16000 [Note 2] [Note 4]
- a=fmtp: (format) [Note 2, 3]


Note 4: The AMR channel number shall be “/1” or omitted.
200 OK (Step 3a2)
[2] with conditions A1, A10 and A21 and the following exceptions:
Require present if UE is configured to use preconditions
Content-Type
Content-Length
Message-body SDP body of the 200 OK response copied from the received UPDATE and modified as
follows:
- IP address on "c=" lines and transport port on "m=" lines changed to indicate to
which IP address and port the UE should start sending the media;
incremented.
Use the default message "180 Ringing for INVITE" in Annex A.2.6 of TS 34.229-1 [2] with conditions A1 and A13.
ETSI
200 OK (Step 5)
Use the default message "200 OK for requests other than REGISTER or SUBSRIBE" in Annex A.3.1 of TS 34.229-1
[2] with conditions A1, A10, A19, and A21.
ACK (Step 6)
Use the default message "ACK" in Annex A.2.7 of TS 34.229-1 [2] with condition A1.
ETSI
A.10 Default handling of PUBLISH requests

This procedure may occur within 3 seconds after a successful IMS registration.
NOTE: For sake of testability and to mitigate detrimental effect on non-IMS test cases, it is assumed that such
PUBLISH request arrives at SS within 3 seconds of sending 200 OK for REGISTER.
The generic test procedure:
1 SS receives from the UE a PUBLISH request.
2 The SS responds to the PUBLISH request with a 503 Service Unavailable response carrying a Retry-after header
field big enough to quench further publication traffic during test case execution.
Expected sequence
UE SS


1 PUBLISH The UE sends a PUBLISH request (A.4.3).
2 503 Service Unavailable The SS responds with 503 Service Unavailable
(A.4.2).
PUBLISH (Step 1)
Use the default message "PUBLISH" in Annex A.4.3 of TS 34.229-1 [2] applying conditions A1 and A5.
503 Service Unavailable (Step 2)
Use the default message “503 Service Unavailable” in Annex A.4.2 of TS 34.229-1 [2] and with the following
exceptions:
Header/param Value/remark Rel Reference

Retry-after RFC 3261 [6]
period 7200
duration Not present
comment Not present
ETSI
A.11 Mobile Initiated De-Registration / 5GS

IMS de-registration is initiated on the UE. The SS waits for the UE to send a REGISTER request, in accordance with
3GPP TS 24.229 [7], clause 5.1.1.6.
Expected sequence:
UE SS
0A  SUBSCRIBE Optional: The UE unsubscribes from one of
its subscribed to event packages.
0B  200 OK If the UE sent SUBSCRIBE, the SS
responds to SUBSCRIBE with 200 OK.
0C  NOTIFY If the UE sent SUBSCRIBE, the SS sends a

final NOTIFY
0D 200 OK If the UE sent SUBSCRIBE, the UE

responds to NOTIFY with 200 OK.
1 REGISTER The UE sends a de-registration request for
IMS services.
2  200 OK The SS responds to REGISTER with 200
OK.
Note 1: Steps 0A-0D may be repeated for any or all event packages subscribed to by the UE. It is the UE’s
decision which unsubscriptions to perform.
Note 2: The UE can send the 200 OK for NOTIFY (step 0D) after the REGISTER request (step 1) or even not
send it at all.
SUBSCRIBE (step 0A)
Use the default message “SUBSCRIBE for reg-event package” in Annex A.1.4 of TS 34.229-1 [2] or “SUBSCRIBE for
conference event package” in Annex A.5.1 of TS 34.229-1 [2] or “SUBSCRIBE for message-summary event package”
in Annex A.6.1 of TS 34.229-1 [2], and with the following exceptions:

From
addr-spec Same as in original SUBSCRIBE that set up the
corresponding subscription
tag Same as in original SUBSCRIBE that set up the
corresponding subscription
To
addr-spec As specified in TS 34.229-1 [2] Annex A.1.4/A.5.1/A.6.1
tag Same as in 200 OK for original SUBSCRIBE that set up
the corresponding subscription
CSeq
value value of the previous SUBSCRIBE sent by the UE for this
dialog incremented by one
method SUBSCRIBE
Expires
delta-seconds 0
200 OK for SUBSCRIBE (step 0B)
Use the default message “200 OK for SUBSCRIBE” in Annex A.1.5, A.5.2 or A.6.3 of TS 34.229-1 [2], whatever
appropriate, with the following exceptions:

To RFC 3261 [6]
addr-spec As specified in TS 34.229-1 [2] Annex A.1.4/A.5.1/A.6.1
tag Same as in step 0A
Expires RFC 3261 [6]
delta-seconds 0
ETSI
NOTIFY (step 0C)

Request-Line RFC 3261 [6]
Method NOTIFY
Request-URI UE’s contact address in SIP URI form, as provided in the
Contact header within the SUBSCRIBE creating the dialog
SIP-Version SIP/2.0
Via order of the parameters in this header must be like in this RFC 3261 [6]
table
via-param1:
sent-protocol SIP/2.0/UDP when using UDP or
SIP/2.0/TCP when using TCP
sent-by IP address and protected server port of SS
via-branch value starting with ‘z9hG4bK’ (NOTE 1)
via-param2:
sent-protocol SIP/2.0/UDP when using UDP or
SIP/2.0/TCP when using TCP
sent-by scscf.3gpp.org
via-branch value starting with ‘z9hG4bK’ (NOTE 1)
From RFC 3261 [6]
addr-spec same URI as received in the To header of the
corresponding SUBSCRIBE message
tag same as to-tag in step 0A
To RFC 3261 [6]
addr-spec same URI as received in the From header of the
corresponding SUBSCRIBE message
tag same as from-tag in step 0A
Call-ID RFC 3261 [6]
callid same as value received in SUBSCRIBE message
CSeq RFC 3261 [6]
value 1
method NOTIFY
addr-spec A1 <sip:scscf.3gpp.org>
addr-spec A2 sip:final@conf-factory. appended with
px_IMS_HomeDomainName
addr-spec A3 <scscf.3gpp.org>
Event RFC 6665 [28]
event-type A1 reg RFC 3680 [18]
event-type A2 conference
event-type A3 message-summary
Max-Forwards RFC 3261 [6]
value 69
Subscription-State RFC 6665 [28]
substate-value terminated
Content-Length
value 0
A1 Final NOTIFY sent for reg-event
A2 Final NOTIFY sent for conf-event
A3 Final NOTIFY sent for message-summary
NOTE 1: Branch parameter values sent by SS are different within a test case execution.
200 OK (step 0D)
[2].
REGISTER (step 1)
ETSI
Use the default message “REGISTER” in Annex A.1.1 of TS 34.229-1 [1] with conditions A2 and A17 "UE initiated
IMS re-registration or de-registration" with the following exceptions:

addr-spec SIP URI with IP address or FQDN and protected server
port of the UE, AND,
if the UE supports GRUU, the following parameter:
+sip.instance="<urn:gsma:imei: (gsma-specifier-defined-
substring)>”, OR
*
Expires (must be present if addr-spec is *) RFC 3261 [6]
delta-seconds 0 (if present)
Supported header may be missing or it may contain any value
Authorization value not checked
NOTE: In contrast to Annex A.1.1 of TS 34.229-1 [2], the Contact header does not have any further mandatory
feature parameters.
200 OK (step 2)
Use the default message “200 OK for REGISTER” in Annex A.1.3 of TS 34.229-1 [2] with the following exceptions:

addr-spec same value as in REGISTER request if "*" is not included
in the Contact header field of the REGISTER request in
step 1
same value as in the Contact header field of the "200 OK"
response to the initial registration if "*" is included in the
Contact header field of the REGISTER request in step 1
(NOTE)
expires 0
NOTE: According to 3GPP TS 24.229 [7] clause 5.4.1.4.1 when the S-CSCF gets a wild-carded contact address for
de-registration it shall include all de-registered contact addresses in the contact header of the 200 OK
response  there is no “*” in DL
ETSI
A.12 IMS Re-Registration / 5GS

The generic test procedure for IMS re-registration
Expected sequence
UE SS


1 REGISTER The UE sends a re-registration request.
REGISTER (Step 1)
Use the default message “REGISTER” in Annex A.1.1 of TS 34.229-1 [2] with conditions A2 and A32.
ETSI
A.13 IMS MO SMS / 5GS

Expected sequence
UE SS
1  SIP MESSAGE UE sends a SIP MESSAGE request including a
vnd.3gpp.sms payload that contains a short

message

2 202 Accepted The SS responds with 202 Accepted
3 SIP MESSAGE SS sends a SIP MESSAGE request including a
vnd.3gpp.sms payload that contains the short
message submission report indicating a positive
acknowledgement of the short message sent by

the UE at Step 1

4 200 OK UE responds with 200 OK
5 SIP MESSAGE SS sends a SIP MESSAGE request including a
vnd.3gpp.sms payload that contains a status

report

6 200 OK UE responds with 200 OK
7 SIP MESSAGE UE sends a SIP MESSAGE request including a
vnd.3gpp.sms payload that contains an
acknowledgement for the status report received at

Step 6
8 202 Accepted The SS responds with 202 Accepted
Specific message contents:
SIP MESSAGE (Step 1)
Use the default “MESSAGE for MO SMS” in Annex A.7.3 of TS 34.229-1 [2] with conditions A2 and A5.
202 Accepted (Step 2 and 8)
Use the default “202 Accepted” in Annex A.3.3 of TS 34.229-1 [2].
Use the default “MESSAGE for submission report for MO SMS” in Annex A.7.4 of TS 34.229-1 [2].
200 OK (step 4 and 6)
Use the default message “200 OK for requests other than REGISTER or SUBSCRIBE” in Annex A.3.1 of TS 34.229-1
[2] with conditions A5 and A22.
Use the default “MESSAGE for status report for MO SMS” in Annex A.7.5 of TS 34.229-1 [2].
Use the default “MESSAGE for delivery report for MO SMS” in Annex A.7.6 of TS 34.229-1 [2].
ETSI
A.14 IMS MT SMS / 5GS

Expected sequence
UE SS
1 <- SIP MESSAGE SS sends a SIP MESSAGE request including a
vnd.3gpp.sms payload that contains a short
message
2 -> 200 OK UE responds with 200 OK
3 -> SIP MESSAGE UE sends a SIP MESSAGE request including a
vnd.3gpp.sms payload that contains a delivery
report
4 <- 202 Accepted The SS responds with 202 Accepted
Use the default “MESSAGE for status report for MO SMS” in Annex A.7.1 of TS 34.229-1 [2].
200 OK (Step 2)
Use the default message “200 OK for requests other than REGISTER or SUBSCRIBE” in Annex A.3.1 of TS 34.229-1
[2] with conditions A22.
Use the default “MESSAGE for delivery report for MT SMS” in Annex A.7.2 of TS 34.229-1 [2].
202 Accepted (Step 4)
Use the default “202 Accepted” in Annex A.3.3 of TS 34.229-1 [2].
ETSI
A.15 MTSI MO Video Call / 5GS
A.15.1 MTSI MO Video Call / with preconditions / 5GS

Expected sequence
UE SS





Progress.


request.





INVITE (Step 1)
ETSI
Supported
ETSI
v=0
s=(session name)
Time description:
Media description:

a=fmtp: (format)
a=fmtp: (format)
a=ptime:20
a=maxptime:240

a=crypto:1
^20|

Media description:
m=video (transport port) RTP/AVPF (fmt) or RTP/AVP (fmt) [Note 17]
ETSI
a=tcap:1 RTP/AVPF [Note 17]

a=pcfg:1 t=1 [Note 17]
a=rtpmap: (payload type) H265/90000
a=fmtp: (format) profile-id=1;level-id=(att-field)
a=fmtp: (format) profile-level-id= (att-field)


Notification.
is supported by UE.
Note 17: The tcap/pcfg attributes are present if RTP/AVP is present on the m line.
100 Trying (Step 2)
ETSI
Require
ETSI
v=0
s=-
b=AS:65
Time description:
t=0 0
Media description:
b=AS:65

a=ptime:20
a=maxptime:240

a=crypto:1
20|1:4 [Note 7]

Media description:
m=video (transport port) RTP/AVPF (fmt) [Note 1]
b=AS: (bandwidth-value) [Note 1]

a=acfg:1 t=1 [Note 10]
a=rtpmap: (payload type) H265/90000 [Note 1]
a=fmtp: (format) (format specific parameters) [Note 1]

a=des:qos mandatory remotel sendrecv
a=des:qos remote sendrecv
Note 1: The values for fmt, bandwidth, payload type, format and format specific parameters are
copied from step 1.
Note 4: Void
Note 5: Void
Notification.
ETSI
supported by UE.
Note 10: Present if tcap/pcfg attributes were included in step 1
PRACK (Step 4)
ETSI
UPDATE (Step 6)
Require
v=0
s=(session name)
Time description:
t=0 0
Media description:

a=rtpmap: (payload type) EVS/16000 [Note 3] [Note 5]
a=fmtp: (format) [Note 3] [Note 4]

Media description:
m=video (transport port) RTP/AVPF (fmt)



one
ETSI
Require
Content-Type
Content-
Length
PRACK (Step 9)
ACK (Step 12)
ETSI
A.15.1a MTSI MO Video Call / Default Configuration / 5GS

Expected sequence
UE SS





Progress.


request.





INVITE (Step 1)
ETSI
Supported
ETSI
v=0
s=(session name)
Time description:
Media description:

a=fmtp: (format) br=5.9-24.4; bw=nb-swb; max-red= (att-field) [Note 4, 5]
a=fmtp: (format)
a=fmtp: (format)
a=ptime:20
a=maxptime:240

a=crypto:1
^20|

Media description:


ETSI


Notification.
is supported by UE.
100 Trying (Step 2)
ETSI
Require
ETSI
v=0
s=-
b=AS:65
Time description:
t=0 0
Media description:
b=AS:65

a=ptime:20
a=maxptime:240

a=crypto:1
20|1:4 [Note 7]

Media description:


a=des:qos mandatory remotel sendrecv
a=des:qos remote sendrecv
Notification.
supported by UE.
Note 6: Present if tcap/pcfg attributes were included in step 1.
ETSI
PRACK (Step 4)
ETSI
UPDATE (Step 6)
Require
v=0
s=(session name)
Time description:
t=0 0
Media description:

a=fmtp: (format) [Note 3, 4]

Media description:



one
ETSI
Require
Content-Type
Content-
Length
PRACK (Step 9)
ACK (Step 12)
ETSI
A.15.2 MTSI MO Video Call / without preconditions / 5GS

Expected sequence
UE SS





Progress.





INVITE (Step 1)
ETSI
Supported
option-tag precondition – option tag not present
Note: this does not affect any other option tags in the Supported header as for instance
prescribed in TS 34.229-1 [2] Annex A.2.1
ETSI
v=0
s=(session name)
Time description:
Media description:

a=fmtp: (format)
a=fmtp: (format)
a=ptime:20
a=maxptime:240

a=crypto:1
^20|
Media description:

ETSI


Notification.
is supported by UE.
100 Trying (Step 2)
ETSI
v=0
s=-
b=AS:65
Time description:
t=0 0
Media description:
b=AS:65

a=ptime:20
a=maxptime:240

a=crypto:1
20|1:4 [Note 7]
Media description:

Note 1: The values for fmt, bandwidth, payload type, format and format specific parameters are
copied from step 1.
Note 4: Void
Note 5: Void
Notification.
supported by UE.
Note 10: Present if tcap/pcfg attributes were included in step 1
PRACK (Step 4)
ETSI
A14.
PRACK (Step 7)
ACK (Step 10)
A.16 MTSI MT Video Call / 5GS
A.16.1 MTSI MT Video Call / with preconditions / 5GS

Expected sequence
UE SS





Progress.



answer.




ETSI
INVITE (Step 1)
Use the default message "INVITE for MT Call" in Annex A.2.9 of TS 34.229-1 [2] applying conditions A1, A3, A4,
A7, and A8, and with the following exceptions:
ETSI
Supported
Content-Type
Content-Length
ETSI
Message-body Session description:

v=0
s=-
b=AS:540
Time description:
t=0 0
Media description:
b=AS:65
b=RS:0
b=RR:2000

a=fmtp: 98 0-15
a=fmtp: 100 0-15
a=ptime:20
a=maxptime:240

Media description:
m=video (transport port) RTP/AVPF 101
b=AS: 540
b=RS: 0
b=RR: 5000

a=rtpmap: 101 H265/90000
a=fmtp: 101 profile-id=1; level-id=93; \
sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \
sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAaiAeFlLktIvQB3CAQQ; \
sprop-pps=RAHAcYDZIA==
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=imageattr:101 send [x=848,y=480] recv [x=848,y=480]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation

ETSI
100 Trying (Step 2)
ETSI
Use the default message "183 Session Progress" in Annex A.2.3 of TS 34.229-1 [2] applying condition A2 and A6, and
with the following exceptions:
Require
Content-Type
Content-Length header shall be present if UE uses TCP to send this message and if there is a message body
v=0
s=(session name)
Time description:
t=0 0
Media description:


Media description:

a=fmtp: (format) profile-id=1; level-id=93
a=acfg:1 t=1

PRACK (Step 4)
200 OK (Step 5)
ETSI
ETSI
UPDATE (step 6)
exceptions:
ETSI
option-tag
Content-Type
Content-Length
v=0
s=-
b=AS:540
Time description:
t=0 0
Media description:
b=AS:65
b=RS:0
b=RR:2000

a=ptime:20
a=maxptime:240

Media description:
b=AS: 540
b=RS: 0
b=RR: 5000

a=rtpmap: 101 H265/90000
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=rtcp-fb:* nack
a=rtcp-fb:* ccm fir

a=curr:qos local.
ETSI
200 OK (step 7)
[2] applying conditions A2, A11, A18, and A22, and with the following exceptions:
option-tag
Content-Type
Length
v=0
s=(session name)
Time description:
t=0 0
Media description:


Media description:

a=fmtp: (format) profile-id=1; level-id=93
a=acfg:1 t=1


one.
ETSI
media-type
Length
value 0
PRACK (Step 9)
200 OK (Step 10)
200 OK (Step 11)
ACK (Step 12)
A.16.2 MTSI MT Video Call / without preconditions / 5GS

Expected sequence
UE SS





Progress.





ETSI
INVITE (Step 1)
Use the default message "INVITE for MT Call" in Annex A.2.9 of TS 34.229-1 [2] applying conditions A1, A3, A4,
A7, and A8, and with the following exceptions:
Content-Type
Content-Length
v=0
s=-
b=AS:540
Time description:
t=0 0
Media description:
b=AS:65
b=RS:0
b=RR:2000

a=fmtp: 98 0-15
a=fmtp: 100 0-15
a=ptime:20
a=maxptime:240
Media description:
b=AS: 540
b=RS: 0
b=RR: 5000

a=rtpmap: 101 H265/90000
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=rtcp-fb:* nack
a=rtcp-fb:* ccm fir
ETSI
100 Trying (Step 2)
Use the default message "183 Session Progress" in Annex A.2.3 of TS 34.229-1 [2] applying condition A2 and A6, and
Content-Type
Content-Length header shall be present if UE uses TCP to send this message and if there is a message body
v=0
s=(session name)
Time description:
t=0 0
Media description:

Media description:

a=fmtp: (format) profile-id=1; level-id=93;
a=acfg:1 t=1
PRACK (Step 4)
ETSI
media-type
Length
value 0
PRACK (Step 7)
ACK (Step 10)
A.17 Putting a MTSI speech call to hold or to resume the

call from the UE / 5GS
Expected sequence
UE SS
1 -> INVITE or UPDATE UE sends INVITE or UPDATE with a SDP offer to
hold or resume the call
2 <- 100 Trying The SS responds to the INVITE with a 100 Trying
3 <- 200 OK The SS responds to INVITE or UPDATE with 200
OK to indicate that the remote UE is no more
sending any media (call hold) or resumes sending
media (call resume)
4 -> ACK Conditional: If the UE sent INVITE in step 1 then
UE acknowledges the receipt of 200 OK for INVITE
INVITE or UPDATE (Step 1)
Use the default message “INVITE for MO call setup” in Annex A.2.1 of TS 34.229-1 [2] applying conditions A1, A3,
A5 and A28 or “UPDATE” in Annex A.2.5 applying conditions A1 and A6 of TS 34.229-1 [2]. In case of an INVITE
ETSI
the UE shall use also the same URI in the request line as the SS has sent in the Contact header of an earlier message
within the same dialog (in case of an UPDATE ref. to A.2.5 of TS 34.229-1 [2]).
The UE shall include support for precondition in the Supported header field.
The UE shall include an SDP body as described in A.4.1a, Step 6, (respectively Step 6 of A.15.1a, for holding a video
call), but with the following exceptions and clarifications:
- the sess-version number of the SDP shall be incremented by one; and
- the direction-tag for the current-status remote segment shall be "sendrecv"; and
- the UE shall either add a session level direction attribute (and remove the direction attributes of all the media
lines) or modify the direction attributes of all the media lines as follows:
- in case of Call Hold
- If the directionality of the media lines were originally as "recvonly" then the directionality attributes
within the INVITE in step 1 shall be "inactive"
- If the directionality of the media lines were originally as "sendrecv" then the directionality attributes
within the INVITE in step 1 shall be "sendonly"
- in case of Call Resume
- the UE shall restore the value of the directionality attributes within the SDP body their original values
(the UE may use either a single session level attribute or separate attributes for each media line).
100 Trying for INVITE (Step 2) optional step used when UE sent INVITE in step 1
Use the default message “100 Trying for INVITE” in Annex A.2.2 of TS 34.229-1 [2], applying condition A1.
200 OK for INVITE or UPDATE (Step 3)
Use the default message “200 OK for other requests than REGISTER or SUBSCRIBE” in Annex A.3.1 of TS 34.229-1
[2], applying conditions A1, A10 and A19, with the following exceptions:
Require
Content-Type
Content-Length
Message-body SDP body of the 200 OK response copied from the received INVITE or UPDATE but
modified as follows:

incremented by one
- IP address on "c=" line and transport port on "m=" lines changed to indicate to which
IP address and port the UE should send the media; and
In case of Call Hold:

- "sendonly" direction attribute inverted to "recvonly".
Note that this applies to “a=sendonly” direction attributes only, not to the direction tags
found in preconditions.
ACK (Step 4) conditional step used when UE sent INVITE in step 1
Use the default message “ACK” in Annex A.2.7 of 34.229-1 [2], applying conditions A1, A3 and A5.
ETSI
A.18 Putting a MTSI speech call to hold or to resume the

call from the SS / 5GS
Expected sequence
UE SS
1 <- INVITE SS sends INVITE with a SDP offer to hold or
resume the call
2 -> 100 Trying Optional: The UE responds with a 100 Trying
3 -> 200 OK The UE responds to INVITE with 200 OK to indicate
that the UE is no more sending any media (call
hold) or resumes sending media (call resume)
4 <- ACK The SS acknowledges the receipt of 200 OK for
INVITE
INVITE (Step 1)
Use the default message “INVITE for MT call setup” in Annex A.2.9 of TS 34.229-1 [2], applying conditions A1 and
A5, with the below exceptions. The SS uses the same URI in the request line as the UE has sent in the Contact header of
the original INVITE request creating this dialog.
The SS shall include support for precondition in the Supported header field.
In case of Call Hold, the SS shall include the same lines in the SDP body as finally accepted for the MTSI call, i.e., the
last SDP sent by the SS, with the following exceptions:
- version number of the SDP shall be incremented; and
- each media line shall carry direction attribute “a=sendonly”.
In case of Call Resume, the SS shall include the same lines in the SDP body as sent in the message for Call Hold with
- each media line shall carry direction attribute “a=sendrecv”.
ETSI
100 Trying for INVITE (Step 2)
[2], applying conditions A2, A5, A11, A20 and A22 with the following exceptions:
Require
Content-Type
Content-Length header shall be present if UE uses TCP to send this message and if there is a
message body
Message-body SDP answer to the SDP offer contained in the INVITE including:
- All mandatory SDP lines as specified in RFC 4566 [38].

- The same number of media lines (“m=”) as in the INVITE.
- All the media lines having directionality as "recvonly"

All the media lines having direction attribute “a=recvonly”.
In case of Call Resume:

All the media lines having direction attribute “a=sendrecv”.
ETSI
ACK (Step 4)
Use the default message “ACK” in Annex A.2.7 of TS 34.229-1 [2], applying conditions A2, A3 and A5.
A.19 MTSI conference creation / 5GS

Expected sequence
UE SS





Progress, with optional SDP offer
Exception : Step 6-7 describe optional
behaviour depending on UE
implementation. The steps will be
executed if no SDP offer was included in

PRACK at step 4

request.
8 <- 200 OK The SS responds INVITE with 200 OK and gives
the final conference URI within the response
9 -> ACK The UE acknowledges the receipt of 200 OK for
INVITE
EXCEPTION: steps 10–13 describe
optional behaviour depending on UE
configuration. The SS shall wait up to 3s
for the SUBSCRIBE of step 10
10 -> SUBSCRIBE UE subscribes the conference event
11 <- 200 OK SS responds to the subscription
12 <- NOTIFY SS sends the initial state of the conference event to
the UE
13 -> 200 OK UE responds to the NOTIFY
The specific message contents for steps 1–7 is otherwise identical to what have been specified in Annex A.4.1, but with
the exceptions as below:
INVITE (Step 1)
Request-Line
Request-URI sip:mmtel@conf-factory appended with px_IMS_HomeDomainName
To
addr-spec sip:mmtel@conf-factory appended with px_IMS_HomeDomainName
ETSI
183 Session in Progress for INVITE (Step 3)

Contact
addr-spec sip:temporary@conf-factory. appended with px_IMS_HomeDomainName
feature-param isfocus
Record-Route
rec-route <sip:[email protected];lr>,
<sip:SS P-CSCF address: protected server port of SS;lr>
PRACK (Step 4)
Message-body (if present, shall be the same as message body in UPDATE at step 6 of Annex A.4.1)

Content-Type
media-type (present, if SDP message-Body was present in PRACK at step 4)
application/sdp
Content-Length (present if SDP message-Body was present in PRACK at step 4)
value length of message body
Message-body (present, if SDP message-Body was present in PRACK at step 4)
same as message body in 200 OK for UPDATE at step 7 of Annex A.4.1
[2], applying conditions A1 and A5 with the following exceptions:
Record-Route
rec-route Same value as in the 183 response
Contact
addr-spec sip:final@conf-factory. appended with px_IMS_HomeDomainName
feature-param Isfocus
ACK (Step 9)
Use the default message “ACK” in Annex A.2.7 of TS 34.229-1 [2], applying conditions A1 and A3, with the following
exceptions:
Request-Line
Request-URI sip:final@conf-factory. appended with px_IMS_HomeDomainName
SUBSCRIBE (Step 10)
Use the default message “SUBSCRIBE for conference event package” in Annex A.5.1 of TS 34.229-1 [2], applying
conditions A1 and A7.
ETSI
200 OK (Step 11)
Use the default message “200 OK for SUBSCRIBE” in Annex A.5.2 of TS 34.229-1 [2], applying condition A1.
NOTIFY (Step 12)
Use the default message “MT NOTIFY for conference event package” in Annex A.5.3 of TS 34.229-1 [2], applying
condition A3.
200 OK (Step 13)
[2], applying conditions A5 and A22.
A.20 Inviting user to conference by sending a REFER

request to the conference focus / 5GS
Expected sequence
UE SS
1 --> REFER UE sends REFER to SS referring to the conference
2 <- 202 Accepted The SS responds with a 202 final response
3 <-- NOTIFY The SS sends initial NOTIFY for the implicit
subscription created by the REFER request
4 --> 200 OK The UE responds the NOTIFY with 200 OK
5 <-- NOTIFY The SS sends a NOTIFY related to REFER request
to confirm that the invited user was able to join the
conference
7 <-- NOTIFY Conditional: If the UE has subscribed the
conference event package, the SS sends a
NOTIFY for conference event package to inform
that the invited user was able to join the conference
8 --> 200 OK Conditional: The UE responds the NOTIFY with
200 OK
REFER (Step 1)
Use the default message “MO REFER” in Annex A.2.10 of TS 34.229-1[2], applying conditions A1 and A5, with the
Refer-To
addr-spec SIP URI or tel URI of the user invited to the conference. If an active session exists, the
Replaces header in the header portion of the SIP URI shall be included (mandatory inclusion
is stated in NG.114 [31]) and set to the dialog ID of the active session according to RFC 3891
[40]. In this case, if the user has been invited with a tel URI, the UE shall convert the tel URI to
a SIP URI according to RFC 3261 [6] clause 19.1.6. In addition, a Require header field with
option tag “replaces” may be included according to RFC 3891 clause 6.2.
(NOTE: the dialog ID is percent encoded according to RFC 3986 [41]).
Route
route-param URIs of the Record-Route header of 183 response sent in step 4 of A.16 in reverse order
ETSI
NOTIFY (Step 3)
Use the default message “MT NOTIFY for refer package” in Annex A.2.11 of TS 34.229-1 [2], applying condition A1,
NOTIFY (Step 5)
Subscription-State
expires omitted from the request
reason noresource
NOTIFY (Step 7)
Use the default message “NOTIFY for conference event package” in Annex A.5.3 of TS 34.229-1 [2], applying
conditions A1 and A3, with the following exceptions:
<conference-info xmlns="urn:ietf:params:xml:ns:conference-info">
entity="sip:final@conf-factory. appended with px_IMS_HomeDomainName"
state="partial"
version=" value as in previous notification for conference event package but
incremented by one"
<users>
<user entity=" SIP URI or tel URI of the invited user">
<endpoint entity=" Contact URI of the invited user">
<status>connected</status>
<joining-method>dialed-in</joining-method>
<media id="1">
<type>audio</type>
<label> unique identifier for the media stream between the focus and the endpoint of the
invited user (e.g. 11223)</label>
<src-id>random SSRC value</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</users>
</conference-info>
A.21 Activation and deactivation of Supplementary

Services / 5GS
Generic test procedure for signalling between UE and XCAP server to activate or deactivate a supplementary service.
Test procedure:
0a) Pre-configurations:
- The UE is in state 3N-A, registered to IMS on an IMS PDU session and at least one PDU session for Internet
active according to TS 38.508-1 [21], clause 4.5.3.
ETSI
NOTE: All XCAP signalling shall occur on the Internet PDU session according to NG.114 [31], Annex C.3. It is
recommended that px_MobileDataOn (TS 36.523-3 [53]) is set to false when executing test cases using
this generic test procedure.
0b) At the SS an HTTP server is established at port 80 to simulate the XCAP server.
NOTE: TLS is not a test requirement i.e. the UE uses port 80 to access XCAP and BSF servers and SS does not
redirect the UE to use HTTPS (port 443).
1) Activation of the specific Supplementary Service is triggered at the UE with appropriate MMI command.
2) The UE sends an initial HTTP request to the SS.
3) In case of HTTP Digest XCAP authentication when the UE does not provide correct authorization credentials
within its initial request:
3a) the SS shall challenge the UE by sending a “401 Unauthorized” response to it.
When the UE supports GBA for XCAP authentication and GBA shall be used according to test requirements or
test configuration, the SS shall indicate bootstrapped security association is required as specified in TS 24.109
[43] clause 5.2.4 and the generic procedure A.22 shall be applied.
3b) the UE repeats the HTTP request including a valid digest response in the authorization header.
The SS shall check the digest response taking into account the user’s prearranged password for (pure) HTTP
digest authentication, or, for GBA, being derived from the key material (Ks) using key derivation function as
specified in 3GPP TS 33.220 [44].
4) The SS sends a 200 (OK) response
5) Optionally UE and SS exchange a sequence of additional HTTP requests and responses. In this sequence the UE
may query the contents of the simservs document or selected parts of it.
In general the HTTP requests are responded with a 200 “Ok” response but in case of a GET request to a non-
existing node the SS shall respond with a 404 “File Not Found”.
6) The simservs document is checked according to specific test requirements.
7) Deactivation of supplementary service is triggered at the UE with appropriate MMI command.
8) UE and SS exchange a sequence of HTTP requests and responses. In this sequence the UE may query the
contents of the simservs document or selected parts of it.
In general the HTTP requests are responded with a 200 “Ok” response but in case of a GET request to a non-
existing node the SS shall respond with a 404 “File Not Found”.
9) The simservs document is checked according to specific test requirements.
ETSI
Expected sequence:
UE SS
1 Make the UE attempt activation of

supplementary service
2 Initial HTTP Request NOTE 1
3 EXCEPTION: steps 3a and 3b describe
behaviour in case of HTTP Digest XCAP
authentication when the UE does not
provide correct authorization credentials

within its initial request
3a HTTP Response: “401 Unauthorized”
EXCEPTION: (optional) GBA authentication at BSF server
By default, when the UE supports GBA
for XCAP authentication, GBA shall be
used according to the generic test
procedure A.22.
NOTE: See TS 34.229-2 [3] for cases

where the default does not apply.
3b HTTP Request with valid authorization The SS checks the digest response

credentials
4 HTTP Response: “200 OK”
further optional message exchange
between the UE and the SS;
steps 5a and steps 5b can be repeated
several times
this exchange of information is
considered to be finished when there is
no further HTTP request sent by the UE
within 20 seconds after the previous

request

5a HTTP Request NOTE 1
5b HTTP Response: “200 OK” or “404 File NOTE 3
Not Found”
6 Check: Does the simservs document This is done by fetching the whole simservs
stored in the SS contain the information document from the XCAP server and
supplied by the UE as required by the checking its content against the respective
test requirements of the specific test XML file (according to the XSD definitions
case? for the respective supplementary service)
7 Make the UE attempt deactivation of
supplementary service
the mandatory message exchange
between the UE and the SS which can
be repeated several times;
this exchange of information is
considered to be finished when there is
no further HTTP request sent by the UE
within 20 seconds after the previous

request

8a HTTP Request NOTE 1
8b HTTP Response: “200 OK” or “404 File NOTE 3
Not Found”
9 Check: Does the simservs document This is done by fetching the whole simservs
stored in the SS contain the information document from the XCAP server and
supplied by the UE as required by the checking its content against the respective
test requirements of the specific test XML file (according to the XSD definitions
case? for the respective supplementary service)
NOTE 1: The HTTP requests sent by the UE are processed by an XCAP server implementation at the SS to
modify or query the contents of the simservs document.
NOTE 2: Void.
NOTE 3: “404 File Not Found” is sent as response for a GET request to a non-existing node
ETSI
HTTP Requests sent by the UE (step 2, 3b, 5a, 8a)

Method GET, PUT, DELETE
Request-URI XCAP URI referring to the simservs document as
specified in RFC 4825 [45]; the document selector of
such XCAP URI consists of
- Configured XCAP root URI
- simservs.ngn.etsi.org
- users
- same public user id as the default public user identity
received in P-Associated-URI header in 200 OK for
REGISTER (NOTE 4).
- simservs.xml
(in this order, separated by a slash);
According to RFC 4825 [45] the node selector of the
XCAP URI shall identify a valid part of a simservs
document or whole document itself (NOTE 2).
Version HTTP 1.1
User-Agent A1 RFC 2616 [46]
Product token 3gpp-gba TS 24.109 [43]
Authorization present in case of HTTP Digest XCAP authentication in RFC 2617 [16]
the initial request or in the request following the “401 RFC 3310 [17]
Unauthorized” response
Digest
username NOT A2 As configured in the UE (NOTE 5).
Same public user id as the default public user identity
received in P-Associated-URI header in 200 OK for
REGISTER (NOTE 6).
username A2 B-TID as obtained from GBA authentication
realm same value as received in the realm directive in the
WWW Authenticate header sent by SS
nonce same value as in WWW-Authenticate header sent by SS
opaque same value as sent by the SS in “401 Unauthorized”
digest-uri same URI as used in Request-URI
qop-value auth
cnonce-value value assigned by UE affecting the response calculation
nonce-count 1
response NOT A2 response calculated by UE using prearranged password
response A2 response calculated by UE using password derived from
the key material of the GBA authentication according to
Generic key derivation as specified in Annex B.3 of TS
33.220 [44] using static string “gba-me” as parameter P0
in Annex B.3.
algorithm MD5
Content-Type present for HTTP PUT method RFC 2616 [46]
media-type application/vnd.etsi.simservs+xml or
application/xcap-el+xml or
application/xcap-att+xml (NOTE 3)
Message-body present for HTTP PUT method: RFC 2616 [46]
XML fragment of given node RFC 4825 [45]
NOTE 1: Any other headers are ignored.
NOTE 2: The SS shall check and make sure that the syntax of the node selector expressions is in compliance to
clause 6.2 of RFC 4825 [45].
NOTE 3: the media-type depends on the kind of node being accessed by the Request-URI: document, element or
attribute (see RFC 4825 [45]).
NOTE 4: According A.12/38 3GPP TS 34.229-2 [3].
NOTE 5: Shall be present if A.12/37 3GPP TS 34.229-2 [3] is yes.
NOTE 6: Shall be present if A.12/37 3GPP TS 34.229-2 [3] is no.
A1 UE supports GBA authentication
ETSI
A2 GBA authentication shall be applied (according to test requirements or test configuration)
HTTP Responses (step 4, 5b, 8b2) – normal case

Status-Line RFC 2616 [46]
Version HTTP 1.1
Code 200
Reason OK
Server RFC 2616 [46]
product XCAP-Server
Date RFC 2616 [46]
HTTP-date valid date according to RFC 2616 [46] section 3.3.1
ETag RFC 2616 [46]
entity-tag hextring: value starting with "478fb2358f700" and
incremented after each PUT operation
Content-Type present for HTTP GET method RFC 2616 [46]
media-type application/vnd.etsi.simservs+xml or
application/xcap-el+xml or
application/xcap-att+xml (NOTE 1)
value length of the message body
Message-body present for GET method: RFC 2616 [46]
XML fragment of given node RFC 4825 [45]
NOTE 1: the media-type depends on the kind of node being accessed with the HTTP GET method: document,
element or attribute (see RFC 4825 [45]).
HTTP Responses (step 5b, 8b) – Response for GET request to a non-existing node
Version HTTP 1.1
Code 404
Reason File Not Found
product XCAP-Server
Date RFC 2616 [46]
ETSI
HTTP Response (step 3a) for HTTP Digest XCAP authentication

Version HTTP 1.1
Code 401
Reason Unauthorized
product XCAP-Server
Date RFC 2616 [46]
WWW-Authenticate RFC 2616 [46]
realm NOT A1 home domain name as stored in EFDOMAIN or home
domain name derived from the IMSI
realm A1 containing two parts delimited by "@" (see TS 24.109
[43] clause 5):
- 3GPP-bootstrapping
- home domain name
as stored in EFDOMAIN
or home domain
name derived from
the IMSI
algorithm MD5
qop-value auth
nonce Base 64 encoding of RAND and AUTN
opaque arbitrary value (to be returned by the UE in subsequent
request)
A1 UE supports GBA authentication and GBA authentication shall be applied (according to test
requirements or test configuration)
A.22 GAA XCAP authentication

The generic test procedure for GBA authentication between UE and BSF.
The generic test procedure for GAA XCAP authentication is referred to the bootstrapping procedure in TS 33.220 [44],
clause 4.5.2 and TS 24.109 [43] clause 4.2.
Test procedure:
0a) Pre-configurations:
The UE may resolve the IP address for the BSF server via DNS.
0b) At the SS an HTTP server is established at port 80 to simulate the BSF server.
1) UE sends initial GET to the BSF server.
2) BSF server responds with “401 Unauthorized”.
3) UE sends GET with Authorization header to the BSF server.
4) BSF server responds with "200 OK" when the UE has provided a valid Authorization header.
ETSI
Expected sequence:
UE SS


1 HTTP Request

2 HTTP Response: “401 Unauthorized”
3 HTTP Request with valid authorization

credentials
4 HTTP Response: “200 OK”
HTTP Request (step 1)

Method GET
Request-URI Request-URI
Version HTTP/ DIGIT.DIGIT
Host RFC 2616 [46]
host bsf.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org (when
no ISIM available on the UICC), optionally followed by port
80
or
bsf.domain name (when using ISIM) , optionally followed
by port 80
User-Agent RFC 2616 [46]
Product token 3gpp-gba-tmpi TS 24.109 [43]
Authorization Digest RFC 2616 [46]
RFC 2617 [23]
username private user identity as stored in EFIMPI (when using ISIM) RFC 3310 [47]
or
private user identity derived from IMSI (when no ISIM
available on the UICC)
or
the value of the TMPI if one has been associated with the
private user identity as described in 3GPP TS 33.220 [44]
realm bsf.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org (when

no ISIM available on the UICC)
or
bsf.domain name (when using ISIM)
nonce empty value
digest-uri absoluteURL http://<BSF address>/
or
abs_path "/"
response empty value
NOTE 1: All choices for applicable conditions are described for each header.
ETSI
HTTP Response (step 2)

Version HTTP/1.1
Code 401
Reason Unauthorized
product BSF-Server
Date RFC 2616 [46]
WWW-Authenticate RFC 2616 [46]
challenge Digest RFC 2617 [23]
realm same value as received in step 1
algorithm AKAv1-MD5
qop-value auth-int
nonce Base 64 encoding of RAND and AUTN
opaque 5ccc069c403ebaf9f0171e9517f30e41
HTTP Request (step 3)

Method GET
Request-URI Request-URI
Version HTTP/ DIGIT.DIGIT
Host RFC 2616 [46]
host bsf.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org (when
no ISIM available on the UICC), optionally followed by port
80
or
bsf.domain name (when using ISIM), optionally followed
by port 80
Authorization Digest RFC 2616 [46]
RFC 2617 [23]
username private user identity as stored in EFIMPI (when using ISIM) RFC 3310 [47]
or
private user identity derived from IMSI (when no ISIM
available on the UICC)
or
the value of the TMPI if one has been associated with the
private user identity as described in 3GPP TS 33.220 [44]
realm same value as received in the realm directive in the WWW

Authenticate header sent by SS
opaque 5ccc069c403ebaf9f0171e9517f30e41
digest-uri absoluteURL http://<BSF address>/

or
abs_path "/"
cnonce-value value assigned by UE affecting the response calculation
nonce-count 00000001
response response calculated by UE
algorithm AKAv1-MD5
NOTE 1: All choices for applicable conditions are described for each header.
ETSI
HTTP Response (step 4)

Version HTTP/1.1
Code 200
Reason OK
Product token 3gpp-gba-tmpi
Date RFC 2616 [46]
Authentication-Info RFC 2616 [46]
message-qop qop=auth-int RFC 2617 [23]
rspauth see Note 1
cnonce same value as received in step 3
nc 1

media-type application/vnd.3gpp.bsf+xml
value length of the message body
Message-body <?xml version="1.0" encoding="UTF-8"?> RFC 2616 [46]
<BootstrappingInfo xmlns="uri:3gpp-gba"> TS 24.109 Annex
<btid>B-TID</btid> C [43]
<lifetime>key lifetime</lifetime>
</BootstrappingInfo>
with
B-TID
Bootstrapping - Transaction Identifier according to TS
33.220 [44] clause 4.5.2:
base64encode(RAND)@BSF_servers_domain_name
- key lifetime
lifetime of the key material formatted according to XSD
dateTime data type
NOTE 1: Rspauth is computed according to RFC 3310 and RFC 2617.
A.23 eCall Setup and MSD Update / 5GS

Expected sequence
UE SS


1 INVITE UE sends INVITE with initial MSD

2 200 OK SS responds INVITE with 200 OK

3 ACK UE responds ACK for 200 OK

4 SIP INFO SS sends SIP INFO to request MSD update

5 200 OK UE responds SIP INFO with 200 OK

6 SIP INFO UE sends SIP INFO with MSD update
7 200 OK SS responds SIP INFO with 200 OK.
ETSI
INVITE (Step 1)
Use the default message "INVITE for MO Call Setup" in Annex A.2.1 of TS 34.229-1 [2] applying condition A7 and
condition A20 or A21 as indicated by the test case and the following inclusion along with the applicable message body
of default message:
-
- v=0
- o=(username) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE)
- s=(session name)
Time description:
- t= (start-time) (stop-time)
Media description:
- m=audio (transport port) [Note 2]

Note 2: EVS codec shall be present in the media attributes, optionally including
channel number "/1".
[2] with conditions A6, A12, (A13 OR A14) and A22 and following inclusion along with the applicable message body
of default message:
ETSI
Content-Type
Content-Length
v=0
s=-
b=AS:37
Time description:
t=0 0
Media description:
b=AS:37
b=RS:0
b=RR:0

a=fmtp: (format) mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
Note 1: The value for fmt, payload type and format is copied from step 1.
INFO (Step 4)
Use the default message “INFO for MT” in Annex A.2.20 of TS 34.229-1 [2].
INFO (Step 6)
Use the default message “INFO for MO” in Annex A.2.19 of TS 34.229-1 [2].
A.24 UE putting a Video Call on hold or resume the call /

5GS
Expected sequence
UE SS
1 ---> INVITE or UPDATE UE sends INVITE or UPDATE with a SDP offer to
hold or resume the call
2 <-- 100 Trying The SS responds to the INVITE with a 100 Trying
3 <-- 200 OK The SS responds to INVITE or UPDATE with 200
OK to indicate that the remote UE is no more
sending any media (call hold) or resumes sending
media (call resume)
4 --> ACK Conditional: If the UE sent INVITE in step 1 then
UE acknowledges the receipt of 200 OK for INVITE
ETSI
INVITE or UPDATE (Step 1)
Use the default message “INVITE for MO call setup” in Annex A.2.1 of TS 34.229-1 [2] applying conditions A1, A3,
A5, A10, A11 and A28 or “UPDATE” in Annex A.2.5 applying conditions A1 and A6 of TS 34.229-1 [2]. In case of an
INVITE the UE shall use also the same URI in the request line as the SS has sent in the Contact header of an earlier
message within the same dialog (in case of an UPDATE ref. to A.2.5 of TS 34.229-1 [2]).
The UE shall include support for precondition in the Supported header field.
The UE shall include an SDP body as described in A.15.1a, Step 6, but with the following exceptions and clarifications:
- the sess-version number of the SDP shall be incremented by one; and
- the direction-tag for the current-status remote segment shall be "sendrecv"; and
- the UE shall either add a session level direction attribute (and remove the direction attributes of all the media
lines) or modify the direction attributes of all the media lines as follows:
- in case of Call Hold
- If the directionality of the media lines were originally as "recvonly" then the directionality attributes
within the INVITE in step 1 shall be "inactive"
- If the directionality of the media lines were originally as "sendrecv" then the directionality attributes
within the INVITE in step 1 shall be "sendonly"
- in case of Call Resume
- the UE shall restore the value of the directionality attributes within the SDP body their original values
(the UE may use either a single session level attribute or separate attributes for each media line).
100 Trying for INVITE (Step 2) optional step used when UE sent INVITE in step 1
200 OK for INVITE or UPDATE (Step 3)
[2], applying conditions A1, A10 and A19, with the following exceptions:
Require
Content-Type
Content-Length
Message-body SDP body of the 200 OK response copied from the received INVITE or UPDATE but
modified as follows:

incremented by one
- IP address on "c=" line and transport port on "m=" lines changed to indicate to which
IP address and port the UE should send the media; and

- "sendonly" direction attribute inverted to "recvonly".
Note that this applies to “a=sendonly” direction attributes only, not to the direction tags
found in preconditions.
ETSI
ACK (Step 4) conditional step used when UE sent INVITE in step 1
Use the default message “ACK” in Annex A.2.7 of 34.229-1 [2], applying conditions A1, A3 and A5.
A.25 Video Conference Creation / 5GS

Expected sequence
UE SS





Progress., with optional SDP offer
Exception : Step 6-7 describe optional
behaviour depending on UE
implementation. The steps will be
executed if no SDP offer was included in

PRACK at step 4

request.
8 <- 200 OK The SS responds INVITE with 200 OK and gives
the final conference URI within the response
9 -> ACK The UE acknowledges the receipt of 200 OK for
INVITE
EXCEPTION: steps 10–13 describe
optional behaviour depending on UE
configuration. The SS shall wait up to 3s
for the SUBSCRIBE of step 10
10 -> SUBSCRIBE UE subscribes the conference event
11 <- 200 OK SS responds to the subscription
12 <- NOTIFY SS sends the initial state of the conference event to
the UE
13 -> 200 OK UE responds to the NOTIFY
The specific message contents for steps 1–7 is otherwise identical to what have been specified in Annex A.15.1, but
with the exceptions as below:
INVITE (Step 1)
Request-Line
Request-URI sip:mmtel@conf-factory appended with px_IMS_HomeDomainName
To
addr-spec sip:mmtel@conf-factory appended with px_IMS_HomeDomainName
ETSI
183 Session in Progress for INVITE (Step 3)

Contact
addr-spec sip:temporary@conf-factory. appended with px_IMS_HomeDomainName
feature-param isfocus
Record-Route
rec-route <sip:[email protected];lr>,
<sip:SS P-CSCF address: protected server port of SS;lr>
PRACK (Step 4)
Message-body (if present, shall be the same as message body in UPDATE at step 6 of Annex A.15.1)

Content-Type
media-type (present, if SDP message-Body was present in PRACK at step 4)
application/sdp
Content-Length (present if SDP message-Body was present in PRACK at step 4)
value length of message body
Message-body (present, if SDP message-Body was present in PRACK at step 4)
same as message body in 200 OK for UPDATE at step 7 of Annex A.15.1
[2], applying conditions A1 and A5 with the following exceptions:
Record-Route
rec-route Same value as in the 183 response
Contact
addr-spec sip:final@conf-factory. appended with px_IMS_HomeDomainName
feature-param Isfocus
ACK (Step 9)
Use the default message “ACK” in Annex A.2.7 of TS 34.229-1 [2], applying conditions A1 and A3, with the following
exceptions:
Request-Line
SUBSCRIBE (Step 10)
Use the default message “SUBSCRIBE for conference event package” in Annex A.5.1 of TS 34.229-1 [2], applying
conditions A1 and A7.
ETSI
200 OK (Step 11)
Use the default message “200 OK for SUBSCRIBE” in Annex A.5.2 of TS 34.229-1 [2], applying condition A1.
NOTIFY (Step 12)
Use the default message “MT NOTIFY for conference event package” in Annex A.5.3 of TS 34.229-1 [2], applying
condition A5.
200 OK (Step 13)
[2], applying conditions A5 and A22.
A.26 Inviting user to Video conference by sending a

REFER request to the conference focus / 5GS
Expected sequence
UE SS
1 --> REFER UE sends REFER to SS referring to the conference
2 <-- 202 Accepted The SS responds with a 202 final response
3 <-- NOTIFY The SS sends initial NOTIFY for the implicit
subscription created by the REFER request
5 <-- NOTIFY The SS sends a NOTIFY related to REFER request
to confirm that the invited user was able to join the
conference
7 <-- NOTIFY Conditional: If the UE has subscribed the
conference event package, the SS sends a NOTIFY
for conference event package to inform that the
invited user was able to join the conference
8 --> 200 OK Conditional: The UE responds the NOTIFY with 200
OK
REFER (Step 1)
Use the default message “MO REFER” in Annex A.2.10 of TS 34.229-1[2], applying conditions A1 and A5, with the
Refer-To
addr-spec SIP URI or tel URI of the user invited to the conference. If an active session exists, the
Replaces header in the header portion of the SIP URI shall be included (mandatory inclusion
is stated in NG.114 [31]) and set to the dialog ID of the active session according to RFC 3891
[40]. In this case, if the user has been invited with a tel URI, the UE shall convert the tel URI to
a SIP URI according to RFC 3261 [6] clause 19.1.6.
(NOTE: the dialog ID is percent encoded according to RFC 3986 [41]).
Route
route-param URIs of the Record-Route header of 183 response sent in step 4 of A.25 in reverse order
ETSI
NOTIFY (Step 3)
NOTIFY (Step 5)
Use the default message “MT NOTIFY for refer package” in annex A.2.11 of TS 34.229-1[2] with the following
exceptions:
Subscription-State
expires omitted from the request
reason noresource
NOTIFY (Step 7)
Use the default message “NOTIFY for conference event package” in annex A.5.3 of TS 34.229-1[2] with the following
exceptions:
<conference-info xmlns="urn:ietf:params:xml:ns:conference-info">
entity="sip:final@conf-factory. appended with
px_IMS_HomeDomainName"
state="partial"
version="1"
<users>
<user entity=" SIP URI or tel URI of the invited user">
<endpoint entity=" Contact URI of the invited user">
<status>connected</status>
<joining-method>dialled-in</joining-method>
<media id="1">
<type>audio</type>
<label>11223</label>
</media>
<media id="2">
<type>video</type>
<label>11224</label>
</media>
</endpoint>
</users>
</conference-info>
ETSI
A.27 Leaving a conference / 5GS

Expected sequence
UE SS
1 -> BYE The UE leaves the conference with BYE
2 <- 200 OK The SS sends 200 OK for BYE
3 <- NOTIFY Conditional: if the UE had subscribed to the
conference event package, the SS notifies the UE
that its subscription to conference event package is
terminated
4 -> 200 OK Conditional: the UE sends 200 OK for NOTIFY (if
sent by SS)
BYE
Use the default message “BYE” in Annex A.2.8 of TS 34.229-1 [2], applying condition A8, with the following
exceptions:
Request-Line
Request-URI sip:final@conf-factory appended with px_IMS_HomeDomainName
200 OK (Step 2)
[2], applying condition A22.
NOTIFY
Use the default message “NOTIFY for conference event package” in Annex A.5.3 of TS 34.229-1 [2], applying
condition A4.
200 OK (Step 4)
[2], applying condition A22.
ETSI
A.28 SS putting a Video Call on hold or resume the call /

5GS
Expected sequence
UE SS
1 <- INVITE SS sends INVITE with a SDP offer to hold or
resume the call
2 -> 100 Trying Optional: The UE responds with a 100 Trying
3 -> 200 OK The UE responds to INVITE with 200 OK to
indicate that the UE is no more sending any media
(call hold) or resumes sending media (call
resume)
4 <- ACK The SS acknowledges the receipt of 200 OK for
INVITE
INVITE (Step 1)
Use the default message “INVITE for MT call setup” in Annex A.2.9 of TS 34.229-1 [2], applying conditions A1, A3,
A5, A7 and A8, with the below exceptions. The SS uses the same URI in the request line as the UE has earlier sent in
its Contact header within the same dialog.
The SS shall include support for preconditions in the Supported header field.
In case of Call Hold, the SS shall include the same lines in the SDP body as finally accepted for the MTSI call, i.e., the
last SDP sent by the SS, with the following exceptions:
- each media line shall carry direction attribute “a=sendonly”.
In case of Call Resume, the SS shall include the same lines in the SDP body as sent in the message for Call Hold with
- each media line shall carry direction attribute “a=sendrecv”.
ETSI
100 Trying for INVITE (Step 2)
[2], applying conditions A5, A11, A18, A20 and A22 with the following exceptions:
Require
Content-Type
Content-Length header shall be present if UE uses TCP to send this message and if there is a
message body
Message-body SDP answer to the SDP offer contained in the INVITE including:
- All mandatory SDP lines as specified in RFC 4566 [38].
- The same number of media lines (“m=”) as in the INVITE.
- All the media lines having directionality as "recvonly"

All the media lines having direction attribute “a=recvonly”.
In case of Call Resume:

All the media lines having direction attribute “a=sendrecv”.
ACK (Step 4)
Use the default message “ACK” in Annex A.2.7 of TS 34.229-1 [2], applying conditions A2, A3 and A5.
ETSI
Annex B (informative):
Change history
ETSI
Change history
Date Meeting TDoc CR R Cat Subject/Comment New
e version
v
2019-10 RAN5#85 R5-197746 - - - First draft version V0.1.0 made available 0.1.0
2019-11 RAN5#85 R5-198832 - - - Second draft version V0.2.0 made available, implementing pCRs 0.2.0
R5-197934, R5-198899, R5-198239, R5-198240, and R5-198241
2020-06 RAN5#87- R5-201458 - - - Third draft version V0.3.0 made available, implementing pCRs 0.3.0
e R5-202693, R5-202686, R5-202687, R5-202688, R5-202689,
R5-202678, R5-202679, R5-202680, R5-202681, R5-202682,
R5-202690, R5-202683, R5-202684, R5-202685, R5-202691,
R5-202692
2020-06 RAN5#87- - - - - Raised to v15.0.0 15.0.0
e
2020-09 RAN5#88- R5-203437 0004 - F Corrections to A.2 on IMS Registration 15.1.0
e
2020-09 RAN5#88- R5-203439 0006 - F New generic procedure for MT Call Release 15.1.0
e
2020-09 RAN5#88- R5-203440 0007 - F Adding references as needed 15.1.0
e
2020-09 RAN5#88- R5-203441 0008 - F Corrections to test cases 7.6 and 7.7 15.1.0
e
2020-09 RAN5#88- R5-203442 0009 - F Corrections to test case 6.1 15.1.0
e
e
e
e
e
e
e
e
2020-09 RAN5#88- R5-203461 0018 - F Corrections to MTSI MT Voice Call TC 7.6 15.1.0
e
2020-09 RAN5#88- R5-203462 0019 - F Corrections to Annex A.5.1 15.1.0
e
2020-09 RAN5#88- R5-204477 0001 1 F Addition of IMS NR TC 9.4-MT Concatenated SMS 15.1.0
e
2020-09 RAN5#88- R5-204478 0002 1 F Addition of IMS NR TC 9.5-MO SMS RP-ERROR 15.1.0
e
2020-09 RAN5#88- R5-204479 0003 1 F Addition of IMS NR TC 10.1-emergency call with registration and 15.1.0
e Location
2020-09 RAN5#88- R5-204480 0005 1 F Adding details for A.3 for IMS Emergency Registration 15.1.0
e
2020-09 RAN5#88- R5-204481 0011 1 F Corrections to test case 6.3 15.1.0
e
2020-09 RAN5#88- R5-204482 0020 1 F Addition of new IMS 5GS test case 9.1 15.1.0
e
2020-09 RAN5#88- R5-204483 0021 1 F Addition of new IMS 5GS test case 9.2 15.1.0
e
2020-09 RAN5#88- R5-204484 0022 1 F New generic IMS procedures for use in EPS fallback 15.1.0
e
2020-09 RAN5#88- R5-204485 0023 1 F Addition of NR TC 8.18 Barring of All Incoming Calls / except for a 15.1.0
e specific user / 5GS
2020-09 RAN5#88- R5-204486 0024 1 F Addition of NR TC 9.3 Mobile Originating Concatenated SMS / 5GS 15.1.0
e
2020-09 RAN5#88- R5-204487 0026 1 F Addition of new IMS test case 8.1 15.1.0
e
2020-12 RAN5#89- R5-205113 0029 F Corrections to A.9 on EPS Fallback 15.2.0
e
2020-12 RAN5#89- R5-205115 0030 F Corrections to A.2 and addition of A.10 15.2.0
e
2020-12 RAN5#89- R5-205157 0033 F Correction to 5GS IMS test case 9.3 15.2.0
e
e
e
ETSI
2020-12 RAN5#89- R5-205185 0037 F New generic procedure for Re-Registration 15.2.0
e
2020-12 RAN5#89- R5-205217 0043 F Corrections to test case 6.6 15.2.0
e
2020-12 RAN5#89- R5-205219 0044 F Corrections to A.7 15.2.0
e
2020-12 RAN5#89- R5-205220 0045 F New References 15.2.0
e
2020-12 RAN5#89- R5-205311 0046 F Corrections to generic procedure A.4 on MO Voice Call 15.2.0
e
2020-12 RAN5#89- R5-205312 0047 F Corrections to generic procedure A.5 on MT Voice Call 15.2.0
e
2020-12 RAN5#89- R5-205518 0057 F Corrections to A.6 15.2.0
e
2020-12 RAN5#89- R5-205585 0063 F Correction to Clause A.2 15.2.0
e
2020-12 RAN5#89- R5-206287 0031 1 F Correction to 5GS IMS test case 9.1 15.2.0
e
e
2020-12 RAN5#89- R5-206373 0036 1 F New generic procedure for Mobile Initiated De-Registration 15.2.0
e
2020-12 RAN5#89- R5-206374 0038 1 F Introduction of generic procedures for IMS MO and MT SMS 15.2.0
e
2020-12 RAN5#89- R5-206375 0039 1 F Addition of MTSI MT Voice Call Test Case 7.8 15.2.0
e
e
e
2020-12 RAN5#89- R5-206378 0048 1 F Editorial correction to add the title of section 10 15.2.0
e
2020-12 RAN5#89- R5-206379 0049 1 F Addition of IMS NR TC 7.3-MO Voice 421 Extension Required 15.2.0
e
2020-12 RAN5#89- R5-206468 0050 2 F Addition of IMS NR TC 7.12-MO Voice MO-MT UE with-without 15.2.0
e preconditions
2020-12 RAN5#89- R5-206381 0051 1 F Addition of IMS NR TC 7.10-MT Voice without preconditions and 15.2.0
e SDP offer
2020-12 RAN5#89- R5-206382 0058 1 F Update test case 7.4, 7.5, 7.6 and 7.7 15.2.0
e
2020-12 RAN5#89- R5-206383 0060 1 F Correction to 5GS IMS TC 6.1 15.2.0
e
2020-12 RAN5#89- R5-206384 0062 1 F Addition of New IMS over 5GS TC 7.2 MTSI MO Voice Call / 504 15.2.0
e Server Time-out / 5GS
2020-12 RAN5#89- R5-206385 0068 1 F Addition of new IMS over 5GS TC 7.1 MTSI MO Voice Call / 503 15.2.0
e Service Unavailable / 5GS
2020-12 RAN5#89- R5-206386 0069 1 F Correction to 5GS IMS TC 6.7 15.2.0
e
2021-01 RAN5#89- - - - - History correction for R5-206468. 15.2.1
e Corrected parts of implementations of R5-206287 and R5-206386
2021-03 RAN5#90- R5-210056 0070 - F Corrections to A.5 on MT Voice Call 15.3.0
e
e
e
2021-03 RAN5#90- R5-210196 0084 - F Corrections to SMS test case 9.5 15.3.0
e
2021-03 RAN5#90- R5-210259 0085 - F Corrections to A.11 15.3.0
e
2021-03 RAN5#90- R5-210343 0090 - F Corrections and extensions to test case 7.4 15.3.0
e
2021-03 RAN5#90- R5-210348 0091 - F Adding NG.114 dependencies to Annex A.4 15.3.0
e
2021-03 RAN5#90- R5-210659 0104 - F Withdrawing NR IMS TC 7.3-MO voice-UE preconditions enabled 15.3.0
e but not included in INVITE
2021-03 RAN5#90- R5-210882 0114 - F Correction to NR IMS TC 7.1-Shorter Retry-after period 15.3.0
e
2021-03 RAN5#90- R5-211334 0072 1 F Addition of IMS over 5GS test case 7.25 15.3.0
e
e
e
ETSI
e
e
e
e
e
e
2021-03 RAN5#90- R5-211429 0083 1 F Update test case 7.4, 7.5, 7.6 and 7.7 15.3.0
e
2021-03 RAN5#90- R5-211430 0092 1 F Editorial corrections to TS 34.229-5 15.3.0
e
2021-03 RAN5#90- R5-211431 0094 1 F Addition of IMS over 5GS TC 7.14 15.3.0
e
2021-03 RAN5#90- R5-211432 0095 1 F Adding references 15.3.0
e
2021-03 RAN5#90- R5-211433 0096 1 F Addition of A.15.1 MTSI MO Video Call / with preconditions / 5GS 15.3.0
e
2021-03 RAN5#90- R5-211434 0099 1 F Correction to IMS over 5GS TC 7.2 15.3.0
e
2021-03 RAN5#90- R5-211435 0100 1 F Correction to IMS over 5GS TC 7.11 15.3.0
e
2021-03 RAN5#90- R5-211436 0102 1 F Correction to NR IMS TC 7.10-Content Type not present 15.3.0
e
2021-03 RAN5#90- R5-211437 0103 1 F Correction to NR IMS A.9.2-Optional UPDATE after EPS fallback 15.3.0
e
2021-03 RAN5#90- R5-211438 0105 1 F Correction to NR IMS TC 10.1-Conformance requirement update 15.3.0
e
2021-03 RAN5#90- R5-211439 0106 1 F Addition of NR IMS TC 7.26-MO CAT forking model 15.3.0
e
2021-03 RAN5#90- R5-211440 0107 1 F Addition of NR IMS TC 8.26-MO hold without announcement 15.3.0
e
2021-03 RAN5#90- R5-211441 0108 1 F Addition of NR IMS TC 8.28-MT hold without announcement 15.3.0
e
2021-03 RAN5#90- R5-211442 0109 1 F Addition of NR IMS TC 8.30-Subscription to MWI event 15.3.0
e
2021-03 RAN5#90- R5-211443 0110 1 F Addition of NR IMS TC 8.31-Creating and leaving conference 15.3.0
e
2021-03 RAN5#90- R5-211444 0111 1 F Addition of NR IMS TC 8.32-Inviting user to conference by REFER 15.3.0
e
2021-03 RAN5#90- R5-211445 0112 1 F Addition of NR IMS TC 8.34-Three way session 15.3.0
e
2021-03 RAN5#90- R5-211446 0113 1 F Addition of NR IMS TC 8.36-MO explicit communication transfer 15.3.0
e
2021-03 RAN5#90- R5-211447 0115 1 F Addition of new IMS over 5GS TC 8.38 Communication Waiting and 15.3.0
e cancelling the call / 5GS
2021-06 RAN5#91- R5-212047 0116 - F Corrections to test case 7.4 regarding NG.114 Profile Requirements 15.4.0
e
2021-06 RAN5#91- R5-212048 0117 - F Corrections to generic procedure A.4 on MO Voice Call 15.4.0
e
2021-06 RAN5#91- R5-212060 0118 - F New References 15.4.0
e
2021-06 RAN5#91- R5-212076 0119 - F Corrections to TC 7.26 15.4.0
e
2021-06 RAN5#91- R5-212104 0121 - F Addition of IMS over 5GS test case 7.19 15.4.0
e
e
e
e
e
e
e
2021-06 RAN5#91- R5-213367 0161 - F Addition of MTSI MO video call without precondition 15.4.0
e
ETSI
e
2021-06 RAN5#91- R5-213521 0122 1 F Corrections to TC 7.1 15.4.0
e
e
2021-06 RAN5#91- R5-213523 0130 1 F Corrections regarding a=sendrecv and a=inactive 15.4.0
e
2021-06 RAN5#91- R5-213524 0131 1 F Addition of generic procedure for MT Video Call 15.4.0
e
e
2021-06 RAN5#91- R5-213526 0135 1 F Correction to NR IMS TC 8.26-MO hold without announcement 15.4.0
e
2021-06 RAN5#91- R5-213527 0136 1 F Correction to NR IMS TC 8.28-MT hold without announcement 15.4.0
e
2021-06 RAN5#91- R5-213528 0137 1 F Correction to NR IMS TC 8.34-Three way session 15.4.0
e
2021-06 RAN5#91- R5-213529 0139 1 F Addition of NR IMS Generic Procedure A.17-MTSI speech hold or 15.4.0
e resume
2021-06 RAN5#91- R5-213530 0140 1 F Addition of NR IMS Generic Procedure A.18-MTSI speech hold or 15.4.0
e resume from SS
2021-06 RAN5#91- R5-213531 0141 1 F Addition of NR IMS Generic Procedure A.19-MTSI conference 15.4.0
e creation
2021-06 RAN5#91- R5-213532 0142 1 F Addition of NR IMS Generic Procedure A.20-REFER inviting user to 15.4.0
e conference
2021-06 RAN5#91- R5-213533 0162 1 F Corrections to IMS over 5GS Test Case 7.31 and 7.32 15.4.0
e
2021-06 RAN5#91- R5-213534 0146 1 F Corrections to IMS over 5GS Test Case 6.2 15.4.0
e
2021-06 RAN5#91- R5-213535 0148 1 F Clarifications on usage of preconditions 15.4.0
e
2021-06 RAN5#91- R5-213536 0149 1 F Addition of NR IMS 7.13-MT Voice with RTCP disabled 15.4.0
e
2021-06 RAN5#91- R5-213537 0150 1 F Addition of NR IMS 7.15-MO Video without preconditions 15.4.0
e
2021-06 RAN5#91- R5-213538 0151 1 F Addition of NR IMS 7.16-MT Video with preconditions 15.4.0
e
2021-06 RAN5#91- R5-213539 0152 1 F Addition of NR IMS 7.17-MT Video without preconditions 15.4.0
e
2021-06 RAN5#91- R5-213540 0153 1 F Addition of NR IMS 7.20-MO Voice-add and remove video-with 15.4.0
e preconditions
2021-06 RAN5#91- R5-213541 0154 1 F Addition of NR IMS 7.21-MO Voice-add and remove video-without 15.4.0
e preconditions
2021-06 RAN5#91- R5-213542 0155 1 F Addition of NR IMS 7.23-MT Voice-add and remove video-without 15.4.0
e preconditions
2021-06 RAN5#91- R5-213543 0156 1 F Addition of NR IMS 7.24-Forking-two responses one cancel 15.4.0
e
2021-06 RAN5#91- R5-213544 0157 1 F Addition of new IMS over 5GS TC 7.22 MTSI MT Voice Call / add 15.4.0
e video and remove video / with preconditions at both originating UE
2021-06 RAN5#91- R5-213545 0160 1 F Correction to test cases 7.33 15.4.0
e
2021-06 RAN5#91- R5-213674 0147 1 F Corrections to IMS over 5GS Test Case 7.14 15.4.0
e
2021-09 RAN5#92- R5-214205 0164 - F Corrections to IMS5GS test case 6.4 15.5.0
e
e
2021-09 RAN5#92- R5-214225 0169 - F Corrections to IMS5GS Generic Procedures A.7 and A.8 15.5.0
e
e
e
2021-09 RAN5#92- R5-214386 0176 - F Corrections to IMS5GS Generic Procedure A.15 15.5.0
e
2021-09 RAN5#92- R5-214442 0180 - F New generic procedure for activation and de-activation of 15.5.0
e Supplementary Services
2021-09 RAN5#92- R5-214443 0181 - F New generic procedure for GAA XCAP authentication 15.5.0
e
e
ETSI
e
e
2021-09 RAN5#92- R5-214450 0188 - F Corrections to IMS over 5GS test case 7.33 15.5.0
e
e
2021-09 RAN5#92- R5-214812 0190 - F Correction to IMS NR A.5.1-adding conf in SDP 15.5.0
e
2021-09 RAN5#92- R5-214813 0191 - F Correction to IMS NR A.14-wrong arrows 15.5.0
e
2021-09 RAN5#92- R5-214815 0193 - F Correction to IMS NR 8.32-using generic procedures of inviting user 15.5.0
e to conference
2021-09 RAN5#92- R5-214821 0199 - F Addition of IMS NR generic procedures-leaving a conference 15.5.0
e
2021-09 RAN5#92- R5-214893 0214 - F Corrections to IMS over 5GS TC 7.14 15.5.0
e
2021-09 RAN5#92- R5-215694 0226 - F To void the IMS registration test case 6.5 15.5.0
e
2021-09 RAN5#92- R5-215721 0179 1 F Corrections to IMS5GS test case 8.30 15.5.0
e
e
2021-09 RAN5#92- R5-215723 0219 1 F Update test case 7.4 15.5.0
e
e
e
e
e
e
2021-09 RAN5#92- R5-216215 0177 1 F Corrections to IMS5GS Generic Procedure A.16 15.5.0
e
e
e
2021-09 RAN5#92- R5-216218 0192 1 F Correction to IMS NR 8.31-using generic procedures of creating 15.5.0
e and leaving a conference
2021-09 RAN5#92- R5-216219 0194 1 F Addition of IMS NR TC 10.2-emergency call with reg-location 15.5.0
e unavailable
2021-09 RAN5#92- R5-216220 0195 1 F Addition of IMS NR TC 10.3-emergency call with reg-other IMS in 15.5.0
e parallel
2021-09 RAN5#92- R5-216221 0196 1 F Addition of IMS NR TC 10.11-new emergency reg after new IP 15.5.0
e
2021-09 RAN5#92- R5-216222 0197 1 F Addition of IMS NR TC 10.12-uer initiated emergency reg with 15.5.0
e ongoing dialog
2021-09 RAN5#92- R5-216223 0198 1 F Addition of IMS NR TC 10.13-uer initiated emergency reg-initiates a 15.5.0
e call
2021-09 RAN5#92- R5-216224 0200 1 F Addition of new 5GS IMS test case 8.27 15.5.0
e
e
e
e
e
e
e
e
e
2021-09 RAN5#92- R5-216233 0209 1 F Addition of new 5GS IMS generic procedure A.24 15.5.0
e
ETSI
e
e
2021-09 RAN5#92- R5-216236 0213 1 F Corrections to IMS over 5GS TCs 8.1 and 8.18 15.5.0
e
2021-09 RAN5#92- R5-216237 0215 1 F Addition of new IMS over 5GS TC 10.6 Non-UE detectable 15.5.0
e emergency call / IM CN sends 380 with an Alternative Service /
Previous emergency IMS registration not expired / 5GS
2021-09 RAN5#92- R5-216238 0218 1 F Update to Re-Registration test case 6.6 15.5.0
e
2021-09 RAN5#92- R5-216240 0223 1 F Addition of test case 10.4 15.5.0
e
2021-09 RAN5#92- R5-216241 0224 1 F Addition of test case 10.9 15.5.0
e
2021-09 RAN5#92- R5-216242 0225 1 F Correction to IMS video call test case 7.15 15.5.0
e
2021-09 RAN5#92- R5-216331 0216 1 F Generic test procedure for eCall setup and MSD Update in 5GS 16.0.0
e
2021-09 RAN5#92- R5-216332 0217 1 F Addition of new IMS over 5GS TC 11.1 eCall over IMS / Manual 16.0.0
e initiation / Normal registration / Emergency registration / Success /
200 OK with ACK / 5GS
e
2021-12 RAN5#93- R5-216495 0229 - F Corrections to IMS5GS test cases 8.32 and 8.33 16.1.0
e
2021-12 RAN5#93- R5-216606 0255 - F Corrections regarding the To header in usages of MO REFER 16.1.0
e
e
2021-12 RAN5#93- R5-217007 0269 - F Correction to IMS NR TC 6.7 authentication MAC-wrong steps 16.1.0
e numbering
2021-12 RAN5#93- R5-217170 0274 - F Extend test cases for video addition to voice call with resource 16.1.0
e reservation
2021-12 RAN5#93- R5-217449 0276 - F DNN/PDU usage for generic XCAP procedure 16.1.0
e
2021-12 RAN5#93- R5-217598 0278 - F Corrections to IMS5GS MT video call test cases 7.16 and 7.17 16.1.0
e
e
2021-12 RAN5#93- R5-217835 0231 1 F Add test case MTSI MO Voice Call with default configuration 16.1.0
e
2021-12 RAN5#93- R5-217836 0232 1 F Add test case MTSI MT Voice Call with default configuration 16.1.0
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
ETSI
e
e
e
e
2021-12 RAN5#93- R5-217856 0252 1 F Update of new 5GS IMS test case 8.29 16.1.0
e
e
e
e
2021-12 RAN5#93- R5-217860 0259 1 F Addition of IMS5GS test case 7.24a 16.1.0
e
2021-12 RAN5#93- R5-217861 0260 1 F Addition of IMS5GS test case 7.24b 16.1.0
e
2021-12 RAN5#93- R5-217862 0268 1 F Correction to NR IMS TC 8.36-MO Explicit Communication Transfer 16.1.0
e
2021-12 RAN5#93- R5-217863 0275 1 F Correction to IMS over 5GS test case 6.4 16.1.0
e
2021-12 RAN5#93- R5-217864 0277 1 F Corrections to IMS5GS test cases 8.1 and 8.18 16.1.0
e
2021-12 RAN5#93- R5-217865 0279 1 F Implementing decision on precondition wording 16.1.0
e
2021-12 RAN5#93- R5-217866 0281 1 F Update to Session timer test cases 16.1.0
e
2021-12 RAN5#93- R5-217998 0272 1 F Corrections to IMS5GS test cases 7.10 and 7.25 16.1.0
e
2021-12 RAN5#93- R5-218010 0282 1 F Addition of new IMS over 5GS TC 11.2 eCall over IMS / Automatic 16.1.0
e initiation / Normal registration / Emergency registration / Success /
200 OK with ACK / 5GS
2021-12 RAN5#93- R5-218011 0283 1 F Addition of new IMS over 5GS TC 11.4 eCall over IMS / Manual 16.1.0
e initiation / MSD transfer and 200 OK with ACK / SIP INFO request
for MSD Update / Success / 5GS
2022-03 RAN5#94- R5-220171 0285 - F Add generic procedure for default MO voice call 16.2.0
e
e
e
2022-03 RAN5#94- R5-220221 0295 - F Corrections to TC 7.24a 16.2.0
e
e
e
e
e
e
e
e
2022-03 RAN5#94- R5-220234 0308 - F Addition of IMS5GS TC 8.39 16.2.0
e
2022-03 RAN5#94- R5-220235 0309 - F Addition of IMS5GS TC 8.39a 16.2.0
e
2022-03 RAN5#94- R5-220238 0312 - F Corrections to test case titles 16.2.0
e
e
2022-03 RAN5#94- R5-220565 0322 - F Correction to NR IMS TC 7.4-MTSI MO Voice Call with 16.2.0
e preconditions
2022-03 RAN5#94- R5-220647 0325 - F Correction to NR IMS generic procedure A.4.1-MTSI MO Voice Call 16.2.0
e with preconditions
e
ETSI
2022-03 RAN5#94- R5-221470 0284 1 F Update test case 7.4a 16.2.0

e
2022-03 RAN5#94- R5-221471 0289 1 F Corrections to usage or non-usage of mode-set 16.2.0
e
e
2022-03 RAN5#94- R5-221473 0292 1 F Addition of IMS5GS test case 10.7 16.2.0
e
2022-03 RAN5#94- R5-221474 0293 1 F Addition of IMS5GS TC 10.8 16.2.0
e
2022-03 RAN5#94- R5-221475 0296 1 F Corrections to TC 7.24b 16.2.0
e
e
e
e
e
2022-03 RAN5#94- R5-221480 0313 1 F Voiding unused test case numbers 16.2.0
e
e
e
2022-03 RAN5#94- R5-221483 0318 1 F Correction of 5GS IMS test case 10.9 16.2.0
e
2022-03 RAN5#94- R5-221484 0320 1 F Correction to NR IMS TC 7.21-MTSI MT Voice Call to add video 16.2.0
e and remove video without preconditions
2022-03 RAN5#94- R5-221485 0321 1 F Correction to NR IMS TC 7.23-MTSI MT Voice Call to add video 16.2.0
e and remove video without preconditions
2022-03 RAN5#94- R5-221486 0323 1 F Correction to NR IMS TC 8.40-User initiated USSI 16.2.0
e
e
2022-03 RAN5#94- R5-221488 0333 1 F Update of XCAP test case Preambles 16.2.0
e
2022-03 RAN5#94- R5-221489 0334 1 F Corrections to A.9 16.2.0
e
for MSD Update / Success / 5GS
for unsupported MSD / UE indicates unsuccessful in SIP INFO /
5GS
2022-03 RAN5#94- R5-222021 0287 1 F Update generic procedure A.6 16.2.0
e
e
2022-03 RAN5#94- R5-222046 0335 1 F Update to test case 6.4 16.2.0
e
e
e
e
e
e
2022-06 RAN5#95- R5-222100 0360 - F Corrections to TC 7.24a 16.3.0
e
2022-06 RAN5#95- R5-222101 0361 - F Corrections to TC 7.24b 16.3.0
e
e
e
e
ETSI

e
e
2022-06 RAN5#95- R5-222127 0371 - F Corrections to IMS over 5GS XCAP test cases 16.3.0
e
e
e
2022-06 RAN5#95- R5-222410 0381 - F Correction of A.17 - Generic test procedure for putting a MTSI 16.3.0
e speech call to hold or to resume the call from the UE / 5GS
2022-06 RAN5#95- R5-222411 0382 - F Editorial updates to title of several generic test procedures 16.3.0
e
2022-06 RAN5#95- R5-222757 0390 - F Correction to NR IMS TC 7.4a-MO Voice Call with preconditions 16.3.0
e and default Configuration
2022-06 RAN5#95- R5-222758 0391 - F Correction to NR IMS TC 7.5-MO Voice Call without preconditions 16.3.0
e at both side
2022-06 RAN5#95- R5-222760 0393 - F Correction to NR IMS TC 7.7-MT Voice Call without preconditions at 16.3.0
e both side
2022-06 RAN5#95- R5-222763 0396 - F Correction to NR IMS TC 7.10-MT Voice call without preconditions 16.3.0
e and without SDP offer
2022-06 RAN5#95- R5-222765 0398 - F Correction to NR IMS TC 7.13-MTSI MT Voice Call with RTCP 16.3.0
e disabled
2022-06 RAN5#95- R5-222766 0399 - F Correction to NR IMS TC 7.18-MTSI MO Voice Call with AMR-WB 16.3.0
e Encoded Media
2022-06 RAN5#95- R5-222767 0400 - F Correction to NR IMS TC 7.19-MTSI MO Voice Call with AMR-WB 16.3.0
e IO Encoded Media
2022-06 RAN5#95- R5-222770 0403 - F Correction to NR IMS TC 7.25-MTSI MT Voice Call without SDP 16.3.0
e offer in INVITE
2022-06 RAN5#95- R5-222776 0409 - F Correction to NR IMS TC 7.31-Session Timer for MT Voice Call 16.3.0
e
2022-06 RAN5#95- R5-222777 0410 - F Correction to NR IMS TC 7.32-Session Timer for MT Voice Call 16.3.0
e
2022-06 RAN5#95- R5-222784 0417 - F Correction to NR IMS TC 9.1-MO SMS 5GS 16.3.0
e
2022-06 RAN5#95- R5-222785 0418 - F Correction to NR IMS TC 9.3-MO Concatenated SMS 5GS 16.3.0
e
2022-06 RAN5#95- R5-222786 0419 - F Correction to NR IMS TC 9.5-MO SMS RP-ERROR 5GS 16.3.0
e
2022-06 RAN5#95- R5-223079 0423 - F Corrections to test case 7.4a 16.3.0
e
2022-06 RAN5#95- R5-223293 0426 - F Update of 5GS IMS test case 10.15 16.3.0
e
2022-06 RAN5#95- R5-223349 0386 1 F Corrections to TC 7.25 precondition 16.3.0
e
2022-06 RAN5#95- R5-223455 0339 1 F Corrections to A.9 16.3.0
e
2022-06 RAN5#95- R5-223456 0340 1 F Corrections to initial EVS offers 16.3.0
e
e
2022-06 RAN5#95- R5-223458 0343 1 F Corrections to TC 7.4a 16.3.0
e
e
e
e
e
2022-06 RAN5#95- R5-223463 0373 1 F Correction to IMS 5GS TC 8.34, 8.35 and 8.36 16.3.0
e
2022-06 RAN5#95- R5-223464 0376 1 F Correction to IMS 5GS TC 10.9 16.3.0
e
2022-06 RAN5#95- R5-223465 0377 1 F Correction to IMS 5GS TC 10.10 16.3.0
e
e
2022-06 RAN5#95- R5-223467 0383 1 F Correction to 5GS IMS Test Case 10.2 16.3.0
e
2022-06 RAN5#95- R5-223468 0384 1 F Correction to IMS testcase 10.6 16.3.0
e
ETSI
2022-06 RAN5#95- R5-223469 0392 1 F Correction to NR IMS TC 7.6-MT Voice Call with preconditions at 16.3.0
e both side
2022-06 RAN5#95- R5-223470 0394 1 F Correction to NR IMS TC 7.8-MT Voice Call without preconditions at 16.3.0
e MO UE
2022-06 RAN5#95- R5-223471 0395 1 F Correction to NR IMS TC 7.9-MT Voice Call without preconditions at 16.3.0
e MT UE
2022-06 RAN5#95- R5-223472 0411 1 F Correction to NR IMS TC 7.33-Session Timer for MT Voice Call 16.3.0
e
2022-06 RAN5#95- R5-223473 0412 1 F Correction to NR IMS TC 7.34-Session Timer for MT Voice Call 16.3.0
e
2022-06 RAN5#95- R5-223474 0414 1 F Correction to NR IMS TC 8.6-Terminating Identification Restriction 16.3.0
e Signalling 5GS
e
2022-06 RAN5#95- R5-223476 0427 1 F Update to call control test case 7.21 16.3.0
e
e
2022-06 RAN5#95- R5-223484 0388 1 F Correction to NR IMS TC 7.1-MO Voice Call with 503 16.3.0
e
2022-06 RAN5#95- R5-223485 0397 1 F Correction to NR IMS TC 7.12-MO Voice Call without preconditions 16.3.0
e at MT UE
2022-06 RAN5#95- R5-223486 0402 1 F Correction to NR IMS TC 7.24-UE receives CANCEL request for a 16.3.0
e forked MT voice call
2022-06 RAN5#95- R5-223487 0404 1 F Correction to NR IMS TC 7.26-Mobile Originating CAT 16.3.0
e
2022-06 RAN5#95- R5-223488 0405 1 F Correction to NR IMS TC 7.27-Session Timer for MO Voice Call 16.3.0
e
e
e
e
2022-06 RAN5#95- R5-223492 0413 1 F Correction to NR IMS TC 8.3-Originating Identification Restriction 16.3.0
e Signalling 5GS
2022-06 RAN5#95- R5-223493 0415 1 F Correction to NR IMS TC 8.8-Communication Forwarding 16.3.0
e Unconditional Signalling 5GS
2022-06 RAN5#95- R5-223494 0416 1 F Correction to NR IMS TC 8.41-Communication Forwarding on No 16.3.0
e Reply MO Voice Call
2022-09 RAN5#96- R5-224194 0430 - F Correction to IMS test case 10.13 16.4.0
e
2022-09 RAN5#96- R5-224670 0443 - F Correction to NR IMS TC 6.6-Re-Registration after capability update 16.4.0
e
2022-09 RAN5#96- R5-224683 0456 - F Correction to NR IMS TC 10.10-Emergency call without emergency 16.4.0
e registration
2022-09 RAN5#96- R5-225266 0461 - F Corrections to USSI test case 8.40 16.4.0
e
2022-09 RAN5#96- R5-225284 0447 1 F Correction to NR IMS TC 8.18-Barring of All Incoming Calls except 16.4.0
e for a Specific User
2022-09 RAN5#96- R5-225423 0429 1 F Correction for IMS 5GS Call Control test case 7.21 16.4.0
e
2022-09 RAN5#96- R5-225424 0431 1 F Updates to IMS emergency over 5G test cases 10.1 and 10.2 16.4.0
e
2022-09 RAN5#96- R5-225425 0432 1 F Corrections to IMS emergency over 5G test case 10.15 16.4.0
e
e
e
2022-09 RAN5#96- R5-225428 0437 1 F Correction to NR IMS TC 6.1-Initial Registration 16.4.0
e
2022-09 RAN5#96- R5-225429 0438 1 F Correction to NR IMS TC 6.2-Initial Registration Failures 16.4.0
e
2022-09 RAN5#96- R5-225430 0439 1 F Correction to NR IMS TC 6.3-Re-Registration Scenarios 16.4.0
e
2022-09 RAN5#96- R5-225431 0440 1 F Correction to NR IMS TC 6.4-De-Registration Scenarios 16.4.0
e
2022-09 RAN5#96- R5-225432 0444 1 F Correction to NR IMS TC 6.7-Authentication with MAC Parameter 16.4.0
e Invalid
2022-09 RAN5#96- R5-225433 0445 1 F Correction to NR IMS TC 6.8-Authentication with SQN out of range 16.4.0
e
2022-09 RAN5#96- R5-225434 0446 1 F Correction to NR IMS TC 6.9-Subscription with 503 Service 16.4.0
e Unavailable
ETSI
2022-09 RAN5#96- R5-225435 0448 1 F Correction to NR IMS TC 7.4a-MTSI MO Voice Call with 16.4.0
e preconditions at both originating UE and terminating UE
2022-09 RAN5#96- R5-225436 0449 1 F Correction to NR IMS TC 7.4-MTSI MO Voice Call with 16.4.0
e preconditions at both originating and terminating UE
2022-09 RAN5#96- R5-225437 0450 1 F Correction to NR IMS TC 7.18-MTSI MO Voice Call 16.4.0
e
2022-09 RAN5#96- R5-225438 0451 1 F Correction to NR IMS TC 7.19-MTSI MT Voice Call 16.4.0
e
2022-09 RAN5#96- R5-225439 0452 1 F Correction to NR IMS TC 7.24a-MTSI MO Voice Call 16.4.0
e
2022-09 RAN5#96- R5-225440 0453 1 F Correction to NR IMS TC 7.24b-MTSI MO Voice Call 16.4.0
e
2022-09 RAN5#96- R5-225441 0455 1 F Correction to NR IMS TC 10.3-Emergency call with emergency 16.4.0
e registration
2022-09 RAN5#96- R5-225442 0457 1 F Correction to NR IMS TC 10.11-New initial emergency registration 16.4.0
e
e
2022-09 RAN5#96- R5-225444 0459 1 F Corrections to test case 10.4 16.4.0
e
2022-12 RAN5#97 R5-225925 0464 - F Update test case 7.1 16.5.0
2022-12 RAN5#97 R5-225929 0468 - F Update test case 7.24b 16.5.0
2022-12 RAN5#97 R5-226059 0477 - F Corrections to 5GS IMS test case 10.4 16.5.0
2022-12 RAN5#97 R5-226308 0478 - F Correction to IMS test case 7.22 16.5.0
2022-12 RAN5#97 R5-226309 0479 - F Correction to IMS testcase 7.20 16.5.0
2022-12 RAN5#97 R5-226310 0480 - F Correction to IMS testcases 10.7 and 10.8 16.5.0
2022-12 RAN5#97 R5-226609 0483 - F Correction to IMS 5GS Call Control test case 7.21 16.5.0
2022-12 RAN5#97 R5-226611 0484 - F Correction to annexures A.20 and A.26 16.5.0
2022-12 RAN5#97 R5-226612 0485 - F Correction to annexure A.19 for MTSI conference creation 16.5.0
2022-12 RAN5#97 R5-226613 0486 - F Correction to annexure A.25 for Video conference creation 16.5.0
2022-12 RAN5#97 R5-226614 0487 - F Correction to IMS test case 8.34 16.5.0
2022-12 RAN5#97 R5-226704 0490 - F Update test case 7.24a 16.5.0
2022-12 RAN5#97 R5-226793 0491 - F Update of test case 8.40 16.5.0
2022-12 RAN5#97 R5-227485 0482 1 F Correction to IMS 5GS test case 10.13 16.5.0
2022-12 RAN5#97 R5-227486 0488 1 F Correction to IMS test case 8.35 16.5.0
2022-12 RAN5#97 R5-227487 0489 1 F Correction to IMS test case 8.36 16.5.0
2022-12 RAN5#97 R5-227488 0492 1 F Update emergency test case 10.14 16.5.0
2022-12 RAN5#97 R5-227600 0481 1 F Correction to IMS testcase 8.36 16.5.0
2023-03 RAN5#98 R5-230323 0494 - F Update test case 7.6a 16.6.0
2023-03 RAN5#98 R5-230922 0509 - F Remove test cases 10.11 and 10.15 16.6.0
2023-03 RAN5#98 R5-231489 0503 1 F Add generic procedure for default MT voice call 16.6.0
2023-03 RAN5#98 R5-231490 0504 1 F Add generic procedure for default MO video call 16.6.0
2023-03 RAN5#98 R5-231492 0496 1 F Update test case 7.19 16.6.0
2023-03 RAN5#98 R5-231499 0505 1 F Correction to IMS testcase 7.21 16.6.0
2023-03 RAN5#98 R5-231500 0510 1 F Update to Annex A.17 16.6.0
2023-03 RAN5#98 R5-231501 0511 1 F Update to Annex A.24 16.6.0
2023-03 RAN5#98 R5-231502 0512 1 F Update to test case 8.26 16.6.0
2023-03 RAN5#98 R5-231506 0520 - F Correction to MTSI MO Video Call for 5GS 16.6.0
2023-03 RAN5#98 R5-231507 0518 1 F Update to clause A.21 Activation and deactivation of Supplementary 16.6.0
Services
2023-03 RAN5#98 R5-231508 0519 1 F Correction to NR forking test cases 7.24a, 7.24b, 7.26 16.6.0
2023-03 RAN5#98 R5-231509 0517 1 F Correction to NR IMS TC 8.36-Consultative Call Transfer 16.6.0
ETSI
2023-03 RAN5#98 R5-231908 0507 1 F Correction to IMS Emergency Call test case 10.1 16.6.0
ETSI
History
Document history
V16.0.0 October 2021 Publication
V16.1.0 January 2022 Publication
V16.2.0 May 2022 Publication
V16.3.0 August 2022 Publication
V16.4.0 October 2022 Publication
V16.5.0 January 2023 Publication
V16.6.0 April 2023 Publication
ETSI

Ts 13422905v160600p

Uploaded by

Copyright:

Available Formats

Ts 13422905v160600p

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ts 13422905v160600p

Uploaded by

Copyright:

Available Formats

ETSI TS 134 229-5 V16.6.

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - APE 7112B

Notice of disclaimer & limitation of liability

Intellectual Property Rights

Modal verbs terminology

Annex A (normative): Generic Test Procedures .............................................................................443

A.5.1 MTSI MT Voice Call / with preconditions / 5GS .......................................................................................... 466

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.

shall indicates a mandatory requirement to do something

shall not indicates an interdiction (prohibition) to do something

should indicates a recommendation to do something

should not indicates a recommendation not to do something

may indicates permission to do something

need not indicates permission not to do something

can indicates that something is possible

cannot indicates that something is impossible

The constructions "is" and "is not" do not indicate requirements.

- the overall test structure;

- the test configurations;

- the conformance requirement and reference to the core specifications;

- the test purposes; and

- the test procedure.

The following information relevant to testing can be found in accompanying specifications:

- For a specific reference, subsequent revisions do not apply.

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".

[6] IETF RFC 3261: "SIP: Session Initiation Protocol".

[14] 3GPP TS 24.341: "Support of SMS over IP networks; Stage 3".

[16] 3GPP TS 33.203: "3G security;Access security for IP-based services".

[27] 3GPP TS 23.003: "Numbering, addressing and identification".

[28] IETF RFC 6665: “SIP-Specific Event Notification”.

[29] IETF RFC 3312: “Integration of Resource Management and SIP”.

[38] IETF RFC 4566: "SDP: Session Description Protocol".

[44] 3GPP TS 33.220: "Generic Authentication Architecture (GAA); Generic Bootstrapping

[46] IETF RFC 2616: "Hypertext Transfer Protocol -- HTTP/1.1".

3 Definitions of terms, symbols and abbreviations

4.1 Test Methodology

4.2 Implicit Testing

4.3 Conformance Requirements

5.2 Generic setup procedures

5.3 Transport protocols applied

6.1 Initial Registration / 5GS

6.1.2 Conformance Requirements

[TS 24.229, clause C.2]:

- generate a private user identity;

- generate a temporary public user identity; and

[TS 24.229, clause 5.1.1.1A]:

- the private user identity;

- one or more public user identities; and

In case the UE does not contain an ISIM, the UE shall:

- generate a private user identity;

- generate a temporary public user identity; and

in accordance with the procedures in clause C.2.

[TS 24.229, clause 5.1.1.2.1]:

a) a From header field set to the SIP URI that contains:

2) the public user identity to be registered;