X.S0013-004 v100 - Post Ballot (Editor)

13GPP2X.SP0013.
004
2Version1.0.00.4.4
3VersionDate:December2003
4
5
6
AllIPCoreNetworkMultimediaDomain
7
8
9
10
3GPP2 X.P0013.4 Cover Sheet

Based on SIP and SDP
12
13
14
15
16
17
18
19
20
COPYRIGHTNOTICE
3GPP2anditsOrganizationalPartnersclaimcopyrightinthisdocumentandindividualOrganizationalPartners
maycopyrightandissuedocumentsorstandardspublicationsinindividualOrganizationalPartner'snamebasedon
thisdocument.Requestsforreproductionofthisdocumentshouldbedirectedtothe3GPP2Secretariatat
secretariat@3gpp2.org.RequeststoreproduceindividualOrganizationalPartner'sdocumentsshouldbedirectedto
thatOrganizationalPartner.Seewww.3gpp2.orgformoreinformation.
1
2EDITOR
3MiloOrsic,LucentTechnologies(orsic@lucent.com)
4
Table of Contents
1
2
3Foreword
..................................................................................................................vii
41 Scope
....................................................................................................................1
52 References ....................................................................................................................1
63 Definitions and abbreviations........................................................................................4
7
8
94
10
11
12
13
14
15
16
17
18
19
20
21
22
3.1
3.2
Definitions..............................................................................................................................................4
Abbreviations.........................................................................................................................................6
General
....................................................................................................................7
4.1
Conformance of IM CN subsystem entities to SIP, SDP and other protocols........................................7
4.2
URI and address assignments.................................................................................................................9
4.2A
Transport mechanisms........................................................................................................................9
4.3
Routeing principles of IM CN subsystem entities.................................................................................9
4.4
Trust domain...........................................................................................................................................9
4.5
Charging correlation principles for IM CN subsystems.......................................................................10
4.5.1
Overview......................................................................................................................................10
4.5.2
IM CN subsystem charging identifier (ICID)..............................................................................10
4.5.3
Access network charging information..........................................................................................11
4.5.3.1 General.....................................................................................................................................11
4.5.3.2 IP Connectivity Network charging information.......................................................................11
4.5.4
Inter operator identifier (IOI).......................................................................................................11
4.5.5
Charging function addresses........................................................................................................12
235 Application usage of SIP..............................................................................................12

24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
5.1
Procedures at the UE............................................................................................................................12
5.1.1
Registration and authentication....................................................................................................12
5.1.1.1 General.....................................................................................................................................12
5.1.1.1A
Parameters contained in the UE...........................................................................................12
5.1.1.1B
Security Association Negotiation.........................................................................................12
5.1.1.2 Initial registration.....................................................................................................................13
5.1.1.3 Initial subscription to the reg event package............................................................................14
5.1.1.4 User-initiated reregistration......................................................................................................14
5.1.1.5 Authentication..........................................................................................................................16
5.1.1.5A
Change of IPv6 address due to privacy................................................................................18
5.1.1.6 Mobile-initiated deregistration.................................................................................................18
5.1.1.7 Network-initiated deregistration..............................................................................................19
5.1.2
Subscription and notification.......................................................................................................19
5.1.2.1 Notification about multiple registered public user identities...................................................19
5.1.2.2 General SUBSCRIBE requirements.........................................................................................20
5.1.2A Generic procedures applicable to all methods excluding the REGISTER method......................20
5.1.2A.1
Mobile-originating case........................................................................................................20
5.1.2A.2
Mobile-terminating case......................................................................................................21
5.1.3
Call initiation-mobile originating case.........................................................................................21
5.1.3.1 Initial INVITE..........................................................................................................................21
5.1.4
Call initiation-mobile terminating case........................................................................................22
5.1.4.1 Initial INVITE..........................................................................................................................22
5.1.5
Call release...................................................................................................................................22
5.1.6
Emergency service.......................................................................................................................22
5.1.7
Void..............................................................................................................................................22
5.2
Procedures at the P-CSCF....................................................................................................................22
i
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
5.2.1
General.........................................................................................................................................22
5.2.2
Registration..................................................................................................................................23
5.2.3
Subscription to the users reg event package.................................................................................25
5.2.4
Registration of multiple public user identities.............................................................................26
5.2.5
Deregistration...............................................................................................................................26
5.2.5.1 User-initiated deregistration.....................................................................................................26
5.2.6
General treatment for all dialogs and standalone transactions excluding the REGISTER method.
......................................................................................................................................................27
5.2.6.1 Introduction..............................................................................................................................27
5.2.6.2 Determination of mobile-originated or mobile-terminated case..............................................27
5.2.6.3 Requests initiated by the UE....................................................................................................27
5.2.6.4 Requests terminated by the UE................................................................................................31
5.2.7
Initial INVITE..............................................................................................................................34
5.2.7.1 Introduction..............................................................................................................................34
5.2.7.2 Mobile-originating case............................................................................................................34
5.2.7.3 Mobile-terminating case...........................................................................................................35
5.2.7.4 IP Connectivity Network charging information.......................................................................35
5.2.8
Call release...................................................................................................................................35
5.2.8.1 P-CSCF-initiated call release...................................................................................................35
5.2.8.2 Call release initiated by any other entity..................................................................................37
5.2.9
Subsequent requests.....................................................................................................................37
5.2.9.1 Mobile-originating case............................................................................................................37
5.2.9.2 Mobile-terminating case...........................................................................................................37
5.2.10
Emergency service.......................................................................................................................37
5.2.11
Void..............................................................................................................................................37
5.3
Procedures at the I-CSCF.....................................................................................................................37
5.3.1
Registration procedure.................................................................................................................37
5.3.1.1 General.....................................................................................................................................37
5.3.1.2 Normal procedures...................................................................................................................37
5.3.1.3 Abnormal cases........................................................................................................................38
5.3.2
Initial requests..............................................................................................................................38
5.3.2.1 Normal procedures...................................................................................................................38
5.3.2.2 Abnormal cases........................................................................................................................39
5.3.3
THIG functionality in the I-CSCF(THIG)...................................................................................39
5.3.3.1 General.....................................................................................................................................39
5.3.3.2 Encryption for topology hiding................................................................................................40
5.3.3.3 Decryption for Topology Hiding..............................................................................................41
5.3.4
Void..............................................................................................................................................41
5.4
Procedures at the S-CSCF....................................................................................................................41
5.4.1
Registration and authentication....................................................................................................41
5.4.1.1 Introduction..............................................................................................................................41
5.4.1.2 Initial registration and user-initiated reregistration..................................................................42
5.4.1.3 Authentication and re-authentication.......................................................................................46
5.4.1.4 User-initiated deregistration.....................................................................................................46
5.4.1.6 Network-initiated re-authentication.........................................................................................47
5.4.1.7 Notification of Application Servers about registration status..................................................48
5.4.2
5.4.2.1 Subscriptions to S-CSCF events..............................................................................................49
5.4.3
General treatment for all dialogs and standalone transactions excluding requests terminated by
the S-CSCF...................................................................................................................................50
5.4.3.1 Determination of mobile-originated or mobile-terminated case..............................................50
5.4.3.2 Requests initiated by the served user.......................................................................................51
5.4.3.3 Requests terminated at the served user....................................................................................53
5.4.3.4 Original dialog identifier..........................................................................................................55
ii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
5.4.3.5 Void..........................................................................................................................................55
5.4.4
Call initiation................................................................................................................................55
5.4.4.1 Initial INVITE..........................................................................................................................55
5.4.4.2 Subsequent requests.................................................................................................................55
5.4.5
Call release...................................................................................................................................56
5.4.5.1 S-CSCF-initiated session release.............................................................................................56
5.4.5.2 Session release initiated by any other entity............................................................................58
5.4.6
Call-related requests.....................................................................................................................58
5.4.6.1 ReINVITE................................................................................................................................58
5.4.7
MESSAGE support......................................................................................................................58
5.5
Procedures at the MGCF......................................................................................................................59
5.5.1
General.........................................................................................................................................59
5.5.2
5.5.3
Call initiation................................................................................................................................59
5.5.3.1 Initial INVITE..........................................................................................................................59
5.5.4
Call release...................................................................................................................................60
5.5.4.1 Call release initiated by a circuit-switched network................................................................60
5.5.4.2
IM CN subsystem-initiated call release..................................................................................60
5.5.4.3 MGW-initiated call release.......................................................................................................60
5.5.5
5.5.5.1 ReINVITE................................................................................................................................61
5.5.6
Further initial requests..................................................................................................................61
5.6
Procedures at the BGCF.......................................................................................................................61
5.6.1
General.........................................................................................................................................61
5.6.2
Session initiation transaction........................................................................................................61
5.7
Procedures at the Application Server (AS)..........................................................................................61
5.7.1
Common Application Server (AS) procedures.............................................................................61
5.7.1.1 Notification about registration status.......................................................................................61
5.7.1.2 Extracting charging correlation information............................................................................62
5.7.1.3 Access-Network-Info...............................................................................................................62
5.7.2
Application Server (AS) acting as terminating UA, or redirect server........................................62
5.7.3
Application Server (AS) acting as originating UA......................................................................63
5.7.4
Application Server (AS) acting as a SIP proxy............................................................................63
5.7.5
Application Server (AS) performing 3rd party call control.........................................................63
5.7.5.1 General.....................................................................................................................................63
5.7.5.2 Call initiation............................................................................................................................63
5.7.5.3 Call release...............................................................................................................................64
5.7.5.4 Call-related requests.................................................................................................................64
5.7.5.5 Further initial requests..............................................................................................................64
5.7.6
Void..............................................................................................................................................64
5.8
Procedures at the MRFC......................................................................................................................64
5.8.1
General.........................................................................................................................................64
5.8.2
Call initiation................................................................................................................................64
5.8.2.1 Initial INVITE..........................................................................................................................64
5.8.3
Call release...................................................................................................................................66
5.8.3.1 S-CSCF-initiated call release...................................................................................................66
5.8.3.2 MRFC-initiated call release.....................................................................................................66
5.8.4
5.8.4.1 ReINVITE................................................................................................................................66
5.8.4.2 REFER.....................................................................................................................................67
5.8.4.3 INFO.........................................................................................................................................67
5.8.5
Further initial requests..................................................................................................................67
556 Application usage of SDP............................................................................................67
iii
1
2
3
4
5
6
7
8
6.1
6.2
Procedures at the P-CSCF....................................................................................................................69
6.3
Procedures at the S-CSCF....................................................................................................................69
6.4
Procedures at the MGCF......................................................................................................................69
6.4.1
Calls originating from circuit-switched networks........................................................................69
6.4.2
Calls terminating in circuit-switched networks............................................................................69
6.5
Procedures at the MRFC......................................................................................................................70
6.6
Procedures at the AS............................................................................................................................70
97
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
Extensions within the present document....................................................................70

7.1
SIP methods defined within the present document..............................................................................70
7.2
SIP headers defined within the present document................................................................................70
7.2.1
Void..............................................................................................................................................70
7.2.2
Void..............................................................................................................................................70
7.2.3
P-Access-Network-Info header....................................................................................................70
7.2.3.1 Introduction..............................................................................................................................70
7.2.3.2 Syntax.......................................................................................................................................71
7.2.3.3 Additional coding rules for P-Access-Network-Info header....................................................71
7.2.4
P-Visited-Network-ID header......................................................................................................71
7.2.4.1 Introduction..............................................................................................................................71
7.2.4.2 Syntax.......................................................................................................................................71
7.2.4.3 Operation..................................................................................................................................71
7.2.5
P-Charging-Function-Addresses header.......................................................................................71
7.2.5.1 Introduction..............................................................................................................................71
7.2.5.2 Syntax.......................................................................................................................................71
7.2.5.3 Operation..................................................................................................................................71
7.2.6
P-Charging-Vector header............................................................................................................72
7.2.6.1 Introduction..............................................................................................................................72
7.2.6.2 Syntax.......................................................................................................................................72
7.2.6.3 Operation..................................................................................................................................73
7.2.7
Void..............................................................................................................................................73
7.2.8
Void..............................................................................................................................................73
7.2.9
Void..............................................................................................................................................73
7.2.10
Void..............................................................................................................................................73
7.2A
Extensions to SIP headers defined within the present document.....................................................73
7.2A.1 Extension to WWW-authenticate header.....................................................................................73
7.2A.1.1
Introduction..........................................................................................................................73
7.2A.1.2
Syntax...................................................................................................................................73
7.2A.1.3
Operation..............................................................................................................................73
7.2A.2 Extension to Authorization header...............................................................................................73
7.2A.2.1
Introduction..........................................................................................................................73
7.2A.2.2
Syntax...................................................................................................................................73
7.2A.2.3
Operation..............................................................................................................................74
7.2A.3 Tokenized-by parameter definition (various headers)..................................................................74
7.2A.3.1
Introduction..........................................................................................................................74
7.2A.3.2
Syntax...................................................................................................................................74
7.2A.3.3
Operation..............................................................................................................................74
7.3
Option-tags defined within the present document................................................................................74
7.4
Status-codes defined within the present document..............................................................................74
7.5
Session description types defined within the present document..........................................................74
7.6
3GPP2 IM CN subsystem XML body, version 1.................................................................................74
7.6.1
General.........................................................................................................................................74
7.6.2
Document Type Definition...........................................................................................................75
7.6.3
DTD description...........................................................................................................................75
7.7
SIP timers.............................................................................................................................................75
iv
18 SIP compression.........................................................................................................76
2
3
4
5
6
7
8
9
8.1
SIP compression procedures at the UE................................................................................................76
8.1.1
SIP compression...........................................................................................................................76
8.1.2
Compression of SIP requests and responses transmitted to the P-CSCF.....................................76
8.1.3
Decompression of SIP requests and responses received from the P-CSCF.................................77
8.2
SIP compression procedures at the P-CSCF........................................................................................77
8.2.1
SIP compression...........................................................................................................................77
8.2.2
Compression of SIP requests and responses transmitted to the UE.............................................77
8.2.3
Decompression of SIP requests and responses received from the UE.........................................77
109 IP Connectivity Network aspects when connected to the IM CN subsystem..................77

11
12
13
14
15
16
17
18
19
20
21
9.1
Introduction..........................................................................................................................................77
9.2
9.2.1
Establishment of ICN Bearer and P-CSCF discovery..................................................................77
9.2.1A Void .............................................................................................................................................78
9.2.1B ICN Bearer Control Point support of DHCP based P-CSCF discovery.......................................78
9.2.2
Void .............................................................................................................................................79
9.2.3
Void .............................................................................................................................................79
9.2.4
Void .............................................................................................................................................79
9.2.5
ICN Bearer for media...................................................................................................................79
9.2.5.1 General requirements...............................................................................................................79
9.2.5.2 Special requirements applying to forked responses.................................................................79
22A.1 Profiles
23
24
25
A.1.1
A.1.2
A.1.3
..................................................................................................................81
Relationship to other specifications.................................................................................................81
Introduction to methodology within this profile..............................................................................81
Roles.................................................................................................................................................83
26A.2 Profile definition for the Session Initiation Protocol as used in the present document. .83
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
A.2.1
User agent role.................................................................................................................................83
A.2.1.1
Introduction..............................................................................................................................83
A.2.1.2
Major capabilities.....................................................................................................................84
A.2.1.3
PDUs........................................................................................................................................87
A.2.1.4
PDU parameters.......................................................................................................................88
A.2.1.4.1 Status-codes..........................................................................................................................88
A.2.1.4.2 ACK method........................................................................................................................90
A.2.1.4.3 BYE method.........................................................................................................................91
A.2.1.4.4 CANCEL method.................................................................................................................97
A.2.1.4.5 COMET method.................................................................................................................100
A.2.1.4.6 INFO method......................................................................................................................100
A.2.1.4.7 INVITE method..................................................................................................................100
A.2.1.4.7A MESSAGE method..........................................................................................................109
A.2.1.4.8 NOTIFY method.................................................................................................................115
A.2.1.4.9 OPTIONS method..............................................................................................................121
A.2.1.3.10 PRACK method................................................................................................................128
A.2.1.4.11 REFER method.................................................................................................................134
A.2.1.4.12 REGISTER method..........................................................................................................140
A.2.1.4.13 SUBSCRIBE method.......................................................................................................147
A.2.1.4.14 UPDATE method..............................................................................................................154
A.2.2
Proxy role.......................................................................................................................................159
A.2.2.1
Introduction............................................................................................................................159
A.2.2.2
Major capabilities...................................................................................................................160
A.2.2.3
PDUs......................................................................................................................................164
A.2.2.4
PDU parameters.....................................................................................................................165
A.2.2.4.1 Status-codes........................................................................................................................165
A.2.2.4.2 ACK method......................................................................................................................167
A.2.2.4.3 BYE method.......................................................................................................................169
v
1
2
3
4
5
6
7
8
9
10
11
12
A.2.2.4.4
A.2.2.4.5
A.2.2.4.6
A.2.2.4.7
A.2.2.4.7A
A.2.2.4.8
A.2.2.4.9
A.2.2.4.10
A.2.2.4.11
A.2.2.4.12
A.2.2.4.13
A.2.2.4.14
CANCEL method...............................................................................................................176
COMET method.................................................................................................................179
INFO method......................................................................................................................179
INVITE method..................................................................................................................179
MESSAGE method..........................................................................................................188
NOTIFY method................................................................................................................195
OPTIONS method..............................................................................................................202
PRACK method................................................................................................................210
REFER method.................................................................................................................216
REGISTER method..........................................................................................................223
SUBSCRIBE method.......................................................................................................230
UPDATE method..............................................................................................................237
13A.3 Profile definition for the Session Description Protocol as used in the present document
14
243
15
16
17
18
19
20
21
22
23
24
25
A.3.1
Introduction....................................................................................................................................243
A.3.2
User agent role...............................................................................................................................243
A.3.2.1
A.3.2.2
SDP types...............................................................................................................................244
A.3.2.3
SDP types parameters.............................................................................................................245
A.3.2.4
SDP types parameters within attribute lines...........................................................................247
A.3.3
Proxy role.......................................................................................................................................248
A.3.3.1
A.3.3.2
SDP types...............................................................................................................................249
A.3.3.3
SDP types parameters.............................................................................................................250
A.3.3.4
SDP types parameters within attribute lines...........................................................................252
26A.4 Profile definition for other message bodies as used in the present document..............253
27
vi
1Foreword
2This document contains portions of material copied from 3GPP document number TS 24.229. The copyright
3on the 3GPP document is owned by the Organizational Partners of 3GPP (ARIB - Association of Radio
4Industries and Businesses, Japan; CWTS China Wireless Telecommunications Standards group, China; ETSI
5 European Telecommunications Standards Institute; Committee T1, USA; TTA - Telecommunications
6Technology Association, Korea; and TTC Telecommunication Technology Committee, Japan), which have
7granted license for reproduction and for use by 3GPP2 and its Organizational Partners.
8
9Revision History
Revision
number
Contentchanges.
Date
InitialPublication
TBD2004
vii
Revision
number
Contentchanges.
Date
N.P0.1
InitialrevisionProposedbaselinetext.
October21,2002
N.P0.1.1
UpdatesbasedonOctobermeetingdiscussions
November18,2002
N.P0.2.0
UpdatesincorporatecorrectionsfromNovembermeeting,
updatesofthereferences,andremovalofthedifmarksfrom
revision0.1.1.
December9,2002
N.P0.3.0
ThisversionincorporatesallacceptedWG2modifications
fromDecember2002meetinginMaui
December12,2002
N402002120910MMD:AAAupdatesforPart4
N.P1.0.0
CleanversionproducedforV&Vstart
December12,2002
N.P1.1.0
IncorporatesCRsfrom3GPPCN#18plenary(December,
2002)
January13,2003
0.1.0
Incorporateseditorialchanges,andupdatesReferences,
Editorialnote,andterminologythatwererequestedonthe
conferencecallJanuary30,2003.
February18,2003
N402003011310R1MMD:PCSCFdiscovery
N402003011309MMD:TempIDTextRemoval
0.2.0
IncorporatesthefollowingV&VContributions:
March17,2003
3GPP2X00PSN2003021716RemovaloftheSLFinterface
3GPP2X00PSN2003021750Referenceupdate
3GPP2X00PSN2003021749R1IPConnectivityNetwork
andICNBearer
3GPP2X00PSN2003021752R1CNPOA
0.3.0
April14,2003
Thisversionincorporates:
CRsfrom3GPPCN#19plenary(March,2003),
3GPP2X3220030317011R1PCSCFDiscoveryProcedure
[QC],
andminoreditorialchanges.
0.4.0
Thisversionincorporatesallmodificationsthatwere
documentedinversion0.3.0andwereacceptedattheTSGX
PSNWGmeetinginCouerd'Alene,Idaho,April1418,2003,
andalsoincorporatesthecontribution
May12,2003
3GPP2X3220030414011R1V&VonPart4[QC].
0.4.1
May16,2003
X3220030512009R1V&VonPart4[LU]
viii
0.4.2
July17,2003
CRsfrom3GPPCN#20plenary(June2003)thatwere
presentedandacceptedattheTSGXPSNWGmeetingin
SanJose,CA,July711,2003,and
X3220030707006aR1_Securuty_inX.P0013.4v041[LU].
0.4.3
Thisversionincorporatesminoreditorialchanges.
August18,2003
0.4.4
August22,2003
contributionX3220030818007X.P0013.4Update[LU],
updatedreferences,andEditornotesremovalasagreedatthe
TSGXPSNWGmeetinginSeoul,SouthKorea,August18
22,2003
1.0.0
Thisversionincorporatesallacceptedballotcomments.
1
2
ix
December8,2003
11
Scope
2The present document defines a call control protocol for use in the IP Multimedia (IM) Core Network (CN)
3subsystem based on the Session Initiation Protocol (SIP), and the associated Session Description Protocol
4(SDP).
5The present document is applicable to:
6
the interface between the User Equipment (UE) and the Call Session Control Function (CSCF);
the interface between the CSCF and any other CSCF;
the interface between the CSCF and an Application Server (AS);
the interface between the CSCF and the Media Gateway Control Function (MGCF);
10
the interface between the S-CSCF and the Media Resource Function Controller (MRFC)
11
the interface between the CSCF and the Breakout Gateway Control Function (BGCF);
12
the interface between the BGCF and the MGCF;
13
the interface between the BGCF and any other BGCF; and
14
the interface between the CSCF and an external Multimedia IP network.
15Where possible the present document specifies the requirements for this protocol by reference to specifications
16produced by the IETF within the scope of SIP and SDP. Where this is not possible, extensions to SIP and SDP
17are defined within the present document. The document has therefore been structured in order to allow both
18forms of specification.
19
20
21
22
NOTE 1: This document assumes the existence of the Go interface between the ICN Bearer Control Point
and the P-CSCF. However, since the Go interface is not supported in the MMD Revision 0, the
procedures that are dependent on the Go interface are not mandatory. This also pertains to the
Serevice Based Local Policy (SBLP) which is also not supported in the MMD Revision 0.
23
24
25
26
27
NOTE 2: The present document covers only the usage of SIP and SDP to communicate with the entities of
the IM CN subsystem. It is perfectly possible, and not precluded, to use only the capabilities of
the IP Connectivity Network to allow a terminal containing a SIP UA to communicate with SIP
servers outside the IM CN subsystem, and therefore utilise the services provided by those SIP
servers. Such usage is outside the scope of the present document.
282
References
29The following documents contain provisions which, through reference in this text, constitute provisions of the
30present document.
31
For non-specific 3GPP references the latest Release 5 applies.
32
33
References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
34
For a specific reference, subsequent revisions do not apply.
35
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP2 document,
a non-specific reference implicitly refers to the latest version of that document.
36
37[1]
void
1[2]
3GPP2 X.SP0013.000: "3GPP2 All-IP Core Network - Multimedia Domain".
2[3]
void
3[4]
void
4[5]
3GPP2 X.SP0013.003: "IP Multimedia (IM) Session Handling; IM call model".
5[6]
void
6[7]
3GPP2 X.SP0013.002: "IP multimedia subsystem; Stage 2"
7[8]
void
8[9]
void
9[10]
void
10[10A] 3GPP2 XP.S00101-CB: "Wireless IP Network Standard".

11[11]
12
void3GPP2 C.S0003-C v1.0: "Medium Access Control (MAC) Standard for cdma2000 Spread
Spectrum Systems".
13[12]
void
14[13]
void
15[14]
16
3GPP2 X.SP0013.005: "IP Multimedia (IM) Subsystem Cx Interface; Signalling flows and message
contents".
17 [15] 3GPP2 X.SP0013.006: "Cx Interface based on the Diameter protocol, Protocol details".
18[16]
3GPP2 X.SP0013.007: "IP Multimedia Subsystem - Charging Architecture".
19[17]
3GPP2 X.SP0013.008: "IP Multimedia Subsystem - Accounting Information Flows and Protocol".
20[18]
3GPP TS 33.102: "3G Security; Security architecture".
21[19] 3GPP2 S.SP0086-0: "IMS Security Framework".

22[20] void
23[20A] IETFRFC 2401 (November 1998): "Security Architecture for the Internet Protocol".
24[20B] IETFRFC 1594 (March 1994): "FYI on Questions and Answers to Commonly asked "New Internet
25
User" Questions".
26[20C] IETFRFC 2403 (November 1998) "The Use of HMAC-MD5-96 within ESP and AH".
27[20D] IETFRFC 2404 (November 1998) "The Use of HMAC-SHA-1-96 within ESP and AH".
28[20E] IETFRFC 2462 (November 1998): "IPv6 Address Autoconfiguration".
29[21] IETFRFC 2617 (June 1999): "HTTP Authentication: Basic and Digest Access Authentication".
30[22] IETFRFC 2806 (April, 2000): "URLs for Telephone Calls".
31[23] IETFRFC 2833 (May 2000): "RTP Payload for DTMF Digits, Telephony Tones and Telephony
32
Signals".
33[24] IETFRFC 2916 (September 2000): "E.164 number and DNS".
1[25] IETFRFC 2976 (October 2000): "The SIP INFO method".

2[25A] IETFRFC 3041 (January 2001): "Privacy Extensions for Stateless Address Autoconfiguration in IPv6".
3[26] IETFRFC 3261 (June 2002): "SIP: Session Initiation Protocol".
4[27] IETFRFC 3262 (June 2002): "Reliability of provisional responses in Session Initiation Protocol".
5[28] IETFRFC 3265 (June 2002): "Session Initiation Protocol (SIP) Specific Event Notification".
6[29] IETFRFC 3311 (September 2002): "The Session Initiation Protocol (SIP) UPDATE method".
7[30] IETFRFC 3312 (October 2002): "Integration of resource management and Session Initiation Protocol
8
9[31]
10
(SIP)".
IETFRFC 3313 (January 2003): "Private Session Initiation Protocol (SIP) Extensions for Media
Authorization".
11[32] IETFRFC 3320 (March 2002): "Signaling Compression (SigComp)"

12[33] IETFRFC 3323 (November 2002): "A Privacy Mechanism for the Session Initiation Protocol (SIP)".
13[34] IETFRFC 3325 (November 2002): "Private Extensions to the Session Initiation Protocol (SIP) for
14
Network Asserted Identity within Trusted Networks".
15[35] IETFRFC 3327 (December 2002): " Session Initiation Protocol Extension Header Field for Registering
16
Non-Adjacent Contacts".
17[36] IETFRFC 3515 (April 2003): "The Session Initiation Protocol (SIP) REFER method".
18 [37] IETFRFC 3420 (November 2002): "Internet Media Type message/sipfrag".
19[38] IETFRFC 3608 (October 2003):draft-ietf-sip-scvrtdisco-04 (May 2003): "Session Initiation Protocol
20
(SIP) Extension Header Field for Service Route Discovery in Private NetworksDuring Registration".
21 Editor's note: The above document cannot be formally referenced until it is published as an RFC.
22[39]
draft-ietf-mmusic-sdp-new-12 14 (SeptemberMarch 2003): "SDP: Session Description Protocol".
23Editor's note: The above document cannot be formally referenced until it is published as an RFC.
24[40] IETFRFC 3315 (July 2003): "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)".
25 [41] IETFRFC 3319 (July 2003): "Dynamic Host Configuration Protocol (DHCPv6) Options for Session
26
Initiation Protocol (SIP) Servers".
27[42] IETFRFC 3485 (February 2003): "The Session Initiation Protocol (SIP) and Session Description
28
Protocol (SDP) static dictionary for Signaling Compression (SigComp)".
29[43]
30
draft-ietf-sipping-reg-event-00 (October 2002): "A Session Initiation Protocol (SIP) Event Package for
Registrations".
31Editor's note: The above document cannot be formally referenced until it is published as an RFC.
32[44]
void
33[45]
void
34[46]
void
35[47]
void
1[48] IETFRFC 3329 (January 2003): "Security Mechanism Agreement for the Session Initiation Protocol
(SIP)".
3[49] IETFRFC 3310 (September 2002): "Hypertext Transfer Protocol (HTTP) Digest Authentication Using
Authentication and Key Agreement (AKA)".
5[50] IETFRFC 3428 (December 2002): "Session Initiation Protocol (SIP) Extension for Instant Messaging".
6[51]
void
7[52] IETFRFC 3455 (December 2002): " Private Header (P-Header) Extensions to the Session Initiation
Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)".
9 [53] IETF RFC 3388 (December 2002): "Grouping of Media Lines in Session Description Protocol".void
10[54]
IETF RFC 3524 (April 2003): "Mapping of Media Streams to Resource Reservation Flows".void
11[55] IETFRFC 3486 (February 2003): "Compressing the Session Initiation Protocol (SIP)".
12 [56] IETFRFC 3361 (August 2002): Dynamic Host Configuration Protocol (DHCP-for-IPv4)- Option for
Session Initiation Protocol (SIP) Servers.
13
14[56A] ITU-T Recommendation E.164 (May 1997): The international public telecommunication numbering
15
plan.
16[56B] IETFRFC 3556 (July 2003): " Session Description Protocol (SDP) Bandwidth Modifiers for RTP
Control Protocol (RTCP) Bandwidth".
17
18 [57] IETFRFC 2131 (March 1997): Dynamic host configuration protocol.

19[58] IETFRFC 3263 (June 2002): SIP: Locating SIP Servers.
203
Definitions and abbreviations
213.1
Definitions
22For the purposes of the present document, the following terms and definitions apply.
23IP Connectivity Network: refers to any collection of network entities and interfaces that provides the
24underlying IP transport connectivity to or between IMS entities.
25IP -Connectivity Network Bearer: a logical grouping of one or more IP flows that share a common QoS
26allocation. Depending on the particular IP -Connectivity Network, obtaining an IP -Connectivity Network
27Bearer may require the UE to specifically request access to specific IP -Connectivity Network resources (e.g.,
28Packet Data Service Instance creation). In some IP Connectivity Networks, bearers may be available without
29a specific access request.
30ICN Bearer Control Point: refers to the entity through which IP -Connectivity Network flows pass, and
31which controls the allocation of IP -Connectivity network bearer resources to the UE (e.g., PDSN).
32For the purposes of the present document, the following terms and definitions given in [20B].
33Fully-Qualified Domain Name (FQDN)
34For the purposes of the present document, the following terms and definitions given in [26] apply (unless
35otherwise specified see clause 6).
36
37
38
Back-to-Back User Agent (B2BUA)

Client
Dialog
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Final response
Header
Header field
Loose routeing
Method
Option-tag (see [26] subclause 19.2)
Provisional response
Proxy, proxy server
Redirect server
Registrar
Request
Response
Server
Session
(SIP) transaction
Stateful proxy
Stateless proxy
Status-code (see [26] subclause 7.2)
Tag (see [26] subclause 19.3)
Target Refresh Request
User agent client (UAC)
User agent server (UAS)
User agent (UA)
24For the purposes of the present document, the following terms and definitions given in [2] subclause 4.1.1.1
25and subclause 4a.7 apply:
26
27
28
29
30
Breakout Gateway Control Function (BGCF)

Call Session Control Function (CSCF)
Home Subscriber Server (HSS)
Media Gateway Control Function (MGCF)
Media Resource Function Controller (MRFC)
31For the purposes of the present document, the following terms and definitions given in [5] subclause 3.1 apply:
32
33
34
35
36
Filter criteria
Initial filter criteria
Initial request
Standalone transaction
Subsequent request
37For the purposes of the present document, the following terms and definitions given in [7] subclause 4.3.3.1
38and subclause 4.6 apply:
39
40
41
42
43
44
Interrogating-CSCF (I-CSCF)
Policy Decision Function (PDF)
Private user identity
Proxy-CSCF (P-CSCF)
Public user identity
Serving-CSCF (S-CSCF)
45For the purposes of the present document, the following terms and definitions given in [19] apply:
46
47
48
Protected Server Port

Protected Client Port
49For the purposes of the present document, the following terms and definitions given in [2] apply:
50User Equipment (UE)
1For the purposes of the present document, the following terms and definitions given in [20A] Appendix A
2apply:
3Security association
4
5
6
NOTE:
A number of different security associations exist within the IM CN subsystem. Within this
document the term specifically applies to the security association that exists between the UE and
the P-CSCF, as this is the only security association that has direct impact on SIP.
7For the purposes of the present document, the following terms and definitions given in [56A] apply:
8International public telecommunication number
93.2
Abbreviations
10For the purposes of the present document, the following abbreviations apply:
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
1xx
2xx
AAA
AIR
AS
AUTN
B2BUA
BGCF
c
CCF
CDR
CK
CN
CSCF
DHCP
DNS
DTD
ECF
FQDN
HSS
i
I-CSCF
ICID
ICN
IK
IM
IMS
IOI
IP
IPv4
IPv6
IPsec
ISC
m
MAC
MGCF
MGW
MRFC
MRFP
PLMN
PSTN
A status-code in the range 101 through 199, and excluding 100

A status-code in the range 200 through 299
Authentication, Authorization and Accounting
Accounting Information Record
Application Server
Authentication Token
Back-to-Back User Agent
Breakout Gateway Control Function
conditional
Charging Collection Function
Charging Data Record
Ciphering Key
Core Network
Call Session Control Function
Dynamic Host Configuration Protocol
Domain Name System
Document Type Definition
Event Charging Function
Fully Qualified Domain Name
Home Subscriber Server
irrelevant
Interrogating CSCF
IM CN subsystem Charging Identifier
IP Connectivity Network
Integrity Key
IP Multimedia
IP Multimedia core network Subsystem
Inter Operator Identifier
Internet Protocol
Internet Protocol version 4
Internet Protocol version 6
IP security
IP multimedia Subsystem Service Control
mandatory
Message Authentication Code
Media Gateway Control Function
Media Gateway
Multimedia Resource Function Controller
Multimedia Resource Function Processor
Public Land Mobile Network
Public Switched Telephone Network
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
n/a
NAI
o
P-CSCF
PDU
RAND
RES
R-UIM
RTP
RTCP
S-CSCF
SDP
SIP
SQN
UA
UAC
UAS
UE
URI
URL
x
XMAC
XML
244
not applicable
NetworkAccessIdentifier
optional
Proxy CSCF
Protocol Data Unit
RANDom challenge
RESponse
Removable User Identity Module
Real-time Transport Protocol
Real-time Transport Control Protocol
Serving CSCF
Session Description Protocol
Session Initiation Protocol
SeQuence Number
User Agent
User Agent Client
User Agent Server
User Equipment
Uniform Resource Identifier
Uniform Resource Locator
prohibited
expected MAC
eXtensible Markup Language
General
254.1
Conformance of IM CN subsystem entities to SIP, SDP and other protocols
26SIP defines a number of roles which entities can implement in order to support capabilities. These roles are
27defined in annex A.
28Each IM CN subsystem functional entity using an interface at the Gm reference point, the Mg reference point,
29the Mi reference point, the Mj reference point, the Mk reference point, the Mm reference point, the Mr
30reference point and the Mw reference point, and also using the IP multimedia Subsystem Service Control (ISC)
31Interface, shall implement SIP, as defined by the referenced specifications in Annex A, and in accordance with
32the constraints and provisions specified in Annex A, according to the following roles.
33The Gm reference point, the Mg reference point, the Mi reference point, the Mj reference point, the Mk
34reference point, the Mm reference point and the Mw reference point are defined in [2].
35The Mr reference point is defined in [7].
36The ISC interface is defined in [7] subclause 4.2.4.
37
38
39
40
41
The User Equipment (UE) shall provide the User Agent (UA) role with the exceptions and additional
capabilities to SIP as described in subclause 5.1, with the exceptions and additional capabilities to SDP
as described in subclause 6.1, and with the exceptions and additional capabilities to SigComp as
described in subclause 8.1. The UE shall also provide the access dependent procedures described in
subclause 9.2.
42
43
44
45
46
The P-CSCF shall provide the proxy role, with the exceptions and additional capabilities to SIP as
described in subclause 5.2., with the exceptions and additional capabilities to SDP as described in
subclause 6.2, and with the exceptions and additional capabilities to SigComp as described in
subclause 8.2. Under certain circumstances as described in subclause 5.2, the P-CSCF shall provide the
UA role with the additional capabilities, as follows:
47
a) when acting as a subscriber to or the recipient of event information; and
b) when performing P-CSCF initiated dialog-release the P-CSCF shall provide the UA role, even when
acting as a proxy for the remainder of the dialog.
1
2
3
4
The I-CSCF shall provide the proxy role, with the exceptions and additional capabilities as described in
subclause 5.3.
5
6
7
8
The S-CSCF shall provide the proxy role, with the exceptions and additional capabilities as described in
subclause 5.4, and with the exceptions and additional capabilities to SDP as described in subclause 6.3.
Under certain circumstances as described in subclause 5.4, the S-CSCF shall provide the UA role with
the additional capabilities, as follows:
9
10
a) the S-CSCF shall also act as a registrar. When acting as a registrar, or for the purposes of executing a
third-party registration, the S-CSCF shall provide the UA role;
11
b) as the notifier of event information the S-CSCF shall provide the UA role;
12
13
c) when providing a messaging mechanism by sending the MESSAGE method, the S-CSCF shall provide
the UA role; and
14
15
d) when performing S-CSCF initiated dialog release the S-CSCF shall provide the UA role, even when
acting as a proxy for the remainder of the dialog.
16
17
The BGCF shall provide the proxy role, with the exceptions and additional capabilities as described in
subclause 5.6.
18
19
The MGCF shall provide the UA role, with the exceptions and additional capabilities as described in
20
21
The AS, acting as terminating UA, or redirect server (as defined in [5] subclause 9.1.1.1), shall provide
the UA role, with the exceptions and additional capabilities as described in subclause 5.7.2.
22
23
The AS, acting as originating UA (as defined in [5] subclause 9.1.1.2), shall provide the UA role, with
the exceptions and additional capabilities as described in subclause 5.7.3.
24
25
The AS, acting as a SIP proxy (as defined in [5] subclause 9.1.1.3), shall provided the proxy role, with
the exceptions and additional capabilities as described in subclause 5.7.4.
26
27
The AS, performing 3rd party call control (as defined in [5] subclause 9.1.1.4), shall provide the UA
role, with the exceptions and additional capabilities as described in subclause 5.7.5.
28
29
The AS, receiving third-party registration requests, shall provide the UA role, with the exceptions and
additional capabilities as described in subclause 5.7.
30
31
NOTE 1: Subclause 5.7 and its subclauses define only the requirements on the AS that relate to SIP. Other
requirements are defined in [5].
32
33
34
35
36
37
NOTE 2: Annex A can change the status of requirements in referenced specifications. Particular attention
is drawn to table A.4 and table A.162 for capabilities within referenced SIP specifications, and to
table A.317 and table A.328 for capabilities within referenced SDP specifications. The remaining
tables build on these initial tables.
The MRFC shall provide the UA role, with the exceptions and additional capabilities as described in
1
2
3
4
5
6
7
NOTE 3: The allocated roles defined in this clause are the starting point of the requirements from the IETF
SIP specifications, and are then the basis for the description of further requirements. Some of
these extra requirements formally change the proxy role into a B2BUA. In all other respects
other than those more completely described in subclause 5.2 a P-CSCF implements proxy
requirements. Despite being a B2BUA a P-CSCF does not implement UA requirements from the
IETF RFCs, except as indicated in this specification, e.g., relating to registration event
subscription.
84.2
URI and address assignments
9In order for SIP and SDP to operate, the following preconditions apply:
10
11
12
13
14
15
16
1) I-CSCFs used in registration are allocated SIP URIs. Other IM CN subsystem entities may be allocated
SIP URIs. For example sip:pcscf.home1.net and sip:<impl-specific-info>@pcscf.home1.net are valid
SIP URIs. If the user part exists, it is an essential part of the address and shall not be omitted when
copying or moving the address. How these addresses are assigned to the logical entities is up to the
network operator. For example, a single SIP URI may be assigned to all I-CSCFs, and the load shared
between various physical boxes by underlying IP capabilities, or separate SIP URIs may be assigned to
each I-CSCF, and the load shared between various physical boxes using DNS SRV capabilities.
17
18
2) All IM CN subsystem entities are allocated IP addresses. Allocation of IP addresses is based on the
requirements of [7].
19
20
21
3) The subscriber is allocated a private user identity by the home network operator, and this shall beis
stored securely on the UE; it may be stored in an R-UIM. This private user identity is available to the
SIP application within the UE.
22
23
NOTE:
24
25
26
4) The subscriber is allocated one or more public user identities by the home network operator. At least
one of these is stored securely on the UE; it may be stored in an R-UIM. All registered public user
identities are available to the SIP application within the UE, after registration.
27
5) The allocation of IP address for UE is also based on the requirements of [7] subclause 4.3.
284.2A
The SIP URIs may be resolved by using any of public DNSs, private DNSs, or peer-to-peer
agreements.
Transport mechanisms
29This document makes no requirement on the transport protocol used to transfer signaling information over and
30above that specified in [26] clause 18. However, the UE and IM CN subsystem entities shall transport SIP
31messages longer than 1300 bytes according to the procedures of [26] subclause 18.1.1, even if a mechanism
32exists of discovering a maximum transmission unit size longer than 1500 bytes.
334.3
Routeing principles of IM CN subsystem entities
34Each IM CN subsystem functional entity shall apply loose routeing policy as described in [26], when
35processing a SIP request. In cases where the I-CSCF or the S-CSCF may interact with SIP entitiesstrict routers
36in non IM CN subsystem networks that apply strict routeing policy, the routeing procedures defined in [26]
37that ensure interoperability with these SIP entities strict routers shall be used by the I-CSCF and S-CSCF.
384.4
Trust domain
39 [34] provides for the existence and trust of an asserted identity within a trust domain. For the IM CN
40subsystem, this trust domain consists of the P-CSCF, the I-CSCF, the S-CSCF, the BGCF,. the MGCF, the
41MRFC, and all ASs that are not provided by third-party service providers. ASs provided by third-party service
42providers are outside the trust domain.
1For the purpose of the P-Access-Network-Info header, a trust domain also applies. This trust domain is
2identical to that of the P-Asserted-Identity. For the P-Access-Network-Info header, subclause 5.4 also identifies
3additional cases for the removal of the header.
4
5
NOTE:
In addition to the procedures specified in clause 5, procedures of [34] in relation to transmission

of P-Asserted-Identity headers and their contents outside the trust domain also apply.
64.5
Charging correlation principles for IM CN subsystems
74.5.1
Overview
8This subclause describes charging correlation principles to aid with the readability of charging related
9procedures in subclause 5. See [16] and [17] for further information on charging. The interface between the
10PDF and P-CSCF is not defined in this release. The IM CN subsystem generates and retrieves the following
11charging correlation information for later use with offline and online charging:
12
1. IM CN subsystem Charging Identifier (ICID);
13
2. Access network charging information:

a. IP Connectivity Network Charging Information;
14
15
16
17
18
NOTE 1: The Go interface see [2] that the P-CSCF utilises to obtain the IP Connectivity Network charging
information from the IP Connectivity Network is an optional interface in this release of this
document. If the Go interface is not supported, the P-Charging-Vector as described in
subclause 7.2.6 will not include the IP Connectivity Network charging information.
19
3. Inter Operator Identifier (IOI);
20
4. Charging function addresses:

a. Authentication, Authorization and Accounting (AAA);
21
22
23
24
25
NOTE 2: The Charging Collection Function (ccf) address is the address of the home AAA server [52]. This
address may be provisioned with SIP entities in the home network, or it may be dynamically
delivered. If provisioned then ccf parameter should not be used in the P-Charging-FunctionAddresses header of the SIP request or response.
26
b. Event Charging Function (ECF).
27How to use and where to generate the parameters in IM CN subsystems are described further in the subclauses
28that follow. The charging correlation information is encoded in the P-Charging-Vector header as defined in
29subclause 7.2.6. The P-Charging-Vector header contains the following parameters: icid, access network
30charging information, and ioi. The parameters are described further in the subclauses that follow. The offline
31and online charging function addresses are encoded in the P-Charging-Function-Addresses as defined in
32subclause 7.2.5. The P-Charging-Function-Addresses header contains the following parameters: CCF and ECF.
334.5.2
IM CN subsystem charging identifier (ICID)
34The ICID is the session level data shared among the IM CN subsystem entities including ASs in both the
35calling and called IM CN subsystems .
36The first IM CN subsystems entity involved in a dialog (session) or standalone (non-session) method will
37generate the ICID and include it in the icid parameter of the P-Charging-Vector header in the SIP request. See
38[17] for requirements on the format of ICID. The P-CSCF will generate an ICID for mobile originated calls.
39The I-CSCF will generate an ICID for mobile-terminated calls if there is no ICID received in the initial request
40(e.g. the calling party network does not behave as an IM CN subsystem). AnThe AS will generate ICID when
41acting as an originating UA. The MGCF will generate an ICID for PSTN/PLMN originated calls. Each entity
42that processes the SIP request will extract the ICID for possible later use in an accounting information records
10
1(AIR). The I-CSCF and S-CSCF are also allowed to generate a new ICID for mobile terminated calls received
2from another network.
3There is also an ICID generated by the P-CSCF with a REGISTER request that is passed in a unique instance
4of P-Charging-Vector header. This ICID is valid for the duration of the registration and is associated with the IP
5Connectivity Network (ICN) Bearer used for signaling.
6The icid parameter is included in any requests that include the P-Charging-Vector header. However, the P7Charging-Vector (and ICID) is not passed to the UE.
8If the Go interface is supported, tThe ICID is will be also passed from the P-CSCF/PDF to the ICN Bearer
9Control Point. The interface supporting this operation is outside the scope of this document.
104.5.3
Access network charging information
114.5.3.1 General
12The access network charging information is the media flow level data shared among the IM CN subsystem
13entities for one side of the session (either the calling or called side).
144.5.3.2 IP Connectivity Network charging information

15If the Go interface is supported, tThe ICN Bearer Control Point will provides the access network charging
16information to the IM CN subsystem, which is the common information used to correlate the ICN Bearer
17Control Point AIRs with IM CN subsystem AIRs.
18If the Go interface is supported, theThe P-CSCF will obtains the IP Connectivity Network charging
19information from the IP Connectivity Network, and forwards it to the S-CSCF in the P-Charging-Vector as
20described in subclause 7.2.6. If tThe S-CSCF receives the IP Connectivity Network charging information, it
21may also pass this information to an Application Server (AS), which may be needed for online pre-pay
22applications. The IP Connectivity Network charging information for the originating network is used only
23within that network, and similarly the IP Connectivity Network charging information for the terminating
24network is used only within that network. Thus IP Connectivity Network charging information is not shared
25between the calling and called networks. The IP Connectivity Network charging information is not passed
26towards the external ASs from its own network.
27If the Go interface is supported, tThe IP Connectivity Network charging information will beis passed at the
28first opportunity after the resources are allocated by the ICN Bearer Control Point. The IP Connectivity
29Network charging information will be updated with new information during the session as media flows are
30added or removed.
314.5.4
Inter operator identifier (IOI)
32The Inter Operator Identifier (IOI) is a globally unique identifier to share between operator networks/service
33providers/content providers. There are two possible instances of an IOI to be exchanged between
34networks/service providers/content providers: one for the originating side, orig-ioi, and one for the terminating
35side, term-ioi.
36The S-CSCF in the originating network populates the orig-ioi parameter of the P-Charging-Vector header in the
37initial request, which identifies the operator network from which the request originated. Also in the initial
38request, the term-ioi parameter is left out of the P-Charging-Vector header. The S-CSCF in the originating
39network retrieves the term-ioi parameter from the P-Charging-Vector header within the message sent in
40response to the initial request, which identifies the operator network from which the response was sent. The S41CSCF in the terminating network retrieves the orig-ioi parameter from the P-Charging-Vector header in the
42initial request, which identifies the operator network from which the request originated. The S-CSCF in the
43terminating network populates the term-ioi parameter of the P-Charging-Vector header in the response to the
44initial request, which identifies the operator network from which the response was sent.
11
1The MGCF takes responsibility for populating the orig-ioi parameter when a call/session is originated from the
2PSTN/PLMN. The MGCF takes responsibility for populating the term-ioi parameter when a call/session is
3terminated at the PSTN/PLMN.
4IOIs will not be passed along within the network, except when proxied by BGCF and I-CSCF to get to MGCF
5and S-CSCF. However, IOIs will be sent to the AS for accounting purposes.
64.5.5
Charging function addresses
7Charging function addresses are distributed to each of the IM CN subsystem entities in the home network for
8one side of the session (either the calling or called side) and are to provide a common location for each entity
9to send charging information. The AAA address is used for offline billing. Event Charging Function (ECF)
10addresses are used for online billing. The charging function addresses may be provisioned in the IMS network
11entities, or conveyed to them in the P-Charging-Function-Addresses header.
12When not provisioned, the AAA and ECF addresses are retrieved from a Home Subscriber Server (HSS) via
13the Cx interface and passed by the S-CSCF to subsequent entities. The charging function addresses are passed
14from the S-CSCF to IM the CN subsystem entities in its home network, but are not passed to the visited
15network or the UE. When the P-CSCF is allocated in the visited network, then the AAA and ECF addresses are
16obtained by means outside the scope of this document. The AS receives the charging function addresses from
17the S-CSCF via the ISC interface.
185
Application usage of SIP
195.1
Procedures at the UE
205.1.1
Registration and authentication
215.1.1.1 General
22The UE shall register public user identities (see table A.4/1 and dependencies on that major capability).
23In case a UE registers several public user identities at different points in time, the procedures to reregister,
24deregister and subscribe to the registration -state event (i.e., reg event package) for these public user identities
25can remain uncoordinated in time.
265.1.1.1A
Parameters contained in the UE
27The UE will be preconfigured with all the necessary parameters to initiate the registration to the IM CN
28subsystem. These parameters stored securely on the UE (e.g., they may be stored in an R-UIM) include:
29
the private user identity;
30
one ore more public user identities; and
31
the home network domain name used to address the SIP REGISTER request; and
32
one or more P-CSCF addresses (specified as IP address or FQDN).
335.1.1.1B
Security Association Negotiation
34The security association between UE and the first point into the operators network (P-CSCF) is negotiated
35based on protocol defined in [48]. Protocol options supported in [48] are: tls, digest, ipsec-ike, ipsec-man and
36ipsec-3gpp. If the negotiated protocol is ipsec-3gpp, this specification document applies, otherwise the
37appropriate protocol, as defined by IETF (e.g., ipsec-ike, tls, etc.) shall be applied.
12
15.1.1.2 Initial registration

2The UE can register a public user identity at any time after it has acquired an IP address, discovered a P-CSCF,
3and established an ICN Bearer to the P-CSCF. However, the UE shall only initiate a new registration procedure
4when it has received a final response from the registrar for the ongoing registration, or the previous
5REGISTER request has timed out.
6A REGISTER request may be protected using a security association, see [19], established as a result of an
7earlier registration.
8The private user identity, the public user identity, and the domain name to be used in the Request-URI in the
9registration, shall be obtained according to the procedures described in subclause 5.1.1.1A. A public user
10identity may be input by the end user. On sending a REGISTER request, the UE shall populate the header
11fields as follows:
12
a) the Authorization header, with the username field set to the value of the private user identity;
13
b) the From header set to the SIP URI that contains the public user identity to be registered;
14
c) the To header set to the SIP URI that contains the public user identity to be registered;
15
16
17
18
d) the Contact header set to include SIP URI(s) containing the IP address of the UE in the hostport
parameter or FQDN. If the REGISTER request is protected by a security association,protected port
value that is bound to the security association is known by the UE, that shall be also included the
protected server port in the hostport parameter;
19
20
21
NOTE 1: If the UE specifies its FQDN in the host parameter in the Contact header, 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.
22
23
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 protected port value see [19].
24
25
e) the Expires header, or the expires parameter within the Contact header, set to the value 600 000 seconds
as the value desired for the duration of the registration;
26
27
28
NOTE 32: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.
29
f) a Request-URI set to the SIP URI of the domain name of the home network;
30
31
32
33
34
35
36
g) the Security-Client header field set to specify the security mechanism the UE supports (see subclause
5.1.1.1B), the IPsSec 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
[19]. The syntax of the parameters needed for the security association setup is specified in [19]. The UE
shall support the "ipsec-3gpp" security mechanism, as specified in [48]. The UE shall support the
HMAC-MD5-96 [20C] and HMAC-SHA-1-96 [20D] IPsec layer algorithms and shall announce
support for them according to the procedures defined in [48];
37
h) the Supported header containing the option tag "path"; and
38
39
i) if a security association exists, a P-Access-Network-Info header that contains information concerning

the access network technology and, if applicable, the cell ID.
40On receiving the 200 (OK) response to the REGISTER request, the UE shall:
41
a) store the expiration time of the registration for the public user identitiyes found in the To header value;
42
43
b) store the list of URIs contained in the P-Associated-URI header value. This list contains the URIs that
are associated to the registered public user identity;
13
1
2
c) store as the default public user identity the first URI on the list of URIs present in the P-Associated-URI
header;
3
4
d) treat the identity under registration as a barred public user identity, if it is not included in the PAssociated-URI header; and
5
6
e) store the list of Service- Route headers contained in the Service-Route header, in order to build a proper
preloaded Route header value for new dialogs.; and
7
8
f) set the security association lifetime to the longest of either the previously existing security association
lifetime (if available), or the lifetime of the just completed registration plus 30 seconds.
9When a 401 (Unauthorized) response to a REGISTER request is received the UE shall behave as described in
10subclause 5.1.1.5.1.
11On receiving a 423 (Interval Too Brief) too brief response to the REGISTER request, the UE shall:
12
13
14
send another REGISTER request populating the Expires header or the expires parameter with an
expiration timer of at least the value received in the Min-Expires header of the 423 (Interval Too Brief)
response.
155.1.1.3 Initial subscription to the registration-state event package

16Upon receipt of a 2xx response to the initial registration, the UE shall subscribe to the reg event package for
17the public user identity registered at the users registrar (S-CSCF) as described in [43].
18The UE shall use the default public user identity for subscription to the registration-state event package, if the
19public user identity that was used for initial registration is a barred public user identity. The UE may use either
20the default public user identity or the public user identity used for initial registration for the subscription to the
21registration-state event package, if the initial public user identity that was used for initial registration is not
22barred.
23On sending a SUBSCRIBE request, the UE shall populate the header fields as follows:
24
25
a) a Request URI set to the resource to which the UE wants to be subscribed to, i.e. to a SIP URI that
contains the public user identity used for the subscription;
26
b) a From header set to a SIP URI that contains a public user identity used for the subscription;
27
c) a To header, set to a SIP URI that contains a public user identity used for the subscription;
28
d) an Event header set to the "reg" event package; and
29
30
e) an Expires header, or an expires parameter within the Contact header, set to 600 000 seconds as the
value desired for the duration of the subscription; and
31
32
f) a P-Access-Network-Info header that contains information concerning the access network technology
and, if applicable, the cell ID (see subclause 7.2.A.4).
33Upon receipt of a 2xx response to the SUBSCRIBE request, the UE shall store the information for the
34established dialog and the expiration time as indicated in the Expires header of the received response.
35If continued subscription is required, the UE shall automatically refresh the subscription by the reg event
36package for a previously registered public user identity, either 600 seconds before the expiration time if the
37initial subscription was for greater than 1200 seconds, or when half of the time has expired if the initial
38subscription was for 1200 seconds or less.
395.1.1.4 User-initiated re-registration

40The UE can reregister a previously registered public user identity at any time.
14
1Unless either the user or the application within the UE has determined that a continued registration is not
2required the UE shall reregister the public user identity either 600 seconds before the expiration time if the
3initial registration was for greater than 1200 seconds, or when half of the time has expired if the initial
4registration was for 1200 seconds or less.
5The UE shall protect the REGISTER request using a security association, see [19], established as a result of an
6earlier registration, if the integrity key is available.
7The UE shall obtain a public user identity, the private user identity, and the domain name to be used in the
8Request-URI in the registration, according to the procedures described in subclause 5.1.1.1A.
9On sending a REGISTER request that does not contain a challenge response, the UE shall populate the header
10fields as follows:
11
a) an Authorization header, with the username field set to the value of the private user identity;
12
b) a From header set to the SIP URI that contains the public user identity to be registered;
13
c) a To header set to the SIP URI that contains the public user identity to be registered;
14
15
d) a Contact header set to thea SIP URI that contains in the hostport parameter the IP address of the UE or
FQDN and protected server port value bound to the security association;
16
17
18
NOTE 1: If the UE specifies its FQDN in the host parameter in the Contact header, 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.
19
20
NOTE 2: The UE associates two ports, a protected client port and a protected server port, with each pair of
security associations. For details on the selection of the protected port value see [19].
21
22
e) anthe Expires header, or anthe expires parameter within the Contact header, set to 600 000 seconds as
the value desired for the duration of the registration;
23
24
25
NOTE 32: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.
26
f) a Request-URI set to the SIP URI of the domain name of the home network;
27
28
29
g) a Security-Client header field, set to specify the security mechanism it supports, the IPsSec layer
algorithms it supports and the parameters needed for the security association setup of two new pairs of
security associations. For further details see [19] and [48];
30
h) the Supported header containing the option tag "path"; and
31
32
i) the P-Access-Network-Info header that contains information concerning the access network technology
and, if applicable, the cell ID (see subclause 7.2A.4).
33On receiving the 200 (OK) response to the REGISTER request, the UE shall:
34
35
a) store the new expiration time of the registration for this public user identity found in the To header
value;
36
37
b) store the list of URIs contained in the P-Associated-URI header value. This list contains the URIs that
are associated to the registered public user identity; and
38
39
c) store the list of Service-Route headers contained in the Service-Route header, in order to build a proper
preloaded Route header value for new dialogs.; and
40
41
d) set the security association lifetime to the longest of either the previously existing security association
lifetime, or the lifetime of the just completed registration plus 30 seconds.
15
1When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in
3On receiving a 423 (Interval Too Brief) response to the REGISTER request, the UE shall:
4
5
6
send another REGISTER request populating the Expires header or the expires parameter with an
expiration timer of at least the value received in the Min-Expires header of the 423 (Interval Too Brief)
response.
75.1.1.5 Authentication
85.1.1.5.1
General
9Authentication is achieved via the registration and re-registration procedures. When the network requires
10authentication or re-authentication of the UE, the UE will receive a 401 (Unauthorized) response to the
11REGISTER request.
12On receiving a 401 (Unauthorized) response to the REGISTER request, the UE shall:
13
1) extract the RAND and AUTN parameters;
14
15
16
2) check the validity of a received authentication challenge, as described in [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
17
18
19
3) check the existence of the Security-Server header as described in [48]. If the header is not present or it
does not contain the parameters required for the setupset up of the security associations, see [19]), the
UE shall abandon the authentication procedure and send a new REGISTER request with a new Call-ID.
20In the case that the 401 (Unauthorized) response to the REGISTER request is deemed to be valid the UE shall:
21
1) calculate the RES parameter and derive the keys CK and IK from RAND as described in [19];
22
23
24
25
26
27
28
29
2) set up twothe new pairs of security associations based on the static list and parameters it received in the
401 (Unauthorized) response and its capabilities sent in the Security-Client header in the REGISTER
request. The UE shall sets up two pairshe of security associations using the most preferred mechanism
and algorithm returned by the P-CSCF and supported by the UE, and if ipsec-3gpp is selected, using
CK and IK as shared keys. The UE shall use the parameters received in the Security-Server header to
set up these security associations. The UE shall set a temporary SIP level lifetime of the newly set up
security associations to a value which has to be long enough to permit the UE to finalize the registration
procedure (longer than 64*T1); and
30
31
32
33
34
35
36
37
38
39
3) send another REGISTER request using the derived IK to integrity protect the message. The header
fields are populated as defined for the initial request, with the addition that the UE shall include an
Authorization header containing the private user identity and the authentication challenge response
(RES parameter), as described in [49]. Instead of Tthe UE shall also insert the Security-Client header
that is identical to the Security-Client header that was included in the previous REGISTER request (i.e.,
the REGISTER request that was challenged with the received 401 (Unauthorized) response). Tthe UE
shall also insert the Security-Verify header into the request, by mirroring in it the content of the
Security-Server header received in the 401 (Unauthorized) response. The Call-ID of the integrity
protected REGISTER request, which carries the RES must be the same as the Call-ID of the 401
(Unauthorized) response which carried the challenge.
40On receiving the 200 (OK) response for the integrity protected REGISTER request, the UE shall:
41
42
1) set the security association lifetime to the longest of either the previously existing security association
lifetime, or the lifetime of the just completed registration plus 30 seconds;
43
2) send subsequent requestsmessages towards the P-CSCF using the new security associations;
16
1
2
3) send the responses toward the P-CSCF over the same security association that the associated request
was receivedthe 200 (OK) response was protected with; and
3
4
4) receive the responses from the P-CSCF over the same security association that the associated request
was sent.
5When the first request or a responsemessage protected with the newly set up security association is received
6from the P-CSCF, the UE shall delete the oldearlier security associations and related keys it may have with the
7P-CSCF, after all SIP transactions that use the old security associations are completed.
8Whenever the 200 (OK) response is not received before the temporary SIP level lifetime of the new security
9associations expiresafter a time-out, the UE shall consider the registration to have failed. The UE shall delete
10the new security associations it was trying to establish, and use the old security associations. The UE should
11send an unprotected REGISTER message according to the procedure specified in subclause 5.1.1.2 if the UE
12considers the earlier established security associations to be no longer active at the P-CSCF.
13In the case that the 401 (Unauthorized) response is deemed to be invalid then the UE shall behave as defined in
155.1.1.5.2
Network-initiated re-authentication
16At any time, the UE can receive a NOTIFY request carrying information related to the reg event package (as
17described in subclause 5.1.1.3). If:
18
the state attribute in any of the <registration> elements is set to "active";
19
the value of the <contact> sub-element is set to the Contact address that the UE registered; and
20
the event attribute of that <contact> sub-element(s) is set to "shortened";
21the UE shall:
22
23
1) use the expiry attribute within the <contact> element to adjust the expiration time for that public user
identity; and
24
25
2) start the re-authentication procedures at the appropriate time (as a result of the S-CSCF procedure
described insee subclause 5.41.1.46) by initiating a reregistration as described in subclause 5.1.1.4.
265.1.1.5.3
Abnormal cases
27If, in a 401 (Unauthorized) response, either the MAC or SQN is incorrect the UE shall respond with a further
28REGISTER request indicating to the S-CSCF that the challenge has been deemed invalid as follows:
29
30
in the case where the UE deems the MAC parameter to be invalid the subsequent REGISTER request
shall contain no RES and no AUTS parameter;
31
32
in the case where the UE deems the SQN to be out of range, the subsequent REGISTER request shall
contain the AUTS parameter and no RES parameter [18].
33The UE shall send the REGISTER request using an existing security association, if available (see [19]). The
34REGISTER request shall contain a new Security-Client header, set to specify the security mechanism it
35supports, the IPsec layer algorithms it supports and the parameters needed for the new security association
36setup.
37A UE shall only respond to two consecutive invalid challenges. The UE may attempt to register with the
38network again after an implementation specific time. The UE shall send the REGISTER request using an
39existing security association if available [19].
17
15.1.1.5A
Change of IPv6 address due to privacy
2Stateless address autoconfiguration as described in [20E] defines how an IPv6 prefix and an interface identifier
3is used by the UE to construct a complete IPv6 address.
4If the UE receives an IPv6 prefix, the UE may change the interface identity of the IPv6 address as described in
5[25A] due to privacy but this will result in service discontinuity for IMS services.
6
7
8
9
NOTE:
The procedure described below will terminate all established dialogs and transactions and
temporarily disconnect the UE from the IM CN subsystem until the new registration is
performed. Due to this, the UE is recommended to provide a limited use of the procedure to
ensure a maximum degree of continuous service to the end user.
10In order to change the IPv6 address due to privacy, the UE shall:
11
1) terminate all ongoing dialogs (e.g., sessions) and transactions (e.g., subscription to the reg event);
12
2) deregister all registered public user identities as described in subsclause 5.1.1.64;
13
3) construct a new IPv6 address according to the procedures specified in [25A];
14
4) register the public user identities that were deregistered in step 2 above, as follows:
15
a) by performing an initial registration as described in subsclause 5.1.1.2; and
16
b) by performing a subscription to the reg event package as described in subsclause 5.1.1.3; and
17
18
5) subscribe to other event packages it was subscribed to before the change of IP address procedure
started.
195.1.1.6 Mobile-initiated deregistration

20The UE can deregister a previously registered public user identity at any time.
21Prior to sending a REGISTER request for deregistration, the UE shall release all dialogs related to the public
22user identity that is going to be deregistered or to one of the implicitly registered public user identities.
23The UE shall protect the REGISTER request using a security association [19] established as a result of an
24earlier registration, if one integrity key is available.
25Prior to sending a REGISTER request for deregistration, the UE shall release all dialogs related to the public
26user identity that is going to be deregistered or to one of the implicitly registered public user identities.
27The UE shall obtain the public user identity, the private user identity, and the domain name to be used in the
28Request-URI in the registration, according to the procedures described in subclause 5.1.1.1A.
29On sending a REGISTER request, the UE shall populate the header fields as follows:
30
a) the Authorization header, with the username field, set to the value of the private user identity;
31
b) the From header set to the SIP URI that contains the public user identity to be deregistered;
32
c) the To header set to the SIP URI that contains the public user identity to be deregistered;
33
34
d) the Contact header set to either the value of "*" or SIP URI(s) that contain(s) in the hostport parameter
the IP address of the UE or FQDN and the protected server port value bound to the security association;
35
36
e) the Expires header, or the expires parameter of the Contact header, set to the value of zero, appropriate
to the deregistration requirements of the user;
37
f) a Request-URI set to the SIP URI of the domain name of the home network; and
18
1
2
g) a P-Access-Network-Info header that contains information concerning the access network technology
and, if applicable, the cell ID (see subclause 7.2.3).
3On receiving the 200 (OK) response to the REGISTER request, the UE shall remove all registration details
4relating to this public user identity.
5If there are no more public user identities registered, the UE shall delete the security associations and related
6keys it may have towards the IM CN subsystem .
7If all public user identities are deregistered and the security association is removed, then the UE shall consider
8subscription to the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an
9Expires header containing a value of zero).
10
11
12
13
14
NOTE:
When the UE has received the 200 (OK) response for the REGISTER request of the only public
user identity currently registered with its associated set of implicitly registered public user
identities (i.e. no other is registered), the UE removes the security association established
between the P-CSCF and the UE. Therefore further SIP signaling (e.g. the NOTIFY request
containing the deregistration event) will not reach the UE
155.1.1.7 Network-initiated deregistration

16Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event
17package as described in subclause 5.1.1.3, including one or more <registration> element(s) with the state
18attribute set to "terminated" and the event attribute set to "rejected" or "deactivated", the UE shall remove all
19registration details relating to these public user identities. In case of a "deactivated" event attribute, the UE
20shall start the reregistration procedure as described in subclause 5.1.1.4. In case of a "rejected" event attribute,
21the UE shall release all dialogs related to those public user identities.
22Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute set to
23"terminated" (i.e. all public user identities are deregistered) and the Subscription-State header contains the
24value of "terminated", the UE shall delete the security associations towards the P-CSCF after the server
25transaction (as defined in [26]) pertaining to the NOTIFY request terminates.
26
27
NOTE 1: Deleting a security association is an internal procedure of the UE and does not involve any SIP
procedures.
28
29
30
31
NOTE 2: If all public user identities are deregistered and the security association is removed, then the UE
considers the subscription to the reg event package terminated (i.e. as if the UE had sent a
SUBSCRIBE request with an Expires header containing a value of zero, or a NOTIFY request
was received with Subscription-State header containing the value of "terminated").
32
33
34
NOTE 3: When the P-CSCF has removed the security association established between the P-CSCF and the
UE, further SIP signaling (e.g. the NOTIFY contaning the deregistration event) will not reach the
UE.
355.1.2
Subscription and notification
365.1.2.1 Notification about multiple registered public user identities

37Upon receipt of a 2xx response to the SUBSCRIBE request the UE shall maintain the generated dialog
38(identified by the values of the Call-ID, To and From headers).
40package the UE shall perform the following actions:
41
42
if a 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;
43
44
if a state attribute "terminated", i.e. deregistered is received for one or more public user identities, the
UE shall store the indicated public user identities as deregistered.
19
1
2
3
4
5
6
7
NOTE:
There may be public user identities which are automatically registered within the registrar (SCSCF) of the user upon registration of one public user identity. Usually these automatically or
implicitly registered public user identities belong to the same service profile of the user and they
might not be available within the UE. The implicitly registered public user identities may also
belong to different service profiles. The here-described procedures provide a different
mechanism (to the 200 (OK) response to the REGISTER request) to inform the UE about these
automatically registered public user identities.
85.1.2.2 General SUBSCRIBE requirements

9If the UA receives a 503 (Service Unavailable) response to an initial SUBSCRIBE request containing a Retry10After header, then the UE shall not automatically reattempt the request until after the period indicated by the
11Retry-After header contents.
125.1.2A Generic procedures applicable to all methods excluding the REGISTER

13method
145.1.2A.1
Mobile-originating case
15The procedures of this subclause are general to all requests and responses, except those for the REGISTER
16method.
17The UE shall discard any SIP message that is not integrity protected and is received from the P-CSCF outside
18of the registration and authentication procedures. The requirements on the UE within the registration and
19authentication procedures are defined in subclause 5.1.1.
20In accordance with [34] the UE may insert a P-Preferred -Identity header in any initial request for a dialog or
21request for a standalone transaction as a hint for creation of an asserted identity within the IM CN subsystem.
22The UE may include any of the following in the P-Preferred -Identity header:
23
a public user identity which has been registered by the user;
24
25
a public user identity returned in a registration-state event package of a NOTIFY request as a result of
an implicit registration that was not subsequently deregistered or has expired; or
26
27
any other public user identity which the user has assumed by mechanisms outside the scope of this
specification to have a current registration.
28
29
NOTE 1: Procedures in the network require international public telecommunication numbers when
telephone numbers are used in P-Preferred-Identity Hheader.
30Where privacy is required, in any initial request for a dialog or request for a standalone transaction, the UE
31shall set the From header to "Anonymous".
32
33
34
35
36
37
38
39
40
41
NOTE 2: The contents of the From header should not be relied upon to be modified by the network based
on any privacy specified by the user either within the UE indication of privacy or by network
subscription or network policy. Therefore the user should include the value "Anonymous"
whenever privacy is explicitly required. As the user may well have privacy requirements,
terminal manufacturers should not automatically derive and include values in this header from
the public user identity or other values stored in the UE. Where the user has not expressed a
preference in the configuration of the terminal implementation, the implementation should
assume that privacy is required. Users that require to identify themselves, and are making calls to
SIP destinations beyond the IM CN subsystem, where the destination does not implement [34],
will need to include a value in the From header other than Anonymous.
42The UE can indicate privacy of the P- Asserted -Identity that will be generated by the P-CSCF in accordance
43with [33], and the additional requirements contained within [34].
20
1The UE shall insert a P-Access-Network-Info header into any request for a dialog, any subsequent request
2(except ACK requests and CANCEL requests) or response (except CANCEL responses) within a dialog or any
3request for a standalone method. This header shall contain information concerning the access network
4technology and, if applicable, the cell ID (see subclause 7.2. 3).
5The UE shall build a proper preloaded Route header value for all new dialogs and standalone transactions. The
6UE shall build a list of Route header values made out of, in this order, the P-CSCF URI (containing the IP
7address or the FQDN learnt through the P-CSCF discovery procedures and the protected server port learnt
8during the registration procedure) and the values received in the Service-Route header saved from the 200
9(OK) response to the last registration or re-registration.
105.1.2A.2
Mobile-terminating case
11The procedures of this subclause are general to all requests and responses, except those for the REGISTER
12method.
13The UE shall discard any SIP message that is not integrity protected and is received from the P-CSCF outside
14of the registration and authentication procedures. The requirements on the UE within the registration and
15authentication procedures are defined in subclause 5.1.1.
16The UE can indicate privacy of the P-Asserted-Identity that will be generated by the P-CSCF in accordance
17with [33], and the additional requirements contained within [34].
18
19
NOTE:
In the mobile-terminating case, this version of the document makes no provision for the UE to
provide a P- Preferred -Identity in the form of a hint.
20The UE shall insert a P-Access-Network-Info header into any response to a request for a dialog, any
21subsequent request (except CANCEL requests) or response (except CANCEL responses) within a dialog or any
22response to a standalone method. This header shall contain information concerning the access network
23technology and, if applicable, the cell ID (see subclause 7.2. 3).
245.1.3
Call initiation - mobile originating case
255.1.3.1 Initial INVITE

26Upon generating an initial INVITE request, the UE shall:
27
28
indicate the support for reliable provisional responses and specify it using the Supported header
mechanism;
29
indicate the requirement of precondition and specify it using the Require header mechanism.
30
31
32
33
34
NOTE 1: Table A.4 specifies that UE support of forking is required in accordance with [26]. While proxies
in the IM CN subsystem do not fork requests, proxies external to the system may initiate forking,
such that the UE is able to receive several forked provisional or final responses from different
terminations. The UE may 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.
35When a final answer is received for one of the early dialogs, the UE proceeds to set up the SIP session. The UE
36shall not progress any remaining early dialogs to established dialogs. Therefore, upon the reception of a
37subsequent final 200 (OK) response for an INVITE request (e.g., due to forking), the UE shall:
38
1) acknowledge the response with an ACK request; and
39
2) send a BYE request to this dialog in order to terminate it.
40If the UA receives a 503 (Service Unavailable) response to an initial INVITE request containing a Retry-After
41header, then the UE shall not automatically reattempt the request until after the period indicated by the Retry42After header contents.
21
1If the UE receives a 488 (Not Acceptable Here) response to an initial INVITE request, the UE should send a
2new INVITE request containing SDP according to the procedures defined in subclause 6.1.
3
4
5
NOTE 2: An example of where a new request would not be built is where knowledge exists within the UE,
or interaction occurs with the user, such that it is known that the resultant SDP would describe a
session that did not meet the user requirements.
6
7
8
If the UE receives a 420 (Bad Extension) response to an initial INVITE request with "precondition" optiontag in the Unsupported header field, the UE shall abort the session attempt and shall not resend
this INVITE request without "precondition" option-tag in the Require header.
95.1.4
Call initiation - mobile terminating case

11Upon receiving an initial INVITE request without containing either Supported: precondition or Require:
12precondition header values, the UE shall generate a 421 (Extension Required) response indicating the required
13extension in the Require header field.
14Upon generating the first response to the initial INVITE request, the UE shall indicate the requirement for
15reliable provisional responses and specify it using the Require header mechanism. The UE shall send the 200
16(OK) response to the initial INVITE request only after the local resource reservation has been completed.
17
18
19
20
NOTE:
215.1.5
Table A.4 specifies that UE support of forking is required in accordance with [26]. While proxy
support of forking is precluded in the IM CN subsystem, proxies external to the system may
initiate forking, such that the UE is able to receive several forked requests for the same
transaction.
Call release
22Void.
235.1.6
Emergency service
24Void.
255.1.7
Void
265.2
Procedures at the P-CSCF
275.2.1
General
28The P-CSCF shall support the Path and Service-Route headers.

29
30
NOTE 1: The Path header is only applicable to the REGISTER request and its 200 (OK) response. The
Service-Route header is only applicable to the 200 (OK) response of REGISTER request.
31When the P-CSCF sends any request or response to the UE, before sending the message the P-CSCF shall:
32
remove the P-Charging-Function-Addresses and P-Charging-Vector headers, if present.
33When the P-CSCF receives any request or response from the UE, the P-CSCF shall:
34
35
36
remove the P-Charging-Function-Addresses and P-Charging-Vector headers, if present. Also, the PCSCF shall ignore any data received in the P-Charging-Function-Addresses and P-Charging-Vector
headers; and
37
38
may insert previously saved values into the P-Charging-Function-Addresses and P-Charging-Vector
headers before forwarding the message.
22
1
2
3
NOTE 2: When the P-CSCF is located in the visited network, then it will not receive the P-ChargingFunction-Addresses header from the S-CSCF or I-CSCF. Instead, the P-CSCF discovers
charging function addresses by other means not specified in this document.
4When the P-CSCF receives any request or response containing the P-Media-Authorization header from the S5CSCF, the P-CSCF shall remove the header.
6
7
NOTE 3: If service based local policy applies, the P-CSCF will insert the P-Media-Authorization header as
described in subclauses 5.2.7.2 and 5.2.7.3.
8The P-CSCF shall integrity protect all SIP messages sent to the UE outside of the registration and
9authentication procedures. The P-CSCF shall discard any SIP message that is not integrity protected and is
10received outside of the registration and authentication procedures. The integrity protection and checking
11requirements on the P-CSCF within the registration and authentication procedures are defined in subclause
125.2.2.
135.2.2
Registration
14When the P-CSCF receives a REGISTER request from the UE, the P-CSCF shall:
15
1) insert a Path header in the request including an entry containing:
16
the SIP URI identifying the P-CSCF;
17
18
19
an indication that requests routed in this direction of the path (i.e. from the S-CSCF to the P-CSCF) are
expected to be treated as for the mobile-terminating case. This indication may e.g. be in a parameter in
the URI, a character string in the user part of the URI or be a port number in the URI;
20
2) insert a Require header containing the option tag "path";
21
22
3) for the initial REGISTER request for a public user identity create a new, globally unique value for icid,
save it locally and insert it into the icid parameter of the P-Charging-Vector header;
23
24
25
26
27
28
4) insert the parameter "integrity-protected" (described in subclause 7.2A.2) with a value yes into the
Authorization header field in case the REGISTER request was either received integrity protected with
the security association created during an ongoing authentication procedure and includes an
authentication response, or it was received on the security association created during the last successful
authentication procedure and with no authentication response,, otherwise insert the parameter with the
value no;
29
30
31
32
5) in case the REGISTER request was received without integrity protection, then check the existence of
the Security-Client header. If the header is present, then remove and store it. The P-CSCF shall remove
the sec-agree item from the Require header, and the header itself if this is the only entry. If the header
is not present, then the P-CSCF shall return a suitable 4xx response;
33
6) in case the REGISTER request was received integrity protected, then the P-CSCF shall:
34
35
36
37
38
39
40
41
42
43
check the security association which protected the request. If that has a temporary lifetime, and the
REGISTER request was received protected with the new security association, then the request shall
contain a Security-Verify header in addition to a Security-Client header. If there areis no such headers,
then the P-CSCF shall return a suitable 4xx error code. If there areis such headers, then compare the
content of the Security-Verify header with the content of the Security-Server header sent earlier and
compare the content of the Security-Client header with the content of the Security-Client header
received in the challenged REGISTER local static list. If those do not match, then there is a potential
man-in-the-middle attack. The request should be rejected by sending a suitable 4xx response. If the
contents match, the P-CSCF shall remove the Security-Verify header, the Security-Client header, and
the "sec-agree" item from the Require header, and the header itself if this is the only entry;
44
if the security association the REGISTER request was received on, is an already established one, then:
23
1
2
- a Security-Verify header is not expected to be included. If the Security-Verify header is present,

then the P-CSCF shall remove that header together with the 'Require: sec-agree' header;
3
4
a Security-Client header containing new parameter values is expected. If this header or any
required parameter is missing, then the P-CSCF shall return a suitable 4xx response;
5
6
the P-CSCF shall remove the Security-Client header before forwarding the request to the SCSCF; and
7
8
9
check if the private user identity conveyed in the integrity-protected REGISTER request is the same as
the private user identity which was previously challenged or authenticated. If the private user identities
are different, the P-CSCF shall reject the REGISTER request by returning a 403 (Forbidden) response;
10
11
7) insert a P-Visited-Network-ID header field, with the value of a pre-provisioned string that identifies the
visited network at the home network; and
12
8) determine the I-CSCF of the home network and forward the request to that I-CSCF.
13When the P-CSCF receives a 401 (Unauthorized) response to a REGISTER request, the P-CSCF shall:
14
15
16
17
1) remove the CK and IK values contained in the 401 (Unauthorized) response and bind them to the
proper private user identity and security associations which will be set up as a result of this challenge.
The P-CSCF shall forward the 401 (Unauthorized) response to the UE if and only if the CK and IK
have been removed;
18
19
20
21
22
2) insert athe Security-Server header in the response, containing the P-CSCF static security list and the
parameters needed for the security association setup, as specified in [19]. The P-CSCF shall support the
"ipsec-3gpp" security mechanism, as specified in [48]. The P-CSCF shall support the HMAC-MD596 [20B] and HMAC-SHA-1-96 [20C] IPsec layer algorithms. . The P-CSCF shall support the setup of
two pairs of security associations. For further information see [19]; and
23
24
25
26
27
3) set up the new security associations with a temporary lifetime between the UE and the P-CSCF for the
user identified with the private user identity. For further details see [19] and [48]. The P-CSCF shall set
a temporary the SIP level lifetime of the security association to be long enough to permit the UE to
finalize the registration procedure (bigger than 64*T1). The P-CSCF shall set the IPSec level lifetime of
the security association to the maximum.
28
29
30
4) send the 401 (Unauthorized) response to the UE using the security association with which the associated
REGISTER request was protected, or unprotected in case the REGISTER request was received
unprotected.
31
32
33
34
35
NOTE 1: The challenge in the 401 (Unauthorized) response sent back by the S-CSCF to the UE as a
response to the REGISTER request is piggybacked by the P-CSCF to insert the Security-Server
header field in it. The S-CSCF authenticates the UE, while the P-CSCF negotiates and sets up
two pairs ofthe security associations with the UE during the same registration procedure. For
further details see [19].
36When the P-CSCF receives a 200 (OK) response to a REGISTER request, the P-CSCF shall check the value of
37the Expires header field and/or Expires parameter in the Contact header. When the value of the Expires header
38field and/or expires parameter in the Contact header is different than zero, then the P-CSCF shall:
39
40
41
42
1) save the list of Service-Route headers preserving the order. The P-CSCF shall store this list during the
entire registration period of the respective public user identity. The P-CSCF shall use this list to validate
the routeing information into the requests originated by the UE. If this registration is a reregistration, the
P-CSCF shall replace the already existing list of Service-Route headers with the new list;
43
2) associate the Service-Route header list with the registered public user identity;
44
45
3) store the public user identities found in the P-Associated-URI header value, as those that are authorized
to be used by the UE;
24
1
2
3
4) store the default public user identity for use with procedures for the P-Asserted-Identity header. The
default public user identity is the first on the list of URIs present in the P-Associated-URI header
values;
4
5
NOTE 2: There may be more then one default public user identities stored in the P-CSCF, as the result of
the multiple registrations of public user identities.
5) store the values received in the P-Charging-Function-Addresses header;
7
8
9
6) set the security association lifetime to the longest of either the previously existing security association
lifetime, or the lifetime of the just completed registration plus 30 seconds; and update the SIP level
lifetime of the security association with the value found in the Expires header.
10
11
7) protect the 200 (OK) response to the REGISTER request within the same security association to that in
which the associated REGISTER request was protected;
12The P-CSCF shall:

13
14
If new security associations are established and there are no old security associations, start using
the new security associations towards the UE after the 200OK has been sent out.
15
16
17
If a request protected within the newly established security associations is received from a UE
which has old security associations, delete the old security associations and related keys when all
SIP transactions that use the old security associations are completed.
18
19
If the newly established security associations has not been taken into use by the UE and the UE
sends request protected on the old security associations, delete the new security associations.
20
21
22
If the newly established security associations are a result of an unprotected REGISTER request
being received from the UE, then delete the old security associations which may exist towards the
UE.
23
24
25
26
8) delete all earlier security associations and related keys it may have towards the UE, when a message
protected within the newly set up security association is received. When sending messages toward the
UE, prior to receiving the first message protected within the newly set up security association, P-CSCF
shall use the earlier security association and related keys it may have towards the UE; and
27
28
9) delete the new security associations that it was trying to establish with the UE, in case the P-CSCF
receives a message from the UE protected with the old security association.
29
30
31
32
33
34
NOTE 3: The P-CSCF will maintain two Route lists. The first Route list - created during the registration
procedure - is used only to pre-load the routeing information into the initial INVITE request that
originated at the UE. This list is valid during the entire registration of the respective public user
identity. The second Route list - constructed from the Record- Route headers in the initial
INVITE and associated response - is used during the duration of the call. Once the call is
terminated, the sec ond Route list is discarded.
35The P-CSCF shall delete any security association when their SIP level lifetime expires.
365.2.3
Subscription to the users registration-state event package
37Upon receipt of a 200 (OK) response to the initial REGISTER request of an user, the P-CSCF shall subscribe
38to the user's registration event package at the users registrar (S-CSCF) as described in [43]. The P-CSCF shall:
39
1) generate a SUBSCRIBE request with the following elements:
40
41
a Request-URI set to the resource to which P-CSCFit wants to subscribe to, i.e. to a SIP URI that
contains the default public user identity of the user;
42
a From header set to the P-CSCF's SIP URI;
25
a To header, set to a SIP URI that contains the default public user identity of the user ;
an Event header set to the "reg" event package; and
3
4
an Expires header set to a value higher thaen the Expires header indicated in the 200 (OK) response to
the REGISTER request; and
5
6
a P-Asserted-Identity header containing the SIP URI of the P-CSCF, which was inserted into the Path
header during the registration of the user to whose registration state the P-CSCF subscribes to; and
2) determine the I-CSCF of the home network (e.g., by using DNS services);
8before sending the SUBSCRIBE request to that I-CSCF, according to the procedures of [26].
9Upon receipt of a 2xx response to the SUBSCRIBE request, the P-CSCF shall store the information for the so
11If continued subscription is required, the P-CSCF shall automatically refresh the subscription to the reg event
12package for a previously registered public user identity, either 600 seconds before the expiration time if the
13initial subscription was for greater than 1200 seconds, or when half of the time has expired if the initial
14subscription was for 1200 seconds or less.
155.2.4
Registration of multiple public user identities
16Upon receipt of a 2xx response to the SUBSCRIBE request the P-CSCF shall maintain the generated dialog
17(identified by the values of the Call-ID, To and From headers).
19package, the P-CSCF shall perform the following actions:
20
21
if a state attribute "active", i.e. registered is received for one or more public user identities, the P-CSCF
shall bind the indicated public user identities as registered to the contact information of the user;
22
23
if a state attribute "terminated", i.e. deregistered is received for one or more public user identities, the PCSCF shall release all stored information for these public user identities.
24
25
26
27
28
29
NOTE:
305.2.5
There may be public user identities which are implicitlyautomatically registered within the
registrar (S-CSCF) of the user upon registration of one public user identity. These automatically
registered public user identities belong to the same service profile of the user and they are not
available at the P-CSCF, i.e. P-CSCF does not know that they have been registered. The heredescribed procedures in this subclause provide a mechanism to inform the P-CSCF about these
implicitlyautomatically registered public user identities.
Deregistration
315.2.5.1 User-initiated deregistration

32When the P-CSCF receives a 200 (OK) response to a REGISTER request (sent according to subclause 5.2.2), it
33shall check the value of the Expires header field and/or expires parameter in the Contact header field. When the
34value of the Expires header field or expires parameter equals zero, then the P-CSCF shall:
35
36
1) remove the public user identity found in the To header field, and all the associated public user identities,
from the registered public user identities list and all related stored information; and
37
38
39
40
41
42
2) check if the user has left any other registered public user identity. When all of the public user identities
of a user are deregistered, the P-CSCF shall delete , if the subscription to the reg event package for that
user is still alive, terminate the subscription to the reg event package for that user by sending a
SUBSCRIBE request with an Expires header containing a value of zero. The P-CSCF shall also remove
the security associations towards that user after the server transaction (as defined in [26]) pertaining to
this deregistration terminates.
26
1
2
3
4
5
NOTE 1: Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute
set to "terminated" (i.e. all public user identities are deregistered) and the Subscription-State
header set to "terminated", the P-CSCF considers the subscription to the reg event package
terminated (i.e. as if the P-CSCF had sent a SUBSCRIBE request with an Expires header
containing a value of zero).
6
7
8
NOTE 21:There is no requirement to distinguish a REGISTER request relating to a registration from that
relating to a deregistration. For administration reasons the P-CSCF may distinguish such
requests, however this has no impact on the SIP procedures.
9
10
11
12
NOTE 32:When the P-CSCF has sent the 200 (OK) for the REGISTER request of the last registered public
user identity, the P-CSCF removes the security association established between the P-CSCF and
the UE. Therefore further SIP signaling (e.g. the NOTIFY containing the deregistration event)
will not reach the UE.

15package as described in subclause 5.2.3, including one or more <registration> element(s) with the state
16attribute set to "terminated" the P-CSCF shall remove all stored information for these public user identities.
17Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute set to
18"terminated" (i.e. all public user identities are deregistered) and the Subscription-State header set to
19"terminated", the P-CSCF shall delete the security associations towards the UE.
20
21
22
NOTE 1: When the P-CSCF has removed the security association established between the P-CSCF and the
UE, further SIP signaling (e.g. the NOTIFY request containing the deregistration event) will not
reach the UE.
23
24
25
26
NOTE 2: When the P-CSCF receives the NOTIFY request with Subscription-State header containing the
value of "terminated", the P-CSCF considers the subscription to the reg event package
terminated (i.e. as if the P-CSCF had sent a SUBSCRIBE request to the S-CSCF with an Expires
header containing a value of zero).
275.2.6 General treatment for all dialogs and standalone transactions excluding the
28REGISTER method
295.2.6.1 Introduction
30The procedures of subclause 5.2.6 and its subclauses are general to all requests and responses, except those for
31the REGISTER method.
325.2.6.2 Determination of mobile-originated or mobile-terminated case

33Upon receipt of an initial request or a target refresh request or a stand-alone transaction, the P-CSCF shall:
34
35
36
37
perform the procedures for the mobile-terminating case as described in subclause 5.2.6.4 if the request
makes use of the information for mobile-terminating calls, which was added to the Path header entry of
the P-CSCF during registration (see subclause 5.2.2), e.g. the message is received at a certain port or the
topmost Route header contains a specific user part or parameter;
38
39
perform the procedures for the mobile-originating case as described in subclause 5.2.6.3 if this
information is not used by the request.
27
15.2.6.3 Requests initiated by the UE

2When the P-CSCF receives an initial request for a dialog or a request for a standalone transaction, and the
3request contains as P-Preferred -Identity header that matches one of the registered public user identities, the P4CSCF shall identify the initiator of the request by that public user identity.
5When the P-CSCF receives an initial request for a dialog or a request for a standalone transaction, and the
6request contains as P-Preferred -Identity header that does not match one of the registered public user identities,
7or does not contain a P-Preferred -Identity header, the P-CSCF shall identify the initiator of the request by a
8default public user identity. If there is more then one default public user identity available, the P-CSCF shall
9randomly select one of them.
10
NOTE 1: The contents of the From header do not form any part of this decision process.
11When the P-CSCF receives from the UE an initial request for a dialog, and a Service-Route header list exists
12for the initiator of the request, the P-CSCF shall:
13
14
15
1) verify that the list of URIs received in the Service-Route header (during the last successful registration
or re-registration) matches the preloaded Route headers in the received request. This verification is done
on a per URI basis, not as a whole string. If the verification fails, then the P-CSCF shall either:
16
17
18
a) return a 400 (Bad Request) response that may include a Warning header containing the warn-code 399;
the P-CSCF shall not forward the request, and shall not continue with the execution of steps 2 onwards;
or
19
20
b) replace the preloaded Route header value in the request with the value of the Service-Route header
received during the last 200 (OK) response for a registration or reregistration;
21
22
2) add its own address to the Via header. The P-CSCF Via header entry is built in a format that contains the
port number of the P-CSCF in accordance with the procedures of [26], and either:
23
a) the P-CSCF FQDN that resolves to the IP address, or
24
b) the P-CSCF IP address;
25
26
27
3) add its own SIP URI to the top of the Record-Route header. The P-CSCF SIP URI is built in a format
that contains the port number of the P-CSCF where it awaits subsequent requests from the called party,
and either:
28
a) the P-CSCF FQDN that resolves to the IP address; or
29
30
31
4) remove the P-Preferred-Identity header, if present, and insert a P-Asserted-Identity header with a value
representing the initiator of the request;
32
33
5) create a new, globally unique value for the icid parameter and insert it into the P-Charging-Vector
header; and
34
35
6) if the request is an INVITE request, save the Contact, CSeq and Record-Route header field values
received in the request such that the P-CSCF is able to release the session if needed;
36before forwarding the request, based on the topmost Route header, in accordance with the procedures of [26].
37When the P-CSCF receives a 1xx or 2xx response to the above request, the P-CSCF shall:
38
39
2) store the list of Record-Route headers from the received response;
40
41
3) store the dialog ID and associate it with the private user identity and public user identity involved in the
session;
28
1
2
3
4) rewrite the port number of its own Record- Route entry to its own protected server port number
negotiated with the calling UE, and append the comp parameter in accordance with the procedures of
[55]; and
4
5
NOTE 2: The P-CSCF associates two ports, a protected client port and a protected server port, with each
pair of security associations. For details on the selection of the protected port values see [19].
6
7
5) if the response corresponds to an INVITE request, save the Contact and Record-Route header field
values received in the response such that the P-CSCF is able to release the session if needed;
8before forwarding the response to the UE in accordance with the procedures of [26].
9When the P-CSCF receives from the UE a target refresh request for a dialog, the P-CSCF shall:
10
1) verify if the request relates to a dialog in which the originator of the request is involved:
11
12
13
14
a) if the request does not relates to an existing dialog in which the originator is involved, then the P-CSCF
shall answer the request by sending a 403 (Forbidden) response back to the originator. The response
may include a Warning header containing the warn-code 399. The P-CSCF will not forward the request.
No other actions are required;
15
16
b) if the request relates to an existing dialog in which the originator is involved, then the P-CSCF shall
continue with the following steps;
17
18
19
20
2) verify that the list of Route headers in the request matchesis included, preserving the same order, in the
list of Record-Route headers that was received during the last target refresh request for the same dialog.
This verification is done on a per URI basis, not as a whole string. If the verification fails, then the PCSCF shall either:
21
22
23
or
24
25
b) replace the Route header value in the request with the one received during the last target refresh request
for the same dialog in the Record-Route header; and
26
27
3) add its own address to the Via header. The P-CSCF Via header entry is built in a format that contains the
port number of the P-CSCF where it awaits the responses to come, and either:
28
a) the P-CSCF FQDN that resolves to the IP address, or
29
30
31
32
4) add its own SIP URI to the top of the Record-Route header; The P-CSCF SIP URI is built in a format
that contains the port number of the P-CSCF where it awaits subsequent requests from the called party,
and either:
33
a) the P-CSCF FQDN that resolves to the IP address; or
34
b) the P-CSCF IP address; and
35
36
5) if the request is an INVITE request, save the Contact, Cseq, and Record-Route header field values
39
1) store the list of Record-Route headers from the received response;
29
1
2
3
2) rewrite the port number of its own Record- Route entry to its own protected server port number
negotiated with the calling UE, and append the comp parameter in accordance with the procedures of
[55]; and
4
5
pair of security associations. For details on the selection of the protected port value see [19].
6
7
9When the P-CSCF receives from the UE the request for a standalone transaction, and a Service-Route header
10list exists for the initiator of the request, the P-CSCF shall:
11
12
13
or re-registration) matches the preloaded Route headers in the received request. This verification is done
on a per URI basis, not as a whole string. If the verification fails, then the P-CSCF shall either:
14
15
16
or
17
18
b) replace the preloaded Route header value in the request with the one received during the last
registration in the Service-Route header of the 200 (OK) response;
19
20
representing the initiator of the request; and
21
22
3) create a new, globally unique value for the icid parameter and insert it into the P-Charging-Vector
header;
24When the P-CSCF receives any response to the above request, the P-CSCF shall:
25
27When the P-CSCF receives from the UE subsequent requests other than a target refresh request (including
28requests relating to an existing dialog where the method is unknown), the P-CSCF shall:
29
1) verify if the request relates to a dialog in which the originator of the request is involved:
30
31
32
33
a) if the request does not relates to an existing dialog in which the originator is involved, then the P-CSCF
shall answer the request by sending a 403 (Forbidden) response back to the originator. The response
may include a Warning header containing the warn-code 399. The P-CSCF will not forward the request.
No other actions are required;
34
35
b) if the request relates to an existing dialog in which the originator is involved, then the P-CSCF shall
continue with the following steps; and
36
37
38
39
40
41
2) verify that the list of Route headers in the request matches the list of Record-Route headers that was
received during the last target refresh request for the same dialog. This verification is done on a per URI
basis, not as a whole string. If the verification fails, then the P-CSCF shall either:
or
30
1
2
b) replace the Route header value in the request with the one received during the last target refresh request
for the same dialog in the Record-Route header;
3before forwarding the request to the UE, (based on the topmost Route header,) in accordance with the
4procedures of [26].
5When the P-CSCF receives from the UE the request for an unknown method (that does not relate to an existing
6dialog), and a Service-Route header list exists for the initiator of the request, the P-CSCF shall:
7
8
9
10
or re-registration) is included, preserving the same order, as a subset of the preloaded Route headers in
the received request. This verification is done on a per URI basis, not as a whole string. If the
verification fails, then the P-CSCF shall either:
11
12
13
or
14
15
b) replace the Route header value in the request with the one received during the last registration in the
Service-Route header of the 200 (OK) response; and
16
17
representing the initiator of the request;
195.2.6.4 Requests terminated by the UE

20When the P-CSCF receives, destined for the UE, an initial request for a dialog, prior to forwarding the request,
21the P-CSCF shall:
22
1) remove its own SIP URI from the topmost Route header;
23
24
2) convert the list of Record-Route header values into a list of Route header values and save this list of
Route headers;
25
26
3) if the request is an INVITE request, save a copy of the Contact, CSeq, and Record-Route header field
values received in the response request such that the P-CSCF is able t to release the session if needed;
27
28
29
30
4) add its own SIP URI on the top of the list of Record-Route headers and save the list. The P-CSCF SIP
URI is built in a format that contains the comp parameter in accordance with the procedures of [55],
and the protected server port number of the security association established from the UE to the P-CSCF
and either:
31
32
a) the P-CSCF FQDN that resolves to the IP address of the security association established from the UE to
the P-CSCF; or
33
b) the P-CSCF IP address of the security association established from the UE to the P-CSCF;
34
35
36
37
5) add its own address to the top of the received list of Via headers and save the list. The P-CSCF Via
header entry is built in a format that contains the comp parameter in accordance with the procedures of
[55], and the protected server port number of the security association established from the UE to the PCSCF and either:
38
39
the P-CSCF; or
40
31
1
2
pair of security associations. For details of the usage of the two ports see [19].
7) remove and store the icid parameter received in the P-Charging-Vector header; and
8) save a copy of the P-Called-Party-ID header;
6before forwarding the request to the UE in accordance with the procedures of [26].
8
9
10
11
12
1) remove the P-Preferred-Identity header, if present, and insert a P-Asserted-Identity header with the
value saved from the P-Called-Party-ID header that was received in the request;
2) verify that the list of Via headers matches the saved list of Via headers received in the request
corresponding to the same dialog, including the P-CSCF via header value. This verification is done on a
per Via header value basis, not as a whole string. If the verification fails, then the P-CSCF shall either:
13
a) discard the response; or
14
b) replace the Via header values with those received in the request;
15
16
17
18
3) verify that the list of URIs received in the Record-Route header of the request corresponding to the
same dialog is included, preserving the same order, as a subset of the Record-Route header list of this
response. This verification is done on a per URI basis, not as a whole string. If the verification fails,
then the P-CSCF shall either:
19
20
21
22
b) replace the Record- Route header values with those received in the request rewrite the port number of
its own Record-Route entry to the port number where it awaits subsequent requests from the calling
party and remove the comp parameter
23
24
25
If the verification is successful, the P-CSCF shall rewrite the port number of its own Record-Route
entry to the port number where it awaits subsequent requests from the calling party and remove the
comp parameter;
26
27
4) store the dialog ID and associate it with the private user identity and public user identity involved in the
session; and
28
29
value received in the response such that the P-CSCF is able to release the session if needed;.
30before forwarding the response in accordance with the procedures of [26].

31When the P-CSCF receives any other response to the above request, the P-CSCF shall:
32
33
34
35
per Via header value basis, not as a whole string. If these lists do not match, then the P-CSCF shall
either:
36
37

39When the P-CSCF receives, destined for the UE, a target refresh request for a dialog, prior to forwarding the
40request, the P-CSCF shall:
32
1) remove its own SIP URI from the topmost Route header value;
2
3
4
5
2) add its own address to the top of the received list of Via header and save the list. The P-CSCF Via
6
7
the P-CSCF; or
b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; and
9
10
11
12
15
16
17
per Via header value basis, not as a whole string. If the verification fails, then the P-CSCF shall either:
18
19
20
21
2) rewrite the port number of its own Record-Route entry to the port number where it awaits subsequent
requests from the calling party and remove the comp parameter; and
22
23

25When the P-CSCF receives, destined for the UE, a request for a stand-alone transaction, or a request for an
26unknown method (that does not relate to an existing dialog), prior to forwarding the request, the P-CSCF shall:
27
28
29
30
1) add its own address to the top of the received list of Via header and save the list. . The P-CSCF Via
31
32
the P-CSCF; or
33
34
35
36
2) store the values received in the P-Charging-Function-Addresses header; and
37
3) remove and store the icid parameter received in the P-Charging-Vector header;.
38before forwarding the request to the UE in accordance with the procedures of [26];.
33
1
2
3
4
either:
b) replace the Via header values with those received in the request; and
7
8
2) remove the P-Preferred-Identity header, if present, and insert a P-Asserted-Identity header with the
value saved from Request-URI of the request;

10When the P-CSCF receives, destined for the UE, a subsequent request for a dialog that is not a target refresh
11request (including requests relating to an existing dialog where the method is unknown), prior to forwarding
12the request, the P-CSCF shall:
13
14
15
16
1) add its own address to the top of the received list of Via header and save the list. The P-CSCF Via
17
18
the P-CSCF; or
19
b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; and
20
21
22
2) remove and store the icid parameter from P-Charging-Vector header;
25
26
27
28
either:
29
30
325.2.7
Initial INVITE
34In addition to following the procedures for initial requests defined in subclause 5.2.6, initial INVITE requests
35also follow the procedures of this subclause.
365.2.7.2 Mobile-originating case

37The P-CSCF shall respond to all INVITE requests with a 100 (Trying) provisional response.
38If the Go interface is supported, uUpon receiving a response (e.g. 183 (Session Progress), 200 (OK)) to the
39initial INVITE request, the P-CSCF shall:
34
1
2
3
if a media authorization token is generated by the PDF as specified in [31] (i.e. when service-based
local policy control is applied), insert the P-Media-Authorization header containing that media
authorization token.
4
5
6
7
8
9
NOTE:
Typically, the first 183 (Session Progress) response contains an SDP answer including one or
more "m=" media descriptions, but it is also possible that the response does not contain an SDP
answer or the SDP does not include at least an "m=" media description. However, the media
authorization token is generated independently of the presence or absence of "m=" media
descriptions and sent to the UE in the P-Media-Authorization header value. The same media
authorization token is used until the session is terminated.
10If the Go interface is supported, wWhen the P-CSCF sends the UPDATE request towards the S-CSCF, the P11CSCF shall also include the access-network-charging-info parameterIP Connectivity Network charging
12information in the P-Charging-Vector header. See subclause 5.2.7.4 for further information on the access13network-charging-info parameterIP Connectivity Network charging information.
145.2.7.3 Mobile-terminating case

15When the P-CSCF receives an initial INVITE request destined for the UE, it will contain the SIP URI of the
16UE in the Request-URI, and a single pre-loaded Route header. The received initial INVITE request will also
17have a list of Record-Route headers. If the Go interface is supported, pPrior to forwarding the initial INVITE
18request to the SIP URI found in the Request-URI, the P-CSCF shall:
19
20
21
if a media authorization token is generated by the PDF as specified in [31] (i.e. when service-based
local policy control is applied), insert the P-Media-Authorization header containing that media
authorization token.
22
23
24
25
26
27
NOTE:
Typically, the initial INVITE request contains an SDP offer including one or more "m=" media
descriptions, but it is also possible that the INVITE request does not contain an SDP offer or the
SDP does not include at least an "m=" media description. However, the media authorization
token is generated independently of the presence or absence of "m=" media descriptions and sent
to the UE in the P-Media-Authorization header value. The same media authorization token is
used until the session is terminated.
28In addition, the P-CSCF shall respond to all INVITE requests with a 100 (Trying) provisional response.
29If the Go interface is supported, wWhen the P-CSCF sends 180 (Ringing) or 200 (OK) (to INVITE) towards
30the S-CSCF, the P-CSCF shall also include the access-network-charging-info parameter IP Connectivity
31Network charging information in the P-Charging-Vector header. See subclause 5.2.7.4 for further information
32on the access-network-charging-info parameterIP Connectivity Network charging information.
335.2.7.4 IP Connectivity Network charging information

34The IP Transport Subsystem charging information shall be coded as the access-networkits-charging-info
35parameter within the P-Charging-Vector header as described in subclause 7.2.6.b
365.2.8
Call release
375.2.8.1 P-CSCF-initiated call release

385.2.8.1.1
Cancellation of a session currently being established
39Upon receipt of an indication that radio coverage is no longer available for a served user, for whom one ore
40more ongoing multimedia session are currently being established, the P-CSCF shall cancel the related dialogs
41by sending out a CANCEL request according to the procedures described in [26].
35
15.2.8.1.2
Release of an existing session
2Upon receipt of an indication that the radio interface resources are no longer available for a served user, for
3whom one or more ongoing session exists, the P-CSCF shall release each of the related dialogs by applying the
4following steps:
5
6
1) if the P-CSCF serves the calling user of a session it shall generate a BYE request based on the
information saved for the related dialog, including:
a Request-URI, set to the stored Contact header provided by the called user;
8
9
a To header, set to the To header value as received in the 200 (OK) response for the initial INVITE
request;
10
a From header, set to the From header value as received in the initial INVITE request;
11
a Call-ID header, set to the Call-Id header value as received in the initial INVITE request;
12
13
a CSeq header, set to the CSeq value that was stored for the direction from the calling to the called user,
incremented by one;
14
a Route header, set to the routeing information towards the called user as stored for the dialog;
15
further headers, based on local policy or the requested session release reason.
16
17
2) If the P-CSCF serves the called user of a session it shall generate a BYE request based on the
information saved for the related dialog, including:
18
a Request-URI, set to the stored Contact header provided by the calling user;
19
a To header, set to the From header value as received in the initial INVITE request;
20
21
a From header, set to the To header value as received in the 200 (OK) response for the initial INVITE
request;
22
23
24
25
a CSeq header, set to the CSeq value that was stored for the direction from the called to the calling user,
incremented by one if no CSeq value was stored for that session it shall generate and apply a random
number within the valid range for CSeqs;
26
a Route header, set to the routeing information towards the calling user as stored for the dialog;
27
28
3) send the so generated BYE request towards the indicated user.
29
30
4) upon receipt of the 2xx responses for the BYE request, shall delete all information related to the dialog
and the related multimedia session.
315.2.8.1.3
Abnormal cases
32Upon receipt of a request on a dialog for which the P-CSCF initiated session release, the P-CSCF shall
33terminate this received request and answer it with a 481 (Call/Transaction Does Not Exist) response.
36
15.2.8.1.4 Release of the existing dialogs due to registration expiration and deletion
2of the security association
3If there are still active dialogs associated with the user after the security associations were deleted, the P-CSCF
4shall discard all information pertaining to these dialogs without performing any further SIP transactions with
5the peer entities of the P-CSCF.
6
7
NOTE:
If the Go interface is supported,At the same time, the P-CSCF will also indicate via the Go
interface that all resources associated with these dialogs should be released.
85.2.8.2 Call release initiated by any other entity

9When the P-CSCF receives a 2xx response for a BYE request matching an existing dialog, it shall delete all the
10stored information related to the dialog.
115.2.9
Subsequent requests
125.2.9.1 Mobile-originating case

13The P-CSCF shall respond to all reINVITE requests with a 100 (Trying) provisional response.
14If the Go interface is supported, fFor a reINVITE request from the UE, when the P-CSCF sends the UPDATE
15request towards the S-CSCF, the P-CSCF shall include the updated access-network-charging-info parameterIP
16Connectivity Network -charging information in the P-Charging-Vector header. See subclause 7.2.6 for further
17information on the access-network-charging-info parameterIP Connectivity Network charging information.
185.2.9.2 Mobile-terminating case

19The P-CSCF shall respond to all reINVITE requests with a 100 (Trying) provisional response.
20If the Go interface is supported, fFor a reINVITE request destined towards the UE, when the P-CSCF sends
21200 (OK) response (to the INVITE request) towards the S-CSCF, the P-CSCF shall include the updated access22network-charging-info parameterIP Connectivity Network charging information in the P-Charging-Vector
23header. See subclause 7.2.6 for further information on the IP Connectivity Network charging information.
245.2.10 Emergency service

25The handling of emergency service in the 3GPP2 networks is FFS.
265.2.11 Void
275.3
Procedures at the I-CSCF
285.3.1
Registration procedure
295.3.1.1 General
30During the registration procedure the I-CSCF shall behave as a stateful proxy.
315.3.1.2 Normal procedures

32When I-CSCF receives a REGISTER request, the I-CSCF starts the user registration status query procedure to
33the HSS as specified in [14].
34If the user registration status query response from the HSS includes a valid SIP URI, the I-CSCF shall:
37
1
2
1) replace the Request-URI of the received REGISTER request with the SIP URI received from the HSS in
the Server-Name AVP;
2) apply the procedures as described in subclause 5.3.3 if topology hiding is required; and
3) forward the REGISTER request to the indicated S-CSCF.
5If the user registration status query response from the HSS includes a list of capabilities, the I-CSCF shall:
6
7
8
1) select a S-CSCF that fulfils the indicated mandatory capabilities if more then one S-CSCFs fulfils the
indicated mandatory capabilities the S-CSCF which fulfils most of the possibly additionally indicated
optional capabilities;
2) replace the Request-URI of the received REGISTER request with the URI of the S-CSCF;
10
11
4) forward the REGISTER request to the selected S-CSCF.
12When the I-CSCF receives a 2xx response to a REGISTER request, the I-CSCF shall proxy the 2xx response to
13the P-CSCF.
145.3.1.3 Abnormal cases

15If the HSSAAA sends a negative response to the user registration status query request, the I-CSCF shall send
16back a 403 (Forbidden) response to the UE. The response may include a Warning header containing the warn17code 399.
18If the user registration status query procedure cannot be completed, e.g. due to time-out or incorrect
19information from the HSS, the I-CSCF shall send back a 480 (Temporarily Unavailable) response to the UE.
20If a selected S-CSCF:
21
does not respond to the REGISTER request and its retransmissions by the I-CSCF; or
22
sends back a 3xx response or 480 (Temporarily Unavailable) response;
23the I-CSCF shall select a new S-CSCF as described in subclause 5.3.1.2, based on the capabilities indicated
24from the HSS. The newly selected S-CSCF shall not be one of any S-CSCFs selected previously during this
25same registration procedure.
26If the I-CSCF cannot select a S-CSCF which fulfils the mandatory capabilities indicated by the HSS, the I27CSCF shall send back a 600 (Busy Everywhere) response to the user.
285.3.2
Initial requests
295.3.2.1 Normal procedures

30The I-CSCF may behave as a stateful proxy for initial requests.
31When the I-CSCF receives an initial request for a dialog or standalone transaction, that does not contain a
32Route header, the I-CSCF shall start the user location query procedure to the HSS as specified in [14] for the
33called user, indicated in the Request-URI. Upon successful user location query, when the response contains the
34URI of the assigned S-CSCF, the I-CSCF shall:
35
1) insert the URI received from the HSS as the topmost Route header;
36
37
38
2) store the value of the icid parameter received in the P-Charging-Vector header and retain the icid
parameter in the P-Charging-Vector header. If no icid parameter was found, then create a new, globally
unique value for the icid parameter and insert it into the P-Charging-Vector header;
39
38
4) forward the request based on the topmost Route header.
2Upon successful user location query, when the response contains information about the required S-CSCF
3capabilities, the I-CSCF shall:
4
1) select a S-CSCF according to the method described in [14];
2) insert the URI of the selected S-CSCF as the topmost Route header field value;
6
7
3) execute the procedure described in step 2 and 3 in the above paragraph (upon successful user location
query, when the response contains the URI of the assigned S-CSCF); and
4) forward the request to the selected S-CSCF.
9Upon an unsuccessful user location query when the response from the HSS indicates that the user does not
10exist, the I-CSCF shall return an appropriate unsuccessful SIP response. This response may be a 404 (Not
11found) or 604 (Does not exist anywhere) in the case the user is not a user of the home network.
12Upon an unsuccessful user location query when the response from the HSS indicates that the user is not
13registered and no services are provided for such a user, the I-CSCF shall return an appropriate unsuccessful SIP
14response. This response may be a 480 (Temporarily unavailable) if the user is recognized as a valid user, but is
15not registered at the moment and it does not have services for unregistered users.
16When the I-CSCF receives an initial request for a dialog or standalone transaction, that contains a single Route
17header pointing to itself, the I-CSCF shall determine from the entry in the Route header whether it needs to do
18HSS query or hiding. In case HSS query is needed, then the I-CSCF shall perform the procedures described for
19the case when there is no Route header present. If the I-CSCF determines that hiding must be performed, then
20the THIG functionality in I-CSCF received an outgoing initial request for which topology hiding has to be
21applied, and the I-CSCF shall:
22
23
2) perform the procedures described in subclause 5.3.3; and
24
3) route the request based on the Request-URI header field.
25When the I-CSCF receives an initial request for a dialog or standalone transaction containing more than one
26Route header, the I-CSCF shall:
27
28
2) apply the procedures as described in subclause 5.3.3; and
29
30
31
32
33
NOTE:
In accordance with SIP the I-CSCF can add its own routeable SIP URI to the top of the RecordRoute header to any request, independently of whether it is an initial request, or whether
topology hiding is performed. The P-CSCF will ignore any Record-Route header that is not in
the initial request of a dialog.
34When the I-CSCF receives a response to an initial request (e.g. 183 or 2xx), the I-CSCF shall store the values
35from the P-Charging-Function-Addresses header, if present. If the next hop is outside of the current network,
36then the I-CSCF shall remove the P-Charging-Function-Addresses header prior to forwarding the message.
375.3.2.2 Abnormal cases

38If the HSS sends a negative response to the user location query, the I-CSCF shall send back a 404 (Not Found)
39response.
40If the I-CSCF receives a CANCEL request and if the I-CSCF finds an internal state indicating a pending
41Cx transaction with the HSS, the I-CSCF:
39
shall answer the CANCEL with a 200 (OK);
shall answer the original request with a 487 (Request Terminated); and
shall silently discard the later arriving (pending) Cx answer message from the AAA.
45.3.3
THIG functionality in the I-CSCF(THIG)
55.3.3.1 General
6The following procedures shall only be applied if topology hiding is required by the network. The network
7requiring topology hiding is called the hiding network.
8
9
NOTE 1: Requests and responses are handled independently therefore no state information is needed for
that purpose within an I-CSCF(THIG).
10The I-CSCF(THIG) shall apply topology hiding to all headers, which reveal topology information, such as Via,
11Route, Record-Route, Service-Route.
12Upon receiving an incoming REGISTER request for which topology hiding has to be applied and which
13includes a Path header, the I-CSCF(THIG) shall add the routeable SIP URI of an I-CSCF(THIG) to the top of
14the Path header. The I-CSCF(THIG) may include in the inserted SIP URI an indicator that identifies the
15direction of subsequent requests received by the I-CSCF, i.e., from the S-CSCF towards the P-CSCF, to
16identify the mobile-terminating case. The I-CSCF(THIG) may encode this indicator in different ways, such as,
17e.g., a unique parameter in the URI, a character string in the username part of the URI, or a dedicated port
18number in the URI.
19
20
21
NOTE 2: Any subsequent request that includes the direction indicator (in the Route header) or arrives at
the dedicated port number, indicates that the request was sent by the S-CSCF toward the PCSCF.
22Upon receiving an incoming initial request for which topology hiding has to be applied and which includes a
23Record-Route header, the I-CSCF(THIG) shall add its own routeable SIP URI to the top of the Record-Route
24header.
25Upon receiving an outgoing initial request for which topology hiding has to be applied and which includes P26Charging-Function-Addresses header, the I-CSCF(THIG) shall remove the P-Charging-Function-Addresses
27header prior to forwarding the message.
285.3.3.2 Encryption for topology hiding

29Upon receiving an outgoing request/response from the hiding network the I-CSCF(THIG) shall perform the
30encryption for topology hiding purposes, i.e. the I-CSCF(THIG) shall:
31
32
1) use the whole header values which were added by one or more specific entity of the hiding network as
input to encryption, besides the UE entry;
33
2) not change the order of the headers subject to encryption when performing encryption;
34
35
36
3) use for one encrypted string all received consecutive header entries subject to encryption, regardless if
they appear in separate consecutive headers or if they are consecutive entries in a comma separated list
in one header;
37
38
4) construct an NAI in the form of 'username@realm', where the username part is the encrypted string, and
the realm is the name of the encrypting network.
39
40
5) append a "tokenized-by=" tag and set it to the value of the encrypting network's name, after the
constructed NAI;
40
1
2
6) form one valid entry for the specific header out of the resulting NAI, e.g. prepend "SIP/2.0/UDP" for
Via headers or "sip:" for Route and Record-Route headers.
3
4
NOTE 1: Even if consecutive entries of the same network in a specific header are encrypted, they will
result in only one encrypted header entry. For example:
5
6
7
8
9
Via: SIP/2.0/UDP icscf1_s.home1.net;lr,

SIP/2.0/UDP Token( SIP/2.0/UDP scscf1.home1.net;lr,
SIP/2.0/UDP pcscf1.home1.net;lr)@home1.net;
tokenized-by=home1.net,
SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]
10
11
12
NOTE 2: If multiple entries of the same network are within the same type of headers, but they are not
consecutive, then these entries will be tokenized to different strings. For example:
13
14
15
16
17
18
Route:
sip:icscf1_s.home1.net;lr,
sip:Token(sip:scscf1.home1.net;lr)@home1.net;tokenized-by=home1.net,
sip:as1.foreign.net;lr,
sip:Token(sip:scscf1.home1.net;lr,
sip:pcscf1.home1.net;lr)@home1.net;tokenized-by=home1.net,
sip:[5555::aaa:bbb:ccc:ddd]
19
205.3.3.3 Decryption for Topology Hiding

21Upon receiving and incoming requests/response to the hiding network the I-CSCF(THIG) shall perform the
22decryption for topology hiding purposes, i.e. the I-CSCF shall:
23
24
1) identify NAIs encrypted by the network this I-CSCF belongs to within all headers of the incoming
message;
25
26
2) use the user part of those NAIs that carry the identification of the hiding network within the value of the
tokenized-by tag as input to decryption;
27
28
3) use as encrypted string the user part of the NAI which follows the sent-protocol (for Via Headers, e.g.
"SIP/2.0/UDP") or the URI scheme (for Route and Record-Route Headers, e.g. "sip:");
29
30
4) replace all content of the received header, which carries encrypted information with the entries resulting
from decryption.
31EXAMPLE:
32
33
An encrypted entry to a Via header that looks like:

Via:
34
will be replaced with the following entries:
35
36
37
38
39
40
SIP/2.0/UDP Token(SIP/2.0/UDP scscf1.home1.net;lr,

SIP/2.0/UDP pcscf1.home1.net;lr)@home1.net;tokenized-by=home1.net
Via: SIP/2.0/UDP scscf1.home1.net;lr, SIP/2.0/UDP pcscf1.home1.net;lr
NOTE:
Motivations for these decryption procedures are e.g. to allow the correct routeing of a response
through the hiding network, to enable loop avoidance within the hiding network, or to allow the
entities of the hiding network to change their entries within e.g. the Record-Route header.
415.3.4
Void
425.4
Procedures at the S-CSCF
435.4.1
Registration and authentication
45The S-CSCF shall act as the SIP registrar for all UAs of the IM CN subsystem with public user identities.
41
1The S-CSCF shall support the use of the Path and Service-Route header. The S-CSCF must also support the
2Require and Supported headers. The Path header is only applicable to the REGISTER request and its 200 (OK)
3response. The Service-Route header is only applicable to the 200 (OK) response of REGISTER.
4The network operator defines minimum and maximum times for each registration. These values are provided
5within the S-CSCF.
6The procedures for notification concerning automatically registered public user identities of a user are
7described in subclause 5.4.2.1.2.
8 5.4.1.2
Initial registration and user-initiated reregistration
95.4.1.2.1
Unprotected REGISTER
10
11
12
NOTE 1: Any REGISTER request sent unprotected by the UE is considered to be an initial registration. A
200 (OK) final response to such a request will only be sent back after the S-CSCF receives a
correct RES in a REGISTER request that is sent integrity protected.
13
14
15
NOTE 2: A REGISTER with Expires header value equal to zero should always be received protected.
However, it is possible that in error conditions a REGISTER with Expires header value equal to
zero may be received unprotected. In that instance the procedures below will be applied.
16Upon receipt of a REGISTER request with the integrity-protection parameter set to 'no', the S-CSCF shall:
17
18
1) identify the user by the public user identity as received in the To header and the private user identity as
received in the username field in the Authorization header of the REGISTER request;
19
20
2) check if the P-Visited-Network header is included in the REGISTER request, and if it is included,
identify the visited network by the value of this header;
21
22
23
24
3) check how many authentications are ongoing for this user. The S-CSCF may based on local policy
reject the request by sending a 403 (Forbidden) response, if there are a number of ongoing
authentications. The response may include a Warning header containing the warn-code 399. If the SCSCF decides to challenge the user, then proceed as follows;
25
26
27
4) select an authentication vector for the user. If no authentication vector for this user is available, after the
S-CSCF has performed the Cx Multimedia Authentication procedure with the HSS, as described in [15],
the S-CSCF shall select an authentication vector as described in [19].
28
29
30
Prior to performing Cx Multimedia Authentication procedure with the HSS, the S-CSCF decides which
HSS to query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as
specified in [14];
31
32
33
NOTE 3: At this point the S-CSCF informs the HSS, that the user currently registering will be served by
the S-CSCF by passing its SIP URI to the HSS. This will be indicated by the HSS for all further
incoming requests to this user, in order to direct all these requests directly to this S-CSCF.
34
5) store the icid parameter received in the P-Charging-Vector header;
35
36
6) challenge the user by generating a 401 (Unauthorized) response for the received REGISTER request,
including a WWW-Authenticate header which transports:
37
the home network identification in the realm field;
38
the RAND and AUTN parameters and optional server specific data for the UE in the nonce field;
39
the security mechanism, which is AKAv1-MD5, in the algorithm field;
40
the IK (Integrity Key) parameter for the P-CSCF in the ik field (see subclause 7.2A.1); and
42
the CK (Cipher Key) parameter for the P-CSCF in the ck field (see subclause 7.2A.1);
7) send the so generated 401 (Unauthorized) response towards the UE; and,
8) start timer reg-await-auth which guards the receipt of the next REGISTER request.
4If the received REGISTER request indicates that the challenge sent previously by the S-CSCF to the UE was
5deemed to be invalid by the UE, the S-CSCF shall stop the timer reg-await-auth and proceed as described in
6the subclause 5.4.1.2.3.
75.4.1.2.2
Protected REGISTER
8Upon receipt of a REGISTER request with the integrity-protection parameter in the Authorization header set to
9"'yes"', the S-CSCF shall identify the user by the public user identity as received in the To header and the
10private user identity as received in the Authorization header of the REGISTER request, and:
11In the case that there is no authentication currently ongoing for this user (i.e. no timer reg-await-auth is
12running):
13
1) check if the user needs to be re-authenticated.
14
15
16
17
The S-CSCF may require authentication of the user for any REGISTER request, and shall always require
authentication for registration requests received without integrity protection by the P-CSCF. The
information that a REGISTER request was received integrity protected at the P-CSCF may be used as
part of the decision to challenge the user.
18
19
20
If the user needs to be re-authenticated, the S-CSCF shall proceed with the procedures as described for the
initial REGISTER in subclause 5.4.1.2.1, beginning with step 4). If the user does not need to be reauthenticated, the S-CSCF shall proceed with the following steps in this paragraph; and
21
22
23
24
25
26
2) check whether an Expires timer is included in the REGISTER request and its value. If the Expires
header indicates a zero value, the S-CSCF shall perform the deregistration procedures as described in
subclause 5.4.1.4. If the Expires header does not indicate zero, the S-CSCF shall check whether the
public user identity received in the To header is already registered. If it is not registered, the S-CSCF
shall proceed beginning with step 5 below. Otherwise, the S-CSCF shall proceed beginning with step 6)
below.
27In the case that a timer reg-await-auth is running for this user the S-CSCF shall:
28
29
1) check if the Call-ID of the request matches with the Call-ID of the 401 (Unauthorized) response which
carried the last challenge. The S-CSCF shall only proceed further if the Call-IDs match.
30
2) stop timer reg-await-auth;
31
3) check whether an Authorization header is included, containing:
32
a) the private user identity of the user in the username field;
33
b) the algorithm which is AKAv1-MD5 in the algorithm field; and
34
c) the RES parameter needed for the authentication procedure in the response field.
35The S-CSCF shall only proceed with the following steps in this paragraph if the RES parameter was included;
36
37
38
4) check whether the received RES parameter and the XRES parameter match. The XRES parameter was
received from the HSS as part of the Authentication Vector. The S-CSCF shall only proceed with the
following steps if the RES and XRES are matching;
39
40
5) after performing the Cx Server Assignment procedure with the HSS, as described in [15], store the
following information in the local data:
43
1
2
3
a) the list of public user identities associated to the user, including the own public user identity under
registration and the implicitly registered due to the received REGISTER request. Each public user
identity is identified as either barred or non-barred; and,
4
5
b) all servicethe user profile(s) corresponding to the public user identities being registered (explicitly or
implicitly),of the user including initial Filter Criteria;
6
7
8
NOTE 1: There might be more than one set of initial Filter Criteria received because some implicitly
registered public user identities that are part of the same users subscription may belong to
different service profiles.
9
10
6) bind to each non-barred registered public user identity all registered contact information and store the
related method tag values from the Contact header for future use;
11
NOTE 2: There might be more then one contact information available for one public user identity.
12
NOTE 3: The barred public user identities are not bound to the contact information.
13
14
15
16
7) check whether a Path header was included in the REGISTER request and construct a list of preloaded
Route headers from the list of entries in the Path header. The S-CSCF shall preserve the order of the
preloaded Route headers and bind them to the contact information that was received in the REGISTER
message;
17
18
NOTE 4: If this registration is a reregistration, then a list of pre-loaded Route headers will already exist.
The new list replaces the old list.
19
20
21
8) determine the duration of the registration by checking the value of the Expires header in the received
REGISTER request. The S-CSCF may reduce the duration of the registration due to local policy or send
back a 423 (Interval Too Brief) response specifying the minimum allowed time for registration;
22
9) store the icid parameter received in the P-Charging-Vector header;
23
10)create a 200 (OK) response for the REGISTER request, including:
24
a) the list of received Path headers;
25
26
27
28
29
30
31
b) a P-Associated-URI header containing the list of public user identities that the user is authorized to use.
The first URI in the list of public user identities supplied by the HSS to the S-CSCF will indicate the
default public user identity to be used by the S-CSCF. The S-CSCF shall place the default public user
identity as a first entry in the list of URIs present in the P-Associated-URI header. The default public
user identity will be used by the P-CSCF in conjunction with the procedures for the P-Asserted-Identity
header, as described in subclause 5.2.6.3. The S-CSCF shall not add a barred public user identity to the
list of URIs in the P-Associated-URI header;
32
c) a Service-Route header containing:
33
34
35
36
the SIP URI identifying the S-CSCF containing an indication that requests routed via the service
route (i.e. from the P-CSCF to the S-CSCF) areshall be treated as for the mobile-originating
case. This indication may e.g. be in a URI parameter, a character string in the user part of the
URI or be a port number in the URI; and,
37
38
if network topology hiding is required a SIP URI identifying an I-CSCF(THIG) as the topmost
entry;
39
11) send the so created 200 (OK) response to the UE;
40
41
12)send a third-party REGISTER request, as described in subclause 5.4.1.7, to each AS that matches the
Filter Criteria from the HSS for the REGISTER event; and,
42
NOTE 5: If this registration is a reregistration, the Filter Criteria already exists in the local data.
44
13)handle the user as registered for the duration indicated in the Expires header.
25.4.1.2.3
Abnormal cases
3The S-CSCF need not challenge an unprotected REGISTER request for a private user identity that already has
4a registration in process, but instead return a 500 (Server Internal Error) response. The response shall contain a
5Retry-After header with a value indicating a time the UE shall wait before resending the request.
6In the case that the authentication response (RES) from the UE does not match with XRES and the request was
7correctly integrity protected (it is indicated by the P-CSCF), and the authentication response was triggered by
8an initial registration or a UE initiated reauthentication, the S-CSCF shall either:
9
start a network initiated re-authentication procedure as defined in subclause 5.4.1.6; or
10
11
12
send a further 403 (Forbidden)challenge 401 (Unauthorized) response to the UE. The S-CSCF shall
consider this authentication attempt as failed. The S-CSCF shall not update the registration time of the
subscriber.
13
NOTE 1: If the UE was registered before, it stays registered until the registration expiration time expires.
14In the case that the authentication response (RES) from the UE does not match with XRES and the request was
15correctly integrity protected (it is indicated by the P-CSCF), and the authentication response was triggered by a
16network initiated reauthentication the S-CSCF shall either:
17
attempt a further authentication challenge; or
18
19
deregister the user and terminate any ongoing sessions for all public user identities associated with the
private user identity being authenticated, and release resources allocated to those sessions.
20In the case that the REGISTER request, which was supposed to carry the response to the challenge, contains no
21RES and no AUTS parameters indicating that the MAC parameter was invalid in the challenge, the S-CSCF
22shall either:
23
24
respond with a 401 (Unauthorised) response containing a new challenge to initiate a further
authentication attempt, or
25
26
respond with a 403 (Forbidden) response to the UE. The S-CSCF shall not update the registration time
of the subscriber.
27
NOTE 2: If the UE was registered before, it stays registered until the registration expiration time expires.
28
if the authentication attempt is to be abandoned.
29In the case that the REGISTER request from the UE containing an authentication response indicates that the
30authentication challenge was invalid (contains the AUTS parameter indicating a synchronization failure), the
31S-CSCF will fetch new authentication vectors from the HSS, including AUTS and RAND in the request to
32indicate a resynchronization. On receipt of these vectors from the HSS, the S-CSCF shall either:
33
34
send a 401 (Unauthorized) response to initiate a further authentication attempt, using these new vectors,
or.
35
respond with a 403 (Forbidden) response if the authentication attempt is to be abandoned.
36
37
NOTE 3 Since the UE responds only to two consecutive challenges, the S-CSCF will send a 401
(Unauthorized) response that contains a new challenge only twice.
38In the case that the expiration timer from the UE is too short to be accepted by the S-CSCF, the S-CSCF shall:
39
40
reject the REGISTER request with a 423 (Interval Too Brief) response, containing a Min-Expires
header with the minimum registration time the S-CSCF will accept.
45
1On receiving a failure response to one of the third-party REGISTER requests, the S-CSCF may initiate
2network-initiated deregistration procedure based on the information in the Filter Criteria. If the Filter Criteria
3does not contain instruction to the S-CSCF regarding the failure of the contact to the AS, the S-CSCF shall not
4initiate network-initiated deregistration procedure.
5In the case that the REGISTER request from the UE contains more than one SIP URIs as Contact header
6entries, the S-CSCF shall only store the entry with the highest "q" value and include it in the 200 (OK)
7response.
8
9
10
11
NOTE 4: If the timer reg-await-auth expires, the S-CSCF will consider the authentication to have failed. If
the public user identity was already registered, the S-CSCF will leave it as registered as
described in [19]. The operator's policy will specify when will, upon authentication failure, the
currently registered public user identity or the user be de-registered by the S-CSCF.
125.4.1.3 Authentication and re-authentication

13Authentication and re-authentication is performed by the registration procedures as described in
14subclause 5.4.1.2.
155.4.1.4 User-initiated deregistration

16When S-CSCF receives a REGISTER request with the Expires header field containing the value zero, the S17CSCF shall:
18
19
20
check whether the P-CSCF included the Integrity-protection parameter into the Authorization header
field set to "yes", indicating that the REGISTER request was received integrity protected. The S-CSCF
shall only proceed with the following steps if the integrity protection parameter is set to "yes";
21
22
23
release each multimedia session, which was initiated with the public user identity found in the PAsserted-Identity header field, or with one of the implicitly registered public used identities by applying
the steps listed in subclause 5.4.5.1.2;
24
25
deregister the public user identity found in the To header field together with the implicitly registered
public user identities;
26
27
send a third-party REGISTER request, as described in subclause 5.4.1.7, to each AS that matches the
Filter Criteria from the HSS for the REGISTER event; and
28
29
30
31
if this is a deregistration request for the only public user identity currently registered with its associated
set of implicitly registered public user identities (i.e. no other is registered) and there are still active
multimedia sessions associated with this user, release each multimedia session belonging to the served
user by applying the steps listed in subclause 5.4.5.1.2.
32Based on operators' policy the S-CSCF can request of the HSS to either be kept or cleared as the S-CSCF
33allocated to this subscriber.
34If all public user identities of the UE are deregistered, then the S-CSCF may consider the UE and P-CSCF
35subscriptions to the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an
36Expires header containing a value of zero).
37If the Authorization header of the REGISTER request did not contain an Integrity-protection parameter, or the
38parameter was set to the value 'no', the S-CSCF shall respond to the request with a 403 (Forbidden) response.
39The response may contain a Warning header with a warn-code 399.

41Prior to initiating the network-initiated deregistration for the only public user identity currently registered with
42its associated set of implicitly registered public user identities (i.e. no other is registered) while there are still
43active multimedia sessions belonging to this user, the S-CSCF shall release all multimedia sessions belonging
44to this user as described in subclause 5.4.5.1.
46
1When a network-initiated deregistration event occurs for a public user identity, the S-CSCF shall send a
2NOTIFY request to the UE on the dialog which was generated by the UE subscribing to the reg event package.
3When the S-CSCF receives a final response to the NOTIFY request or upon a timeout, the S-CSCF shall
4release all remaining dialogs related to the public user identity being deregistered and shall generate a NOTIFY
5request on all remaining dialogs which have been established due to subscription to the reg event package of
6that user. For each NOTIFY request, the S-CSCF shall:
7
1) set the Request-URI and Route header to the saved route information during subscription;
2) set the Event header to the "reg" value;
9
10
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;
11
4) set the aor attribute within each <registration> element to one public user identity:
12
13
a) set the <contact> sub-element of each <registration> element to the contact address provided by the
UE;
14
b) if the public user identity:
15
i) has been deregistered then:
16
set the state attribute within the <registration> element to "terminated";
17
set the state attribute within the <contact> element to "terminated"; and
18
19
set the event attribute within the <contact> element to "deactivated" if the S-CSCF expects
the UE to reregister or "rejected" if the S-CSCF does not expect the UE to reregister; or
20
ii) has been kept registered then:
21
set the state attribute within the <registration> element to "active"; and
22
set the state attribute within the <contact> element to "active".
23When sending a final NOTIFY request with all <registration> element(s) having their state attribute set to
24"terminated" (i.e. all public user identities are deregistered), the S-CSCF shall also terminate the subscription to
25the reg event package by setting the Subscription-State header to the value of "terminated".
26The S-CSCF shall only include the non-barred public user identities in the NOTIFY request.
27Based on operators' policy the S-CSCF can request of the HSS to either be kept or cleared as the S-CSCF
28allocated to this subscriber.
29Also, the S-CSCF shall send a third-party REGISTER request, as described in subclause 5.4.1.7, to each AS
30that matches the Filter Criteria from the HSS for the REGISTER event.
315.4.1.6 Network-initiated re-authentication

32The S-CSCF may request a subscriber to re-authenticate at any time, based on a number of possible operator
33settable triggers as described in subclause 5.4.1.2.
34If the S-CSCF is informed that a private user identity needs to be re-authenticated, the S-CSCF shall generate a
35NOTIFY request on all dialogs which have been established due to subscription to the reg event package of
36that user. For each NOTIFY request the S-CSCF shall:
37
38
2) set the Event header to the "reg" value; and
47
1
2
identities the S-CSCF is aware of the user owns:
3
4
UE;
b) set the aor attribute within each <registration> element to one public user identity;
c) set the state attribute within each <registration> element to "active";
d) set the state attribute within each <contact> element to "active";
e) set the event attribute within each <contact> element to "shortened"; and
f) set the expiry attribute within each <contact> element to an operator defined value.
10Afterwards the S-CSCF shall wait for the user to re-authenticate (see subclause 5.4.1.2).
11
NOTE:
Network initiated re-authentication may occur due to internal processing within the S-CSCF.
13When generating the NOTIFY request, the S-CSCF shall shorten the validity of subscriber's registration timer
14to an operator defined value that will allow the user to be re-authenticated. If, for any reason, the re15authentication procedure is not successfully completed, the S-CSCF shall deregister all public user identities
16associated with the private user identity, as described in subclause 5.4.1.5, and terminate the ongoing sessions
17of that user.
185.4.1.7 Notification of Application Servers about registration status

19During registration, the S-CSCF shall include a P-Access-Network-Info header (as received in the REGISTER
20request from the UE) in the 3rd-party REGISTER towards AS(s), if the AS is part of the trust domain. If the AS
21is not part of the trust domain, the S-CSCF shall not include any P-Access-Network-Info header. The S-CSCF
22shall not include a P-Access-Network-Info header in any responses to the REGISTER request.
23If the registration procedure described in subclauses 5.4.1.2, 5.4.1.4 or 5.4.1.5 (as appropriate) was successful,
24the S-CSCF shall send a third-party REGISTER request to each AS with the following information:
25
a) the Request-URI, which shall contain the AS's SIP URI;
26
b) the From header, which shall contain the S-CSCF's SIP URI;
27
28
29
c) the To header, which shall contain either the public user identity as contained in the REGISTER request
received from the UE or one of the implicitly registered public user identities, as configured by the
operator;
30
d) the Contact header, which shall contain the S-CSCF's SIP URI;
31
32
33
e) for initial registration and user-initiated reregistration (subclause 5.4.1.2), the Expires header, which
shall contain the same value that the S-CSCF returned in the 200 (OK) response for the REGISTER
request received form the UE;
34
35
f) for user-initiated deregistration (subclause 5.4.1.4) and network-initiated deregistration

(subclause 5.4.1.5), the Expires header, which shall contain the value zero;
36
37
38
39
40
g) for initial registration and user-initiated reregistration (subclause 5.4.1.2), a message body, if there is
Filter Criteria indicating the need to include HSS provided data for the REGISTER event (e.g. HSS may
provide AS specific data to be included in the third-party REGISTER request). If there is a service
information XML element provided in the HSS Filter Criteria for an AS (see [14]), then the S-CSCF
shall include it in the message body of the REGISTER request within the <service-info> XML element
48
as described in subclause 7.6. For the messages including the IMS XML body, the S-CSCF shall set the
value of the Content-Type header to include the MIME type specified in subclause 7.6;
1
2
3
4
NOTE:
5
6
h) for initial registration, the P-Charging-Vector header, which shall contain the same icid parameter that
the S-CSCF received in the original REGISTER request from the UE;
7
8
i) for initial registration, a P-Charging-Function-Addresses header, which shall contain the values received
from the HSS if the message is forwarded within the S-CSCF home network.
95.4.2
Step g) is needed since, as specified in [14], the HSS may pass an IMS XML body to the SCSCF, and indicate that it should be conveyed to the designated AS.
105.4.2.1 Subscriptions to S-CSCF events

115.4.2.1.1
Subscription to the event providing registration state
12When an incoming SUBSCRIBE request addressed to S-CSCF arrives containing the Event header with the
13reg event package, the S-CSCF shall:
14
15
1) check if, based on the local policy, the request was generated by a subscriber who is authorised to
subscribe to the registration state of this particular user. The authorized subscribers include:
16
17
all public user identities this particular user owns, that the S-CSCF is aware of, and which are not
barred;
18
all the entities identified by the Path header (i.e. the P-CSCF to which this user is attached to); and
19
all the ASs not belonging to third-party providers;
20
21
NOTE: The S-CSCF finds the identity of the originator of the SUBSCRIBE request in the P-AssertedIdentity header.
22
23
24
2) generate a 2xx response acknowledging the SUBSCRIBE request and indicating that the authorised
subscription was successful as described in [43]. The S-CSCF shall populate the header fields as
follows:
25
26
an Expires header set to either the same or a decreased value as the Expires header in SUBSCRIBE
request; and
27
28
a Contact header set to is an identifier generated within the S-CSCF that will help to correlate refreshes
for the SUBSCRIBE.
29Afterwards the S-CSCF shall perform the procedures for notification about registration state as described in
315.4.2.1.2
Notification about registration state
32For each NOTIFY request on all dialogs which have been established due to subscription to the reg event
33package of that user, the S-CSCF shall:
34
35
2) set the Event header to the "reg" value;
49
1
2
identities the S-CSCF is aware of the user owns; and
4) set the aor attribute within each <registration> element to one public user identity:
4
5
UE; and
b) if the public user identity:
I) has been deregistered then:
set the state attribute within the <registration> element to "terminated";
set the state attribute within the <contact> element to "terminated"; and
10
11
set the event attribute within the <contact> element to "deactivated", "expired",
"unregistered" or " probation " according [43]; or
12
II) has been registered then:
13
set the state attribute within the <registration> element to "active";
14
set the state attribute within the <contact> element to "active"; and
15
set the event attribute within the <contact> element to "registered"; or
16
III) has been automatically registered:
17
set the state attribute within the <registration> element to "active";
18
set the state attribute within the <contact> element to "active"; and
19
set the event attribute within the <contact> element to "created".
20
The S-CSCF shall only include the non-barred public user identities in the NOTIFY request.
21EXAMPLE:
If sip:user1_public1@home1.net is registered, the public user identity
22
sip:user1_public2@home1.net can automatically be registered. Therefore the entries in the body of the
23
NOTIFY request look like:
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
version="0" state="full">
<registration aor="sip:user1_public1@home1.net" id="as9"
state="active">
<contact id="76" state="active" event="registered"
>sip:[5555::aaa:bbb:ccc:ddd]</contact>
</registration>
<registration aor="sip:user1_public2@home1.net" id="as10"
state="active">
<contact id="86" state="active" event="created"
>sip:[5555::aaa:bbb:ccc:ddd]</contact>
</registration>
</reginfo>
40
41When sending a final NOTIFY request with all <registration> element(s) having their state attribute set to
42"terminated" (i.e. all public user identities have been deregistered or expired), the S-CSCF shall also terminate
43the subscription to the registration event package by setting the Subscription-State header to the value of
44"terminated".
50
25.4.3 General treatment for all dialogs and standalone transactions excluding
3requests terminated by the S-CSCF
45.4.3.1 Determination of mobile-originated or mobile-terminated case
5Upon receipt of an initial request or a target refresh request or a stand-alone transaction, the S-CSCF shall:
6
7
8
9
perform the procedures for the mobile-originating case as described in subclause 5.4.3.2 if the request
makes use of the information for mobile-originating calls, which was added to the Service-Route header
entry of the S-CSCF during registration (see subclause 5.4.1.2), e.g. the message is received at a certain
port or the topmost Route header contains a specific user part or parameter; or,
10
11
perform the procedures for the mobile-terminating case as described in subclause 5.4.3.3 if this
information is not used by the request.
125.4.3.2 Requests initiated by the served user

13When the S-CSCF receives from the served user an initial request for a dialog or a request for a standalone
14transaction, prior to forwarding the request, the S-CSCF shall:
15
16
17
18
19
1) determine whether the request contains a barred public user identity in the P-Asserted-Identity header
field of the request or not. In case the said header field contains a barred public user identity for the
user, then the S-CSCF shall reject the request by generating a 403 (Forbidden) response. The response
may include a Warning header containing the warn-code 399. Otherwise, continue with the rest of the
steps;
20
21
22
NOTE 1: If the P-Asserted-Identity header field contains a barred public user identity, then the message
has been received, either directly or indirectly, from a non-compliant entity which should have
had generated the content with a non-barred public user identity.
23
24
25
26
3) check if an original dialog identifier that the S-CSCF previously placed in a Route header is present in
the topmost Route header of the incoming request. If present, it indicates an association with an existing
dialog, the request has been sent from an AS in response to a previously sent request;
27
28
29
30
31
32
4) check whether the initial request matches the initial filter criteria based on a public user identity in the
P-Asserted-Identity header, and if it does, forward this request to that AS, then check for matching of
the next following filter criteria of lower priority, and apply the filter criteria on the SIP method
received from the previously contacted AS as described in [5]. Depending on the result of the previous
process, the S-CSCF may contact one or more AS(s) before processing the outgoing Request-URI. In
case of contacting one or more AS(s) the S-CSCF shall:
33
34
a) insert the AS URI to be contacted into the Route header as the topmost entry followed by its own URI
populated as specified in the subclause 5.4.3.4; and
35
36
37
38
b) if the AS is located outside the trust domain then the S-CSCF shall remove the P-Access-Network-Info
header field and its values in the request; if the AS is located within the trust domain, then the S-CSCF
shall retain the P-Access-Network-Info header field and its values in the request that is forwarded to the
AS;
39
40
41
42
43
5) store the value of the icid parameter received in the P-Charging-Vector header and retain the icid
parameter in the P-Charging-Vector header. Optionally, the S-CSCF may generate a new, globally
unique icid and insert the new value in the icid parameter of the P-Charging-Vector header when
forwarding the message. If the S-CSCF creates a new icid, then it is responsible for maintaining the two
icid values in the subsequent messaging;
51
1
2
3
6) insert an orig-ioi parameter into the P-Charging-Vector header. The S-CSCF shall set the orig-ioi
parameter to a value that identifies the sending network. The S-CSCF shall not include the term-ioi
parameter;
4
5
7) insert a P-Charging-Function-Addresses header populated with values received from the HSS if the
message is forwarded within the S-CSCF home network, including towards AS;
6
7
8) in the case where the S-CSCF has knowledge of an associated tel -URL for a SIP URI contained in the
received P-Asserted-Identity header, add a second P-Asserted-Identity header containing this tel -URL;
8
9
10
11
12
13
9) if the outgoing Request-URI is a tel URL, the S-CSCF shall translate the E.164 address (see [22]) to a
globally routeable SIP URI using an ENUM/DNS translation mechanism with the format specified in
[24]. Databases aspects of ENUM are outside the scope of the present document. If this translation fails,
the request may be forwarded to a BGCF or any other appropriate entity (e.g. a MRFC to play an
announcement) in the originator's home network or the S-CSCF may send an appropriate SIP response
to the originator;
14
15
10)determine the destination address (e.g. DNS access) using the URI placed in the topmost Route header
if present, otherwise based on the Request-URI;
16
17
11) if network hiding is needed due to local policy, put the address of the I-CSCF(THIG) to the topmost
route header;
18
19
12)in case of an initial request for a dialog the S-CSCF shall create a Record-Route header containing its
own SIP URI;
20
21
13)remove the P-Access-Network-Info header prior to forwarding the message based on the destination
user (Request-URI);
22
14)route the request based on SIP routeing procedures;: and
23
24
15)if the request is an INVITE request, save the Contact, Cseq, and Record-Route header field values
received in the request such that the S-CSCF is able to release the session if needed.
25When the S-CSCF receives any response to the above request, the S-CSCF may:
26
1) apply any privacy required by [33] to the P-Asserted-Identity header.
27
NOTE 2: This header would normally only be expected in 1xx or 2xx responses.
28
29
NOTE 3: The optional procedure above is in addition to any procedure for the application of privacy at the
edge of the trust domain specified [33].
30When the S-CSCF receives a 1xx or 2xx response to the initial request for a dialog, if the response corresponds
31to an INVITE request, the S-CSCF shall save the Contact and Record-Route header field values in the response
32in order to be able to release the session if needed.
33When the S-CSCF receives from the served user a target refresh request for a dialog, prior to forwarding the
34request the S-CSCF shall:
35
1) remove its own URI from the topmost Route header;
36
2) create a Record-Route header containing its own SIP URI;
37
38
received in the request such that the S-CSCF is able to release the session if needed;
39
40
4) in case the request is routed towards the destination user (Request-URI) or to an AS located outside the
trust domain, remove the P-Access-Network-Info header; and
41
5) route the request based on the topmost Route header.
52
1When the S-CSCF receives a 1xx or 2xx response to the target refresh request for a dialog, if the response
2corresponds to an INVITE request, the S-CSCF shall save the Contact and Record-Route header field values in
3the response in order to release the session if needed.
4When the S-CSCF receives from the served user a subsequent request other than target refresh request for a
5dialog, prior to forwarding the request the S-CSCF shall:
6
7
8
2 in case the request is routed towards the destination user (Request-URI) or is routed to an AS located
outside the trust domain, remove the P-Access-Network-Info header; and
3) route the request based on the topmost Route header.
105.4.3.3 Requests terminated at the served user

11When the S-CSCF receives, destined for a registered served user, an initial request for a dialog or a request for
12a standalone transaction, prior to forwarding the request, the S-CSCF shall:
13
14
15
16
1) determine whether the request contains a barred public user identity in the Request-URI of the request
or not. In case the Request URI contains a barred public user identity for the user, then the S-CSCF
shall reject the request by generating a 404 (Not Found) response. Otherwise, continue with the rest of
the steps;
17
18
3) save the Request-URI from the request;
19
20
34)check if an original dialog identifier that the S-CSCF previously placed in a Route header is present in
the topmost Route header of the incoming request.
21
22
If present, it indicates an association with an existing dialog, the request has been sent from an AS in
response to a previously sent request,.;
23
24
If not present, it indicates that the request is visiting the S-CSCF for the first time, and in this case the
S-CSCF shall save the Request-URI from the request;
25
26
27
28
45)check whether the initial request matches the next unexecuted initial filter criteria in the priority order
and apply the filter criteria on the SIP method as described in [5] subclause 6.5. If there is a match, then
insert the AS URI to be contacted into the Route header as the topmost entry followed by its own URI
populated as specified in the subclause 5.4.3.4;
29
30
NOTE 1: Depending on the result of the previous process, the S-CSCF may contact one or more AS(s)
before processing the outgoing Request-URI.
31
32
33
56)insert a P-Charging-Function-Addresses header field (see subclause 7.2.4), if not present, populated
with values received from the HSS if the message is forwarded within the S-CSCF home network,
including towards AS;
34
35
67)store the value of the icid parameter received in the P-Charging-Vector header and retain the icid
parameter in the P-Charging-Vector header;
36
37
38
78)store the value of the orig-ioi parameter received in the P-Charging-Vector header, if present. The origioi parameter identifies the sending network of the request message. The orig-ioi parameter shall only
be retained in the P-Charging-Vector header if the next hop is to an AS;
39
40
89)check whether the Request-URI equals to the saved value of the Request-URI. If there is no match,
then:
53
1
2
a) if the request is an INVITE request, save the Contact, CSeq, and Record-Route header field values
received in the request such that the S-CSCF is able to release the session if needed; and
b) forward the request based on the Request-URI and skip the following steps;
If there is a match, then continue with the further steps;
5
6
7
109)
in case there are no Route headers in the request, then determine, from the destination public
user identity, the list of preloaded routes saved during registration or re-registration, as described in
subclause 5.4.1.2. Furthermore, the S-CSCF shall:
a) build the Route header field with the values determined in the previous step;
9
10
b) determine, from the destination public user identity, the saved Contact URI where the user is reachable
saved at registration or reregistration, as described in subclause 5.4.1.2;
11
c) build a Request-URI with the contents of the saved Contact URI determined in the previous step; and
12
d) insert a P-Called-Party-ID SIP header field including the Request-URI received in the INVITE;
13
14
101)
if the request is an INVITE request, save the Contact, CSeq, and Record-Route header field
values received in the request such that the S-CSCF is able to release the session if needed; and
15
112)
16
17
NOTE 2: The optional procedure above is in addition to any procedure for the application of privacy at the
edge of the trust domain specified by [33].
18
123)
optionally, apply any privacy required by [33] to the P-Asserted-Identity header; and
forward the request based on the topmost Route header.
19When the S-CSCF receives, destined for an unregistered user, an initial request for a dialog or a request for a
20standalone transaction, the S-CSCF shall:
21
22
23
1) execute the procedures described in the steps 1, 2, 3 and 34 in the above paragraph (when the S-CSCF
receives, destined for the registered served user, an initial request for a dialog or a request for a
standalone transaction);
24
25
26
27
2) if the S-CSCF does not have the user profile, then initiate the S-CSCF Registration/deregistration
notification with the purpose of downloading the relevant user profile (i.e. for unregistered user) and
informing the HSS that the user is unregistered, but this S-CSCF will assess triggering of services for
the unregistered user, as described in [14];
28
29
30
3) execute the procedure described in step 4, 5, 6, 7, 8, 9, 11, and12, and 13 in the above paragraph (when
the S-CSCF receives, destined for the registered served user, an initial request for a dialog or a request
for a standalone transaction).
31
32
In case that no AS needs to be contacted, then S-CSCF shall return an appropriate unsuccessful SIP
response. This response may be a 480 (Temporarily unavailable) and terminate these procedures.
33When the S-CSCF receives a 1xx or 2xx response to the initial request for a dialog (whether the user is
34registered or not), it shall:
35
36
1) if the response corresponds to an INVITE request, save the Contact and Record-Route headers field
values in the response such that the S-CSCF is able to release the session if needed;
37
38
39
2) in the case where the S-CSCF has knowledge of an associated tel -URL for a SIP URI contained in the
received P-Asserted-Identity header, the S-CSCF shall add a second P-Asserted-Identity header
containing this tel -URL; and
54
1
2
3
3) in case the response is forwarded to an AS that is located within the trust domain, the S-CSCF shall
retain the P-Access-Network-Info header; otherwise, the S-CSCF shall remove the P-Access-NetworkInfo header.
4When the S-CSCF receives a response to a request for a standalone transaction (whether the user is registered
5or not), in the case where the S-CSCF has knowledge of an associated tel -URL for a SIP URI contained in the
6received P-Asserted-Identity header, the S-CSCF shall add a second P-Asserted-Identity header containing this
7tel -URI. In case the response is forwarded to an AS that is located within the trust domain, the S-CSCF shall
8retain the P-Access-Network-Info header; otherwise, the S-CSCF shall remove the P-Access-Network-Info
9header.
10When the S-CSCF receives the 200 (OK) response for a standalone transaction request, the S-CSCF shall insert
11a P-Charging-Function-Addresses header populated with values received from the HSS if the message is
12forwarded within the S-CSCF home network, including towards an AS.
13When the S-CSCF receives, destined for a served user, a target refresh request for a dialog, prior to forwarding
14the request, the S-CSCF shall:
15
16
17
received in the request such that the S-CSCF is able to release the session if needed;
18
3) create a Record-Route header containing its own SIP URI; and
19
20When the S-CSCF receives a 1xx or 2xx response to the target refresh request for a dialog (whether the user is
21registered or not), the S-CSCF shall:
22
23
1) if the response corresponds to an INVITE request, save the Record-Route and Contact header field
values in the response such that the S-CSCF is able to release the session if needed; and
24
25
26
2) in case the response is forwarded to an AS that is located within the trust domain, the S-CSCF shall
retain the P-Access-Network-Info header; otherwise, the S-CSCF shall remove the P-Access-NetworkInfo header.
27When the S-CSCF receives, destined for the served user, a subsequent request other than target refresh request
28for a dialog, prior to forwarding the request, the S-CSCF shall:
29
1) remove its own URI from the topmost Route header; and
30
31When the S-CSCF receives a response to a subsequent request other than target refresh request for a dialog, in
32case the response is forwarded to an AS that is located within the trust domain, the S-CSCF shall retain the P33Access-Network-Info header; otherwise, the S-CSCF shall remove the P-Access-Network-Info header.
345.4.3.4 Original dialog identifier

35The original dialog identifier is an implementation specific token that the S-CSCF encodes into the own S36CSCF URI in a Route header, prior to forwarding the request to an AS. This is possible because the S-CSCF is
37the only entity that creates and consumes the value.
38The token identifies the original dialog of the request, so in case an AS acting as a B2BUA changes the dialog,
39the S-CSCF is able to identify the original dialog when the request returns to the S-CSCF. The token can be
40encoded in different ways, such as e.g., a character string in the user-part of the S-CSCF URI, a parameter in
41the S-CSCF URI or port number in the S-CSCF URI.
55
1The S-CSCF shall ensure that the value chosen is unique so that the S-CSCF may recognize the value when
2received in a subsequent message and make the proper association between related dialogs that pass through an
3AS.
45.4.3.5 Void
55.4.4
Call initiation

7Void.
85.4.4.2 Subsequent requests

95.4.4.2.1
10When the S-CSCF receives the 1xx response, the S-CSCF shall store the value of the received term-ioi
11parameter received in the P-Charging-Vector header, if present. The term-ioi parameter identifies the sending
12network of the response message. The term-ioi parameter shall only be retained in the P-Charging-Vector
13header if the next hop is to an AS.
14When the S-CSCF receives the 1xx or 2xx response, the S-CSCF shall insert a P-Charging-Function-Addresses
15header populated with values received from the HSS if the message is forwarded within the S-CSCF home
16network, including towards AS.
17When the S-CSCF receives the UPDATE request, the S-CSCF shall store the access-network-charging-info
18parameterIP Connectivity Network charging information from the P-Charging-Vector header. The S-CSCF
19shall retain the access-network-charging-info parameterIP Connectivity Network charging information in the
20P-Charging-Vector header when the request is forwarded to an AS. However, the S-CSCF shall not include
21access-network-charging-info parameterIP Connectivity Network charging information in the P-Charging22Vector header when the UPDATE request is forwarded outside the home network of the S-CSCF.
23When the S-CSCF receives any request or response (excluding ACK requests and CANCEL requests and
24responses) related to a mobile-originated dialog or standalone transaction, the S-CSCF may insert previously
25saved values into P-Charging-Vector and P-Charging-Function-Addresses headers before forwarding the
26message within the S-CSCF home network, including towards AS.
275.4.4.2.2
28When the S-CSCF sends anythe 1xx response, the S-CSCF shall insert a term-ioi parameter in the P-Charging29Vector header of the outgoing response. The S-CSCF shall set the term-ioi parameter to a value that identifies
30the sending network of the response and the orig-ioi parameter is set to the previously received value of orig31ioi.
32When the S-CSCF receives anythe 1xx or 2xx response, the S-CSCF shall insert a P-Charging-Function33Addresses header populated with values received from the HSS if the message is forwarded within the S-CSCF
34home network, including towards AS.
35When the S-CSCF receives 180 (Ringing) or 200 (OK) (to INVITE) responses, the S-CSCF shall store the
36access-network-charging-info parameterIP Connectivity Network charging information from the P-Charging37Vector header. The S-CSCF shall retain the access-network-charging-info parameterIP Connectivity Network
38charging information in the P-Charging-Vector header when the response is forwarded to an AS. However, the
39S-CSCF shall not include the access-network-charging-info parameterIP Connectivity Network charging
40information in the P-Charging-Vector header when the response is forwarded outside the home network of the
41S-CSCF.
56
1When the S-CSCF receives any request or response (excluding ACK requests and CANCEL requests and
2responses) related to a mobile-originated dialog or standalone transaction, the S-CSCF may insert previously
3saved values into P-Charging-Vector and P-Charging-Function-Addresses headers before forwarding the
4message within the S-CSCF home network, including towards AS.
55.4.5
Call release
65.4.5.1 S-CSCF-initiated session release

75.4.5.1.1
Cancellation of a session currently being established
8Upon receipt of a network internal indication to release a session which is currently being established, the S9CSCF shall cancel the related dialogs by sending the CANCEL request according to the procedures described
10in [26].
115.4.5.1.2
Release of an existing session
12Upon receipt of a network internal indication to release an existing multimedia session, the S-CSCF shall:
13
14
1) generate a first BYE request for the called user based on the information saved for the related dialog,
including:
15
a Request-URI, set to the stored Contact header provided by the called user;
16
17
a To header, set to the To header value as received in the 200 (OK) response for the initial INVITE
request;
18
a From header, set to the From header value as received in the initial INVITE request;
19
20
21
a CSeq header, set to the CSeq value that was stored for the direction from the calling to the called user,
incremented by one;
22
a Route header, set to the routeing information towards the called user as stored for the dialog;
23
24
25
2) generate a second BYE request for the calling user based on the information saved for the related
dialog, including:
26
a Request-URI, set to the stored Contact header provided by the calling user;
27
a To header, set to the From header value as received in the initial INVITE request;
28
29
a From header, set to the To header value as received in the 200 (OK) response for the initial INVITE
request;
30
31
32
33
a CSeq header, set to the CSeq value that was stored for the direction from the called to the calling user,
incremented by one if no CSeq value was stored for that session it shall generate and apply a random
number within the valid range for CSeqs;
34
a Route header, set to the routeing information towards the calling user as stored for the dialog;
35
57
1
2
3) if the S-CSCF serves the calling user, treat the first BYE request as if received directly from the calling
user, i.e. send it to internal service control and based on the outcome further on towards the called user;
4) if the S-CSCF serves the calling user, send the second BYE request directly to the calling user.
5) if the S-CSCF serves the called user, send the first BYE request directly to the called user;
5
6
7
6) if the S-CSCF serves the called user, treat the second BYE request as if received directly from the called
user, i.e. shall send it to internal service control and based on the outcome further on towards to the
calling user.
8Upon receipt of the 2xx responses for both BYE requests, the S-CSCF shall release all information related to
9the dialog and the related multimedia session.
105.4.5.1.2A Release of the existing dialogs due to registration expiration

11When the registration lifetime of the only public user identity currently registered with its associated set of
12implicitly registered public user identities (i.e. no other is registered) expires while there are still active
13multimedia sessions belonging to the served user, the S-CSCF shall release each multimedia session belonging
14to the served user by applying the steps listed in the subclause 5.4.5.1.2.
155.4.5.1.3
Abnormal cases
16Upon receipt of a request on a dialog for which the S-CSCF initiated session release, the S-CSCF shall
17terminate the received request and answer it with a 481 (Call/Transaction Does Not Exist) response.
185.4.5.2 Session release initiated by any other entity

19Upon receipt of a 2xx response for a BYE request matching an existing dialog, the S-CSCF shall delete all the
20stored information related to the dialog.
215.4.6
Call-related requests
225.4.6.1 ReINVITE
235.4.6.1.1
Determination of served user
24Void.
255.4.6.1.2
26For a reINVITE request from the UE, when the S-CSCF receives the UPDATE request, the S-CSCF shall store
27the updated access-network-charging-info parameterIP Connectivity Network charging information from P28Charging-Vector header. The S-CSCF shall retain the access-network-charging-info parameterIP Connectivity
29Network charging information in the P-Charging-Vector header when the request is forwarded to an AS.
30However, the S-CSCF shall not include the access-network-charging-info parameterIP Connectivity Network
31charging information in the P-Charging-Vector header when the UPDATE request is forwarded outside the
32home network of the S-CSCF.
33For a reINVITE request from the UE, if the request is to be forwarded to an AS that is located within the trust
34domain, the S-CSCF shall retain the P-Access-Network-Info header; otherwise, the S-CSCF shall remove the
35P-Access-Network-Info header.
58
15.4.6.1.3
2For a reINVITE request destined towards the UE, when the S-CSCF receives the 200 (OK) response (to the
3INVITE), the S-CSCF shall store the updated access-network-charging-info parameterIP Connectivity Network
4charging information from the P-Charging-Vector header. The S-CSCF shall retain the access-network5charging-info parameterIP Connectivity Network charging information in the P-Charging-Vector header when
6the response is forwarded to the AS. However, the S-CSCF shall include the access-network-charging-info
7parameterIP Connectivity Network charging information in the P-Charging-Vector header when the 200 (OK)
8response is forwarded outside the home network of the S-CSCF.
9For any SIP response to an INVITE request, if the response is to be forwarded to an AS that is located within
10the trust domain, the S-CSCF shall retain the P-Access-Network-Info header; otherwise, the S-CSCF shall
11remove the P-Access-Network-Info header.
125.4.7
MESSAGE support
13A S-CSCF may be capable of sending and/or receiving the MESSAGE method to conduct dialog-unrelated
14interactions. To do so, a S-CSCF may initiate or terminate the MESSAGE method.
155.5
Procedures at the MGCF
165.5.1
General
17The MGCF, although acting as a UA, does not initiate any registration of its associated addresses. These are
18assumed to be known by peer-to-peer arrangements within the IM CN subsystem. Therefore table A.4/1 and
19dependencies on that major capability shall not apply.
20The use of the Path and Service-Route headers shall not be supported by the MGCF.
21When the MGCF sends any request or response related to a dialog or standalone transaction, the MGCF may
22insert previously saved values into P-Charging-Vector and P-Charging-Function-Addresses headers before
23sending the message.
245.5.2
25Void.
265.5.3
Call initiation

285.5.3.1.1
Calls originated from circuit-switched networks
29When the MGCF receives an indication of an incoming call from a circuit-switched network, the MGCF shall:
30
generate and send an INVITE request to I-CSCF:
31
set the Request-URI to the "tel" format using an E.164 address;
32
set the Supported header to "100rel" (see [30]);
33
include a P-Asserted-Identity header;
34
35
create a new, globally unique value for the icid parameter and insert it into the P-Charging-Vector
header; and
59
1
2
3
insert an orig-ioi parameter into the P-Charging-Vector header. The orig-ioi parameter shall be set to a
value that identifies the sending network in which the MGCF resides and the term-ioi parameter shall
not be included.
45.5.3.1.2
Calls terminating in circuit-switched networks
5When the MGCF receives an initial INVITE request with Supported header indicating "100rel", the MGCF
6shall:
7
send 100 (Trying) response;
after a matching codec is found at the MGW, send 183 ("Session Progress)" response:
set the Require header to the value of "100rel";
10
store the values received in the P-Charging-Function-Addresses header;
11
store the value of the icid parameter received in the P-Charging-Vector header; and
12
13
insert a term-ioi parameter into the P-Charging-Vector header. The term-ioi parameter shall be set to a
value that identifies the network in which the MGCF resides.
14When the MGCF does not find an available matching codec at the MGW for the received initial INVITE
15request, the MGCF shall:
16
send 503 (Service Unavailable) response if the type of codec was acceptable but none were available; or
17
18
send 488 (Not Acceptable Here) response if the type of codec was not supported, and may include SDP
in the message body to indicate the codecs supported by the MGCF/MGW.

205.5.3.2.1
Calls originating in circuit-switched networks
21When the MGCF receives 183 (Session Progress) response to an INVITE request, the MGCF shall:
22
store the values received in the P-Charging-Function-Addresses header.
23When the MGCF receives 200 (OK) response to a PRACK request and notification that bearer setup is
24complete, the MGCF shall:
25
send an UPDATE request.
265.5.3.2.2
27When the MGCF receives an indication of a ringing for the called party of outgoing call to a circuit-switched
28network, the MGCF shall:
29
send 180 (Ringing) to the UE.
30When the MGCF receives an indication of answer for the called party of outgoing call to a circuit-switched
31network, the MGCF shall:
32
send 200 (OK) to the UE, including an P-Asserted-Identity header.
60
15.5.4
Call release
25.5.4.1 Call release initiated by a circuit-switched network

3When the MGCF receives an indication of call release from a circuit-switched network, the MGCF shall:
4
send a BYE request to the UE.
55.5.4.2 IM CN subsystem -initiated call release

6
7
NOTE:
The release of a call towards the circuit-switched network additionally requires signaling
procedures other than SIP in the MGCF that are outside the scope of this document.
85.5.4.3 MGW-initiated call release

9When the MGCF receives an indication from the MGW that the bearer was lost, the MGCF shall:
10
send a BYE request towards the UE; and
11
may include Error-Info header with a pointer to additional information indicating that bearer was lost.
125.5.5
135.5.5.1 ReINVITE
145.5.5.1.1
Calls originating from circuit-switched networks
15Void.
165.5.5.1.2
17When the MGCF receives a reINVITE request for hold/resume operation, the MGCF shall:
18
send 100 (Trying) response;
19
after performing interaction with MGW to hold/resume the media flow, send 200 (OK) response.
205.5.6
Further initial requests
21When the MGCF responds to an OPTIONS request with a 200 (OK) response, the MGCF may include a
22message body with an indication of the DTMF capabilities and supported codecs of the MGCF/MGW.
23
24
NOTE:
The detailed interface for requesting MGCF/MGW capabilities is not specified in this version of
the document. Other solutions may be used in the interim.
255.6
Procedures at the BGCF
265.6.1
General
27The use of the Path and Service-Route headers shall not be supported by the BGCF.
28When the BGCF receives any request or response (excluding ACK requests and CANCEL requests and
29responses) related to a dialog or standalone transaction, the BGCF may insert previously saved values into P30Charging-Vector and P-Charging-Function-Addresses headers before forwarding the message.
61
15.6.2
Session initiation transaction
2When the BGCF receives an INVITE request, the BGCF shall forward the request either to an MGCF within
3its own network, or to another network containing an MGCF. The BGCF need not Record-Route the INVITE
4request. While the next entity may be a MGCF acting as a UA, the BGCF shall not apply the procedures of
5[33] relating to privacy. The BGCF shall store the values received in the P-Charging-Function-Addresses
6header. The BGCF shall store the value of the icid parameter received in the P-Charging-Vector header and
7retain the icid parameter in the P-Charging-Vector header.
8
9
10
NOTE:
The means by which the decision is made to forward to an MGCF or to another network is
outside the scope of the present document, but may be by means of a lookup to an external
database, or may be by data held internally to the BGCF.
115.7
Procedures at the Application Server (AS)
125.7.1
Common Application Server (AS) procedures
135.7.1.1 Notification about registration status

14The AS may support the REGISTER method in order to discover the registration status of the user. If a
15REGISTER request arrives containing information about the user's registration status and the AS supports the
16REGISTER method, the AS shall store the Expires parameter from the request and generate a 200 (OK)
17response or an appropriate failure response. For the success case, the 200 (OK) response shall contain Expires
18value equal to the value received in the REGISTER request. The AS shall store the values received in P19Charging-Function-Addresses header.Also, the AS shall store the values of the icid parameter in the P20Charging-Vector header from the REGISTER request.
21Upon receipt of a third-party REGISTER request, the AS may subscribe to the reg event package for the public
22user identity registered at the users registrar (S-CSCF) as described in [43].
23On sending a SUBSCRIBE request, the AS shall populate the header fields as follows:
24
25
26
a) a Request URI set to the resource to which the AS wants to be subscribed to, i.e. to a SIP URI that
contains the public user identity of the user that was received in the To header field of the third-party
REGISTER request;
27
b) a From header field set to the ASs SIP URI;
28
29
c) a To header field, set to a SIP URI that contains the public user identity of the user that was received in
the To header field of the third-party REGISTER request; and
30
d) an Event header set to the "reg" event package.
31The AS may set the P-Asserted-Identity header field containing the SIP URI of the AS, which identifies this AS
32in the initial filter criteria of the user to whose registration state the AS subscribes to.
33Upon receipt of a 2xx response to the SUBSCRIBE request, the AS shall store the information for the so
35
36
37
38
39
NOTE 1: Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute
set to "terminated" (i.e. all public user identities are deregistered) and the Subscription-State
header set to "terminated", the AS considers the subscription to the reg event package
terminated, i.e. as if the AS had sent a SUBSCRIBE request with an Expires header containing a
value of zero.
405.7.1.2 Extracting charging correlation information

41When an AS receives an initial request for a dialog or a request (excluding ACK requests and CANCEL
42requests and responses) for a standalone transaction, the AS shall store the values received in the P-Charging-
62
1Vector header, e.g. icid parameter, and retain the P-Charging-Vector header in the message. The AS shall store
2the values received in the P-Charging-Function-Addresses header and retain the P-Charging-Function3Addresses header in the message.
4When an AS sends any request or response related to a dialog or standalone transaction, the AS may insert
5previously saved values into the P-Charging-Vector and P-Charging-Function-Addresses headers before
6sending the message.
75.7.1.3 Access-Network-Info
8The AS may receive in any request or response (excluding ACK requests and CANCEL requests and
9responses) information about the served user access network. This information is contained in the P-Access10Network-Info header. The AS can use the header to provide an appropriate service to the user.
115.7.2
Application Server (AS) acting as terminating UA, or redirect server
12When acting as a terminating UA the AS shall behave as defined for a UE in subclause 5.1.4, with the
13exceptions identified in this subclause.
14The AS, although acting as a UA, does not initiate any registration of its associated addresses. These are
15assumed to be known by peer-to-peer arrangements within the IM CN subsystem.
16An AS acting as redirect server shall propagate any received IMS XML message body in the redirected
17message.
185.7.3
Application Server (AS) acting as originating UA
19When acting as an originating UA the AS shall behave as defined for a UE in subclause 5.1.3, with the
20exceptions identified in this subclause.
23When an AS acting as an originating UA generates an initial request for a dialog or a request for a standalone
24transaction, the AS shall create a new, globally unique value for the icid parameter and insert it into the P25Charging-Vector header. The AS may retrieve AAA and/or ECF addresses from HSS on Sh interface.
26The AS shall extract charging function addresses from any P-Charging-Function-Addresses header that is
27received in any 1xx or 2xx responses to the requests.
28Furthermore the AS shall insert a Route header pointing to the S-CSCF of the UE on whose behalf the request
29is generated.
30
31
NOTE:
325.7.4
The address of the S-CSCF may be obtained either from a previous request terminated by the
AS, by querying the HSS on the Sh interface or from static configuration.
Application Server (AS) acting as a SIP proxy
33When the AS acting as a SIP proxy receives a request from the S-CSCF, prior to forwarding the request it shall:
34
remove its own URI from the topmost Route header; and
35
after executing the required services, route the request based on the topmost Route header.
36The AS may modify the SIP requests based on service logic, prior to forwarding the request back to the S37CSCF.
38An AS acting as a SIP proxy shall propagate any received IMS XML message body in the forwarded message.
63
15.7.5
Application Server (AS) performing 3rd party call control
25.7.5.1 General
3The AS performing 3rd party call control acts as a B2BUA. There are two kinds of 3rd party call control:
4
5
Routeing B2BUA: an AS receives a request from S-CSCF, terminates it and generates a new request,
which is based on the received request.
Initiating B2BUA: an AS initiates two requests, which are logically connected together at the AS.
7The B2BUA AS will internally map the message headers between the two dialogs that it manages. It is
8responsible for correlating the dialog identifiers and will decide when to simply translate a message from one
9dialog to the other, or when to perform other functions. These decisions are specific to each AS and are outside
10the scope of the present document.
135.7.5.2 Call initiation

145.7.5.2.1
Initial INVITE
15When the AS acting as a Routing B2BUA receives an initial INVITE request from the S-CSCF, the AS shall:
16
remove its own SIP URI from the topmost Route header of the received INVITE request;
17
perform the AS specific functions (see [5]);
18
if successful, generate and send a new INVITE request to the S-CSCF to establish a new dialog;
19
20
copy the remaining Route header(s) unchanged from the received INVITE request to the new INVITE
request;
21
route the new INVITE request based on the topmost Route header.
22
23
NOTE:
The topmost Route header of the received INVITE request will contain the ASs SIP URI. The
following Route header will contain the SIP URI of the S-CSCF.
24When the AS is acting as an Initiating B2BUA the AS shall apply the procedures described in subclause 5.7.3
25for both requests. The AS shall either set the icid parameter in the P-Charging-Vector header to be the same as
26received or different. The AS may retrieve AAA and/or ECF addresses from HSS on Sh interface.
275.7.5.2.2
Subsequent requests
28Void.
295.7.5.3 Call release

305.7.5.4 Call-related requests
31An AS may initiate a call release. See [5] for possible reasons. The AS shall simultaneously send the BYE
32request for both dialogs managed by the B2BUA.
64
15.7.5.5 Further initial requests

2When the AS acting as an Initiating B2BUA the AS shall apply the procedures described in subclause 5.7.3 for
3both requests. The AS shall either set the icid parameter in the P-Charging-Vector header to be the same as
4received or different.
55.7.6
Void
65.8
Procedures at the MRFC
75.8.1
General
8Although the MRFC is acting as a UA, it is outside the scope of this specification how the MRFC associated
9addresses are made known to other entities.
10When the MRFC sends any request or response (excluding ACK requests and CANCEL requests and
11responses) related to a dialog or standalone transaction, the MRFC may insert previously saved values into P12Charging-Vector and P-Charging-Function-Addresses headers before sending the message.
135.8.2
Call initiation

155.8.2.1.1
165.8.2.1.1.1
MRFC-terminating case
Introduction
17The MRFC shall provide a P-Asserted-Identity header in a response to the initial request for a dialog, or any
18response for a standalone transaction. It is a matter of network policy whether the MRFC expresses privacy
19according to [33] with such responses.
20When the MRFC receives an initial INVITE request, the MRFC shall store the values received in the P21Charging-Vector header, e.g., icid parameter. The MRFC shall store the values received in the P-Charging22Function-Addresses header.
235.8.2.1.1.2
Tones and announcements
24The MRFC can receive INVITE requests to set up a session to play tones and announcements. The MRFC acts
25as terminating UA in this case.
26When the MRFC receives an INVITE request with an indicator for a tone or announcement, the MRFC shall:
27
send 100 (Trying) response.
28
29
NOTE:
305.8.2.1.1.3
The detailed interfaces for requesting tones and announcements are not specified in this version
of the document. Other solutions may be used in the interim.
Ad-hoc conferences
31The MRFC can receive INVITE requests to set up an ad-hoc conferencing session (e.g. Multiparty Call) or to
32add parties from the conference. The MRFC acts as terminating UA in this case.
33When the MRFC receives an INVITE request with an indicator to initiate ad hoc conferencing, the MRFC
34shall:
35
send 100 (Trying) response; and
36
37
after the MRFP indicates that the conference resources are available, send 200 (OK) response with an
MRFC conference identifier. If the MRFC chooses to send a 183 (Session Progress) response prior to
65
the 200 (OK), then the conference identifier may also be included in the 183 (Session Progress)
response.
1
2
3When the MRFC receives an INVITE request with an indicator to add a party to an existing ad hoc conference
4(i.e. MRFC conference identifier), the MRFC shall:
5
6
7
8
9
after the MRFP indicates that the conferencing request is granted, send 200 (OK) response with the
response.
10
11
NOTE:
125.8.2.1.1.4
The detailed interface for requesting ad-hoc conferencing sessions is not specified in this version
Transcoding
13The MRFC may receive INVITE requests to set up transcoding between endpoints with incompatible codecs.
14The MRFC acts as terminating UA in this case.
15When the MRFC receives an INVITE request with an indicator for transcoding and a codec is supplied in SDP,
16the MRFC shall:
17
18
after the MRFP indicates that the transcoding request is granted, send 200 (OK) response.
19When the MRFC receives an INVITE request with an indicator for transcoding but no SDP, the MRFC shall:
20
send 183 (Session Progress) response with list of codecs supported by the MRFC/MRFP.
215.8.2.1.2
MRFC-originating case
22The MRFC shall provide a P-Asserted-Identity header in an initial request for a dialog, or any request for a
23standalone transaction. It is a matter of network policy whether the MRFC expresses privacy according to [33]
24with such requests.

265.8.2.2.1
27When the MRFC receives an ACK request for a session, this may be considered as an event to direct the MRFP
28to start the playing of a tone or announcement.
295.8.3
Call release
305.8.3.1 S-CSCF-initiated call release

315.8.3.1.1
32When the MRFC receives a BYE request for a session, the MRFC directs the MRFP to stop the playing of a
33tone or announcement.
66
15.8.3.2 MRFC-initiated call release

25.8.3.2.1
3When the MRFC has a timed session to play tones and announcements and the time expires, the MRFC shall:
4
send a BYE request towards the UE.
5When the MRFC is informed by the MRFP that tone or announcement resource has been released, the MRFC
6shall:
7
send a BYE request towards the UE.
85.8.32.2.2 Transcoding
9When the MRFC receives a PRACK request (in response to the 183 (Session Progress) response) with an
10indicator for transcoding and codec supplied in SDP, the MRFC shall:
11
125.8.4
after the MRFP indicates that the transcoding request is granted, send 200 (OK) response.
135.8.4.1 ReINVITE
145.8.4.1.1
155.8.4.1.1.1
Ad-hoc conferences
16The MRFC can receive reINVITE requests to modify an ad-hoc conferencing session (e.g. Multiparty Call) for
17purposes of floor control and for parties to leave and rejoin the conference.
18When the MRFC receives a reINVITE request, the MRFC shall:
19
20
21
22
23
after the MRFP indicates that the conferencing request is granted, send 200 (OK) response with the
response.
24
25
NOTE:
265.8.4.1.2
The detailed interface for requesting ad-hoc conferencing sessions is not specified in this version
27Void.
285.8.4.2 REFER
295.8.4.2.1
30Void.
67
15.8.4.2.2
2Void.
35.8.4.2.3
REFER initiating a new session
4Void.
55.8.4.2.4
REFER replacing an existing session
6Void.
75.8.4.3 INFO
8Void.
95.8.5
Further initial requests
10When the MRFC responds to an OPTIONS request with a 200 (OK) response, the MRFC may include a
11message body with an indication of the supported tones/announcement packages, DTMF capabilities,
12supported codecs and conferencing options of the MRFC/MRFP.
13
14
NOTE:
156
The detailed interface for requesting MRFC/MRFP capabilities is not specified in this version of
the document. Other solutions may be used in the interim.
Application usage of SDP
166.1
17Usage of SDP by the UE:

18
19
1. In order to authorize the media streams, the P-CSCF and S-CSCF have to be able to inspect and
possibly modify the SDP payloads. Hence, the UE shall not encrypt the SDP payloads.
20
21
22
23
24
25
2. An INVITE request generated by a UE shall contain SDP payload. The SDP payload shall reflect the
calling user's terminal capabilities and user preferences for the session. The UE shall order the SDP
payload with the most preferred codec listed first. In addition, the calling user shall indicate the desired
QoS for the session, using the segmented status type. In an initial INVITE request the UE shall indicate
that it mandates local QoS and that this precondition is not yet satisfied, i.e. the UE shall include the
following preconditions:
26
a=des: qos mandatory local sendrecv
27
a=curr: qos local none.
28
29
30
31
3. Providing that the INVITE request received by the UE contains an SDP offer including one or more
"m=" media descriptions, the first 183 (Session Progress) provisional response that the UE sends, shall
contain the answer for the SDP received in the INVITE. The said SDP answer shall reflect the called
user's terminal capabilities and user preferences.
32
33
34
4. When UE sends out a 183 (Session Progress) response with SDP payload including one or more "m="
media descriptions, it shall request confirmation for the result of the resource reservation at the
originating end point.
68
1
2
5. During session establishment procedure, SIP messages shall only contain SDP payload if that is
intended to modify the session description.
3
4
5
6. 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.
6
7
8
9
If the media line in the SDP indicates the usage of RTP/RTCP, 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 [56B] to
specify the required bandwidth allocation for RTCP.
For other media streams the "b=" media descriptor may be included.
10
11
12
NOTE 1: In a two-party session where both participants are active, the RTCP receiver reports are not sent,
therefore, the RR bandwidth modifer will typically get the value of zero.
13
14
15
7. The UE shall include the MIME subtype "telephone-event" in the "m=" media descriptor in the SDP for
audio media flows that support both audio codec and DTMF payloads in RTP packets as described in
[23].
16
17
8. If an ICN Bearer is rejected or modified, the UE shall, if the SDP is affected, update the remote SIP
entity according to [26] and [29].
18
19
20
21
22
23
9. If the UE builds SDP for an INVITE request generated after receiving a 488 (Not Acceptable Here)
response, as described in subclause 5.1.3.1, the UE shall include SDP payload containing a subset of the
allowed media types, codecs and other parameters from the SDP payload of all 488 (Not Acceptable
Here) responses related to the same session establishment attempt (i.e. a set of INVITE requests used
for the same session establishment). The UE shall order the codecs in the SDP payload according to the
order of the codecs in the SDP payload of the 488 (Not Acceptable Here) response.
24
25
26
27
28
NOTE 2: The UE may be attempting a session establishment through multiple networks with different
policies and potentially may 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 contents of all the 488 (Not Acceptable Here) responses received related to the
same session establishment when building a new INVITE request.
296.2
Procedures at the P-CSCF
30When the P-CSCF receives any SIP request containing SDP, the P-CSCF shall examine the media parameters
31in the received SDP. If the P-CSCF finds any media parameters which are not allowed on the network by local
32policy, the P-CSCF shall return a 488 (Not Acceptable Here) response containing SDP payload. This SDP
33payload contains either all media types, codecs and other SDP parameters which are allowed according to the
34local policy, or, based on configuration by the operator of the P-CSCF, a subset of these allowed parameters.
35This subset may depend on the content of the received SIP request. The P-CSCF shall build the SDP payload in
36the 488 (Not Acceptable Here) response in the same manner as a UAS builds the SDP in a 488 (Not Acceptable
37Here) response as specified in [26]. The P-CSCF shall order the SDP payload with the most preferred codec
38listed first.
39The P-CSCF may inspect, if present, the "b=RS" and "b=RR" lines in order to find out the bandwidth
40allocation requirements for RTCP.
416.3
Procedures at the S-CSCF
42When the S-CSCF receives any SIP request containing SDP, the S-CSCF shall examine the media parameters
43in the received SDP. If the S-CSCF finds any media parameters which are not allowed based on either local
44policy or the subscription, the S-CSCF shall return a 488 (Not Acceptable Here) response containing SDP
45payload. This SDP payload contains either all media types, codecs and other SDP parameters which are
69
1allowed according to the local policy and users subscription, or, based on configuration by the operator of the
2S-CSCF, a subset of these allowed parameters. This subset may depend on the content of the received SIP
3request. The S-CSCF shall build the SDP payload in the 488 (Not Acceptable Here) response in the same
4manner as a UAS builds the SDP in a 488 (Not Acceptable Here) response as specified [26].
56.4
Procedures at the MGCF
66.4.1
Calls originating from circuit-switched networks
7The usage of SDP by the MGCF is the same as its usage by the UE, as defined in the subclause 6.1 and A.3.2,
8with the following exception:.
9
10
In an INVITE request generated by a MGCF, the MGCF shall indicate the current status of the
precondition.
11When sending an SDP, the MGCF shall not include the "i=", "u=", "e=", "p=", "r=", and "z=" descriptors in the
12SDP, and it shall ignore them when received in the SDP.
13When the MGCF generates and sends an INVITE request for a call originating in a circuit-switched network,
14the MGCF shall:
15
populate the SDP with the codecs supported by the associated MGW for the supported codecs, and
16
in order to support DTMF, populate the SDP with MIME subtype "telephone-event" as described in [23]
17When the MGCF receives 183 (Session Progress) response to an INVITE request, the MGCF shall:
18
196.4.2
check that a supported codec has been indicated in the SDP.

20The usage of SDP by the MGCF is the same as its usage by the UE, as defined in the subclause 6.1 and A.3.2. ,
21with the following exception:
22
23
24
When the MGCF sends a 183 (Session Progress) response with SDP payload, it shall only request
confirmation for the result of the resource reservation at the originating end point if there are any
remaining unfulfilled preconditions.
25When sending an SDP, the MGCF shall not include the "i=", "u=", "e=", "p=", "r=", and "z=" descriptors in the
26SDP, and it shall ignore them when received in the SDP.
27When the MGCF receives an initial INVITE request, the MGCF shall:
28
29
check for a codec that matches the requested SDP, which may include the MIME subtype "telephoneevent" as described in [23].
30When the MGCF generates and sends a 183 (Session Progress) response to an initial INVITE request, the
31MGCF shall:
32
33
346.5
set SDP indicating the selected codec, which may include the MIME subtype "telephone-event" as
described in [23].
Procedures at the MRFC
35Void
366.6
Procedures at the AS
37Since an AS may provide a wide range of different services, procedures for the SDP usage for an AS acting as
38originating UA, terminating UA or third-party call control role are dependent on the service provided to the UA
70
1and on the capabilities on the remote UA. There is no special requirements regarding the usage of the SDP,
2except the requirements for the SDP capabilities described in the following paragraphs:
3
4
5
1) Providing that an INVITE request generated by an AS contains SDP payload, the AS has the capability
of reflecting the originating AS's capabilities, desired QoS and precondition requirements for the session
in the SDP payload.
6
7
8
2) When the AS sends a 183 (Session Progress) response with SDP payload including one or more "m="
media types, it has the capability of requesting confirmation for the result of the resource reservation at
the originating endpoint.
97
107.1
Extensions within the present document

SIP methods defined within the present document
11There are no SIP methods defined within the present document over and above those defined in the referenced
12IETF specifications.
137.2
SIP headers defined within the present document
147.2.1
Void
157.2.2
Void
16
Table 7.1: Void
17
Table 7.2: Void
187.2.3
P-Access-Network-Info header
20The P-Access-Network-Info header is the mechanism whereby the UE provides the S-CSCF with information
21relating to the access network it is using. This may include the cell ID.
22The UE shall insert the P-Access-Network-Info header into all requests or responses it originates.
23When forwarding a request or response to an AS that is located within the trust domain, the S-CSCF will retain
24the P-Access-Network-Info header; otherwise, the S-CSCF will remove the P-Access-Network-Info header
25from any message where it is present.
26When the S-CSCF sends a 3rd-party REGISTER request to an AS that is located within the trust domain, the
27S-CSCF will include the P-Access-Network-Info header received in the REGISTER request from the UE. If
28the AS is not located within the trust domain, then the S-CSCF will not include any P-Access-Network-Info
29header.
307.2.3.2 Syntax
31The syntax of the P-Access-Network-Info header is described in [52].
327.2.3.3 Additional coding rules for P-Access-Network-Info header

33In the IMS, there are additional coding rules for the P-Access-Network-Info header:
71
1The access type field is set to the access network specific identifier. The access info field shall contain a value
2that specifies the point where the UE has attached itself to the access network. This value shall be the Cell
3Global Identity obtained from lower layers of the UE.
47.2.4
P-Visited-Network-ID header
6The P-Visited-Network-ID header is used to allow the home network (e.g., the HSS) to discover, during the
7registration procedures, the network(s), other than the home network, that are utilized by the user. This allows
8the registration to be processed based on this, e.g. actions can be taken that are dependent on the roaming
9agreements between networks.
107.2.4.2 Syntax
11The P-Visited-Network-ID header field has the syntax described in [52].
127.2.4.3 Operation
13The header is inserted by the P-CSCF in every REGISTER request the UE sends. The I-CSCF sends the
14contents of the header to the HSS.
157.2.5
P-Charging-Function-Addresses header
17The P-Charging-Function-Addresses header is the mechanism whereby the S-CSCF may distribute a common
18set of addresses for charging functions to other network entities within the same network as the S-CSCF. The
19address of the AAA used for offline charging may be either provisioned in the SIP nodes (e.g., P-CSCF, AS), or
20conveyed to the SIP nodes in the charging correlation function (ccf1) parameter in the P-Charging-Function21Addresses header. Both the primary and secondary Event Charging Function (ecf1 and ecf2) addresses for
22online charging are optional.
23The S-CSCF may insert the header at the first opportunity when initializing dialogs and with standalone
24transactions. The header may be included in requests and responses.
257.2.5.2 Syntax
26The P-Charging-Function-Addresses header field has the syntax described in [52].
277.2.5.3 Operation
28The operation of this header is described in subclauses 5.2, 5.3, 5.4, 5.5, 5.6, 5.7 and 5.8.
297.2.6
P-Charging-Vector header
31The P-Charging-Vector header is the mechanism whereby the charging correlation information may be shared
32by IM CN subsystem functional entities. The charging correlation information consists of the following:
33
34
IMS Charging Identifier (ICID), which is a globally unique identifier created per IMS dialog that is
stored in all related AIRs. See [17] for requirements on the format of ICID.
35
Inter Operator Identifier (IOI), which are globally unique identifiers for a particular network.
72
1
2
Access Network Charging Information, which contains charging information for the signaling and
media flows related to the IMS session..
3
4
NOTE:
If the Go interface is not supported, the P-Charging-Vector will not include the P Connectivity
Network charging information..
5The first IM CN subsystem functional entity involved with a dialog or standalone transaction inserts the header
6with the icid parameter. Additional parameters are inserted into the P-Charging-Vector header by other entities
7as the processing continues. The header may be included in requests and responses.
87.2.6.2 Syntax
9The extensions to the P-Charging-Vector header field haves the syntax described in table 7.3.
Table 7.3: Syntax of extensions to P-Charging-Vector header
10
11
12
13
14
15
16
17
18
19
20
21
22
23
access-network-charging-info = (icn-charging-info / generic-value)

icn-charging-info =
icn-bcp *(SEMI itid)
[SEMI extension-param]
icn-bcp = "icn-bcp" EQUAL gen-value
itid = itc-sig SEMI itc-id SEMI *(flow-id)
SEMI auth-token
itc-sig = "itc-sig" EQUAL ("yes" / "no")
itc-id = "itc-id" EQUAL gen-value
flow-id = "flow-id" EQUAL gen-value
auth-token = "auth-token" EQUAL gen-value
extension-param = token [EQUAL (token | quoted-string)]
24
25
26The access-network-charging-info parameter is an instance of generic-param from the current charge-params
27component of P-Charging-Vector header. The access-network-charging-info parameter includes alternative
28definitions for different types access networks.
29The icn-charging-info parameter contains one icn-bcp child parameter and one or more child itid parameters.
30The icn-bcp parameter - provided by the IP Connectivity Network - identifies the point of attachment where
31UE has attached itself to the core network. Each itid child parameter within icn-charging-info corresponds to
32one ICN Bearer that was established by the IP Connectivity Network for a UE. Each itid parameter contains an
33indicator if it is an IM CN subsystem signaling ICN Bearer (itc-sig parameter), an associated IP Connectivity
34Network Charging Identifier (itc-id parameter), a media authorization token (auth-token parameter) and one or
35more flow identifiers (flow-id parameter) that identify associated m-lines within the SDP from the SIP
36signaling. These parameters are transferred from the ICN Bearer Control Point to the P-CSCF (PDF) over the
37Go interface. For more information about the ICN Bearer for media, see subclause 9.2.5.
38For an ICN Bearer that is only used for SIP signaling, i.e. no media stream requested for a session, then there is
39no authorization activity or information exchange over the Go interface. Since there are no itc-id, media
40authorization token or flow identifiers in this case, the itc-id and media authorization token are set to zero and
41no flow identifier parameters are constructed by the P-CSCF.
42 7.2.6.3
Operation
43The operation of this header is described in subclauses 5.2, 5.3, 5.4, 5.5, 5.6, 5.7 and 5.8.
73
17.2.7
Void
27.2.8
Void
37.2.9
Void
47.2.10 Void
57.2A
Extensions to SIP headers defined within the present document
67.2A.1 Extension to WWW-authenticate header

77.2A.1.1
Introduction
8This extension defines a new authentication parameter (auth-param) for the WWW-Authenticate header used in
9a 401 (Unauthorized) response to the REGISTER request. For more information, see [21] subclause 3.2.1.
107.2A.1.2
Syntax
11The syntax for auth-param is specified in table 7.4.
Table 7.4: Syntax of auth-param
12
13
14auth-param
15integrity-key
16cipher-key
17ik-value
18ck-value
=
=
=
=
=
1#( integrity-key / cipher-key )

"ik" EQUAL ik-value
"ck" EQUAL ck-value
LDQUOT *(HEXDIG) RDQUOT
LDQUOT *(HEXDIG) RDQUOT
19
20
217.2A.1.3
Operation
22This authentication parameter will be used in a 401 (Unauthorized) response in the WWW-Aauthenticate
23header during UE authentication procedure as specified in subclause 5.4.1.
24The S-CSCF appends the integrity-key parameter (directive) to the WWW.-Authenticate header in a 401
25(Unauthorized) response. The P-CSCF stores the integrity-key value and removes the integrity-key parameter
26from the header prior to forwarding the response to the UE.
27The S-CSCF appends the cipher-key parameter (directive) to the WWW-Authenticate header in a 401
28(Unauthorized) response. The P-CSCF removes the cipher-key parameter from the header prior to forwarding
29the response to the UE. In the case ciphering is used, the P-CSCF stores the cipher-key value.
307.2A.2 Extension to Authorization header

317.2A.2.1
Introduction
32The integrity-protected authentication parameter (auth-param) is an extension parameter defined for the
33Authorization header used in REGISTER requests. For more information, see [21] subclause 3.2.2.
347.2A.2.2
Syntax
35The syntax for auth-param is specified in table 7.5.
74
Table 7.5: Syntax of auth-param
2
3integrity-protected = integrity-protected EQUAL (yes / no)
4
57.2A.2.3
Operation
6This authentication parameter is inserted by the P-CSCF in all the REGISTER requests received from the UE.
7The value of the parameter is set to yes in case the request was integrity protected, otherwise the value of it
8is set to no. This information is used by S-CSCF to decide whether to challenge the REGISTER request or
9not, as specified in subclause 5.4.1.
107.2A.3 Tokenized-by parameter definition (various headers)

117.2A.3.1
Introduction
12The tokenized-by parameter is an extension parameter appended to encrypted entries in various SIP headers as
13defined in subclause 5.3.3.1.
147.2A.3.2
Syntax
15The syntax for the tokenized-by parameter is specified in table 7.6:
Table 7.6: Syntax of tokenized-by-param
16
17
18uri-parameter = transport-param / user-param / method-param
19/ ttl-param / maddr-param / lr-param / tokenized-by-param / other-param
20tokenized-by-param = tokenized-by EQUAL hostname
21
22
23The BNF for uri-parameter is taken from IETF [26] and modified accordingly.
247.2A.3.3
Operation
25The tokenized-by parameter is appended by I-CSCF(THIG) after all encrypted strings within SIP headers when
26network configuration hiding is active. The value of the parameter is the domain name of the network which
27encrypts the information.
287.3
Option-tags defined within the present document
29There are no option-tags defined within the present document over and above those defined in the referenced
317.4
Status-codes defined within the present document
32There are no status-codes defined within the present document over and above those defined in the referenced
347.5
Session description types defined within the present document
35There are no session description types defined within the present document over and above those defined in the
36referenced IETF specifications.
75
17.6
3GPP2 IM CN subsystem XML body, version 1
27.6.1
General
3This subclause describes the Document Type Definition that is applicable for the 3GPP2 IM CN Subsystem
4XML body.
5Any SIP User Agent or proxy may insert or remove the 3GPP2 IM CN subsystem XML body or parts of it, as
6required, in any SIP message. The 3GPP2 IM CN subsystem XML body shall not be forwarded outside a
73GPP2 network.
8The associated MIME type with the 3GPP2 IMS XML body is "application/3gpp-ims+xml".
97.6.2
Document Type Definition
10The Document Type Definition, according to XML syntax definitions, is defined in table 7.7.
11
Table 7.7: 3GPP2 IM CN subsystem XML body, version 1 DTD
12<?xml version="1.0" ?>

13
14
15<!DOCTYPE ims-3gpp
16
17
18
<!ELEMENT service-info
(#CDATA)>
197.6.3
DTD description
20This subclause describes the elements of the 3GPP2 IMS Document Type Definition as defined in table 7.7.
21<ims-3gpp>:
This is the root element of the 3GPP2 IMS XML body. It shall always be present. The
22
version described in the present document is 1.
23<service-info>: the transparent element received from the HSS for a particular trigger point are placed within
24
this optional element.
257.7
SIP timers
26The timers defined in [26] need modification in some cases to accommodate the delays introduced by the air
27interface processing and transmission delays. Table 7.8 shows recommended values for 3GPP2.
28Table 7.8 lists in the first column, titled "SIP Timer" the timer names as defined in [26].
29The second column, titled "3GPP2 value to be applied between network elements" lists the values
30recommended for network elements e.g. P-CSCF, S-CSCF, and MGCF, when communicating with each other
31i.e. when no air interface leg is included. These values are identical to those recommended by [26].
32The third column, titled "3GPP2 value to be applied at the UE" lists the values recommended for the UE.
33These are modified when compared to [26] to accommodate the air interface delays.
34The fourth column, titled "3GPP2 value to be applied at the P-CSCF toward a UE" lists the values
35recommended for the P-CSCF when an air interface leg is traversed. These are modified when compared to
36[26].
37The final column reflects the timer meaning as defined in [26].
76
Table 7.8: SIP timers
1
SIP Timer
T1
T2
3GPP2 value to be
applied between
network elements
500ms default
4s
T4
5s
Timer A
initially T1
Timer B
64*T1
Timer C
> 3min
Timer D
Timer E
> 32s for UDP

0s for TCP/SCTP
initially T1
Timer F
64*T1
Timer G
initially T1
Timer H
Timer I
64*T1
T4 for UDP
0s for TCP/SCTP
64*T1 for UDP
0s for TCP/SCTP
T4 for UDP
0s for TCP/SCTP
Timer J
Timer K
3GPP2 value to
3GPP2 value to be
Meaning
be applied at the applied at the P-CSCF
UE
toward a UE
2s default
2s default
RTT estimate
16s
16s
The maximum retransmit
interval for non-INVITE
requests and INVITE
responses
17s
17s
Maximum duration a message
will remain in the network
initially T1
initially T1
INVITE request retransmit
interval, for UDP only
64*T1
64*T1
INVITE transaction timeout
timer
> 3 min
> 3 min
proxy INVITE transaction
timeout
>128s
>128s
Wait time for response
retransmits
0s for TCP/SCTP 0s for TCP/SCTP
initially T1
initially T1
non-INVITE request retransmit
interval, UDP only
64*T1
64*T1
non-INVITE transaction timeout
timer
initially T1
initially T1
INVITE response retransmit
interval
64*T1
64*T1
Wait time for ACK receipt.
T4 for UDP
T4 for UDP
Wait time for ACK retransmits
64*T1 for UDP
64*T1 for UDP
Wait time for non-INVITE
request retransmits
T4 for UDP
T4 for UDP
Wait time for response
retransmits
38
SIP compression
48.1
SIP compression procedures at the UE
58.1.1
SIP compression
6The UE shall support SigComp as specified in [32]. When using SigComp tThe compartment shall UE shall
7send compressed SIP messages start when a SigComp message is received within a security association in
8accordance with [55]. The compartment and shall finish when the UE is no longer registered. State creations
9and announcements shall be allowed only for messages received in a security association.
10The UE shall support the SIP dictionary specified in [42]. If compression is enabled, the UE shall use the
11dictionary to compress the first message.
128.1.2
Compression of SIP requests and responses transmitted to the P-CSCF
13The UE should compress the requests and responses transmitted to the P-CSCF according to subclause 8.1.1.
14
15
NOTE:
Compression of SIP messages is an implementation option. However, compression is strongly

recommended.
77
18.1.3
Decompression of SIP requests and responses received from the P-CSCF
2The UE shall decompress the compressed requests and responses received from the P-CSCF according to
3subclause 8.1.1.
4If the UE detects a decompression failure at the P-CSCF, the recovery mechanism is implementation specific
5and this may, as an example, include resetting the compartment, changing the algorithm or sending the
6following message(s) without compression.
78.2
SIP compression procedures at the P-CSCF
88.2.1
SIP compression
9The P-CSCF shall support SigComp as specified in [32]. When using SigComp tThe compartment shall start P10CSCF shall send compressed SIP messageswhen a SigComp message is received within a security in
11accordance with [55]. The compartment association and shall finish when the UE is no longer registered. State
12creations and announcements shall be allowed only for messages received in a security association.
13The P-CSCF shall support the SIP dictionary specified in [42]. If compression is enabled, the P-CSCF shall use
14the dictionary to compress the first message.
158.2.2
Compression of SIP requests and responses transmitted to the UE
16The P-CSCF should compress the requests and responses transmitted to the UE according to subclause 8.2.1.
17
18
NOTE:
198.2.3
Compression of SIP messages is an implementation option. However, compression is strongly

recommended.
Decompression of SIP requests and responses received from the UE
20The P-CSCF shall decompress the compressed requests and responses received from the UE according to
21subclause 8.2.1.
22If the P-CSCF detects a decompression failure at the UE, the recovery mechanism is implementation specific
23and this may, as an example, include resetting the compartment, changing the algorithm or sending the
24following message(s) without compression.
259
IP Connectivity Network aspects when connected to

26the IM CN subsystem
279.1
Introduction
28A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilizes the services provided by IP
29Connectivity Network to provide packet-mode communication between the UE and the IM CN subsystem.
30Requirements for the UE on the use of these packet-mode services are specified in this subclause.
31Requirements for the ICN Bearer Control Point in support of this communication are specified in [10A].
329.2
339.2.1
Establishment of ICN Bearer and P-CSCF discovery
34Prior to communication with the IM CN subsystem, the UE shall:

35
a) establish a connection with the IP Connectivity Network [10A];
78
1
2
3
b) establish an ICN Bearer used for SIP signaling. This ICN Bearer shall remain active throughout the
period the UE is connected to the IM CN subsystem, i.e. from the initial registration and at least until
the last deregistration. As a result, the ICN Bearer provides the UE with ability to obtain an IP address;
The UE shall choose one of the following options when performing establishment of this ICN Bearer:
I. A dedicated ICN Bearer for SIP signaling:
6
7
8
The UE shall indicate to the ICN Bearer Control Point that this is an ICN Bearer intended to
carry IM CN subsystem-related signaling only. The UE may also use this ICN Bearer for DNS
and DHCP access.
9
10
11
NOTE 1: For this release of the specification, the UE can not indicate that an ICN Bearer is intended to
carry signaling messages only, so the option of a dedicated ICN bearer for SIP signaling is not
available in this release.
12
13
14
II. A general-purpose ICN Bearer:

The UE may decide to use a general-purpose ICN Bearer to carry IM CN subsystem-related
signaling. The UE may carry both signaling and media on the general-purpose ICN Bearer.
15
16
17
NOTE 2: A general-purpose ICN Bearer may carry both IM CN subsystem signaling and media, in case
the media does not need to be authorized by Service Based Local Policy mechanisms and the
media component is not mandated by the P-CSCF to be carried in a separate ICN Bearer.
18
c) discover a P-CSCF.
19
20
The UE may use pre-configured P-CSCF address(es) (IP address or domain name) or DHCP to discover
P-CSCF address(es). If DHCP is used, the following procedures apply:
21
22
Upon establishing an ICN Bearer, the UE may use the Dynamic Host Configuration Protocol (DHCP)
[57] or Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [40] to discover the P-CSCF.
23
24
25
26
Prior to accessing the DHCP server, the UE shall obtain an IP address via means other than DHCP and
DHCPv6 [10A]. Hence, if the UE uses DHCP or DHCPv6 for P-CSCF discovery, the UE shall only
request the configuration information from the DHCP server through a single request and reply
exchanged with the DHCP server.
27
28
29
30
31
32
33
34
35
36
37
38
If the UE uses DHCP for P-CSCF discovery, the UE shall send the DHCPINFORM using the limited
broadcast IP address (i.e., 255.255.255.255) and UDP port 67. The DHCP server shall send the
DHCPACK on the IP address specified in the Client IP Address field of the DHCPINFORM. The
DHCP server may include in the DHCPACK the SIP Server DHCP Option [56], which carries either a
list of IPv4 address(es) of the P-CSCF(s) or a list of DNS fully qualified domain name(s) that can be
mapped to one or more P-CSCF(s). If the UE uses DHCPv6 for P-CSCF discovery, the UE shall send
an Information Request using the IPv6 multicast address FF02::1:2 and the UDP port 547. In the
Information Request, the UE may request either one or both the SIP Servers Domain Name List option
and the SIP Servers IPv6 Address List option [41]. The DHCP server shall send the Reply to the IP
address specified in the Information- Request. The DHCP server may include in the Reply either one
or both the SIP Servers Domain Name List option and the SIP Servers IPv6 Address List option, as
requested by the UE.
39
40
41
In case several P-CSCF's IP addresses or domain names are provided to the UE, the UE shall perform PCSCF selection according to [56] or [41]. The UE shall perform the procedure for the resolution of host
name according to [58].
79
19.2.1A Void Procedures at ICN BearerControl Point

2Void.
39.2.1B ICN Bearer Control Point support of DHCP based P-CSCF discovery
4The ICN Bearer Control Point, or Homa Agent in case of Mobile IP with reverse tunneling, may forward the
5packet to one or more local DHCP servers, or relay the packet to a specific DHCP server. The ICN Bearer
6Control Point, or Homa Agent in case of Mobile IP with reverse tunneling, shall not forward the
7DHCPINFORM (or Information-Request) to any UE.
8
9
NOTE 1: In this section, the ICN Bearer Control Point refers to the HA when Mobile IP reverse-tunnelling
is enabled for the UE or to the PDSN for all other cases.
10
11
12
NOTE 12:For forwarding the DHCPINFORM or Information-Request, the ICN Bearer Control Point, or
Homa Agent in case of Mobile IP with reverse tunneling,CN-POA does not change the
destination IP address of the packet.
13
14
15
NOTE 23:For relaying the DHCPINFORM or Information-Request, the ICN Bearer Control Poin, or Homa
Agent in case of Mobile IP with reverse tunneling,tCN-POA inserts a DHCP servers IP address
in the destination IP address field of the packet.
169.2.2
Void Session management procedures
17Void.
189.2.3
Void Mobility management procedures
19Void.
209.2.4
Void Cell selection and lack of coverage
21Void.
22The existing mechanisms and criteria for cell selection as described in [11] shall apply while the UE is
23connected to the IM CN subsystem.
249.2.5
ICN Bearer for media
259.2.5.1 General requirements

26During establishment of a session, the UE establishes data streams(s) for media related to the session. Such
27data stream(s) may result in activation of additional ICN Bearer(s). Such additional ICN Bearer(s) shall be
28associated with the ICN Bearer used for signaling.
29The UE has to allocate bandwidth for RTP and RTCP in an ICN Bearer.
30The P-CSCF shall indicate to the UE in SIP/SDP if a separate ICN Bearer is required for a media component.
31The UE shall establish an additional ICN Bearer for a media component if so indicated by the P-CSCF.
32The UE shall pass the authorization token received from the P-CSCF in the 183 (Session Progress) response to
33an INVITE request at originating setup or in the INVITE request at terminating setup to the ICN Bearer
34Control Point.
35The UE shall indicate to the ICN Bearer Control Point which flow(s) (identified by m-lines within the SDP)
36are to be transferred within a particular ICN Bearer.
80
1Detailed description of how the authorization token and flow identifiers are conveyed to the IP Connectivity
2Network (e.g., PDSN) is for further study.
39.2.5.2 Special requirements applying to forked responses

4Since the UE does not know that forking has occurred until a second, provisional response arrives, the UE sets
5up the ICN Bearer as required by the initial response received. If a subsequent provisional response is received,
6different alternative actions may be performed depending on the requirements in the SDP answer:
7
8
1) the bearer requirements of the subsequent SDP can be accommodated by the existing ICN Bearer. The
UE performs no activation or modification of the ICN Bearer(s).
9
10
2) the subsequent SDP introduces different QoS requirements or additional IP flows. The UE modifies the
existing ICN Bearer(s), if necessary, according to subclause 9.2.5.1
11
12
3) the subsequent SDP introduces one or more additional IP flows. The UE establishes additional ICN
Bearer (s) according to subclause 9.2.5.1.
13
14
15
16
NOTE 1: When several forked responses are received, the resources requested by the UE are 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.
17
18
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.
19When a final answer is received for one of the early dialogues, the UE proceeds to set up the SIP session. The
20UE shall release all the unneeded radio/bearer resources. Therefore, upon the reception of a first final 200 (OK)
21response for the INVITE request (in addition to the procedures defined in [26] subclause 13.2.2.4), the UE
22shall:
23
24
25
1) in case the ICN Bearer(s) were established or modified as a consequence of the INVITE request and
forked provisional responses that are not related to the accepted 200 (OK) response, delete the ICN
Bearer(s) or modify the delete ICN Bearer(s) back to their original state.
81
Annex A (normative):
Profiles of IETF RFCs for 3GPP2 usage
2
3
4A.1
Profiles
5A.1.1
Relationship to other specifications
6This annex contains a profile to the IETF specifications which are referenced by this specification, and the
7PICS proformas underlying profiles do not add requirements to the specifications they are proformas for.
8This annex provides a profile specification according to both the current IETF specifications for SIP, SDP and
9other protocols (as indicated by the "RFC status" column in the tables in this annex) which are referenced by
10this specification and to the 3GPP specifications using SIP (as indicated by the "Profile status" column in the
11tables in this annex.
12In the "RFC status" column the contents of the referenced specification takes precedence over the contents of
13the entry in the column.
14In the "Profile status" column, there are a number of differences from the "RFC status" column. Where these
15differences occur, these differences take precedence over any requirements of the IETF specifications. Where
16specification concerning these requirements exists in the main body of the present document, the main body of
17the present document takes precedence.
18Where differences occur in the "Profile status" column, the "Profile status" normally gives more strength to a
19"RFC status" and is not be in contradiction with the "RFC status", e.g. it may change an optional "RFC status"
20to a mandatory "Profile status". If the "Profile status" weakens the strength of a "RFC status" then additionally
21this will be indicated by further textual description in the present document.
22For all IETF specifications that are not referenced by this document or that are not mentioned within the 3GPP
23profile of SIP and SDP, the generic rules as defined by RFC 3261 [26] and in addition the rules in clauses 5 and
246 of this specification apply, e.g..
25
26
27
a proxy which is built in accordance to this specification passes on any unknown method, unknown
header field or unknown header parameter after applying procedures such as filtering, insertion of PAsserted-Identity header, etc.;
28
an UA which is built in accordance to this specification will
29
30
handle received unknown methods in accordance to the procedures defined in RFC 3261 [26], e.g.
respond with a 400 (Bad Request) response; and
31
32
33
handle unknown header fields and unknown header parameters in accordance to the procedures defined
in RFC 3261 [26], e.g. respond with a 420 (Bad Extension) if an extension identified by an option tag
in the Require header of the received request is not supported by the UA.
34A.1.2
Introduction to methodology within this profile
35This subclause does not reflect dynamic conformance requirements but static ones. In particular, an condition
36for support of a PDU parameter does not reflect requirements about the syntax of the PDU (i.e. the presence of
37a parameter) but the capability of the implementation to support the parameter.
38In the sending direction, the support of a parameter means that the implementation is able to send this
39parameter (but it does not mean that the implementation always sends it).
40In the receiving direction, it means that the implementation supports the whole semantic of the parameter that
41is described in the main part of this specification.
82
1As a consequence, PDU parameter tables in this subclause are not the same as the tables describing the syntax
2of a PDU in the reference specification, e.g. RFC 3261 [26] tables 2 and 3. It is not rare to see a parameter
3which is optional in the syntax but mandatory in subclause below.
4The various statii used in this subclause are in accordance with the rules in table A.1.
Table A.1: Key to status codes
5
Status code
m
Status name
mandatory
o
n/a
optional
not applicable
x
c <integer>
prohibited (excluded)
conditional
o.<integer>
qualified optional
irrelevant
Meaning
the capability shall be supported. It is a static view of the fact that the
conformance requirements related to the capability in the reference
specification are mandatory requirements. This does not mean that a given
behaviour shall always be observed (this would be a dynamic view), but that it
shall be observed when the implementation is placed in conditions where the
conformance requirements from the reference specification compel it to do so.
For instance, if the support for a parameter in a sent PDU is mandatory, it does
not mean that it shall always be present, but that it shall be present according
to the description of the behaviour in the reference specification (dynamic
conformance requirement).
the capability may or may not be supported. It is an implementation choice.
it is impossible to use the capability. No answer in the support column is
required.
It is not allowed to use the capability. This is more common for a profile.
the requirement on the capability ("m", "o", "n/a" or "x") depends on the
support of other optional or conditional items. <integer> is the identifier of
the conditional expression.
for mutually exclusive or selectable options from a set. <integer> is the
identifier of the group of options, and the logic of selection of the options.
capability outside the scope of the given specification. Normally, this notation
should be used in a base specification ICS proforma only for transparent
parameters in received PDUs. However, it may be useful in other cases, when
the base specification is in fact based on another standard.
6
7In the context of this specification the "i" status code mandates that the implementation does not change the
8content of the parameter. It is an implementation option if the implementation acts upon the content of the
9parameter (e.g. by setting filter criteria to known or unknown parts of parameters in order to find out the route
10a message has to take).
11It must be understood, that this 3GPP SIP profile does not list all parameters which an implementation will
12treat as indicated by the status code "irrelevant". In general an implementation will pass on all unknown
13messages, header fields and header parameters, as long as it can perform its normal behaviour.
14The following additional comments apply to the interpretation of the tables in this Annex.
15
16
NOTE 1: The tables are constructed according to the conventional rules for ICS proformas and profile
tables.
17
18
19
20
NOTE 2: The notation (either directly or as part of a conditional) of "m" for the sending of a parameter
and "i" for the receipt of the same parameter, may be taken as indicating that the parameter is
passed on transparently, i.e. without modification. Where a conditional applies, this behaviour
only applies when the conditional is met.
83
1A.1.3
Roles
Table A.2: Roles
2
Item
1
2
o.1:
NOTE:
Roles
Reference
RFC status
Profile status
User agent
[26]
o.1
o.1
Proxy
[26]
o.1
o.1
It is mandatory to support exactly one of these items.
For the purposes of the present document it has been chosen to keep the specification simple by the tables
specifying only one role at a time. This does not preclude implementations providing two roles, but an
entirely separate assessment of the tables shall be made for each role.
Table A.3: Roles specific to this profile
4
Item
1
2
3
3A
4
5
6
7
7A
7B
7C
7D
8
c1:
c2:
o.1:
o.2:
NOTE:
Roles
Reference
RFC status
Profile status
UE
5.1
n/a
o.1
P-CSCF
5.2
n/a
o.1
I-CSCF
5.3
n/a
o.1
I-CSCF (THIG)
5.3
n/a
c1
S-CSCF
5.4
n/a
o.1
BGCF
5.6
n/a
o.1
MGCF
5.5
n/a
o.1
AS
5.7
n/a
o.1
AS acting as terminating UA, or redirect 5.7.2
n/a
c2
server
AS acting as originating UA
5.7.3
n/a
c2
AS acting as a SIP proxy
5.7.4
n/a
c2
AS performing 3rd party call control
5.7.5
n/a
c2
MRFC
5.8
n/a
o.1
IF A.3/3 THEN o ELSE x - - I-CSCF.
IF A.3/7 THEN o.2 ELSE n/a - - AS.
It is mandatory to support exactly one of these items.
It is mandatory to support at least one of these items.
For the purposes of the present document it has been chosen to keep the specification simple by the tables
specifying only one role at a time. This does not preclude implementations providing two roles, but an
entirely separate assessment of the tables shall be made for each role.
6A.2
Profile definition for the Session Initiation Protocol as

7used in the present document
8A.2.1
User agent role
9A.2.1.1 Introduction
10This subclause contains the ICS proforma tables related to the user role. They need to be completed only for
11UA implementations:
12
Prerequisite: A.2/1 - - user agent role.
84
1A.2.1.2 Major capabilities

2
Table A.4: Major capabilities
85
Item
1
2
2A
3
4
5
6
7
8
8A
9
10
11
12
13
14
15
16
17
19
20
21
22
23
24
25
26
26A
26B
26C
26D
26E
Does the implementation support

Capabilities within main protocol
client behaviour for registration?
registrar?
initiating a session?
client behaviour for INVITE requests?
server behaviour for INVITE requests?
session release?
timestamping of requests?
authentication between UA and UA?
authentication between UA and
registrar?
authentication between UA and proxy?
server handling of merged requests due
to forking?
client handling of multiple responses
due to forking?
insertion of date in requests and
responses?
downloading of alerting information?
Extensions
the SIP INFO method?
reliability of provisional responses in
SIP?
the REFER method?
integration of resource management
and SIP?
the SIP UPDATE method?
SIP extensions for media authorization?
SIP specific event notification?
the use of NOTIFY to establish a
dialog?
acting as the notifier of event
information?
acting as the subscriber to event
information?
session initiation protocol extension
header field for registering non-adjacent
contacts?
private extensions to the Session
Initiation Protocol (SIP) for network
asserted identity within trusted
networks
a privacy mechanism for the Session
Initiation Protocol (SIP)
request of privacy by the inclusion of a
Privacy header
application of privacy based on the
received Privacy header
passing on of the Privacy header
transparently
application of the privacy option
"header" such that those headers which
cannot be completely expunged of
identifying information without the
assistance of intermediaries are
obscured?
"session" such that anonymization for
the session(s) initiated by this message
Reference
RFC status
Profile status
[26] subclause 10.2

[26] subclause 10.3
[26] subclause 13
[26] subclause 13.2
[26] subclause 13.3
[26] subclause 15.1
[26] subclause 8.2.6.1
[26] subclause 22.2
[26] subclause 22.2
m
o
o
c18
c18
c18
o
o
o
c3
c4
o
c18
c18
c18
o
o
n/a
[26] 20.28, 22.3

[26] 8.2.2.2
o
m
o
m
[26] 13.2.2.4
[26] subclause 20.17
[26] subclause 20.4
[25]
[27]
o
c19
n/a
c18
[36]
[30]
o
c19
o
c18
[29]
[31]
[28]
[28] 4.2
c5
o
o
o
c18
c14
c13
n/a
[28]
c2
c15
[28]
c2
c16
[35]
c6
[34]
[33]
[33]
c9
c11
[33]
c9
n/a
[33]
c9
c12
[33] 5.1
c10
[33] 5.2
c10
86
occurs?
87
26F
26G
27
28
29
30
31
32
33
34
35
36
37
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
c14:
c15:
c16:
c17:
c18:
c19:
c20:
c21:
c22:
c23:
c24:
application of the privacy option "user"

[33] 5.3
c10
such that user level privacy functions
are provided by the network?
application of the privacy option "id"
[34] 7
c10
n/a
such that privacy of the network
asserted identity is provided by the
network?
a messaging mechanism for the
[50]
o
c7
Session Initiation Protocol (SIP)?
session initiation protocol extension
[38]
o
c17
header field for service route discovery
during registration?
compressing the session initiation
[55]
o
c8
protocol?
private header extensions to the
[52]
o
m
session initiation protocol for the 3rdGeneration Partnership Project
(3GPP)?
the P-Associated-URI header
[52] 4.1
c21
c22
extension?
the P-Called-Party-ID header
[52] 4.2
c21
c23
extension?
the P-Visited-Network-ID header
[52] 4.3
c21
c24
extension?
the P-Access-Network-Info header
[52] 4.4
c21
c25
extension?
the P-Charging-Function-Addresses
[52] 4.5
c21
c26
header extension?
the P-Charging-Vector header
[52] 4.6
c21
c26
extension?
security mechanism agreement for the
[48]
o
c20
session initiation protocol?
IF A.4/20 THEN o.1 ELSE n/a - - SIP specific event notification extension.
IF A.3/1 OR A.3/4 THEN m ELSE n/a - - UE or S-CSCF functional entity.
IF A.3/4 OR A.3/7 THEN m ELSE n/a - - S-CSCF or AS functional entity.
IF A.4/16 THEN m ELSE o - - integration of resource management and SIP extension.
IF A.3/4 OR A.3/1 THEN m ELSE n/a. - - S-CSCF or UE.
IF A.3/4 THEN m ELSE (IF A.3/1 OR A.3/7B OR A.3/7D THEN o ELSE n/a - - S-CSCF or UA or AS acting
as originating UA, or AS performing 3rd party call control
IF A.3/1 THEN m ELSE n/a - - UE behaviour.
IF A.4/26 THEN o.2 ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP).
IF A.4/26B THEN o.3 ELSE n/a - - application of privacy based on the received Privacy header.
IF A.3/1 OR A.3/6 THEN o ELSE n/a - - UE or MGCF.
IF A.3/7D THEN m ELSE n/a - - AS performing 3rd-party call control.
IF A.3/1 OR A.3/4 THEN m ELSE o - - UE behaviour or S-CSCF.
IF A.3/1 THEN m ELSE IF A.3/2 THEN o ELSE n/a UE or P-CSCF
IF A.4/20 and A.3/4 THEN m ELSE o SIP specific event notification extensions and S-CSCF.
IF A.4/20 and (A.3/1 OR A.3/2) THEN m ELSE o - - SIP specific event notification extension and UE or PCSCF.
IF A.3/1 o A3./4 THEN m ELSE n/a UE or S-CSCF
IF A.4/2A THEN m ELSE n/a - - initiating sessions
IF A.4/2A THEN o ELSE n/a - - initiating sessions
IF A.3/1 THEN m ELSE n/a - - UE behaviour.
IF A.4/30 THEN o.4 ELSE n/a - - private header extensions to the session initiation protocol for the 3rdGeneration Partnership Project (3GPP).
IF A.4/30 AND (A.3/1 OR A.3/4) THEN m ELSE n/a - - private header extensions to the session initiation
protocol for the 3rd-Generation Partnership Project (3GPP) and S-CSCF or UA.
IF A.4/30 AND A.3/1 THEN o ELSE n/a - - - - private header extensions to the session initiation protocol for
the 3rd-Generation Partnership Project (3GPP) and UE.
IF A.4/30 AND A.3/4) THEN m ELSE n/a - - private header extensions to the session initiation protocol for
the 3rd-Generation Partnership Project (3GPP) and S-CSCF.
88
c25:
c26:
o.1:
o.2:
o.3:
o.4:
IF A.4/30 AND (A.3/1 OR A.3/4 OR A.3/7A OR A.3/7D) THEN m ELSE n/a - - private header extensions to
the session initiation protocol for the 3rd-Generation Partnership Project (3GPP) and UE, S-CSCF or AS
acting as terminating UA or AS acting as third-party call controller.
IF A.4/30 AND (A.3/6 OR A.3/7A OR A.3/7B or A.3/7D) THEN m ELSE n/a - - private header extensions to
the session initiation protocol for the 3rd-Generation Partnership Project (3GPP) and MGCF, AS acting as a
terminating UA, or AS acting as an originating UA, or AS acting as third-party call controller.
At least one of these capabilities is supported.
2A.2.1.3 PDUs
Table A.5: Supported methods
3
Item
PDU
Sending
RFC
Profile
Ref.
status
status
ACK request
[26] 13
m
m
[26] 13
BYE request
[26] 15.1
o
[26] 15.1
BYE response
[26] 15.1
o
[26] 15.1
CANCEL request
[26] 9
o
[26] 9
CANCEL response
[26] 9
o
[26] 9
INVITE request
[26] 13
m
m
[26] 13
INVITE response
[26] 13
m
m
[26] 13
MESSAGE request
[50] 4
c7
c7
[50] 7
MESSAGE response
[50] 4
c7
c7
[50] 7
NOTIFY request
[28] 8.1.2
c4
c4
[28] 8.1.2
NOTIFY response
[28] 8.1.2
c3
c3
[28] 8.1.2
OPTIONS request
[26] 11
m
m
[26] 11
OPTIONS response
[26] 11
m
m
[26] 11
PRACK request
[27] 6
c5
c5
[27] 6
PRACK response
[27] 6
c5
c5
[27] 6
REFER request
[36] 3
c1
c1
[36] 3
REFER response
[36] 3
c1
c1
[36] 3
REGISTER request
[26] 10
o
[26] 10
REGISTER response
[26] 10
n/a
[26] 10
SUBSCRIBE request
[28] 8.1.1
c3
c3
[28] 8.1.1
SUBSCRIBE response
[28] 8.1.1
c4
c4
[28] 8.1.1
UPDATE request
[30] 6.1
c6
c6
[30] 6.2
UPDATE response
[30] 6.2
c6
c6
[30] 6.1
IF A.4/15 THEN m ELSE n/a - - the REFER method extension.
IF A.4/23 THEN m ELSE n/a - - recipient for event information.
IF A.4/22 THEN m ELSE n/a - - notifier of event information.
IF A.4/14 THEN m ELSE n/a - - reliability of provisional responses extension.
IF A.4/17 THEN m ELSE n/a - - the SIP update method extension.
IF A.4/27 THEN m ELSE n/a - - the SIP MESSAGE method.
Ref.
1
2
3
4
5
8
9
9A
9B
10
11
12
13
14
15
16
17
18
19
20
21
22
23
c1:
c3:
c4:
c5:
c6:
c7:
Receiving
RFC
status
m
o
o
o
o
m
m
c7
c7
c3
c4
m
m
c5
c5
c1
c1
n/a
m
c4
c3
c6
c6
Profile
status
m
m
m
c7
c7
c3
c4
m
m
c5
c5
c1
c1
c4
c3
c6
c6
4
5
6
NOTE 1Editor's note: Optional status of BYE in RFC status is given because RFC states SHOULD (client
and server).
7
8
9
NOTE 2Editor's note: Optional status of REGISTER in RFC status is given because RFC states
RECOMMENDED (client); for the UAS, not statement is made, but it is assumed that this
therefore means n/a.
89
1A.2.1.4 PDU parameters

2A.2.1.4.1
Status-codes
Table A.6: Supported status-codes
90
Item
Header
Ref.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
41A
42
43
44
45
46
47
100 (Trying)
180 (Ringing)
181 (Call Is Being
Forwarded)
182 (Queued)
183 (Session Progress)
200 (OK)
202 (Accepted)
300 (Multiple Choices)
301 (Moved Permanently)
302 (Moved Temporarily)
305 (Use Proxy)
380 (Alternative Service)
400 (Bad Request)
401 (Unauthorized)
402 (Payment Required)
403 (Forbidden)
404 (Not Found)
405 (Method Not Allowed)
406 (Not Acceptable)
407 (Proxy Authentication
Required)
408 (Request Timeout)
410 (Gone)
413 (Request Entity Too
Large)
414 (Request-URI Too
Large)
415 (Unsupported Media
Type)
416 (Unsupported URI
Scheme)
420 (Bad Extension)
421 (Extension Required)
423 (Interval Too Brief)
480 (Temporarily
Unavailable)
481 (Call/Transaction
Does Not Exist)
482 (Loop Detected)
483 (Too Many Hops)
484 (Address Incomplete)
485 (Ambiguous)
486 (Busy Here)
487 (Request Terminated)
488 (Not Acceptable Here)
489 (Bad Event)
491 (Request Pending)
493 (Undecipherable)
494 (Security Agreement
Required)
500 (Internal Server Error)
501 (Not Implemented)
502 (Bad Gateway)
503 (Service Unavailable)
504 (Server Time-out)
505 (Version not
[26] 21.1.1
[26] 21.1.2
[26] 21.1.3
[26] 21.1.4
[26] 21.1.5
[26] 21.2.1
[28] 8.3.1
[26] 21.3.1
[26] 21.3.2
[26] 21.3.3
[26] 21.3.4
[26] 21.3.5
[26] 21.4.1
[26] 21.4.2
[26] 21.4.3
[26] 21.4.4
[26] 21.4.5
[26] 21.4.6
[26] 21.4.7
[26] 21.4.8
Sending
RFC
status
n/a
c2
c2
Profile
status
n/a
c2
c2
c2
c1
c2
c1
c3
c3
Receiving
RFC
status
[26] 21.1.1
m
[26] 21.1.2
c1
[26] 21.1.3
c1
Ref.
[26] 21.1.4
[26] 21.1.5
[26] 21.2.1
[28] 8.3.1
[26] 21.3.1
[26] 21.3.2
[26] 21.3.3
[26] 21.3.4
[26] 21.3.5
[26] 21.4.1
[26] 21.4.2
[26] 21.4.3
[26] 21.4.4
[26] 21.4.5
[26] 21.4.6
[26] 21.4.7
[26] 21.4.8
[26] 21.4.9
[26] 21.4.10
[26] 21.4.11
[26] 21.4.9
[26] 21.4.10
[26] 21.4.11
[26] 21.4.12
[26] 21.4.12
[26] 21.4.13
[26] 21.4.13
[26] 21.4.14
[26] 21.4.14
[26] 21.4.15
[26] 21.4.16
[26] 21.4.17
[26] 21.4.18
[26] 21.4.15
[26] 21.4.16
[26] 21.4.17
[26] 21.4.18
c4
c4
[26] 21.4.19
[26] 21.4.19
[26] 21.4.20
[26] 21.4.21
[26] 21.4.22
[26] 21.4.23
[26] 21.4.24
[26] 21.4.25
[26] 21.4.26
[28] 7.3.2
[26] 21.4.27
[26] 21.4.28
[48] 2
[26] 21.4.20
[26] 21.4.21
[26] 21.4.22
[26] 21.4.23
[26] 21.4.24
[26] 21.4.25
[26] 21.4.26
[28] 7.3.2
[26] 21.4.27
[26] 21.4.28
[48] 2
c3
c3
c5
c5
[26] 21.5.1
[26] 21.5.2
[26] 21.5.3
[26] 21.5.4
[26] 21.5.5
[26] 21.5.6
[26] 21.5.1
[26] 21.5.2
[26] 21.5.3
[26] 21.5.4
[26] 21.5.5
[26] 21.5.6
91
Profile
status
m
c1
c1
c1
c1
c1
c1
c3
c3
c3
c3
c6
c6
Item
Header
Ref.
48
49
50
51
52
53
c1:
c2:
c3:
c4:
c5:
c6:
Sending
RFC
status
Profile
status
Ref.
Receiving
RFC
status
Profile
status
supported)
513 (Message Too Large)
[26] 21.5.7
[26] 21.5.7
580 (Precondition Failure)
[30] 8
[30] 8
600 (Busy Everywhere)
[26] 21.6.1
[26] 21.6.1
603 (Decline)
[26] 21.6.2
[26] 21.6.2
604 (Does Not Exist
[26] 21.6.3
[26] 21.6.3
Anywhere)
[26] 21.6.4
[26] 21.6.4
IF A.5/9 THEN m ELSE n/a - - INVITE response.
IF A.5/9 THEN o ELSE n/a - - INVITE response.
IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension.
IF A.5/19 OR A.5/21 THEN m ELSE n/a - - REGISTER response or SUBSCRIBE response.
IF A.4/37 AND A.4/2 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol
and registrar.
IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol.
2A.2.1.4.2
ACK method
3Prerequisite A.5/1 ACK request
[CR481R1]Table A.7: Supported headers within the ACK request
4
Item
Header
Ref.
2
3
4
6
7
8
9
10
11
12
13
14
15
15A
16
17
18
19
20
21
22
23
c1:
c2:
c3:
c4:
c5:
c6:
c7:
Allow-Events
Sending
RFC
status
c1
Ref.
Receiving
RFC
status
c2
[28]
[28]
87.2.2
87.2.2
Authorization
[26] 20.7
c3
c3
[26] 20.7
c3
Call-ID
[26] 20.8
m
m
[26] 20.8
m
Content-Disposition
[26] 20.11 o
o
[26] 20.11 m
Content-Encoding
[26] 20.12 o
o
[26] 20.12 m
Content-Language
[26] 20.13 o
o
[26] 20.13 m
Content-Length
[26] 20.14 m
m
[26] 20.14 m
Content-Type
[26] 20.15 mo
mo
[26] 20.15 m
Cseq
[26] 20.16 m
m
[26] 20.16 m
Date
[26] 20.17 c4
c4
[26] 20.17 m
From
[26] 20.20 m
m
[26] 20.20 m
Max-Forwards
[26] 20.22 om
om
[26] 20.22 n/a
MIME-Version
[26] 20.24 o
o
[26] 20.24 m
Privacy
[33] 4.2
c6
n/a
[33] 4.2
c6
Proxy-Authorization
[26] 20.28 c5
c5
[26] 20.28 n/a
Proxy-Require
[26] 20.29 o
n/a
[26] 20.29 n/a
Require
[26] 20.32 o
o
[26] 20.32 m
Route
[26] 20.34 m
m
[26] 20.34 n/a
Timestamp
[26] 20.38 c7
c7
[26] 20.38 m
To
[26] 20.39 m
m
[26] 20.39 m
User-Agent
[26] 20.41 o
o
[26] 20.41 m
Via
[26] 20.42 m
m
[26] 20.42 m
IF A.4/20 THEN o ELSE n/a - - SIP specific event notification extension.
IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA.
IF A.4/11 THEN o ELSE n/a - - insertion of date in requests and responses.
IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy.
IF A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP).
IF A.4/6 THEN o ELSE n/a - - timestamping of requests.
Profile
status
c1
92
Profile
status
c2
c3
m
m
m
m
m
m
m
m
m
n/a
m
n/a
n/a
n/a
m
n/a
m
m
m
m
Editor's note: Is the following table a suitable way of showing the contents of message bodies.
2Prerequisite A.5/1 ACK request
Table A.8: Supported message bodies within the ACK request
3
Item
Header
Ref.
Sending
RFC
status
93
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.1.4.3
BYE method
2Prerequisite A.5/2 - - BYE request

3
[CR481R1]Table A.9: Supported headers within the BYE request
94
Item
Header
Ref.
1
2
3
3A
4
5
6
7
8
9
10
11
12
13
14
15
16
16A
16B
16C
16D
16E
16F
17
18
19
20
21
21A
21B
22
23
24
25
26
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
c14:
c15:
c16:
NOTE:
Sending
RFC
status
o
o
o
o
c1
c3
m
o
o
o
m
m
m
c4
m
om
o
c9
n/a
c13
Profile
status
o
o
o
o
c1
c3
m
o
o
o
m
m
m
c4
m
om
o
c10
n/a
c14
Ref.
Receiving
RFC
status
m
m
m
m
c2
c3
m
m
m
m
m
m
m
m
m
n/a
m
c9
c6
c13
Profile
status
m
m
m
m
c2
c3
m
m
m
m
m
m
m
m
m
n/a
m
c11
c6
c14
Accept
[26] 20.1
[26] 20.1
Accept-Encoding
[26] 20.2
[26] 20.2
Accept-Language
[26] 20.3
[26] 20.3
Allow
[26] 20.5
[26] 20.5
Allow-Events
[28] 87.2.2
[28] 87.2.2
Authorization
[26] 20.7
[26] 20.7
Call-ID
[26] 20.8
[26] 20.8
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
Max-Forwards
[26] 20.22
[26] 20.22
MIME-Version
[26] 20.24
[26] 20.24
P-Access-Network-Info [52] 4.4
[52] 4.4
P-Asserted-Identity
[34] 9.1
[34] 9.1
P-Charging-Function[52] 4.5
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c12
n/a
[52] 4.6
c12
n/a
P-Preferred-Identity
[34] 9.2
c6
x
[34] 9.2
n/a
n/a
Privacy
[33] 4.2
c7
n/a
[33] 4.2
c7
c7
Proxy-Authorization
[26] 20.28
c5
c5
[26] 20.28
n/a
n/a
Proxy-Require
[26] 20.29
o
n/a
[26] 20.29
n/a
n/a
Record-Route
[26] 20.30
n/a
n/a
[26] 20.30
n/a
n/a
Require
[26] 20.32
o
o
[26] 20.32
m
m
Route
[26] 20.34
m
m
[26] 20.34
n/a
n/a
Security-Client
[48] 2.3.1
c15
c15
[48] 2.3.1
n/a
n/a
Security-Verify
[48] 2.3.1
c16
c16
[48] 2.3.1
n/a
n/a
Supported
[26] 20.37
o
o
[26] 20.37
m
m
Timestamp
[26] 20.38
c8
c8
[26] 20.38
m
m
To
[26] 20.39
m
m
[26] 20.39
m
m
User-Agent
[26] 20.41
o
o
[26] 20.41
o
o
Via
[26] 20.42
m
m
[20] 20.42
m
m
IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted identity
within trusted networks.
IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-Info header extension.
IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-Info header extension and UE.
IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-Info header extension and AS
acting as terminating UA or AS acting as third-party call controller.
IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension.
IF A.4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension.
IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension.
IF A.4/37 THEN o ELSE n/a - - security mechanism agreement for the session initiation protocol (note).
Support of this header in this method is dependent on the security mechanism and the security architecture which
is implemented. Use of this header in this method is not appropriate to the security mechanism defined by
3GPP TS 33.203 [19].
95
1
Table A.10: Supported message bodies within the BYE request
3
Item
Header
Ref.
Sending
RFC
status
Profile
status
Ref.
Receiving
RFC
status
Profile
status
Receiving
RFC
status
m
m
m
m
m
m
m
Profile
status
m
m
m
m
m
m
m
4
5Prerequisite A.5/3 - - BYE response
6Prerequisite: A.6/1 - - 100 (Trying)
Table A.11: Supported headers within the BYE response
7
Item
Header
Ref.
1
2
3
4
5
6
7
Call-ID
Content-Length
Cseq
Date
From
To
Via
[26] 20.8
[26] 20.14
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.39
[26] 20.42
Sending
RFC
status
n/a
n/a
n/a
n/a
n/a
n/a
n/a
96
Profile
status
n/a
n/a
n/a
n/a
n/a
n/a
n/a
Ref.
[26] 20.8
[26] 20.14
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.39
[26] 20.42
Table A.12: Supported headers within the BYE response - all remaining status-codes
Item
Header
Ref.
1
2
3
4
5
6
7
8
9
10
10A
10B
10C
10D
10E
10F
10G
10H
11
12
12A
13
14
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
NOTE:
Sending
RFC
status
m
o
o
o
m
m
m
c1
m
o
c5
n/a
c9
Profile
status
m
o
o
o
m
m
m
c1
m
o
c6
n/a
c10
Ref.
Receiving
RFC
status
m
m
m
m
m
m
m
m
m
m
c5
c3
c9
Profile
status
m
m
m
m
m
m
m
m
m
m
c6
c3
c10
Receiving
RFC
status
m
c2
m
Profile
status
m
c2
m
Call-ID
[26] 20.8
[26] 20.8
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
P-Access-Network-Info
[52] 4.4
[52] 4.4
P-Asserted-Identity
[34] 9.1
[34] 9.1
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c8
n/a
[52] 4.6
c8
n/a
[34] 9.2
c3
x
[34] 9.2
n/a
n/a
Privacy
[33] 4.2
c4
n/a
[33] 4.2
c4
c4
Require
[26] 20.32 m
m
[26] 20.32 m
m
Server
[26] 20.35 o
o
[26] 20.35 o
o
Timestamp
[26] 20.38 m
m
[26] 20.38 c2
c2
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 o (note)
o
[26] 20.43 o
o
IF A.4/6 THEN m ELSE n/a - - timestamping of requests.
IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted
identity within trusted networks.
IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-Info header extension and
AS acting as terminating UA or AS acting as third-party call controller.
For a 606 (Not Acceptable Here) response, this status is RECOMMENDED rather than OPTIONAL.
3
5Prerequisite: A.6/6 - - 2xx
6
Item
Header
Sending
RFC
Profile
status
status
Allow
[26] 20.5
o
o
Authentication-Info
[26] 20.6
c1
c1
Supported
[26] 20.37 m
m
IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA.
Ref.
0A
1
4
c1:
c2:
97
Ref.
[26] 20.5
[26] 20.6
[26] 20.37

2Prerequisite: A.6/8 OR A.6/9 OR A.6/10 OR A.6/11 OR A.6/12 OR A.6/35 - - 3xx or 485 (Ambiguous)
3
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Contact
[26] 20.10 o (note)
o
[26] 20.10
Error-Info
[26] 20.18 o
o
[26] 20.18
Supported
[26] 20.37 m
m
[26] 20.37
The strength of this requirement is RECOMMENDED rather than OPTIONAL.
Ref.
0A
0B
1
4
NOTE:
Receiving
RFC
status
m
m
o
m
Profile
status
m
m
o
m
Receiving
RFC
status
m
o
c1
m
m
Profile
status
m
o
c1
m
m
4
6Prerequisite: A.6/14 - - 401 (Unauthorized)
7
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c1
c1
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 m
m
[26] 20.44
IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA.
Ref.
0A
1
2
5
8
c1:
8
10Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - 404,
11413, 480, 486, 500, 503, 600, 603
12
Item
Header
Ref.
0A
1
3
5
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
o
o
o
m
Profile
status
o
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
m
o
o
m
Profile
status
m
o
o
m
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
13
15Prerequisite: A.6/18 - - 405 (Method Not Allowed)
16
Item
Header
Ref.
1
2
5
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
o
m
17
98
Profile
status
m
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37

2Prerequisite: A.6/19 - - 407 (Proxy Authentication Required)
3
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c1
c1
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 o
o
[26] 20.44
Ref.
0A
1
2
5
6
c1:
Receiving
RFC
status
m
o
c1
m
o
Profile
status
m
o
c1
m
o
Receiving
RFC
status
m
m
m
m
o
m
Profile
status
m
m
m
m
o
m
Receiving
RFC
status
m
o
m
m
Profile
status
m
o
m
m
4
6Prerequisite A.6/25 - - 415 (Unsupported Media Type)
7
Item
Header
Ref.
1
2
3
3A
4
7
o.1
Accept
[26] 20.1
Accept-Encoding
[26] 20.2
Accept-Language
[26] 20.3
Allow
[26] 20.5
Error-Info
[26] 20.18
Supported
[26] 20.37
Sending
RFC
status
o.1
o.1
o.1
o
o
m
Profile
status
o.1
o.1
o.1
o
o
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
8
10Prerequisite: A.6/27 - - 420 (Bad Extension)
11
Item
Header
Ref.
0A
1
4
5
Allow
Error-Info
Supported
Unsupported
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Sending
RFC
status
o
o
m
m
12
99
Profile
status
o
o
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40

2Prerequisite: A.6/28 OR A.6/41A - - 421 (Extension Required), 494 (Security Agreement Required)
Table A.20A: Supported headers within the BYE response
3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
Security-Server
[48] 2
x
x
[48] 2
c1
Supported
[26] 20.37 m
m
[26] 20.37 m
Ref.
1
2
3
3
c1:
Profile
status
m
o
c1
m
4
6Prerequisite: A.6/34 - - 484 (Address Incomplete)
7
Item
Header
Ref.
0A
1
4
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
o
o
m
Profile
status
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
Receiving
RFC
status
Profile
status
8
Table A.22: Supported message bodies within the BYE response
10
Item
Header
Ref.
Sending
RFC
status
11
100
Profile
status
Ref.
1A.2.1.4.4
CANCEL method
2Prerequisite A.5/4 - - CANCEL request
[CR481R1]Table A.23: Supported headers within the CANCEL request
3
Item
Header
Ref.
Allow-Events
5
6
8
9
10
11
12
14
16
18
19
20
21
22
23
c1:
c2:
c3:
c4:
c6:
c8:
Sending
RFC
status
c1
Profile
status
c1
Ref.
Receiving
RFC
status
c2
[28]
[28]
87.2.2
87.2.2
Authorization
[26] 20.7
c3
c3
[26] 20.7
c3
Call-ID
[26] 20.8
m
m
[26] 20.8
m
Content-Length
[26] 20.14 m
m
[26] 20.14 m
Cseq
[26] 20.16 m
m
[26] 20.16 m
Date
[26] 20.17 c4
c4
[26] 20.17 m
From
[26] 20.20 m
m
[26] 20.20 m
Max-Forwards
[26] 20.22 om
om
[26] 20.22 n/a
Privacy
[33] 4.2
c6
n/a
[33] 4.2
c6
Record-Route
[26] 20.30 n/a
n/a
[26] 20.30 n/a
Route
[26] 20.34 m
m
[26] 20.34 n/a
Supported
[26] 20.37 o
o
[26] 20.37 m
Timestamp
[26] 20.38 c8
c8
[26] 20.38 m
To
[26] 20.39 m
m
[26] 20.39 m
User-Agent
[26] 20.41 o
[26] 20.41 o
Via
[26] 20.42 m
m
[26] 20.42 m
Profile
status
c2
c3
m
m
m
m
m
n/a
n/a
n/a
n/a
m
m
m
m
4
Table A.24: Supported message bodies within the CANCEL request
6
Item
Header
Ref.
Sending
RFC
status
101
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1Prerequisite A.5/5 - - CANCEL response
Table A.25: Supported headers within the CANCEL response - all status-codes
2
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Call-ID
[26] 20.8
m
m
[26] 20.8
m
m
Content-Length
[26] 20.14 m
m
[26] 20.14 m
m
Cseq
[26] 20.16 m
m
[26] 20.16 m
m
Date
[26] 20.17 c1
c1
[26] 20.17 m
m
From
[26] 20.20 m
m
[26] 20.20 m
m
Privacy
[33] 4.2
c3
n/a
[33] 4.2
c3
n/a
Timestamp
[26] 20.38 m
m
[26] 20.38 c2
c2
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 o (note)
o
[26] 20.43 o
o
Ref.
1
2
3
4
5
5A
6
7
7A
8
9
c1:
c2:
c3:
NOTE:
3
5Prerequisite: A.6/6 - - 200 (OK)
Table A.26: Supported headers within the CANCEL response
6
Item
Header
Ref.
2
4
Record-Route
Supported
[26] 20.30
[26] 20.37
Sending
RFC
status
n/a
m
Profile
status
n/a
m
Ref.
[26] 20.30
[26] 20.37
Receiving
RFC
status
n/a
m
Profile
status
n/a
m
7
10
Item
Header
Ref.
2
5
Error-Info
Supported
[26] 20.18
[26] 20.37
Sending
RFC
status
o
m
Profile
status
o
m
Ref.
[26] 20.18
[26] 20.37
Receiving
RFC
status
o
m
Profile
status
o
m
11
13Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - 404, 413, 480,
14500, 503, 600, 603
15
Item
Header
Ref.
2
4
5
Error-Info
Retry-After
Supported
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
o
o
m
102
Profile
status
o
o
m
Ref.
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
o
o
m
Profile
status
o
o
m
1
4
Item
Header
Ref.
2
4
Error-Info
Supported
[26] 20.18
[26] 20.37
Sending
RFC
status
o
m
Profile
status
o
m
Ref.
[26] 20.18
[26] 20.37
Receiving
RFC
status
o
m
Profile
status
o
m
5
Table A.31: Supported message bodies within the CANCEL response
7
Item
Header
Ref.
Sending
RFC
status
103
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.1.4.5
COMET method
2Void
3A.2.1.4.6
INFO method
4Void
5A.2.1.4.7
INVITE method
6Prerequisite A.5/8 - - INVITE request

7
[CR481R1]Table A.46: Supported headers within the INVITE request
104
Item
Header
Ref.
o
o
o
o
o
c2
c2
Profile
status
Ref.
Profile
status
m
m
m
c1
m
c2
c2
Accept
Accept-Encoding
Accept-Language
Alert-Info
Allow
Allow-Events
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
24A
24B
24C
24D
Authorization
c3
c3
c3
c3
Call-ID
m
m
m
m
Call-Info
o
o
o
o
Contact
m
m
m
m
Content-Disposition
o
o
m
m
Content-Encoding
o
o
m
m
Content-Language
o
o
m
m
Content-Length
m
m
m
m
Content-Type
m
m
m
m
Cseq
m
m
m
m
Date
c4
c4
m
m
Expires
o
o
o
o
From
m
m
m
m
In-Reply-To
o
o
o
o
Max-Forwards
om
om
n/a
n/a
MIME-Version
o
o
m
m
Organization
o
o
o
o
c15
c16
c15
c17
P-Asserted-Identity
n/a
n/a
c7
c7
P-Called-Party-ID
x
x
c13
c13
P-Charging-Functionc20
c21
c20
c21
Addresses
P-Charging-Vector
[52] 4.6
c18
c19
[52] 4.6
c18
c19
P-Media-Authorization
[31] 6.1
n/a
n/a
[31] 6.1
c11
c12
[34] 9.2
c7
c5
[34] 9.2
n/a
n/a
P-Visited-Network-ID
[52] 4.3
x (note 3) x
[52] 4.3
c14
n/a
Priority
[26] 20.26 o
o
[26] 20.26 o
o
Privacy
[33] 4.2
c9
c9
[33] 4.2
c9
c9
Proxy-Authorization
[26] 20.28 c6
c6
[26] 20.28 n/a
n/a
Proxy-Require
[26] 20.29 o (note 2) o (note 2) [26] 20.29 n/a
n/a
Record-Route
[26] 20.30 n/a
n/a
[26] 20.30 m
m
Reply-To
[26] 20.31 o
o
[26] 20.31 o
o
Require
[26] 20.32 c8o
om
[26] 20.32 m
m
Route
[26] 20.34 m
m
[26] 20.34 n/a
n/a
Security-Client
[48] 2.3.1
c22
c22
[48] 2.3.1
n/a
n/a
Security-Verify
[48] 2.3.1
c23
c23
[48] 2.3.1
n/a
n/a
Subject
[26] 20.36 o
o
[26] 20.36 o
o
Supported
[26] 20.37 c8
m
[26] 20.37 m
m
Timestamp
[26] 20.38 c10
c10
[26] 20.38 m
m
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
IF A.4/12 THEN m ELSE n/a - - downloading of alerting information.
IF A.3/1 AND A.4/25 THEN o ELSE n/a - - UE and private extensions to the Session Initiation Protocol (SIP)
for asserted identity within trusted networks.
c6:
105
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.4
[26] 20.5,
[26] 5.1
[28]
78.2.2
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.19
[26] 20.20
[26] 20.21
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Receiving
RFC
status
m
m
m
c1
m
1
2
3
4
5
24E
25
25A
25B
26
26A
27
28
29
31
32
33
33A
33B
34
35
36
37
38
39
c1:
c2:
c3:
c4:
c5:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.4
[26] 20.5,
[26] 5.1
[28]
78.2.2
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.19
[26] 20.20
[26] 20.21
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Sending
RFC
status
o
o
o
o
o (note 1)
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
IF A.4/14 THEN o.1 ELSE o - - Reliability of provisional responses in SIP.
IF A.4/19 THEN m ELSE n/a - - SIP extensions for media authorization.
IF A.3/1 THEN m ELSE n/a - - UE.
IF A.4/32 THEN o ELSE n/a - - the P-Called-Party-ID extension.
IF A.4/33 THEN o ELSE n/a - - the P-Visited-Network-ID extension.
IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension.
IF A.4/37 THEN o ELSE n/a - - security mechanism agreement for the session initiation protocol (note 4).
At least one of these shall be supported.
The strength of this requirement in RFC 3261 [26] is RECOMMENDED, rather than OPTIONAL.
No distinction has been made in these tables between first use of a request on a From/To/Call-ID
combination, and the usage in a subsequent one. Therefore the use of "o" etc. above has been included
from a viewpoint of first usage.
The strength of this requirement in RFC 3455 [52] is SHOULD NOT, rather than MUST NOT.
Support of this header in this method is dependent on the security mechanism and the security architecture
which is implemented. Use of this header in this method is not appropriate to the security mechanism
defined by 3GPP TS 33.203 [19].
Ref.
c7:
c8:
c9:
c10:
c11:
c12:
c13:
c14:
c15:
c16:
c17:
c18:
c19:
c20:
c21:
c22:
c23:
o.1:
NOTE 1:
NOTE 2:
NOTE 3:
NOTE 4:
1
Table A.47: Supported message bodies within the INVITE request
3
Item
Header
Sending
RFC
status
Ref.
Profile
status
Ref.
Receiving
RFC
status
Profile
status
Receiving
RFC
status
m
m
m
m
m
m
m
Profile
status
m
m
m
m
m
m
m
4
5Prerequisite A.5/9 - - INVITE response
Table A.48: Supported headers within the INVITE response
7
Item
Header
Ref.
1
2
3
4
5
6
7
Call-ID
Content-Length
Cseq
Date
From
To
Via
[26] 20.8
[26] 20.14
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.39
[26] 20.42
Sending
RFC
status
n/a
n/a
n/a
n/a
n/a
n/a
n/a
106
Profile
status
n/a
n/a
n/a
n/a
n/a
n/a
n/a
Ref.
[26] 20.8
[26] 20.14
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.39
[26] 20.42
Table A.49: Supported headers within the INVITE response - all remaining status-codes
Item
Header
Ref.
1
1A
2
3
4
5
6
7
8
9
10
11
11A
11B
11C
11D
11E
11F
11G
11H
12
13
13A
14
15
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
NOTE:
Sending
RFC
status
m
o
o
o
o
m
m
m
c1
m
o
o
c5
n/a
c10
Ref.
Receiving
RFC
status
m
o
m
m
m
m
m
m
m
m
m
o
c5
c3
c11
Profile
status
m
o
m
m
m
m
m
m
m
m
m
o
c7
c3
c11
Call-ID
[26] 20.8
[26] 20.8
Call-Info
[26] 20.9
[26] 20.9
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
Organization
[26] 20.25
[26] 20.25
[52] 4.4
[52] 4.4
P-Asserted-Identity
[34] 9.1
[34] 9.1
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c8
c9
[52] 4.6
c8
c9
[34] 9.2
c3
x
[34] 9.2
n/a
n/a
Privacy
[33] 4.2
c4
c4
[33] 4.2
c4
c4
Require
[26] 20.32 m
m
[26] 20.32 m
m
Server
[26] 20.35 o
o
[26] 20.35 o
o
Timestamp
[26] 20.38 m
m
[26] 20.38 c2
c2
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 o (note)
o
[26] 20.43 o
o
Profile
status
m
o
o
o
o
m
m
m
c1
m
o
o
c6
n/a
c11
107

2Prerequisite: A.6/2 OR A.6/3 OR A.6/4 OR A.6/5 - - 1xx
[CR481R1]Table A.50: Supported headers within the INVITE response
3
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Contact
[26] 20.10 o
m
[26] 20.10
[31] 6.1
n/a
n/a
[31] 6.1
Rseq
[27] 7.1
c2
m
[27] 7.1
Supported
[26] 20.37 mo
mo
[26] 20.37
IF A.4/14 THEN o ELSE n/a - - reliability of provisional responses in SIP.
IF A.4/14 THEN m ELSE n/a - - reliability of provisional responses in SIP.
Ref.
1
4
6
9
11
c2:
c3:
c11:
c12:
Receiving
RFC
status
m
o/mm
c11
c3
m
Profile
status
m
m
c12
m
m
4
7
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
status
status
status
1
Accept
[26] 20.1
o
o
[26] 20.1
m
1A
Accept-Encoding
[26] 20.2
o
o
[26] 20.2
m
1B
Accept-Language
[26] 20.3
o
o
[26] 20.3
m
2
Allow
[26] 20.5
o (note 1) o
[26] 20.5
m
4
Authentication-Info
[26] 20.6
c1
c1
[26] 20.6
c2
6
Contact
[26] 20.10 m
m
[26] 20.10 m
8
[31] 6.1
n/a
n/a
[31] 6.1
c11
9
Record-Route
[26] 20.30 m
m
[26] 20.30 m
13
Supported
[26] 20.37 m
m
[26] 20.37 m
c1:
c2:
c11:
c12:
NOTE 1: The strength of this requirement in RFC 3261 [26] is RECOMMENDED, rather than OPTIONAL.
Ref.
Profile
status
m
m
m
m
c2
m
c12
m
m
8
10Prerequisite: A.6/8 OR A.6/9 OR A.6/10 OR A.6/11 OR A.6/12 OR [CR481R1]A.6/354 - - 3xx or 485
11(Ambiguous)
12
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Contact
[26] 20.10 o (note 1) o
[26] 20.10
Error-Info
[26] 20.18 o
o
[26] 20.18
Supported
[26] 20.37 m
m
[26] 20.37
Ref.
1
4
5
10
NOTE:
13
108
Receiving
RFC
status
m
m
o
m
Profile
status
m
m
o
m

3
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c3
c3
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 m
m
[26] 20.44
Ref.
1
4
6
10
13
c1:
c2:
c3:
Receiving
RFC
status
m
o
c3
m
m
Profile
status
m
o
c3
m
m
4
6Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/50 OR A.6/51 - - 404, 413, 480, 486, 600, 603
7
Item
Header
Ref.
1
4
8
10
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
o
o
o
m
Profile
status
o
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
m
o
o
m
Profile
status
m
o
o
m
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
8
11
Item
Header
Ref.
2
5
10
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
o
m
Profile
status
m
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
12
15
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 o
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 o
o
[26] 20.44
Ref.
1
4
6
10
11
c1:
109
Receiving
RFC
status
m
o
o
m
o
Profile
status
m
o
m
o
1
3Prerequisite: A.6/25 - - 415 (Unsupported Media Type)
4
Item
Header
Ref.
1
2
3
3A
6
11
o.1
Accept
[26] 20.1
Accept-Encoding
[26] 20.2
Accept-Language
[26] 20.3
Allow
[26] 20.5
Error-Info
[26] 20.18
Supported
[26] 20.37
Sending
RFC
status
o.1
o.1
o.1
o
o
m
Profile
status
o.1
o.1
o.1
o
o
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
m
m
m
m
o
m
Profile
status
m
m
m
m
o
m
Receiving
RFC
status
m
o
m
m
Profile
status
m
o
m
m
5
8
Item
Header
Ref.
1
4
9
10
Allow
Error-Info
Supported
Unsupported
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Sending
RFC
status
o
o
m
m
Profile
status
o
o
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
9
Table A.58A: Supported headers within the INVITE response
12
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
Security-Server
[48] 2
x
x
[48] 2
c1
Supported
[26] 20.37 m
m
[26] 20.37 m
Ref.
1
2
3
3
c1:
Profile
status
m
o
c1
m
13
16
Item
Header
Ref.
1
4
9
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
o
o
m
110
Profile
status
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
1
3Prerequisite: A.6/42 - - 500 (Server Internal Error)
4
Item
Header
Ref.
1
4
8
10
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
o
o
m
m
Profile
status
o
o
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
m
o
o
m
Profile
status
m
o
o
m
Receiving
RFC
status
m
o
o
m
Profile
status
m
o
m
m
5
7Prerequisite: A.6/45 - - 503 (Service Unavailable)
8
Item
Header
Ref.
1
4
8
10
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
o
o
o
m
Profile
status
o
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
9
Table A.62: Supported message bodies within the INVITE response
11
Item
Header
Ref.
Sending
RFC
status
12
111
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.1.4.7A MESSAGE method

2Prerequisite A.5/9A - - MESSAGE request
3
[CR481R1]Table A.62A: Supported headers within the MESSAGE request
112
Item
Header
Ref.
Profile
status
Profile
status
m
c2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
18A
18B
18C
18D
Authorization
c3
c3
c3
c3
Call-ID
m
m
m
m
Call-Info
o
o
o
o
Content-Disposition
o
o
m
m
Content-Encoding
o
o
m
m
Content-Language
o
o
m
m
Content-Length
m
m
m
m
Content-Type
m
m
m
m
Cseq
m
m
m
m
Date
c4
c4
m
m
Expires
o
o
o
o
From
m
m
m
m
In-Reply-To
o
o
o
o
Max-Forwards
om
om
on/a
on/a
MIME-Version
o
o
m
m
Organization
o
o
o
o
c15
c16
c15
c16
P-Asserted-Identity
n/a
n/a
c11
c11
P-Called-Party-ID
x
x
c13
c13
c21
c20
c21
Addresses
P-Charging-Vector
[52] 4.6
c18
c19
[52] 4.6
c18
c19
[34] 9.2
c11
c7
[34] 9.2
n/a
n/a
[52] 4.3
x (note 1) x
[52] 4.3
c14
n/a
Priority
[26] 20.26 o
o
[26] 20.26 o
o
Privacy
[33] 4.2
c12
c12
[33] 4.2
c12
c12
Proxy-Authorization
[26] 20.28 c5
c5
[26] 20.28 n/a
n/a
Proxy-Require
[26] 20.29 o
n/a
[26] 20.29 n/a
n/a
Record-Route
[26] 20.30 n/a
n/a
[26] 20.30 n/a
n/a
Reply-To
[26] 20.31 o
o
[26] 20.31 o
o
Require
[26] 20.32 c8
o
[26] 20.32 m
m
Route
[26] 20.34 m
m
[26] 20.34 n/a
n/a
Security-Client
[48] 2.3.1
c22
c22
[48] 2.3.1
n/a
n/a
Security-Verify
[48] 2.3.1
c23
c23
[48] 2.3.1
n/a
n/a
Subject
[26] 20.35 o
o
[26] 20.36 o
o
Supported
[26] 20.37 c9
m
[26] 20.37 m
m
Timestamp
[26] 20.38 c10
c10
[26] 20.38 m
m
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
IF A.162/8A THEN m ELSE i - - authentication between UA and proxy.
IF A.4/14 THEN o.1 ELSE o - - Reliable transport.
IF IF A.4/14 THEN o.1 ELSE o - - support of reliable transport.
c12:
c13:
113
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 29.15
[26] 20.16
[26] 20.17
[26] 20.19
[26] 20.20
[26] 20.21
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Receiving
RFC
status
m
c2
Allow
Allow-Events
c8:
c9:
c10:
c11:
o
c1
Ref.
1
2
18E
18F
18G
19
19A
20
21
22
23
24
25
25A
25B
26
27
28
29
30
31
c1:
c2:
c3:
c4:
c5:
c7:
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.19
[26] 20.20
[26] 20.21
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Sending
RFC
status
o
c1
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
c14:
c15:
c16:
c17:
c18:
c19:
c20:
c21:
c22:
c23:
NOTE 1: The strength of this requirement in RFC 3455 [52] is SHOULD NOT, rather than MUST NOT.
NOTE 2: Support of this header in this method is dependent on the security mechanism and the security architecture
Ref.
1
Table A.62B: Supported message bodies within the MESSAGE request
3
Item
Header
Ref.
Sending
RFC
status
114
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1Prerequisite A.5/9B - - MESSAGE response

2
3
[CR481R1]Table A.62C: Supported headers within the MESSAGE response - all remaining
status-codes
Item
Header
1
2
3
Call-ID
Call-Info
Content-Disposition
[26] 20.8
[26] 20.9
[26] 20.11
Sending
RFC
status
m
o
o (note 2)
Content-Encoding
[26] 20.12
o (note 2)
o (note 2)
[26] 20.12
Content-Language
[26] 20.13
o (note 2)
o (note 2)
[26] 20.13
Content-Length
[26] 20.14
Content-Type
[26] 20.15
m
(note 2)
m
(note 2)
m
c1
m
o
o
c6
n/a
c11
[26] 20.14
m
(note 2)
m
(note 2)
m
c1
m
o
o
c5
n/a
c10
Ref.
8
9
10
11
12
12A
12B
12C
Profile
status
m
o
o (note 2)
Ref.
[26] 20.8
[26] 20.9
[26] 20.11
[26] 20.15
Receiving
RFC
status
m
o
m
(note 2)
m
(note 2)
m
(note 2)
m
(note 2)
m
(note 2)
m
m
m
m
o
c5
c3
c10
Profile
status
m
o
m
(note 2)
m
(note 2)
m
(note 2)
m
(note 2)
m
(note 2)
m
m
m
m
o
c7
c3
c11
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
Organization
[26] 20.25
[26] 20.25
[52] 4.4
[52] 4.4
P-Asserted-Identity
[34] 9.1
[34] 9.1
[52] 4.5
Addresses
12D
P-Charging-Vector
[52] 4.6
c8
c9
[52] 4.6
c8
c9
12E
[34] 9.2
c3
x
[34] 9.2
n/a
n/a
12F
Privacy
[33] 4.2
c4
c4
[33] 4.2
c4
c4
12G
Require
[26] 20.32 m
m
[26] 20.32 m
m
13
Server
[26] 20.35 o
o
[26] 20.35 o
o
14
Timestamp
[26] 20.38 m
m
[26] 20.38 c2
c2
15
To
[26] 20.39 m
m
[26] 20.39 m
m
16
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
17
Via
[26] 20.42 m
m
[26] 20.42 m
m
18
Warning
[26] 20.43 o
o
[26] 20.43 o
o
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
NOTE 1: For a 606 (Not Acceptable Here) response, this status is RECOMMENDED rather than OPTIONAL.
NOTE 2: RFC 3428 [50] clause 7 states that all 2xx class responses to a MESSAGE request must not include any
body, therefore for 2xx responses to the MESSAGE request the values on Sending side for "RFC status"
and "Profile status" are "x", the values for Receiving side for "RFC status" and "Profile Status" are "n/a".
RFC 3261 [26] subclause 7.4 states that all responses may contain bodies, therefore for all responses to
the MESSAGE request other than 2xx responses, the values on Sending side for "RFC status" and "Profile
status" are "o", the values for Receiving side for "RFC status" and "Profile Status" are "m".
115
1
[CR481R1]Table A.62D: Supported headers within the MESSAGE response
4
Item
Header
Sending
RFC
Profile
status
status
Allow
[26] 20.5
o
o
Authentication-Info
[26] 20.6
c1
c1
Supported
[26] 20.37 mo
mo
Ref.
1
2
4
c1:
c2:
Ref.
[26] 20.5
[26] 20.6
[26] 20.37
Receiving
RFC
status
m
c2
m
Profile
status
m
c2
m
5
Table A.62E: Supported headers within the MESSAGE response
8
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Contact
[26] 20.10 o (note)
o
[26] 20.10
Error-Info
[26] 20.18 o
o
[26] 20.18
Supported
[26] 20.37 m
m
[26] 20.37
Ref.
1
2
3
5
NOTE:
Receiving
RFC
status
m
m
o
m
Profile
status
m
m
o
m
Receiving
RFC
status
m
o
c1
m
m
Profile
status
m
o
c1
m
m
9
Table A.62F: Supported headers within the MESSAGE response
12
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c1
c1
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 m
m
[26] 20.44
Ref.
1
2
3
5
6
c1:
13
116

3413, 480, 486, 500, 503, 600, 603
Table A.62G: Supported headers within the MESSAGE response
4
Item
Header
Ref.
1
2
4
5
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
o
o
o
m
Profile
status
o
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
m
o
o
m
Profile
status
m
o
o
m
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
Receiving
RFC
status
m
o
c1
m
o
Profile
status
m
o
c1
m
o
Receiving
RFC
status
m
m
m
m
o
m
Profile
status
m
m
m
m
o
m
5
Table A.62H: Supported headers within the MESSAGE response
8
Item
Header
Ref.
1
2
4
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
o
m
Profile
status
m
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
9
Table A.62I: Supported headers within the MESSAGE response
12
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c1
c1
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 o
o
[26] 20.44
Ref.
1
2
3
5
6
c1:
13
Table A.62J: Supported headers within the MESSAGE response
16
Item
Header
Ref.
1
2
3
4
5
7
o.1
Accept
[26] 20.1
Accept-Encoding
[26] 20.2
Accept-Language
[26] 20.3
Allow
[26] 20.5
Error-Info
[26] 20.18
Supported
[26] 20.37
Sending
RFC
status
o.1
o.1
o.1
o
o
m
117
Profile
status
o.1
o.1
o.1
o
o
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
1
Table A.62K: Supported headers within the MESSAGE response
4
Item
Header
Ref.
1
2
4
5
Allow
Error-Info
Supported
Unsupported
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Sending
RFC
status
o
o
m
m
Profile
status
o
o
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Receiving
RFC
status
m
o
m
m
Profile
status
m
o
m
m
5
Table A.62L: Supported headers within the MESSAGE response
8
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
Security-Server
[48] 2
x
x
[48] 2
c1
Supported
[26] 20.37 m
m
[26] 20.37 m
Ref.
1
2
3
4
c1:
Profile
status
m
o
c1
m
9
Table A.62M: Supported headers within the MESSAGE response
12
Item
Header
Ref.
1
2
4
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
o
o
m
Profile
status
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
13
Table A.62N: Supported message bodies within the MESSAGE response
15
Item
Header
Ref.
Sending
RFC
status
16
118
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.1.4.8
NOTIFY method
2Prerequisite A.5/10 - - NOTIFY request

3
[CR481R1]Table A.63: Supported headers within the NOTIFY request
119
Item
Header
Ref.
o
o
o
o
c1
c3
m
m
o
o
o
m
m
m
c4
m
c3
m
m
o
o
o
m
m
m
c4
m
Profile
status
Ref.
Profile
status
m
m
m
m
c2
c3
m
m
m
m
m
m
m
m
m
m
c3
m
m
m
m
m
m
m
m
m
m
Accept
Accept-Encoding
Accept-Language
Allow
Allow-Events
5
6
6A
7
8
9
10
11
12
13
14
Authorization
Call-ID
Contact
Content-Disposition
Content-Encoding
Content-Language
Content-Length
Content-Type
Cseq
Date
Event
15
16
17
17A
17B
17C
From
m
m
m
m
Max-Forwards
om
om
n/a
n/a
MIME-Version
o
o
m
m
c10
c11
c10
c12
P-Asserted-Identity
n/a
n/a
c6
c6
c15
c14
c15
Addresses
P-Charging-Vector
[52] 4.6
c13
n/a
[52] 4.6
c13
n/a
[34] 9.2
c6
x
[34] 9.2
n/a
n/a
Privacy
[33] 4.2
c7
n/a
[33] 4.2
c7
c7
Proxy-Authorization
[26] 20.28 c5
c5
[26] 20.28 n/a
n/a
Proxy-Require
[26] 20.29 o
n/a
[26] 20.29 n/a
n/a
Record-Route
[26] 20.30 n/a
n/a
[26] 20.30 c9
c9
Require
[26] 20.32 o
o
[26] 20.32 m
m
Security-Client
[48] 2.3.1
c16
c16
[48] 2.3.1
n/a
n/a
Security-Verify
[48] 2.3.1
c17
c17
[48] 2.3.1
n/a
n/a
Route
[26] 20.34 m
m
[26] 20.34 n/a
n/a
Subscription-State
[28] 8.2.3
m
m
[28] 8.2.3
m
m
Supported
[26] 20.37 o
o
[26] 20.37 m
m
Timestamp
[26] 20.38 c8
c8
[26] 20.38 m
m
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
IF A.4/15 OR A.4/20 THEN m ELSE n/a - - the REFER method extension or SIP specific event notification
extension.
c7:
c8:
c9:
c10:
c11:
c12:
c13:
120
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[28]
87.2.1
[26] 20.20
[26] 20.22
[26] 20.24
[52] 4.4
[34] 9.1
[52] 4.5
Receiving
RFC
status
m
m
m
m
c2
1
2
3
3A
4
17D
17E
17F
18
19
20
21
22A
22B
22
23
24
25
26
27
28
c1:
c2:
c3:
c4:
c5:
c6:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[28]
87.2.1
[26] 20.20
[26] 20.22
[26] 20.24
[52] 4.4
[34] 9.1
[52] 4.5
Sending
RFC
status
o
o
o
o
c1
c14:
c15:
c16:
c17:
NOTE:

1
Table A.64: Supported message bodies within the NOTIFY request
3
Item
Header
Sending
RFC
Profile
status
status
sipfrag
[37] 2
c1
c1
IF A.4/15 THEN m ELSE o - - the REFER method extension
Ref.
1
c1:
121
Ref.
[37]
Receiving
RFC
status
c1
Profile
status
c1
1Prerequisite A.5/11 - - NOTIFY response
Table A.65: Supported headers within the NOTIFY response - all status-codes
2
Item
Header
Ref.
1
2
3
4
5
6
7
8
9
10
10A
10B
10C
10D
10E
10F
10G
10H
11
12
12A
13
14
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
NOTE:
Sending
RFC
status
m
o
o
o
m
m
m
c1
m
o
c5
n/a
c9
Profile
status
m
o
o
o
m
m
m
c1
m
o
c6
n/a
c10
Ref.
Receiving
RFC
status
m
m
m
m
m
m
m
m
m
m
c5
c3
c9
Profile
status
m
m
m
m
m
m
m
m
m
m
c7
c3
c10
Call-ID
[26] 20.8
[26] 20.8
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
[52] 4.4
[52] 4.4
P-Asserted-Identity
[34] 9.1
[34] 9.1
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c8
n/a
[52] 4.6
c8
n/a
[34] 9.2
c3
x
[34] 9.2
n/a
n/a
Privacy
[33] 4.2
c4
n/a
[33] 4.2
c4
c4
Require
[26] 20.32 m
m
[26] 20.32 m
m
Server
[26] 20.35 o
o
[26] 20.35 o
o
Timestamp
[26] 20.38 m
m
[26] 20.38 c2
c2
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 o (note)
o
[26] 20.43 o
o
122
1
3Prerequisite: A.6/6 and A.6/7 - - 2xx
Table A.66: Supported headers within the NOTIFY response
4
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
m
Authentication-Info
[26] 20.6
c1
c1
[26] 20.6
c2
c2
Contact
[26] 20.10 m
m
[26] 20.10 m
m
Record-Route
[26] 20.30 c3
c3
[26] 20.30 c3
c3
Supported
[26] 20.37 m
m
[26] 20.37 m
m
IF A.4/15 OR A.4/20 THEN m ELSE n/a - - the REFER method extension or SIP specific event notification
extension.
Ref.
0A
1
1A
2
5
c1:
c2:
c3:
5
8
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
m
Contact
[26] 20.10 m (note)
m
[26] 20.10 m
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
o
Supported
[26] 20.37 m
m
[26] 20.37 m
m
The strength of this requirement is RECOMMENDED rather than MANDATORY for a 485 response.
Ref.
0A
1
2
5
NOTE:
9
12
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c1
c1
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 m
m
[26] 20.44
Ref.
0A
1
2
5
8
c1:
13
123
Receiving
RFC
status
m
o
c1
m
m
Profile
status
m
o
c1
m
m

3413, 480, 486, 500, 503, 600, 603
4
Item
Header
Ref.
0A
1
3
5
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
o
o
o
m
Profile
status
o
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
m
o
o
m
Profile
status
m
o
o
m
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
Receiving
RFC
status
m
o
c3
m
o
Profile
status
m
o
c3
m
o
Receiving
RFC
status
m
m
m
m
o
m
Profile
status
m
m
m
m
o
m
5
7Prerequisite: A.6/18 -- 405 (Method Not Allowed)
8
Item
Header
Ref.
1
2
5
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
o
m
Profile
status
m
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
9
12
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c3
c3
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 o
o
[26] 20.44
Ref.
0A
1
2
5
6
c3:
13
16
Item
Header
Ref.
1
2
3
3A
4
7
Accept
Accept-Encoding
Accept-Language
Allow
Error-Info
Supported
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
o.1
o.1
o.1
o
o
m
17
124
Profile
status
o.1
o.1
o.1
o
o
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37

3
Item
Header
Ref.
0A
1
4
5
Allow
Error-Info
Supported
Unsupported
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Sending
RFC
status
o
o
m
m
Profile
status
o
o
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Receiving
RFC
status
m
o
m
m
Profile
status
m
o
m
m
4
Table A.73A: Supported headers within the NOTIFY response
7
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
Security-Server
[48] 2
x
x
[48] 2
c1
Supported
[26] 20.37 m
m
[26] 20.37 m
Ref.
1
2
3
4
c1:
Profile
status
m
o
c1
m
8
11
Item
Header
Ref.
0A
1
4
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
o
o
m
Profile
status
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
Receiving
RFC
status
m
m
Profile
status
m
m
12
14Prerequisite: A.6/39 - - 489 (Bad Event)
15
Item
Header
Ref.
0A
1
Allow
Allow-Events
Error-Info
[26] 20.5
[28]
87.2.2
[26] 20.18
Sending
RFC
status
o
m
o
m
16
125
Profile
status
Ref.
[26] 20.5
[28]
78.2.2
[26] 20.18
Table A.76: Supported message bodies within the NOTIFY response
2
Item
Header
Ref.
Sending
RFC
status
126
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.1.4.9
OPTIONS method
2Prerequisite A.5/12 - - OPTIONS request

3
[CR481R1]Table A.77: Supported headers within the OPTIONS request
127
Item
Header
Ref.
Profile
status
m
m
m
o
c1
Ref.
Profile
status
m
m
m
m
c1
Accept
Accept-Encoding
Accept-Language
Allow
Allow-Events
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
19A
19B
19C
19D
Authorization
c2
c2
c2
c2
Call-ID
m
m
m
m
Call-Info
o
o
o
o
Contact
o
o
o
o
Content-Disposition
o
o
m
m
Content-Encoding
o
o
m
m
Content-Language
o
o
m
m
Content-Length
m
m
m
m
Content-Type
m
m
m
m
Cseq
m
m
m
m
Date
c3
c3
m
m
From
m
m
m
m
Max-Forwards
om
om
n/a
n/a
MIME-Version
o
o
m
m
Organization
o
o
o
o
c11
c12
c11
c13
P-Asserted-Identity
n/a
n/a
c6
c6
P-Called-Party-ID
x
x
c9
c9
c17
c16
c17
Addresses
P-Charging-Vector
[52] 4.6
c14
c15
[52] 4.6
c14
c15
[34] 9.2
c6
c4
[34] 9.2
n/a
n/a
[52] 4.3
x (note 2) x
[52] 4.3
c10
n/a
Privacy
[33] 4.2
c8
c8
[33] 4.2
c8
c8
Proxy-Authorization
[26] 20.28 c5
c5
[26] 20.28 n/a
n/a
Proxy-Require
[26] 20.29 o
o (note 1) [26] 20.29 n/a
n/a
Record-Route
[26] 20.30 n/a
n/a
[26] 20.30 n/a
n/a
Require
[26] 20.32 o
o
[26] 20.32 m
m
Route
[26] 20.34 m
m
[26] 20.34 n/a
n/a
Security-Client
[48] 2.3.1
c18
c18
[48] 2.3.1
n/a
n/a
Security-Verify
[48] 2.3.1
c19
c19
[48] 2.3.1
n/a
n/a
Supported
[26] 20.37 c6
c6
[26] 20.37 m
m
Timestamp
[26] 20.38 c7
c7
[26] 20.38 m
m
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
c5:
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
128
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Receiving
RFC
status
m
m
m
m
c1
1
2
3
3A
4
19E
19F
19G
19H
20
21
22
23
24
24A
24B
25
26
27
28
29
c1:
c2:
c3:
c4:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Sending
RFC
status
m
m
m
o
c1

c14:
c15:
c16:
c17:
c18:
c19:
NOTE 1:
1
Table A.78: Supported message bodies within the OPTIONS request
3
Item
Header
Sending
RFC
status
Ref.
Profile
status
Ref.
Receiving
RFC
status
Profile
status
Receiving
RFC
status
m
m
m
m
m
m
m
Profile
status
m
m
m
m
m
m
m
4
5Prerequisite A.5/13 - - OPTIONS response
Table A.79: Supported headers within the OPTIONS response
7
Item
Header
Ref.
1
2
3
4
5
6
7
Call-ID
Content-Length
Cseq
Date
From
To
Via
[26] 20.8
[26] 20.14
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.39
[26] 20.42
Sending
RFC
status
n/a
n/a
n/a
n/a
n/a
n/a
n/a
129
Profile
status
n/a
n/a
n/a
n/a
n/a
n/a
n/a
Ref.
[26] 20.8
[26] 20.14
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.39
[26] 20.42

2
Table A.80: Supported headers within the OPTIONS response - all remaining status-codes
Item
Header
Ref.
1
1A
2
3
4
5
6
7
8
9
10
11
11A
11B
11C
11D
11E
11F
11G
12
13
13A
14
15
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
NOTE:
Sending
RFC
status
m
o
o
o
o
m
m
m
c1
m
o
o
c5
n/a
c10
Ref.
Receiving
RFC
status
m
o
m
m
m
m
m
m
m
m
m
o
c5
c3
c10
Profile
status
m
o
m
m
m
m
m
m
m
m
m
o
c7
c3
c11
Call-ID
[26] 20.8
[26] 20.8
Call-Info
[26] 20.9
[26] 20.9
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
Organization
[26] 20.25
[26] 20.25
[52] 4.4
[52] 4.4
P-Asserted-Identity
[34] 9.1
[34] 9.1
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c8
c9
[52] 4.6
c8
c9
[34] 9.2
c3
x
[34] 9.2
n/a
n/a
Privacy
[33] 4.2
c4
c4
[33] 4.2
c4
c4
Require
[26] 20.32 m
m
[26] 20.32 m
m
Timestamp
[26] 20.38 m
m
[26] 20.38 c2
c2
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 o (note)
o
[26] 20.43 o
o
Profile
status
m
o
o
o
o
m
m
m
c1
m
o
o
c6
n/a
c11
130

3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
status
status
status
1
Accept
[26] 20.1
m
m
[26] 20.1
m
2
Allow
[26] 20.5
o (note 1) o
[26] 20.5
m
3
Authentication-Info
[26] 20.6
c1
c1
[26] 20.6
c2
5
Contact
[26] 20.10 o
[26] 20.10 o
8
Supported
[26] 20.37 m
m
[26] 20.37 m
c1:
c2:
NOTE 1: The strength of this requirement in RFC 3261 [26] is RECOMMENDED, rather than OPTIONAL.
Ref.
Profile
status
m
m
c2
m
4
7
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Contact
[26] 20.10 o (note)
o
[26] 20.10
Error-Info
[26] 20.18 o
o
[26] 20.18
Supported
[26] 20.37 m
m
[26] 20.37
Ref.
1
3
4
7
NOTE:
Receiving
RFC
status
m
m
o
m
Profile
status
m
m
o
m
8
11
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c1
c1
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 o
[26] 20.44
Ref.
1
3
4
7
10
c1:
12
131
Receiving
RFC
status
m
o
c1
m
o
Profile
status
m
o
c1
m

3413, 480, 486, 500, 503, 600, 603
4
Item
Header
Ref.
1
3
5
7
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
o
o
o
m
Profile
status
o
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
m
o
o
m
Profile
status
m
o
o
m
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
Receiving
RFC
status
m
o
c1
m
o
Profile
status
m
o
c1
m
o
Receiving
RFC
status
m
m
m
m
o
m
Profile
status
m
m
m
m
o
m
5
8
Item
Header
Ref.
2
4
7
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
o
m
Profile
status
m
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
9
12
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c1
c1
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 o
o
[26] 20.44
Ref.
1
3
4
7
8
c1:
13
16
Item
Header
Ref.
1
2
3
4
5
8
o.1
Accept
[26] 20.1
Accept-Encoding
[26] 20.2
Accept-Language
[26] 20.3
Allow
[26] 20.5
Error-Info
[26] 20.18
Supported
[26] 20.37
Sending
RFC
status
o.1
o.1
o.1
o
o
m
132
Profile
status
o.1
o.1
o.1
o
o
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
1
4
Item
Header
Ref.
1
3
6
7
Allow
Error-Info
Supported
Unsupported
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Sending
RFC
status
o
o
m
m
Profile
status
o
o
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Receiving
RFC
status
m
o
m
m
Profile
status
m
o
m
m
5
Table A.88A: Supported headers within the OPTIONS response
8
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
Security-Server
[48] 2
x
x
[48] 2
c1
Supported
[26] 20.37 m
m
[26] 20.37 m
Ref.
1
2
3
4
c1:
Profile
status
m
o
c1
m
9
12
Item
Header
Ref.
1
4
7
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
o
o
m
Profile
status
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
13
Table A.90: Supported message bodies within the OPTIONS response
15
Item
Header
Ref.
Sending
RFC
status
16
133
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.1.3.10 PRACK method

2Prerequisite A.5/14 - - PRACK request
[CR481R1]Table A.91: Supported headers within the PRACK request
3
Item
Header
Ref.
Profile
status
Profile
status
m
m
m
m
c2
5
6
7
8
9
10
11
12
13
14
15
16
16A
16B
Authorization
c3
c3
c3
c3
Call-ID
m
m
m
m
Content-Disposition
o
o
m
m
Content-Encoding
o
o
m
m
Content-Language
o
o
m
m
Content-Length
m
m
m
m
Content-Type
m
m
m
m
Cseq
m
m
m
m
Date
c4
c4
m
m
From
m
m
m
m
Max-Forwards
om
om
n/a
n/a
MIME-Version
o
o
m
m
c9
c10
c9
c11
c14
c13
c14
Addresses
P-Charging-Vector
[52] 4.6
c12
n/a
[52] 4.6
c12
n/a
Privacy
[33] 4.2
c6
n/a
[33] 4.2
c6
n/a
Proxy-Authorization
[26] 20.28 c5
c5
[26] 20.28 n/a
n/a
Proxy-Require
[26] 20.29 o
n/a
[26] 20.29 n/a
n/a
RAck
[27] 7.2
m
m
[27] 7.2
m
m
Record-Route
[26] 20.30 n/a
n/a
[26] 20.30 n/a
n/a
Require
[26] 20.32 o
o
[26] 20.32 m
m
Route
[26] 20.34 m
m
[26] 20.34 n/a
n/a
Supported
[26] 20.37 o
o
[26] 20.37 m
m
Timestamp
[26] 20.38 c8
c8
[26] 20.38 m
m
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
134
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.22
[26] 20.24
[52] 4.4
[52] 4.5
Receiving
RFC
status
m
m
m
m
c2
Accept
Accept-Encoding
Accept-Language
Allow
Allow-Events
c12:
c13:
c14:
o
o
o
o
c1
Ref.
1
2
3
3A
4
16C
16D
17
18
19
20
21
22
23
24
25
26
27
c1:b
c2:
c3:
c4:
c5:
c6:
c8:
c9:
c10:
c11:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.22
[26] 20.24
[52] 4.4
[52] 4.5
Sending
RFC
status
o
o
o
o
c1
Table A.92: Supported message bodies within the PRACK request
2
Item
Header
Sending
RFC
status
Ref.
Profile
status
Ref.
Receiving
RFC
status
Profile
status
Receiving
RFC
status
m
m
m
m
m
m
m
Profile
status
m
m
m
m
m
m
m
3
4Prerequisite A.5/15 - - PRACK response
Table A.93: Supported headers within the PRACK response
6
Item
Header
Ref.
1
2
3
4
5
6
7
Call-ID
Content-Length
Cseq
Date
From
To
Via
[26] 20.8
[26] 20.14
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.39
[26] 20.42
Sending
RFC
status
n/a
n/a
n/a
n/a
n/a
n/a
n/a
135
Profile
status
n/a
n/a
n/a
n/a
n/a
n/a
n/a
Ref.
[26] 20.8
[26] 20.14
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.39
[26] 20.42

2 [CR481R1]Table A.94: Supported headers within the PRACK response - all remaining status3
codes
Item
Header
Ref.
1
2
3
4
5
6
7
8
9
10
10A
10B
10C
10D
10E
10F
11
12
12A
13
14
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
NOTE:
Sending
RFC
status
m
o
o
o
m
m
m
c1
m
o
c3
c7
Profile
status
m
o
o
o
m
m
m
c1
m
o
c4
c8
Ref.
Receiving
RFC
status
m
m
m
m
m
m
m
m
m
m
c3
c7
Profile
status
m
m
m
m
m
m
m
m
m
m
c5
c8
Receiving
RFC
status
m
c2
m
Profile
status
m
c2
m
Call-ID
[26] 20.8
[26] 20.8
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
[52] 4.4
[52] 4.4
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c6
n/a
[52] 4.6
c6
n/a
Privacy
[33] 4.2
c2
n/a
[33] 4.2
c2
n/a
Require
[26] 20.32 mo
mo
[26] 20.32 m
m
Server
[26] 20.35 o
o
[26] 20.35 o
o
Timestamp
[26] 20.38 m
m
[26] 20.38 c2
c2
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 o (note)
o
[26] 20.43 o
o
4
7
Item
Header
Sending
RFC
Profile
status
status
Allow
[26] 20.5
o
o
Authentication-Info
[26] 20.6
c1
c1
Supported
[26] 20.37 m
m
Ref.
0A
0B
3
c1:
c2:
136
Ref.
[26] 20.5
[26] 20.6
[26] 20.37

3
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Contact
[26] 20.10 o (note)
o
[26] 20.10
Error-Info
[26] 20.18 o
o
[26] 20.18
Supported
[26] 20.37 m
m
[26] 20.37
Ref.
0A
1
2
5
NOTE:
Receiving
RFC
status
m
m
o
m
Profile
status
m
m
o
m
Receiving
RFC
status
m
o
c1
m
m
Profile
status
m
o
c1
m
m
4
7
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c1
c1
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 m
m
[26] 20.44
Ref.
0A
1
2
5
8
c1:
8
11413, 480, 486, 500, 503, 600, 603
12
Item
Header
Ref.
0A
1
3
5
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
o
o
o
m
Profile
status
o
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
m
o
o
m
Profile
status
m
o
o
m
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
13
16
Item
Header
Ref.
1
2
5
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
o
m
17
137
Profile
status
m
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37

3
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c1
c1
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 o
o
[26] 20.44
Ref.
0A
1
2
5
6
c1:
Receiving
RFC
status
m
o
c1
m
o
Profile
status
m
o
c1
m
o
Receiving
RFC
status
m
m
m
m
o
m
Profile
status
m
m
m
m
o
m
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
4
7
Item
Header
Ref.
1
2
3
3A
4
7
Accept
Accept-Encoding
Accept-Language
Allow
Error-Info
Supported
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
o.1
o.1
o.1
o
o
m
Profile
status
o.1
o.1
o.1
o
o
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
8
11
Item
Header
Ref.
0A
1
4
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
o
o
m
Profile
status
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
12
Table A.102A: Supported headers within the PRACK response
15
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
Security-Server
[48] 2
x
x
[48] 2
c1
Supported
[26] 20.37 m
m
[26] 20.37 m
Ref.
1
2
3
4
c1:
16
138
Profile
status
m
o
c1
m

3
Item
Header
Ref.
0A
1
4
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
o
o
m
Profile
status
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
4
Table A.104: Supported message bodies within the PRACK response
6
Item
Header
Ref.
Sending
RFC
status
139
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.1.4.11 REFER method

2Prerequisite A.5/16 - - REFER request
3
[CR481R1]Table A.105: Supported headers within the REFER request
140
Item
Header
Ref.
0A
0B
1
1A
2
Accept
Accept-Encoding
Accept-Language
Allow
Allow-Events
3
4
5
5A
5B
5C
6
7
8
9
10
11
12
13
14
14A
14B
14C
14D
Authorization
Call-ID
Contact
Content-Disposition
Content-Encoding
Content-Language
Content-Length
Content-Type
Cseq
Date
Expires
From
Max-Forwards
MIME-Version
Organization
P-Asserted-Identity
P-Called-Party-ID
P-Charging-FunctionAddresses
P-Charging-Vector
Privacy
Proxy-Authorization
Proxy-Require
Record-Route
Refer-To
Require
Route
Security-Client
Security-Verify
Subject
Supported
14E
14F
14G
14H
15
16
17
18
19
20
20A
20B
20C
21
22
23
24
25
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.19
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Sending
RFC
status
o
o
o
o
c1
o
o
o
o
c1
c3
m
m
o
o
o
m
m
m
c4
o
m
om
o
o
c12
n/a
x
c17
c3
m
m
o
o
o
m
m
m
c4
o
m
om
o
o
c13
n/a
x
c18
Profile
status
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.19
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Receiving
RFC
status
m
m
m
m
c2
Profile
status
m
m
m
m
c2
c3
m
m
m
m
m
m
m
m
m
o
m
n/a
m
o
c12
c8
c10
c17
c3
m
m
m
m
m
m
m
m
m
o
m
n/a
m
o
c14
c8
c10
c18
[52] 4.6
c15
c16
[52] 4.6
c15
c16
[34] 9.2
c8
c7
[34] 9.2
n/a
n/a
[52] 4.3
x (note 1) x
[52] 4.3
c11
n/a
[33] 4.2
c9
c9
[33] 4.2
c9
c9
[26] 20.28 c5
c5
[26] 20.28 n/a
n/a
[26] 20.29 o
n/a
[26] 20.29 n/a
n/a
[26] 20.30 n/a
n/a
[26] 20.30 m
m
[36] 3
m
m
[36] 3
m
m
[26] 20.32 o
o
[26] 20.32 m
m
[26] 20.34 m
m
[26] 20.34 n/a
n/a
[48] 2.3.1
c19
c19
[48] 2.3.1
n/a
n/a
[48] 2.3.1
c20
c20
[48] 2.3.1
n/a
n/a
[26] 20.36 o
o
[26] 20.36 o
o
[26]
o
o
[26]
m
m
20.37,
20.37,
[26] 7.1
[26] 7.1
Timestamp
[26] 20.38 c6
c6
[26] 20.38 m
m
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
141
c10:
c11:
c12:
c13:
c14:

c15:
c16:
c17:
c18:
c19:
c20:
1
Table A.106: Supported message bodies within the REFER request
3
Item
Header
Sending
RFC
status
Ref.
Profile
status
Ref.
Receiving
RFC
status
Profile
status
Receiving
RFC
status
m
m
m
m
m
m
m
Profile
status
m
m
m
m
m
m
m
4
5Prerequisite A.5/17 - - REFER response
Table A.107: Supported headers within the REFER response
7
Item
Header
Ref.
1
2
3
4
5
6
7
Call-ID
Content-Length
Cseq
Date
From
To
Via
[26] 20.8
[26] 20.14
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.39
[26] 20.42
Sending
RFC
status
n/a
n/a
n/a
n/a
n/a
n/a
n/a
142
Profile
status
n/a
n/a
n/a
n/a
n/a
n/a
n/a
Ref.
[26] 20.8
[26] 20.14
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.39
[26] 20.42
Table A.108: Supported headers within the REFER response - all remaining status-codes
Item
Header
Ref.
1
1A
2
3
4
5
6
7
8
9
10
10A
10B
10C
10D
10E
10F
10G
10H
11
12
12A
13
14
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
NOTE:
Sending
RFC
status
m
o
o
o
m
m
m
c1
m
o
o
c5
n/a
c10
Profile
status
m
o
o
o
m
m
m
c1
m
o
o
c6
n/a
c11
Ref.
Receiving
RFC
status
m
m
m
m
m
m
m
m
m
m
o
c5
c3
c10
Profile
status
m
m
m
m
m
m
m
m
m
m
o
c7
c3
c11
Call-ID
[26] 20.8
[26] 20.8
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
Organization
[26] 20.25
[26] 20.25
[52] 4.4
[52] 4.4
P-Asserted-Identity
[34] 9.1
[34] 9.1
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c8
c9
[52] 4.6
c8
c9
[34] 9.2
c3
x
[34] 9.2
n/a
n/a
Privacy
[33] 4.2
c4
c4
[33] 4.2
c4
c4
Require
[26] 20.32 m
m
[26] 20.32 m
m
Server
[26] 20.35 o
o
[26] 20.35 o
o
Timestamp
[26] 20.38 m
m
[26] 20.38 c2
c2
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 o (note)
o
[26] 20.43 o
o
143
1
3Prerequisite: A.6/7 - - 202 (Accepted)
4
Item
Header
Sending
RFC
Profile
status
status
Allow
[26] 20.5
o
o
Authentication-Info
[26] 20.6
c1
c1
Contact
[26] 20.10 m
m
Record-Route
[26] 20.30 m
m
Supported
[26] 20.37 m
m
Ref.
1
2
3
5
8
c1:
c2:
Ref.
[26] 20.5
[26] 20.6
[26] 20.10
[26] 20.30
[26] 20.37
Receiving
RFC
status
m
c2
m
m
m
Profile
status
m
c2
m
m
m
5
8
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Contact
[26] 20.10 o (note)
o
[26] 20.10
Error-Info
[26] 20.18 o
o
[26] 20.18
Supported
[26] 20.37 m
m
[26] 20.37
Ref.
1
2
3
7
NOTE:
Receiving
RFC
status
m
m
o
m
Profile
status
m
m
o
m
Receiving
RFC
status
m
o
c1
m
m
Profile
status
m
o
c1
m
m
9
12
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c1
c1
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 m
m
[26] 20.44
Ref.
1
2
4
7
10
c1:
13
144

3413, 480, 486, 500, 503, 600, 603
4
Item
Header
Ref.
1
3
6
8
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
o
o
o
m
Profile
status
o
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
m
o
o
m
Profile
status
m
o
o
m
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
Receiving
RFC
status
m
o
c1
m
o
Profile
status
m
o
c1
m
o
Receiving
RFC
status
m
m
m
m
o
m
Profile
status
m
m
m
m
o
m
5
8
Item
Header
Ref.
2
3
6
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
o
m
Profile
status
m
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
9
12
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c1
c1
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 o
o
[26] 20.44
Ref.
1
2
4
7
8
c1:
13
16
Item
Header
Ref.
1
2
3
3A
4
8
o.1
Accept
[26] 20.1
Accept-Encoding
[26] 20.2
Accept-Language
[26] 20.3
Allow
[26] 20.5
Error-Info
[26] 20.18
Supported
[26] 20.37
Sending
RFC
status
o.1
o.1
o.1
o
o
m
145
Profile
status
o.1
o.1
o.1
o
o
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
1
4
Item
Header
Ref.
1
3
7
8
Allow
Error-Info
Supported
Unsupported
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Sending
RFC
status
o
o
m
m
Profile
status
o
o
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Receiving
RFC
status
m
o
m
m
Profile
status
m
o
m
m
5
Table A.116A: Supported headers within the REFER response
8
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
Security-Server
[48] 2
x
x
[48] 2
c1
Supported
[26] 20.37 m
m
[26] 20.37 m
Ref.
1
2
3
4
c1:
Profile
status
m
o
c1
m
9
12
Item
Header
Ref.
1
3
7
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
o
o
m
Profile
status
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
13
Table A.118: Supported message bodies within the REFER response
15
Item
Header
Ref.
Sending
RFC
status
16
146
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.1.4.12 REGISTER method

2Prerequisite A.5/18 - - REGISTER request
3
[CR481R1]Table A.119: Supported headers within the REGISTER request
147
Item
Header
Ref.
o
o
o
o
c1
c2
n/ao
Profile
status
Ref.
Profile
status
m
m
m
m
c1
c22
Accept
Accept-Encoding
Accept-Language
Allow
Allow-Events
Authorization
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
20A
20B
Call-ID
m
m
m
m
Call-Info
o
o
o
o
Contact
o
o
m
m
Content-Disposition
o
o
m
m
Content-Encoding
o
o
m
m
Content-Language
o
o
m
m
Content-Length
m
m
m
m
Content-Type
m
m
m
m
Cseq
m
m
m
m
Date
c3
c3
m
m
Expires
o
o
m
m
From
m
m
m
m
Max-Forwards
om
om
n/a
n/a
MIME-Version
o
o
m
m
Organization
o
o
o
o
c12
c13
c12
c14
c18
c17
c18
Addresses
P-Charging-Vector
[52] 4.6
c15
c16
[52] 4.6
c15
c16
[52] 4.3
x (note 2) x
[52] 4.3
c10
c11
Path
[35] 4
c4
c5
[35] 4
m
c6
Privacy
[33] 4.2
c9
n/a
[33] 4.2
c9
n/a
Proxy-Authorization
[26] 20.28 c8
c8
[26] 20.28 n/a
n/a
Proxy-Require
[26] 20.29 o
o (note 1) [26] 20.29 n/a
n/a
Require
[26] 20.32 o
o
[26] 20.32 m
m
Route
[26] 20.34 o
n/a
[26] 20.34 n/a
n/a
Security-Client
[48] 2.3.1
c19
c20
[48] 2.3.1
n/a
n/a
Security-Verify
[48] 2.3.1
c20
c20
[48] 2.3.1
c21
n/a
Supported
[26] 20.37 o
o
[26] 20.37 m
m
Timestamp
[26] 20.38 m
m
[26] 20.38 c7
c7
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
IF A.4/8 THEN m ELSE n/a - - authentication between UA and registrar.
IF A.4/24 THEN o ELSE n/a - - session initiation protocol extension header field for registering non-adjacent
contacts.
IF A.4/24 THEN x ELSE n/a - - session initiation protocol extension header field for registering non-adjacent
contacts.
IF (A.3/4) OR A.3/1 THEN m ELSE n/a. - - S-CSCF or UE.
IF A.4/33 THEN m ELSE n/a - - the P-Visited-Network-ID extension.
IF A.4/34 AND (A.3/1 OR A.3/4) THEN m o ELSE n/a - - the P-Access-Network-Info header extension and
UE or S-CSCF (note 4).
c5:
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
148
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7,
[49]
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.19
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[52] 4.5
Receiving
RFC
status
m
m
m
m
c1
1
2
3
3A
4
20C
20D
20E
20F
21
22
23
24
24A
24B
25
26
27
28
29
c1:
c2:
c3:
c4:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7,
[49]
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.19
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[52] 4.5
Sending
RFC
status
o
o
o
o
c1
c14:
c15:
c16:
c17:
c18:
c19:
c20:
c21:
c22:
NOTE 1:
NOTE 2:
NOTE 3:
NOTE 4:
IF A.4/34 AND (A.3/4 OR A.3/7A) THEN m ELSE n/a - - the P-Access-Network-Info header extension and
S-CSCF or AS acting as terminating UA.
IF A.4/36 OR A.3/4 THEN m ELSE n/a - - the P-Charging-Vector header extension (including S-CSCF as
registrar).
IF A.4/35 OR A.3/4 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension (including
S-CSCF as registrar).
IF A.4/37 AND A.4/2 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol
and registrar.
IF A.3/41 THEN m ELSE A4/8n/a - - UES-CSCF.
The strength of this requirement in RFC 3455 [52] is SHOULD NOT, rather than MUST NOT.
which is implemented.
Refere to subclause 5.1.1.2 for information on when the UE sets the P-Access-Network-Info header.
1
Table A.120: Supported message bodies within the REGISTER request
3
Item
Header
Sending
RFC
status
Ref.
Profile
status
Ref.
Receiving
RFC
status
Profile
status
Receiving
RFC
status
m
m
m
m
m
m
m
Profile
status
m
m
m
m
m
m
m
4
5Prerequisite A.5/19 - - REGISTER response
Table A.121: Supported headers within the REGISTER response
7
Item
Header
Ref.
1
2
3
4
5
6
7
Call-ID
Content-Length
Cseq
Date
From
To
Via
[26] 20.8
[26] 20.14
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.39
[26] 20.42
Sending
RFC
status
n/a
n/a
n/a
n/a
n/a
n/a
n/a
149
Profile
status
n/a
n/a
n/a
n/a
n/a
n/a
n/a
Ref.
[26] 20.8
[26] 20.14
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.39
[26] 20.42
Table A.122: Supported headers within the REGISTER response - all status-codes
2
Item
Header
Ref.
1
1A
2
3
4
5
6
7
8
9
10
11
11A
11B
11C
11D
11E
11F
12
13
13A
14
15
c1:
c2:
c3:
c4:
c5:
c6:
c7:
NOTE:
Sending
RFC
status
m
o
o
o
o
m
m
m
c1
m
o
o
c3
c6
Ref.
Receiving
RFC
status
m
o
m
m
m
m
m
m
m
m
m
o
c3
c6
Profile
status
m
o
m
m
m
m
m
m
m
m
m
o
n/a
c7
Call-ID
[26] 20.8
[26] 20.8
Call-Info
[26] 20.9
[26] 20.9
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
Organization
[26] 20.25
[26] 20.25
[52] 4.4
[52] 4.4
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c4
c5
[52] 4.6
c4
c5
Privacy
[33] 4.2
c2
n/a
[33] 4.2
c2
n/a
Require
[26] 20.32 m
m
[26] 20.32 m
m
Server
[26] 20.35 o
o
[26] 20.35 o
o
Timestamp
[26] 20.38 c2
c2
[26] 20.38 m
m
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 o (note)
o
[26] 20.43 o
o
IF A.4/36 OR A.3/4 THEN m ELSE n/a - - the P-Charging-Vector header extension (including S-CSCF as
registrar).
IF A.4/35 OR A.3/4 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension (including
S-CSCF as registrar).
Profile
status
m
o
o
o
o
m
m
m
c1
m
o
o
n/a
c7
150

3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Accept
[26] 20.1
o
[26] 20.1
o
Accept-Encoding
[26] 20.2
o
o
[26] 20.2
m
m
Accept-Language
[26] 20.3
o
o
[26] 20.3
m
m
Allow
[26] 20.5
o
o
[26] 20.5
m
m
Authentication-Info
[26] 20.6
c6
c6
[26] 20.6
c7
c7
Contact
[26] 20.10 o
o
[26] 20.10 m
m
P-Associated-URI
[52] 4.1
c8
c9
[52] 4.1
c10
c11
Path
[35] 4
c3
c3
[35] 4
c4
c4
Service-Route
[38] 6
c5
c5
[38] 6
c5
c5
Supported
[26] 20.37 m
m
[26] 20.37 m
m
IF (A.3/4 AND A.4/2) THEN m ELSE n/a. - - S-CSCF acting as registrar.
IF A.3/4 OR A.3/1THEN m ELSE n/a. - - S-CSCF or UE.
IF A.4/24 THEN m ELSE n/a - - session initiation protocol extension header field for registering nonadjacent contacts.
IF A.4/24 THEN o ELSE n/a - - session initiation protocol extension header field for registering non-adjacent
contacts.
IF A.4/28 THEN m ELSE n/a - - session initiation protocol extension header field for service route discovery
during registration.
IF A.4/8 THEN o ELSE n/a - - authentication between UA and registrar.
IF A.4/8 THEN m ELSE n/a - - authentication between UA and registrar.
IF A.4/2 AND A.4/31 THEN m ELSE n/a - - P-Assocated-URI header extension and registrar.
IF A.3/1 AND A.4/31 THEN m ELSE n/a - - P-Assocated-URI header extension and S-CSCF.
IF A.4/31 THEN o ELSE n/a - - P-Assocated-URI header extension.
IF A.4/31 AND A.3/1 THEN m ELSE n/a - - P-Assocated-URI header extension and UE.
Ref.
1
1A
1B
2
3
5
5A
6
8
9
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
4
7
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Contact
[26] 20.10 o (note)
o
[26] 20.10
Error-Info
[26] 20.18 o
o
[26] 20.18
Supported
[26] 20.37 m
m
[26] 20.37
Ref.
1
3
4
8
NOTE:
151
Receiving
RFC
status
m
m
o
m
Profile
status
m
m
o
m

3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
Proxy-Authenticate
[26] 20.27 c1
x
[26] 20.27 c1
Security-Server
[48] 2
x
x
[48] 2
n/a
Supported
[26] 20.37 m
m
[26] 20.37 m
WWW-Authenticate
[26] 20.44 m
m
[26] 20.44 m
Ref.
1
3
4
6
7
10
c1:
c2:
Profile
status
m
o
x
c2
m
m
4
7413, 480, 486, 500, 503, 600, 603
8
Item
Header
Ref.
1
3
6
8
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
o
o
o
m
Profile
status
o
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
m
o
o
m
Profile
status
m
o
o
m
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
9
12
Item
Header
Ref.
2
4
8
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
o
m
13
152
Profile
status
m
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37

3
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c1
x
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 o
o
[26] 20.44
Ref.
1
3
5
8
9
c1:
Receiving
RFC
status
m
o
c1
m
o
Profile
status
m
o
x
m
o
Receiving
RFC
status
m
m
m
m
o
m
Profile
status
m
m
m
m
o
m
Receiving
RFC
status
m
o
m
m
Profile
status
m
o
m
m
4
7
Item
Header
Ref.
1
2
3
4
5
9
o.1
Accept
[26] 20.1
Accept-Encoding
[26] 20.2
Accept-Language
[26] 20.3
Allow
[26] 20.5
Error-Info
[26] 20.18
Supported
[26] 20.37
Sending
RFC
status
o.1
o.1
o.1
o
o
m
Profile
status
o.1
o.1
o.1
o
o
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
8
11
Item
Header
Ref.
1
3
7
8
Allow
Error-Info
Supported
Unsupported
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Sending
RFC
status
o
o
m
m
12
153
Profile
status
o
o
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40

Table A.130A: Supported headers within the REGISTER response
3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
o
Security-Server
[48] 2
c2
c2
[48] 2
c1
c1
Supported
[26] 20.37 m
m
[26] 20.37 m
m
IF A.4/37 AND A.4/2 THEN m ELSE n/a - - security mechanism agreement for the session initiation
protocol and registrar.
Ref.
1
2
3
4
c1:
c2:
4
6Prerequisite: A.6/29 - - 423 (Interval Too Brief)
7
Item
Header
Ref.
1
3
5
8
Allow
Error-Info
Min-Expires
Supported
[26] 20.5
[26] 20.18
[26] 20.23
[26] 20.37
Sending
RFC
status
o
o
m
m
Profile
status
o
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.23
[26] 20.37
Receiving
RFC
status
m
o
m
m
Profile
status
m
m
m
8
11
Item
Header
Ref.
1
3
7
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
o
o
m
Profile
status
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
12
Table A.133: Supported message bodies within the REGISTER response
14
Item
Header
Ref.
Sending
RFC
status
15
154
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.1.4.13 SUBSCRIBE method

2Prerequisite A.5/20 - - SUBSCRIBE request
3
[CR481R1]Table A.134: Supported headers within the SUBSCRIBE request
155
Item
Header
Ref.
o
o
o
o
c1
c3
m
m
o
o
o
m
m
m
c4
m
c3
m
m
o
o
o
m
m
m
c4
m
Profile
status
Ref.
Profile
status
m
m
m
m
c2
c3
m
m
m
m
m
m
m
m
m
m
c3
m
m
m
m
m
m
m
m
m
m
Accept
Accept-Encoding
Accept-Language
Allow
Allow-Events
5
6
6A
7
8
9
10
11
12
13
14
Authorization
Call-ID
Contact
Content-Disposition
Content-Encoding
Content-Language
Content-Length
Content-Type
Cseq
Date
Event
15
16
17
18
18A
18B
18C
18D
18E
Expires
o (note 1) o (note 1)
m
m
From
m
m
m
m
Max-Forwards
om
om
n/a
n/a
MIME-Version
o
o
m
m
Organization
o
o
o
o
c12
c13
c12
c14
P-Asserted-Identity
n/a
n/a
c6
c6
P-Called-Party-ID
x
x
c10
c10
c18
c17
c18
Addresses
P-Charging-Vector
[52] 4.6
c15
c16
[52] 4.6
c15
c16
[34] 9.2
c6
c7
[34] 9.2
n/a
n/a
[52] 4.3
x (note 2) x
[52] 4.3
c11
n/a
Privacy
[33] 4.2
c9
c9
[33] 4.2
c9
c9
Proxy-Authorization
[26] 20.28 c5
c5
[26] 20.28 n/a
n/a
Proxy-Require
[26] 20.29 o
n/a
[26] 20.29 n/a
n/a
Record-Route
[26] 20.30 n/a
n/a
[26] 20.30 m
m
Require
[26] 20.32 o
o
[26] 20.32 m
m
Route
[26] 20.34 m
m
[26] 20.34 n/a
n/a
Security-Client
[48] 2.3.1
c19
c19
[48] 2.3.1
n/a
n/a
Security-Verify
[48] 2.3.1
c20
c20
[48] 2.3.1
n/a
n/a
Supported
[26] 20.37 o
o
[26] 20.37 m
m
Timestamp
[26] 20.38 c8
c8
[26] 20.38 m
m
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
c7:
c8:
c9:
c10:
c11:
156
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[28]
78.2.1
[26] 20.19
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Receiving
RFC
status
m
m
m
m
c2
1
2
3
3A
4
18F
18G
18H
18I
19
20
21
22
23
23A
23B
24
25
26
27
28
c1:
c2:
c3:
c4:
c5:
c6:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[28]
78.2.1
[26] 20.19
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Sending
RFC
status
o
o
o
o
c1
c12:
c13:
c14:

c15:
c16:
c17:
c18:
c19:
c20:
NOTE 1: The strength of this requirement is RECOMMENDED rather than OPTIONAL.
1
Table A.135: Supported message bodies within the SUBSCRIBE request
3
Item
Header
Ref.
Sending
RFC
status
157
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1Prerequisite A.5/21 - - SUBSCRIBE response
Table A.136: Supported headers within the SUBSCRIBE response - all status-codes
2
Item
Header
Ref.
1
2
3
4
5
6
7
8
9
10
10A
10B
10C
10D
10E
10F
10G
10H
10I
11
12
12A
13
14
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
NOTE:
Sending
RFC
status
m
o
o
o
m
m
m
c1
m
o
o
c5
n/a
c10
Profile
status
m
o
o
o
m
m
m
c1
m
o
o
c6
n/a
c11
Ref.
Receiving
RFC
status
m
m
m
m
m
m
m
m
m
m
o
c5
c3
c10
Profile
status
m
m
m
m
m
m
m
m
m
m
o
c7
c3
c11
Call-ID
[26] 20.8
[26] 20.8
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
Organization
[26] 20.25
[26] 20.25
[52] 4.4
[52] 4.4
P-Asserted-Identity
[34] 9.1
[34] 9.1
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c8
c9
[52] 4.6
c8
c9
[34] 9.2
c3
x
[34] 9.2
n/a
n/a
Privacy
[33] 4.2
c4
c4
[33] 4.2
c4
c4
Require
[26] 20.32 m
m
[26] 20.32 m
m
Server
[26] 20.35 o
o
[26] 20.35 o
o
Timestamp
[26] 20.38 m
m
[26] 20.38 c2
c2
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 o (note)
o
[26] 20.43 o
o
158
1
3Prerequisite: A.6/6 and A.6/7 - - 2xx
Table A.137: Supported headers within the SUBSCRIBE response
4
Item
Header
Sending
RFC
Profile
status
status
Allow
[26] 20.5
o
o
Authentication-Info
[26] 20.6
c1
c1
Contact
[26] 20.10 m
m
Expires
[26] 20.19 m
m
Require
[26] 20.32 m
m
Supported
[26] 20.37 m
m
Ref.
0A
1
1A
2
4
6
c1:
c2:
Ref.
[26] 20.5
[26] 20.6
[26] 20.10
[26] 20.19
[26] 20.32
[26] 20.37
Receiving
RFC
status
m
c2
m
m
m
m
Profile
status
m
c2
m
m
m
m
5
8
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
m
Contact
[26] 20.10 m (note)
m
[26] 20.10 m
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
o
Supported
[26] 20.37 m
m
[26] 20.37 m
m
The strength of this requirement is RECOMMENDED rather than MANDATORY for a 485 response.
Ref.
0A
1
2
5
NOTE:
9
12
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c1
c1
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 m
m
[26] 20.44
Ref.
0A
1
2
5
8
c1:
13
159
Receiving
RFC
status
m
o
c1
m
m
Profile
status
m
o
c1
m
m

2Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/50 OR A.6/51 - - 404, 413, 480,
3486, 500, 600, 603
4
Item
Header
Ref.
0A
1
3
5
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
o
o
o
m
Profile
status
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
m
o
o
m
Profile
status
m
o
m
5
8
Item
Header
Ref.
1
2
5
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
o
m
Profile
status
m
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
Receiving
RFC
status
m
o
c1
m
o
Profile
status
m
o
c1
m
o
Receiving
RFC
status
m
m
m
m
o
m
Profile
status
m
m
m
m
o
m
9
12
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c1
c1
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 o
o
[26] 20.44
Ref.
0A
1
2
5
6
c1:
13
16
Item
Header
Ref.
1
2
3
4
6
7
o.1
Accept
[26] 20.1
Accept-Encoding
[26] 20.2
Accept-Language
[26] 20.3
Allow
[26] 20.5
Server
[26] 20.35
Supported
[26] 20.37
Sending
RFC
status
o.1
o.1
o.1
o
o
m
160
Profile
status
o.1
o.1
o.1
o
o
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.35
[26] 20.37
1
4
Item
Header
Ref.
0A
1
4
5
Allow
Error-Info
Supported
Unsupported
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Sending
RFC
status
o
o
m
m
Profile
status
o
o
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Receiving
RFC
status
m
o
m
m
Profile
status
m
o
m
m
5
Table A.144A: Supported headers within the SUBSCRIBE response
8
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
Security-Server
[48] 2
x
x
[48] 2
c1
Supported
[26] 20.37 m
m
[26] 20.37 m
Ref.
1
2
3
4
c1:
Profile
status
m
o
c1
m
9
12
Item
Header
Ref.
0A
1
2
5
Allow
Error-Info
Min-Expires
Supported
[26] 20.5
[26] 20.18
[26] 20.23
[26] 20.37
Sending
RFC
status
o
o
m
m
Profile
status
o
o
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.23
[26] 20.37
Receiving
RFC
status
m
o
m
m
Profile
status
m
o
m
m
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
13
16
Item
Header
Ref.
0A
1
4
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
o
o
m
17
161
Profile
status
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37

3
Item
Header
Ref.
0A
1
Allow
Allow-Events
Error-Info
[26] 20.5
[28]
87.2.2
[26] 20.18
Sending
RFC
status
o
m
o
m
Profile
status
Ref.
[26] 20.5
[28]
87.2.2
[26] 20.18
Receiving
RFC
status
m
m
Profile
status
m
m
Receiving
RFC
status
m
o
o
m
Profile
status
m
o
m
m
4
7
Item
Header
Ref.
0A
1
3
5
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
o
o
o
m
Profile
status
o
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
8
Table A.149: Supported message bodies within the SUBSCRIBE response
10
Item
Header
Ref.
Sending
RFC
status
11
162
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.1.4.14 UPDATE method

2Prerequisite A.5/22 - - UPDATE request
3
[CR481R1]Table A.150: Supported headers within the UPDATE request
163
Item
Header
Ref.
Profile
status
Profile
status
m
m
m
m
c3
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
20A
20B
Authorization
c4
c4
c4
c4
Call-ID
m
m
m
m
Call-Info
o
o
o
o
Contact
m
m
m
m
Content-Disposition
o
o
m
m
Content-Encoding
o
o
m
m
Content-Language
o
o
m
m
Content-Length
m
m
m
m
Content-Type
m
m
m
m
Cseq
m
m
m
m
Date
c5
c5
m
m
From
m
m
m
m
Max-Forwards
om
om
n/a
n/a
MIME-Version
o
o
m
m
Organization
o
o
o
o
c11
c12
c11
c13
c17
c16
c17
Addresses
P-Charging-Vector
[52] 4.6
c14
c15
[52] 4.6
c14
c15
Privacy
[33] 4.2
c6
n/a
[33] 4.2
c6
n/a
Proxy-Authorization
[26] 20.28 c10
c10
[26] 20.28 n/a
n/a
Proxy-Require
[26] 20.29 o
n/a
[26] 20.29 n/a
n/a
Record-Route
[26] 20.30 n/a
n/a
[26] 20.30 n/a
n/a
Require
[26] 20.32 o
o
[26] 20.32 m
m
Route
[26] 20.34 m
m
[26] 20.34 n/a
n/a
Security-Client
[48] 2.3.1
c18
c18
[48] 2.3.1
n/a
n/a
Security-Verify
[48] 2.3.1
c19
c19
[48] 2.3.1
n/a
n/a
Supported
[26] 20.37 o
o
[26] 20.37 m
m
Timestamp
[26] 20.38 c9
c9
[26] 20.38 m
m
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
164
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[52] 4.5
Receiving
RFC
status
m
m
m
m
c3
Accept
Accept-Encoding
Accept-Language
Allow
Allow-Events
c14:
c15:
c16:
c17:
c18:
c19:
NOTE:
o
o
o
o
c2
Ref.
1
2
3
4
5
20C
20D
21
22
23
24
25
25A
25B
26
27
28
29
30
c2:
c3:
c4:
c5:
c6:
c9:
c10:
c11:
c12:
c13:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[52] 4.5
Sending
RFC
status
o
o
o
o
c2
1
Table A.151: Supported message bodies within the UPDATE request
3
Item
Header
Ref.
Sending
RFC
status
Profile
status
Ref.
Receiving
RFC
status
Profile
status
4
5Prerequisite A.5/23 - - UPDATE response
6
Table A.152: Supported headers within the UPDATE response - all remaining status-codes
Item
Header
Ref.
1
1A
2
3
4
5
6
7
8
9
10
10A
10B
10C
10D
10E
10F
10G
11
12
12A
13
14
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
NOTE:
Sending
RFC
status
m
o
o
o
o
m
m
m
c1
m
o
o
c4
c9
Profile
status
m
o
o
o
o
m
m
m
c1
m
o
o
c5
c10
Ref.
Receiving
RFC
status
m
o
m
m
m
m
m
m
m
m
m
o
c4
c9
Profile
status
m
o
m
m
m
m
m
m
m
m
m
o
c6
c10
Call-ID
[26] 20.8
[26] 20.8
Call-Info
[26] 20.9
[26] 20.9
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
Organization
[26] 20.25
[26] 20.25
[52] 4.4
[52] 4.4
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c7
c8
[52] 4.6
c7
c8
Privacy
[33] 4.2
c3
n/a
[33] 4.2
c3
n/a
Require
[26] 20.31 m
m
[26] 20.31 m
m
Server
[26] 20.35 o
o
[26] 20.35 o
o
Timestamp
[26] 20.38 m
m
[26] 20.38 c2
c2
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
o
[26] 20.41 o
o
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 o (note)
o
[26] 20.43 o
o
165
1
Table A.153: Supported headers within the UPDATE response
4
Item
Header
Sending
RFC
Profile
status
status
Accept
[26] 20.1
o
o
Accept-Encoding
[26] 20.2
o
o
Accept-Language
[26] 20.3
o
o
Allow
[26] 20.5
o
o
Authentication-Info
[26] 20.6
c1
c1
Contact
[26] 20.10 m
m
Supported
[26] 20.37 m
m
Ref.
0A
0B
0C
1
2
3
6
c1:
c2:
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.6
[26] 20.10
[26] 20.37
Receiving
RFC
status
m
m
m
m
c2
m
m
Profile
status
m
m
m
m
c2
m
m
Receiving
RFC
status
m
o
o
m
Profile
status
m
o
o
m
5
7Prerequisite: A.6/8 OR A.6/9 OR A.6/10 OR A.6/11 OR A.6/12 - - 3xx
8
Item
Header
Ref.
1
2
3
7
Allow
Contact
Error-Info
Supported
[26] 20.5
[26] 20.10
[26] 20.18
[26] 20.37
Sending
RFC
status
o
o
o
m
Profile
status
o
o
o
m
Ref.
[26] 20.5
[26] 20.10
[26] 20.18
[26] 20.37
9
Table A.154A: Supported headers within the UPDATE response
12
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 o
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 m
m
[26] 20.44
Ref.
1
2
3
5
6
c1:
13
166
Receiving
RFC
status
m
o
o
m
m
Profile
status
m
o
m
m

3413, 480, 486, 500, 503, 600, 603
4
Item
Header
Ref.
1
2
5
7
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
o
o
o
m
Profile
status
o
o
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
m
o
o
m
Profile
status
m
o
o
m
Receiving
RFC
status
m
o
m
Profile
status
m
o
m
Receiving
RFC
status
m
o
c1
m
o
Profile
status
m
o
c1
m
o
Receiving
RFC
status
m
m
m
m
o
m
Profile
status
m
m
m
m
o
m
5
8
Item
Header
Ref.
1
3
7
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
o
m
Profile
status
m
o
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
9
12
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Error-Info
[26] 20.18 o
o
[26] 20.18
Proxy-Authenticate
[26] 20.27 c1
c1
[26] 20.27
Supported
[26] 20.37 m
m
[26] 20.37
WWW-Authenticate
[26] 20.44 o
o
[26] 20.44
Ref.
1
2
4
7
8
c1:
13
16
Item
Header
Ref.
1
2
3
4
6
10
o.1
Accept
[26] 20.1
Accept-Encoding
[26] 20.2
Accept-Language
[26] 20.3
Allow
[26] 20.5
Error-Info
[26] 20.18
Supported
[26] 20.37
Sending
RFC
status
o.1
o.1
o.1
o
o
m
167
Profile
status
o.1
o.1
o.1
o
o
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
1
4
Item
Header
Ref.
1
2
6
7
Allow
Error-Info
Supported
Unsupported
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Sending
RFC
status
o
o
m
m
Profile
status
o
o
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Receiving
RFC
status
m
o
m
m
Profile
status
m
o
m
m
5
8
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
Security-Server
[48] 2
x
x
[48] 2
c1
Supported
[26] 20.37 m
m
[26] 20.37 m
Ref.
1
2
3
4
c1:
Profile
status
m
o
c1
m
9
11Prerequisite: A.6/35 - - 485 (Ambiguous)
12
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
o
o
[26] 20.5
Contact
[26] 20.10 o (note)
o
[26] 20.10
Error-Info
[26] 20.18 o
o
[26] 20.18
Supported
[26] 20.37 m
m
[26] 20.37
Ref.
1
2
3
7
NOTE:
Receiving
RFC
status
m
m
o
m
Profile
status
m
m
o
m
13
Table A.161: Supported message bodies within the UPDATE response
15
Item
Header
Ref.
Sending
RFC
status
16
168
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.2
Proxy role
2A.2.2.1 Introduction
3This subclause contains the ICS proforma tables related to the proxy role. They need to be completed only for
4proxy implementations.
5Prerequisite: A.2/2 - - proxy role
169

2
170
Item
3
4
5
6
7
8
8A
9
10
11
12
13
14
15
16
17
18
19
19A
19B
19C
19D
19E
20

initiate session release?
stateless proxy behaviour?
stateful proxy behaviour?
forking of initial requests?
support of TLS connections on the
upstream side?
support of TLS connections on the
downstream side?
authentication between UA and proxy?
insertion of date in requests and
responses?
suppression or modification of alerting
information data?
reading the contents of the Require
header before proxying the request or
response?
adding or modifying the contents of the
Require header before proxying the
REGISTER request or response
adding or modifying the contents of the
Require header before proxying the
request or response for methods other
than REGISTER?
being able to insert itself in the
subsequent transactions in a dialog
(record-routing)?
the requirement to be able to use
separate URIs in the upstream direction
and downstream direction when record
routeing?
reading the contents of the Supported
header before proxying the response?
reading the contents of the
Unsupported header before proxying
the 420 response to a REGISTER?
Unsupported header before proxying
the 420 response to a method other
than REGISTER?
the inclusion of the Error-Info header in
3xx - 6xx responses?
Organization header before proxying
the request or response?
adding or concatenating the
Organization header before proxying
the request or response?
reading the contents of the Call-Info
response?
adding or concatenating the Call-Info
response?
delete Contact headers from 3xx
responses prior to relaying the
response?
Extensions
the SIP INFO method?
171
Reference
RFC status
Profile status
[26] 16
[26] 16.11
[26] 16.2
[26] 16.1
[26] 16.7
x
o.1
o.1
c1
o
c27
c28
c29
x
n/a
[26] 16.7
n/a
[26] 20.28,
22.3
[26] 20.17
[26] 20.4
[26] 20.32
[26] 20.32
[26] 20.32
[26] 16.6
c2
[26] 16.7
c3
c3
[26] 20.37
[26] 20.40
[26] 20.40
[26] 20.18
[26] 20.25
[26] 20.25
[26] 20.25
[26] 20.25
[26] 20
[25]
21
22
23
24
26
27
28
29
30
30A
30B
31
31A
31B
31C
31D
31E
31F
31G
32
33
34
35
36
37
38
reliability of provisional responses in

SIP?
the REFER method?
integration of resource management
and SIP?
the SIP UPDATE method?
SIP extensions for media authorization?
SIP specific event notification
the use of NOTIFY to establish a dialog
Session Initiation Protocol Extension
Header Field for Registering NonAdjacent Contacts
extensions to the Session Initiation
Protocol (SIP) for asserted identity
within trusted networks
act as first entity within the trust domain
for asserted identity
act as subsequent entity within trust
network that can route outside the trust
network
a privacy mechanism for the Session
Initiation Protocol (SIP)
request of privacy by the inclusion of a
Privacy header
application of privacy based on the
received Privacy header
passing on of the Privacy header
transparently
"header" such that those headers which
cannot be completely expunged of
identifying information without the
assistance of intermediaries are
obscured?
"session" such that anonymization for
the session(s) initiated by this message
occurs?
application of the privacy option "user"
such that user level privacy functions
are provided by the network?
application of the privacy option "id"
such that privacy of the network
asserted identity is provided by the
network?
Session Initiation Protocol Extension
Header Field for Service Route
Discovery During Registration
a messaging mechanism for the
Session Initiation Protocol (SIP)
Compressing the Session Initiation
Protocol
private header extensions to the
session initiation protocol for the 3rdGeneration Partnership Project
(3GPP)?
the P-Associated-URI header
extension?
the P-Called-Party-ID header
extension?
the P-Visited-Network-ID header
172
[27]
[36]
[30]
o
o
o
i
[29]
[31]
[28]
[28] 4.2
[35]
c4
o
o
o
o
i
c7
i
n/a
c6
[34]
[34]
c5
c8
[34]
c5
c9
[33]
[33]
n/a
[33]
c10
[33]
c10
[33] 5.1
[33] 5.2
n/a
n/a
[33] 5.3
n/a
n/a
[34] 7
c11
c12
[38]
c30
[50]
[55]
c7
[52]
[52] 4.1
c14
c15
[52] 4.2
c14
c16
[52] 4.3
c14
c17
extension?
173
39
41
42
43
44
44A
45
46
47
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
c14:
c15:
c16:
c17:
c18:
c19:
c20:
c21:
c22:
reading, or deleting the P-Visited[52] 4.3

c18
n/a
Network-ID header before proxying the
request or response?
the P-Access-Network-Info header
[52] 4.4
c14
c19
extension?
act as first entity within the trust domain [52] 4.4
c20
c21
for access network information?
act as subsequent entity within trust
[52] 4.4
c20
c22
network for access network information
that can route outside the trust
network?
the P-Charging-Function-Addresses
[52] 4.5
c14
m
header extension?
adding, deleting or reading the P[52] 4.6
c25
c26
Charging-Function-Addresses header
before proxying the request or
response?
the P-Charging-Vector header
[52] 4.6
c14
m
extension?
adding, deleting, reading or modifying
[52] 4.6
c23
c24
the P-Charging-Vector header before
proxying the request or response?
security mechanism agreement for the
[48]
o
c7
session initiation protocol?
IF A.162/5 THEN o ELSE n/a - - stateful proxy behaviour.
IF A.3/2 OR A.3/3A OR A.3/4 THEN m ELSE o - - P-CSCF, I-CSCF(THIG) or S-CSCF.
IF (A.162/7 AND NOT A.162/8) OR (NOT A.162/7 AND A.162/8) THEN m ELSE IF
A.162/14 THEN o ELSE n/a - - TLS interworking with non-TLS else proxy insertion.
IF A.162/23 THEN m ELSE o - - integration of resource management and SIP.
IF A.162/30 THEN o ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for
asserted identity within trusted networks.
IF A.3/2 OR A.3/3A THEN m ELSE n/a - - P-CSCF or I-CSCF (THIG).
IF A.3/2 THEN m ELSE n/a - - P-CSCF.
IF A.3/2 AND A.162/30 THEN m ELSE n/a - - P-CSCF and extensions to the Session
Initiation Protocol (SIP) for asserted identity within trusted networks.
IF A.162/31 THEN o.2 ELSE n/a - - a privacy mechanism for the Session Initiation
Protocol (SIP).
IF A.162/31B THEN o ELSE x - - application of privacy based on the received Privacy
header.
IF A.162/35 THEN o.3 ELSE n/a - - private header extensions to the session initiation
protocol for the 3rd-Generation Partnership Project (3GPP).
IF A.162/35 AND (A.3/2 OR A.3/3) THEN m THEN o ELSE n/a - - private header
extensions to the session initiation protocol for the 3rd-Generation Partnership Project
(3GPP) and P-CSCF or I-CSCF.
IF A.162/35 AND (A.3/2 OR A.3/3 OR A.3/4) THEN m ELSE n/a - - private header
extensions to the session initiation protocol for the 3rd-Generation Partnership Project
(3GPP) and P-CSCF or I-CSCF or S-CSCF.
IF A.162/35 AND (A.3/2 OR A.3/3) THEN m ELSE n/a - - private header extensions to
the session initiation protocol for the 3rd-Generation Partnership Project (3GPP) and
P-CSCF or I-CSCF.
IF A.162/38 THEN o ELSE n/a - - the P-Visited-Network-ID header extension.
IF A.162/35 AND (A.3/2 OR A.3.3 OR A.3/4 OR A.3/7 THEN m ELSE n/a - - private
header extensions to the session initiation protocol for the 3rd-Generation Partnership
Project (3GPP) and P-CSCF, I-CSCF, S-CSCF, AS acting as a proxy.
IF A.162/41 AND A.3/2 THEN m ELSE n/a - - the P-Access-Network-Info header
extension and P-CSCF.
IF A.162/41 AND A.3/4 THEN m ELSE n/a - - the P-Access-Network-Info header
extension and S-CSCF.
174
c23:
c24:
c25:
c26:
c27:
c28:
c29:
c30:
o.1:
o.2:
o.3:
NOTE:

IF A.162/44 THEN o ELSE n/a - - the P-Charging-Function-Addresses header
extension.
IF A.162/44 THEN m ELSE n/a - - the P-Charging-Function Addresses header
extension.
IF A.3/2 OR A.3/4 THEN m ELSE x - - P-CSCF or S-CSCF.
IF A.3/2 OR A.3/4 OR A.3/6 then m ELSE o - - P-CSCF or S-CSCF of MGCF.
IF A.3/2 OR A.3/4 OR A.3/6 then o ELSE m - - P-CSCF or S-CSCF of MGCF.
IF A.3/2 o ELSE i - - P-CSCF.
An AS acting as a proxy may be outside the trust domain, and therefore not able to
support the capability for that reason; in this case it is perfectly reasonable for the
header to be passed on transparently, as specified in the PDU parts of the profile.
2A.2.2.3 PDUs
Table A.163: Supported methods
3
Item
PDU
Sending
RFC
Profile
status
status
ACK request
[26] 13
m
m
BYE request
[26] 16
o
m
BYE response
[26] 16
o
m
CANCEL request
[26] 16.10 o
m
CANCEL response
[26] 16.10 o
m
INVITE request
[26] 16
m
m
INVITE response
[26] 16
m
m
MESSAGE request
[50] 4
c5
c5
MESSAGE response
[50] 4
c5
c5
NOTIFY request
[28] 8.1.2
c3
c3
NOTIFY response
[28] 8.1.2
c3
c3
OPTIONS request
[26] 16
m
m
OPTIONS response
[26] 16
m
m
PRACK request
[27] 6
c6
c6
PRACK response
[27] 6
c6
c6
REFER request
[36] 3
c1
c1
REFER response
[36] 3
c1
c1
REGISTER request
[26] 16
m
m
REGISTER response
[26] 16
m
m
SUBSCRIBE request
[28] 8.1.1
c3
c3
SUBSCRIBE response
[28] 8.1.1
c3
c3
UPDATE request
[30] 7
c4
c4
UPDATE response
[30] 7
c4
c4
IF A.162/22 THEN m ELSE n/a - - the REFER method.
IF A.162/27 THEN m ELSE n/a - - SIP specific event notification.
IF A.162/24 THEN m ELSE n/a - - the SIP UPDATE method.
IF A.162/33 THEN m ELSE n/a - - the SIP MESSAGE method.
F A.162/21 THEN m ELSE n/a - - reliability of provisional responses.
Ref.
1
2
3
4
5
8
9
9A
9B
10
11
12
13
14
15
16
17
18
19
20
21
22
23
c1:
c3
c4
c5:
c6:
175
Ref.
[26] 13
[26] 16
[26] 16
[26] 16.10
[26] 16.10
[26] 16
[26] 16
[50] 7
[50] 7
[28] 8.1.2
[28] 8.1.2
[26] 16
[26] 16
[27] 6
[27] 6
[36] 3
[36] 3
[26] 16
[26] 16
[28] 8.1.1
[28] 8.1.1
[30] 7
[30] 7
Receiving
RFC
status
m
o
o
o
o
m
m
c5
c5
c3
c3
m
m
c6
c6
c1
c1
m
m
c3
c3
c4
c4
Profile
status
m
m
m
m
m
m
m
c5
c5
c3
c3
m
m
c6
c6
c1
c1
m
m
c3
c3
c4
c4
1A.2.2.4 PDU parameters

2A.2.2.4.1
Status-codes
Table A.164: Supported-status codes
176
Item
Header
Ref.
100 (Trying)
180 (Ringing)
181 (Call Is Being Forwarded)
182 (Queued)
183 (Session Progress)
200 (OK)
7
8
202 (Accepted)
300 (Multiple Choices)
301 (Moved Permanently)
10
302 (Moved Temporarily)
11
305 (Use Proxy)
12
380 (Alternative Service)
13
400 (Bad Request)
14
401 (Unauthorized)
15
402 (Payment Required)
16
403 (Forbidden)
17
404 (Not Found)
18
405 (Method Not Allowed)
19
20
21
407 (Proxy Authentication

Required)
408 (Request Timeout)
22
410 (Gone)
23
413 (Request Entity Too

Large)
414 (Request-URI Too Large)
24
25
27
415 (Unsupported Media

Type)
416 (Unsupported URI
Scheme)
420 (Bad Extension)
28
421 (Extension Required)
29
423 (Interval Too Brief)
30
480 (Temporarily not
26
[26]
21.1.1
[26]
21.1.2
[26]
21.1.3
[26]
21.1.4
[26]
21.1.5
[26]
21.2.1
[28] 8.3.1
[26]
21.3.1
[26]
21.3.2
[26]
21.3.3
[26]
21.3.4
[26]
21.3.5
[26]
21.4.1
[26]
21.4.2
[26]
21.4.3
[26]
21.4.4
[26]
21.4.5
[26]
21.4.6
[26]
21.4.7
[26]
21.4.8
[26]
21.4.9
[26]
21.4.10
[26]
21.4.11
[26]
21.4.12
[26]
21.4.13
[26]
21.4.14
[26]
21.4.15
[26]
21.4.16
[26]
21.4.17
[26]
Sending
RFC
status
c1
Profile
status
c1
c3
c3
c3
c3
c3
c3
c3
c3
c4
c4
c5
c5
177
Ref.
[26]
21.1.1
[26]
21.1.2
[26]
21.1.3
[26]
21.1.4
[26]
21.1.5
[26]
21.2.1
[28] 8.3.1
[26]
21.3.1
[26]
21.3.2
[26]
21.3.3
[26]
21.3.4
[26]
21.3.5
[26]
21.4.1
[26]
21.4.2
[26]
21.4.3
[26]
21.4.4
[26]
21.4.5
[26]
21.4.6
[26]
21.4.7
[26]
21.4.8
[26]
21.4.9
[26]
21.4.10
[26]
21.4.11
[26]
21.4.12
[26]
21.4.13
[26]
21.4.14
[26]
21.4.15
[26]
21.4.16
[26]
21.4.17
[26]
Receiving
RFC
status
c2
Profile
status
c2
c3
c3
c3
c3
c3
c3
c3
c3
c4
c4
c6
c6
Item
Header
Ref.
32
available)
481 (Call /Transaction Does
Not Exist)
482 (Loop Detected)
33
483 (Too Many Hops)
34
484 (Address Incomplete)
35
485 (Ambiguous)
36
486 (Busy Here)
37
487 (Request Terminated)
38
488 (Not Acceptable Here)
39
40
489 (Bad Event)

491 (Request Pending)
41
493 (Undecipherable)
41A
494 (Security Agreement

Required)
500 (Internal Server Error)
31
42
43
44
45
46
47
48
49
50
51
52
53
c1:
c2:
c3:
c4:
c5:
c6:
c7:
21.4.18
[26]
21.4.19
[26]
21.4.20
[26]
21.4.21
[26]
21.4.22
[26]
21.4.23
[26]
21.4.24
[26]
21.4.25
[26]
21.4.26
[28] 7.3.2
[26]
21.4.27
[26]
21.4.28
[48] 2
Sending
RFC
status
c4
c4
c7
c7
Ref.
21.4.18
[26]
21.4.19
[26]
21.4.20
[26]
21.4.21
[26]
21.4.22
[26]
21.4.23
[26]
21.4.24
[26]
21.4.25
[26]
21.4.26
[28] 7.3.2
[26]
21.4.27
[26]
21.4.28
[48] 2
Receiving
RFC
status
Profile
status
c4
c4
n/a
n/a
[26]
[26]
21.5.1
21.5.1
501 (Not Implemented)
[26]
[26]
21.5.2
21.5.2
502 (Bad Gateway)
[26]
[26]
21.5.3
21.5.3
503 (Service Unavailable)
[26]
[26]
21.5.4
21.5.4
504 (Server Time-out)
[26]
[26]
21.5.5
21.5.5
505 (Version not supported)
[26]
[26]
21.5.6
21.5.6
513 (Message Too Large)
[26]
[26]
21.5.7
21.5.7
580 (Precondition Failure)
[30] 8
[30] 8
600 (Busy Everywhere)
[26]
[26]
21.6.1
21.6.1
603 (Decline)
[26]
[26]
21.6.2
21.6.2
604 (Does Not Exist
[26]
[26]
Anywhere)
21.6.3
21.6.3
[26]
[26]
21.6.4
21.6.4
IF A.162/15 THEN m ELSE n/a - - stateful proxy.
IF A.162/15 THEN m ELSE i - - the requirement to be able to use separate URIs in the upstream direction
and downstream direction when record routeing.
IF A.163/9 THEN m ELSE n/a - - INVITE response.
IF A.162/27 THEN m ELSE n/a - - SIP specific event notification.
IF A.163/19 OR A.163/21 THEN m ELSE n/a - - REGISTER response or SUBSCRIBE response.
IF A.163/19 OR A.163/21 THEN i ELSE n/a - - REGISTER response or SUBSCRIBE response.
Profile
status
178
1A.2.2.4.2
ACK method
2Prerequisite A.163/1 - - ACK request
Table A.165: Supported headers within the ACK request
3
Item
Header
Ref.
Allow-Events
3
4
6
7
8
9
10
11
12
13
14
15
16
17
17A
18
19
20
21
22
23
c1:
c2:
c3:
c4:
c5:
c6:
c7:
NOTE:
Sending
RFC
status
m
Profile
status
m
Ref.
Receiving
RFC
status
c1
Profile
status
c1
[28]
[28]
87.2.2
87.2.2
Authorization
[26] 20.7
m
m
[26] 20.7
i
i
Call-ID
[26] 20.8
m
m
[26] 20.8
m
m
Content-Disposition
[26] 20.11 m
m
[26] 20.11 i
i
Content-Encoding
[26] 20.12 m
m
[26] 20.12 i
i
Content-Language
[26] 20.13 m
m
[26] 20.13 i
i
Content-Length
[26] 20.14 m
m
[26] 20.14 m
m
Content-Type
[26] 20.15 m
m
[26] 20.15 i
c3
Cseq
[26] 20.16 m
m
[26] 20.16 m
m
Date
[26] 20.17 m
m
[26] 20.17 c2
c2
From
[26] 20.20 m
m
[26] 20.20 m
m
Max-Forwards
[26] 20.22 m
m
[26] 20.22 m
m
MIME-Version
[26] 20.24 m
m
[26] 20.24 i
c3
Proxy-Authorization
[26] 20.28 m
m
[26] 20.28 c4
c4
Proxy-Require
[26] 20.29 m
m
[26] 20.29 m
m
Privacy
[33] 4.2
c6
c6
[33] 4.2
c7
c7
Require
[26] 20.32 m
m
[26] 20.32 c5
c5
Route
[26] 20.34 m
m
[26] 20.34 m
m
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
IF A.4/20 THEN m ELSE i - - SIP specific event notification extension.
IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses.
IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF.
IF A.162/11 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying
the request or response or adding or modifying the contents of the Require header before proxying the
request or response for methods other than REGISTER.
IF A.162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP).
IF A.162/31D OR A.162/31G THEN m ELSE IF A.162/31C THEN i ELSE n/a - - application of the privacy
option "header" or application of the privacy option "id" or passing on of the Privacy header transparently.
c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for
SUBSCRIBE and NOTIFY.
4
5
Editor's note: Is the following table a suitable way of showing the contents of message bodies.
6Prerequisite A.163/1 - - ACK request
Table A.166: Supported message bodies within the ACK request
7
Item
Header
Ref.
Sending
RFC
status
179
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.2.4.3
BYE method

3
Table A.167: Supported headers within the BYE request
180
Item
Header
Ref.
Profile
status
m
m
m
m
m
Ref.
Profile
status
Accept
Accept-Encoding
Accept-Language
Allow
Allow-Events
5
6
7
8
9
10
11
12
13
14
15
16
16A
16B
16C
Authorization
m
m
i
i
Call-ID
m
m
m
m
Content-Disposition
m
m
i
c3
Content-Encoding
m
m
i
c3
Content-Language
m
m
i
c3
Content-Length
m
m
m
m
Content-Type
m
m
i
c3
Cseq
m
m
m
m
Date
m
m
c2
c2
From
m
m
m
m
Max-Forwards
m
m
m
m
MIME-Version
m
m
i
c3
c13
c13
c14
c14
P-Asserted-Identity
c9
c9
c10
c10
c17
c18
c18
Addresses
P-Charging-Vector
[52] 4.6
c15
n/a
[52] 4.6
c16
n/a
[34] 9.2
x
x
[34] 9.2
c8
n/a
Privacy
[33] 4.2
c11
c11
[33] 4.2
c12
c12
Proxy-Authorization
[26] 20.28 m
m
[26] 20.28 c4
c4
Proxy-Require
[26] 20.29 m
m
[26] 20.29 m
m
Record-Route
[26] 20.30 m
m
[26] 20.30 c7
c7
Require
[26] 20.32 m
m
[26] 20.32 c5
c5
Route
[26] 20.34 m
m
[26] 20.34 m
m
Security-Client
[48] 2.3.1
x
x
[48] 2.3.1
c19
c19
Security-Verify
[48] 2.3.1
x
x
[48] 2.3.1
c19
c19
Supported
[26] 20.37 m
m
[26] 20.37 c6
c6
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
IF A.162/16 THEN m ELSE i - - reading the contents of the Supported header before proxying the response.
IF A.162/14 THEN o ELSE i - - the requirement to be able to insert itself in the subsequent transactions in a
dialog.
IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity.
IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity
IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for
asserted identity within trusted networks or subsequent entity within trust network that can route outside the
trust network.
IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
181
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.22
[26] 20.24
[52] 4.4
[34] 9.1
[52] 4.5
Receiving
RFC
status
i
i
i
i
c1
1
2
3
3A
4
16D
16E
16F
17
18
19
20
21
21A
21B
22
23
24
25
26
c1:
c2:
c3:
c4:
c5:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.22
[26] 20.24
[52] 4.4
[34] 9.1
[52] 4.5
Sending
RFC
status
m
m
m
m
m
i
i
i
i
c1
c14:
c15:
c16:
c17:
c18:
c19:
NOTE:
for access network information that can route outside the trust network, the P-Access-Network-Info header
extension.
IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network
extension.
IF A.162/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the PCharging-Vector header before proxying the request or response or the P-Charging-Vector header
extension.
IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-ChargingFunction-Addresses header before proxying the request or response, or the P-Charging-FunctionAddresses header extension.
1
Table A.168: Supported message bodies within the BYE request
3
Item
Header
Ref.
Sending
RFC
status
Profile
status
Ref.
Receiving
RFC
status
Profile
status
Receiving
RFC
status
m
m
m
c1
m
m
m
Profile
status
m
m
m
c1
m
m
m
4
7
Item
Header
Sending
RFC
Profile
Ref.
status
status
Call-ID
[26] 20.8
m
m
[26] 20.8
Content-Length
[26] 20.14 m
m
[26] 20.14
Cseq
[26] 20.16 m
m
[26] 20.16
Date
[26] 20.17 m
m
[26] 20.17
From
[26] 20.20 m
m
[26] 20.20
To
[26] 20.39 m
m
[26] 20.39
Via
[26] 20.42 m
m
[26] 20.42
Ref.
1
2
3
4
5
6
7
c1:
182
Table A.170: Supported headers within the BYE response - all remaining status-codes
Item
Header
Ref.
1
2
3
4
5
6
7
8
9
10
10A
10B
10C
10D
10E
10F
10G
10H
11
12
12A
13
14
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
c14:
Sending
RFC
status
m
m
m
m
m
m
m
m
m
m
c12
c4
c10
Profile
status
m
m
m
m
m
m
m
m
m
m
c12
c4
c10
Ref.
Receiving
RFC
status
m
i
i
i
m
i
m
c1
m
i
c13
c5
c11
Profile
status
m
c2
c2
c2
m
c2
m
c1
m
c2
c13
c5
c11
Call-ID
[26] 20.8
[26] 20.8
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
[52] 4.4
[52] 4.4
P-Asserted-Identity
[34] 9.1
[34] 9.1
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c8
n/a
[52] 4.6
c9
n/a
[34] 9.2
x
x
[34] 9.2
c3
n/a
Privacy
[33] 4.2
c6
c6
[33] 4.2
c7
c7
Require
[26] 20.32 m
m
[26] 20.32 c14
c14
Server
[26] 20.35 m
m
[26] 20.35 i
i
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 m
m
[26] 20.43 i
i
trust network.
extension.
extension.
extension.
183
1
4
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Authentication-Info
[26] 20.6
m
m
[26] 20.6
i
i
Record-Route
[26] 20.30 m
m
[26] 20.30 c3
c3
Supported
[26] 20.37 m
m
[26] 20.37 i
i
IF A.162/15 THEN o ELSE i - - the requirement to be able to use separate URIs in the upstream direction
Ref.
0A
1
2
5
c3:
5
6Prerequisite A.163/3 - BYE response
7Prerequisite: A.164/8 OR A.164/9 OR A.164/10 OR A.164/11 OR A.164/12 OR A.164/35 - - 3xx or 485
8(Ambiguous)
9
Item
Header
Sending
RFC
Profile
status
status
Allow
[26] 20.5
m
m
Contact
[26] 20.10 m
m
Error-Info
[26] 20.18 m
m
Supported
[26] 20.37 m
m
IF A.162/19E THEN m ELSE i - - deleting Contact headers.
Ref.
0A
1
2
4
c1:
Ref.
[26] 20.5
[26] 20.10
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
c1
i
i
Profile
status
i
c1
i
i
10
13
Item
Header
Ref.
0A
1
2
5
8
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
14
184
Profile
status
m
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i

2Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/45 OR A.164/50 OR
3A.164/51 - - 404, 413, 480, 486, 500, 503, 600, 603
4
Item
Header
Ref.
0A
1
3
5
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
m
m
m
m
Profile
status
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
i
i
i
i
Profile
status
i
i
i
i
5
8
Item
Header
Ref.
1
2
5
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
9
12
Item
Header
Ref.
0A
1
2
5
6
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
Profile
status
m
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i
13
16
Item
Header
Ref.
1
2
3
3A
4
7
Accept
Accept-Encoding
Accept-Language
Allow
Error-Info
Supported
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
m
m
m
17
185
Profile
status
m
m
m
m
m
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
i
i
i
Profile
status
i
i
i
i
i
i

3
Item
Header
Ref.
[26] 20.5
[26] 20.18
Sending
RFC
status
m
m
Profile
status
m
m
Ref.
[26] 20.5
[26] 20.18
Receiving
RFC
status
i
i
Profile
status
0A
1
Allow
Error-Info
i
i
4
5
c3:
Supported
[26] 20.37 m
m
[26] 20.37 i
i
Unsupported
[26] 20.40 m
m
[26] 20.40 c3
c3
IF A.162/18 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420
response to a method other than REGISTER.
4
Table A.178A: Supported headers within the BYE response
7
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
o
Security-Server
[48] 2
c1
c1
[48] 2
n/a
n/a
Supported
[26] 20.37 m
m
[26] 20.37 m
m
Ref.
1
2
3
4
c1:
8
11
Item
Header
Ref.
0A
1
4
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
12
Table A.180: Supported message bodies within the BYE response
14
Item
Header
Ref.
Sending
RFC
status
15
186
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.2.4.4
CANCEL method
Table A.181: Supported headers within the CANCEL request
3
Item
Header
Ref.
Allow-Events
5
6
8
9
10
11
12
13
16
18
19
20
21
22
23
c1:
c2:
c3:
c4:
c6:
c7:
NOTE:
Sending
RFC
status
m
Profile
status
m
Ref.
Receiving
RFC
status
c1
Profile
status
c1
[28]
[28]
87.2.2
87.2.2
Authorization
[26] 20.7
m
m
[26] 20.7
i
i
Call-ID
[26] 20.8
m
m
[26] 20.8
m
m
Content-Length
[26] 20.14 m
m
[26] 20.14 m
m
Cseq
[26] 20.16 m
m
[26] 20.16 m
m
Date
[26] 20.17 m
m
[26] 20.17 c2
c2
From
[26] 20.20 m
m
[26] 20.20 m
m
Max-Forwards
[26] 20.22 m
m
[26] 20.22 m
m
Privacy
[33] 4.2
c3
c3
[33] 4.2
c4
c4
Record-Route
[26] 20.30 m
m
[26] 20.30 c7
c7
Route
[26] 20.34 m
m
[26] 20.34 m
m
Supported
[26] 20.37 m
m
[26] 20.37 c6
c6
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
dialog.
4
Table A.182: Supported message bodies within the CANCEL request
6
Item
Header
Ref.
Sending
RFC
status
187
Profile
status
Ref.
Receiving
RFC
status
Profile
status
Table A.183: Supported headers within the CANCEL response - all status-codes
2
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Call-ID
[26] 20.8
m
m
[26] 20.8
m
m
Content-Length
[26] 20.14 m
m
[26] 20.14 m
m
Cseq
[26] 20.16 m
m
[26] 20.16 m
m
Date
[26] 20.17 m
m
[26] 20.17 c1
c1
From
[26] 20.20 m
m
[26] 20.20 m
m
Privacy
[33] 4.2
c2
c2
[33] 4.2
c3
c3
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 o
[26] 20.41 o
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 m
m
[26] 20.43 i
i
Ref.
1
2
3
4
5
5A
6
7
7A
8
9
c1:
c2:
c3:
3
5Prerequisite: A.164/6 - - 200 (OK)
6
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Record-Route
[26] 20.30 m
m
[26] 20.30 c3
c3
Supported
[26] 20.37 m
m
[26] 20.37 i
i
Ref.
2
4
c3:
7
10
Item
Header
Ref.
2
5
Error-Info
Supported
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
11
188
Profile
status
m
m
Ref.
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
Profile
status
i
i

2Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/42 OR A.164/45 OR A.164/50 OR A.164/51 - 3404, 413, 480, 500, 503, 600, 603
4
Item
Header
Ref.
2
4
5
Error-Info
Retry-After
Supported
[26] 2418
[26] 20.33
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
5
8
Item
Header
Ref.
2
4
Error-Info
Supported
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
Profile
status
m
m
Ref.
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
Profile
status
i
i
9
Table A.189: Supported message bodies within the CANCEL response
11
Item
Header
Ref.
Sending
RFC
status
12
189
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.2.4.5
COMET method
2Void
3A.2.2.4.6
INFO method
4Void
5A.2.2.4.7
INVITE method

7
Table A.204: Supported headers within the INVITE request
190
Item
Header
Ref.
1
2
3
4
5
6
Accept
Accept-Encoding
Accept-Language
Alert-Info
Allow
Allow-Events
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
24A
24B
24C
24D
Authorization
Call-ID
Call-Info
Contact
Content-Disposition
Content-Encoding
Content-Language
Content-Length
Content-Type
Cseq
Date
Expires
From
In-Reply-To
Max-Forwards
MIME-Version
Organization
P-Asserted-Identity
P-Called-Party-ID
P-Charging-FunctionAddresses
P-Charging-Vector
Priority
Privacy
Proxy-Authorization
Proxy-Require
24E
25
25A
25B
26
26A
27
28
29
31
32
33
33A
33B
34
35
36
37
38
39
c1:
c2:
c3:
c4:
c5:
c6:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.4
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.19
[26] 20.20
[26] 20.21
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Sending
RFC
status
m
m
m
c2
m
m
Profile
status
m
m
m
c2
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
c28
c15
c19
c26
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
c28
c15
c19
c27
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.4
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.19
[26] 20.20
[26] 20.21
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Receiving
RFC
status
i
i
i
c3
i
c1
i
i
i
c3
i
c1
i
m
c12
i
i
i
i
m
i
m
c4
i
m
i
m
i
c5
c29
c16
c20
c26
i
m
c12
i
c6
c6
c6
m
c6
m
c4
i
m
i
m
c6
c5
c30
c16
c21
c27
Profile
status
[52] 4.6
c24
c24
[52] 4.6
c25
c25
[31] 6.1
c9
c10
[31] 6.1
n/a
n/a
[34] 9.2
x
x
[34] 9.2
c14
c14
[52] 4.3
c22
n/a
[52] 4.3
c23
n/a
[26] 20.26 m
m
[26] 20.26 i
i
[33] 4.2
c17
c17
[33] 4.2
c18
c18
[26] 20.28 m
m
[26] 20.28 c13
c13
[26]
m
m
[26]
m
m
20.29,
20.29,
[34] 4
[34] 4
Record-Route
[26] 20.30 m
m
[26] 20.30 c11
c11
Reply-To
[26] 20.31 m
m
[26] 20.31 i
i
Require
[26] 20.32 m
m
[26] 20.32 c7
c7
Route
[26] 20.34 m
m
[26] 20.34 m
m
Security-Client
[48] 2.3.1
x
x
[48] 2.3.1
c31
c31
Security-Verify
[48] 2.3.1
x
x
[48] 2.3.1
c31
c31
Subject
[26] 20.36 m
m
[26] 20.36 i
i
Supported
[26] 20.37 m
m
[26] 20.37 c8
c8
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
IF A.162/10 THEN n/a ELSE m - - suppression or modification of alerting information data.
IF A.162/10 THEN m ELSE i - - suppression or modification of alerting information data.
IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header.
191
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
IF A.162/14 THEN m ELSE i - - the requirement to be able to insert itself in the subsequent transactions in a
dialog.
IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header.
trust network.
IF A.162/37 THEN m ELSE n/a - - the P-Called-Party-ID header extension.
IF A.162/37 THEN i ELSE n/a - - the P-Called-Party-ID header extension.
IF A.162/37 AND A.3/2 THEN m ELSE IF A.162/37 AND A.3/3 THEN i ELSE n/a - - the P-Called-Party-ID
header extension and P-CSCF or I-CSCF.
IF A.162/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension.
IF A.162/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the
request or response.
extension.
extension.
extension.
IF A.162/43 OR (A.162/41 AND A.3/2) THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent
entity within trust network for access network information that can route outside the trust network, the PAccess-Network-Info header extension (with or without P-CSCF).
Ref.
c7:
c8:
c9:
c10:
c11:
c12:
c13:
c14:
c15:
c16:
c17:
c18:
c19:
c20:
c21:
c22:
c23:
c24:
c25:
c26:
c27:
c28:
c29:
c30:
c31:
NOTE:
1
Table A.205: Supported message bodies within the INVITE request
3
Item
Header
Ref.
Sending
RFC
status
192
Profile
status
Ref.
Receiving
RFC
status
Profile
status

3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Call-ID
[26] 20.8
m
m
[26] 20.8
m
m
Content-Length
[26] 20.14 m
m
[26] 20.14 m
m
Cseq
[26] 20.16 m
m
[26] 20.16 m
m
Date
[26] 20.17 c1
c1
[26] 20.17 c2
c2
From
[26] 20.20 m
m
[26] 20.20 m
m
To
[26] 20.39 m
m
[26] 20.39 m
m
Via
[26] 20.42 m
m
[26] 20.42 m
m
IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a - - stateful proxy behaviour that inserts date, or
stateless proxies.
IF A.162/4 THEN i ELSE m - - Stateless proxy passes on.
Ref.
1
2
3
4
5
6
7
c1:
c2:
193

2
Table A.207: Supported headers within the INVITE response - all remaining status-codes
194
Item
Header
Ref.
1
1A
2
3
4
5
6
7
8
9
10
11
11A
11B
11C
11D
11E
11F
11G
11H
12
13
13A
14
15
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
c14:
c15:
c16:
Sending
RFC
status
m
m
m
m
m
m
m
m
m
m
m
m
c14
c6
c12
Ref.
Receiving
RFC
status
m
c4
i
i
i
m
i
m
c1
m
i
c2
c15
c7
c13
Profile
status
m
c4
c3
c3
c3
m
c3
m
c1
m
c3
c2
c15
c7
c13
Call-ID
[26] 20.8
[26] 20.8
Call-Info
[26] 20.9
[26] 20.9
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
Organization
[26] 20.25
[26] 20.25
[52] 4.4
[52] 4.4
P-Asserted-Identity
[34] 9.1
[34] 9.1
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c10
c10
[52] 4.6
c11
c11
[34] 9.2
x
x
[34] 9.2
c5
n/a
Privacy
[33] 4.2
c8
c8
[33] 4.2
c9
c9
Require
[26] 20.32 m
m
[26] 20.32 c16
c16
Server
[26] 20.35 m
m
[26] 20.35 i
i
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 m
m
[26] 20.43 i
i
trust network.
extension.
extension.
extension.
Profile
status
m
m
m
m
m
m
m
m
m
m
m
m
c14
c6
c12
195

2Prerequisite: A.164/2 OR A.164/3 OR A.164/4 OR A.164/5 - - 1xx
3
Item
Header
Sending
RFC
Profile
Ref.
status
status
Allow
[26] 20.5
m
m
[26] 20.5
Contact
[26] 20.10 m
m
[26] 20.10
[31] 6.1
c9
c10
[31] 6.1
Rseq
[27] 7.1
m
m
[27] 7.1
Supported
[26] 20.37 m
m
[26] 20.37
Ref.
1
4
6
9
11
c9:
c10:
Receiving
RFC
status
i
i
n/a
i
i
Profile
status
i
i
n/a
i
i
4
7
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Accept
[26] 20.1
m
m
[26] 20.1
i
i
Accept-Encoding
[26] 20.2
m
m
[26] 20.2
i
i
Accept-Language
[26] 20.3
m
m
[26] 20.3
i
i
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Authentication-Info
[26] 20.6
m
m
[26] 20.6
i
i
Contact
[26] 20.10 m
m
[26] 20.10 i
i
[31] 6.1
c9
c10
[31] 6.1
n/a
n/a
Record-Route
[26] 20.30 m
m
[26] 20.30 c3
c3
Supported
[26] 20.37 m
m
[26] 20.37 i
i
dialog.
Ref.
1
1A
1B
2
4
6
8
9
13
c3:
c9:
c10:
8
11(Ambiguous)
12
Item
Header
Sending
RFC
Profile
status
status
Allow
[26] 20.5
m
m
Contact
[26] 20.10 m
m
Error-Info
[26] 20.18 m
m
Supported
[26] 20.37 m
m
Ref.
1
4
5
10
c1:
13
196
Ref.
[26] 20.5
[26] 20.10
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
c1
i
i
Profile
status
i
c1
i
i

3
Item
Header
Ref.
1
4
6
10
15
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
o
Profile
status
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
o
Profile
status
i
i
m
i
4
6Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/50 OR A.164/51 - - 404, 413, 480,
7486, 600, 603
8
Item
Header
Ref.
1
4
8
10
12
Allow
Error-Info
Retry-After
Supported
Via
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
[26] 20.42
Sending
RFC
status
m
m
m
m
m
Profile
status
m
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
[26] 20.42
Receiving
RFC
status
i
i
i
i
m
Profile
status
i
i
i
i
m
9
12
Item
Header
Ref.
2
5
13
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
m/o
i
i
Profile
status
i
i
13
16
Item
Header
Ref.
1
4
6
10
11
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
17
197
Profile
status
m
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i

3
Item
Header
Ref.
1
2
3
3A
6
11
Accept
Accept-Encoding
Accept-Language
Allow
Error-Info
Supported
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
m
m
m
Profile
status
m
m
m
m
m
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
i
i
i
Profile
status
i
i
i
i
i
i
4
7
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Error-Info
[26] 20.18 m
m
[26] 20.18 i
i
Supported
[26] 20.37 m
m
[26] 20.37 i
i
Unsupported
[26] 20.40 m
m
[26] 20.40 c3
c3
Ref.
1
4
9
10
c3:
8
11
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
o
Security-Server
[48] 2
c1
c1
[48] 2
n/a
n/a
Supported
[26] 20.37 m
m
[26] 20.37 m
m
Ref.
1
2
3
4
c1:
12
15
Item
Header
Ref.
1
4
9
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
16
198
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i

2Prerequisite: A.164/42 - - 500 (Server Internal Error)
3
Item
Header
Ref.
1
4
8
10
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
m
m
m
m
Profile
status
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
i
i
i
i
Profile
status
i
i
i
i
4
Table A.217B: Supported headers within the INVITE response
7
Item
Header
Ref.
1
4
8
10
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
m
m
m
m
Profile
status
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
i
i
i
i
Profile
status
i
i
i
i
8
Table A.218: Supported message bodies within the INVITE response
10
Item
Header
Ref.
Sending
RFC
status
11
199
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.2.4.7A MESSAGE method

3
Table A.218A: Supported headers within the MESSAGE request
200
Item
Header
Ref.
Profile
status
m
m
Ref.
Profile
status
Allow
Allow-Events
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
18A
18B
18C
18D
Authorization
m
m
i
i
Call-ID
m
m
m
m
Call-Info
m
m
c4
c4
Content-Disposition
m
m
i
i
Content-Encoding
m
m
i
i
Content-Language
m
m
i
i
Content-Length
m
m
m
m
Content-Type
m
m
i
i
Cseq
m
m
m
m
Date
m
m
c2
c2
Expires
m
m
I
i
From
m
m
m
m
In-Reply-To
m
m
i
i
Max-Forwards
m
m
m
m
MIME-Version
m
m
i
i
Organization
m
m
c3
c3
c23
c23
c24
c24
P-Asserted-Identity
c10
c10
c11
c11
P-Called-Party-ID
c14
c14
c15
c16
c21
c22
c22
Addresses
P-Charging-Vector
[52] 4.6
c19
c19
[52] 4.6
c20
c20
[34] 9.2
x
x
[34] 9.2
c9
c9
[52] 4.3
c17
n/a
[52] 4.3
c18
n/a
Priority
[26] 20.26 m
m
[26] 20.26 i
i
Privacy
[33] 4.2
c12
c12
[33] 4.2
c13
c13
Proxy-Authorization
[26] 20.28 m
m
[26] 20.28 c8
c8
Proxy-Require
[26] 20.29 m
m
[26] 20.29 m
m
Record-Route
[26] 20.30 m
m
[26] 20.30 c7
c7
Reply-To
[26] 20.31 m
m
[26] 20.31 i
i
Require
[26] 20.32 m
m
[26] 20.32 c5
c5
Route
[26] 20.34 m
m
[26] 20.34 m
m
Security-Client
[48] 2.3.1
x
x
[48] 2.3.1
c25
c25
Security-Verify
[48] 2.3.1
x
x
[48] 2.3.1
c25
c25
Subject
[26] 20.36 m
m
[26] 20.36 i
i
Supported
[26] 20.37 m
m
[26] 20.37 c6
c6
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
dialog.
c6:
c7:
c8:
c9:
c10:
201
[50] 10
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.19
[26] 20.20
[50] 10
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Receiving
RFC
status
i
c1
1
2
18E
18F
18G
19
19A
20
21
22
23
24
25
25A
25B
26
27
28
29
30
31
c1:
c2:
c3:
c4:
c5:
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.19
[26] 20.20
[26] 20.21
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Sending
RFC
status
m
m
i
c1
c11:
c12:
c13:
c14:
c15:
c16:
c17:
c18:
c19:
c20:
c21:
c22:
c23:
c24:
c25:
NOTE:
trust network.
extension.
extension.
extension.
1
Table A.218B: Supported message bodies within the MESSAGE request
3
Item
Header
Ref.
Sending
RFC
status
202
Profile
status
Ref.
Receiving
RFC
status
Profile
status

2 Table A.218C: Supported headers within the MESSAGE response - all remaining status-codes
203
Item
Header
Ref.
1
2
3
4
5
6
7
8
9
10
11
12
12A
12B
12C
12D
12E
12F
12G
13
14
15
16
17
18
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
c14:
c15:
Sending
RFC
status
m
m
m
m
m
m
m
m
m
m
m
m
c13
c5
c11
Ref.
Receiving
RFC
status
m
c3
i
i
i
m
i
m
c1
m
i
c2
c14
c6
c12
Profile
status
m
c3
i
i
i
m
i
m
c1
m
i
c2
c14
c6
c12
Call-ID
[26] 20.8
[26] 20.8
Call-Info
[26] 20.9
[26] 20.9
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
Organization
[26] 20.25
[26] 20.25
[52] 4.4
[52] 4.4
P-Asserted-Identity
[34] 9.1
[34] 9.1
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c9
n/a
[52] 4.6
c10
n/a
[34] 9.2
x
x
[34] 9.2
c4
n/a
Privacy
[33] 4.2
c7
c7
[33] 4.2
c8
c8
Require
[26] 20.32 m
m
[26] 20.32 c15
c15
Server
[26] 20.35 m
m
[26] 20.35 i
i
Timestamp
[26] 20.38 i
i
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 m
m
[26] 20.43 i
i
trust network.
extension.
extension.
extension.
Profile
status
m
m
m
m
m
m
m
m
m
m
m
m
c13
c5
c11
204

Table A.218D: Supported headers within the MESSAGE response
3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Authentication-Info
[26] 20.6
m
m
[26] 20.6
i
i
Record-Route
[26] 20.30 m
m
[26] 20.30 c3
c3
Supported
[26] 20.37 m
m
[26] 20.37 i
i
Ref.
1
2
4
6
c3:
4
7(Ambiguous)
Table A.218E: Supported headers within the MESSAGE response
8
Item
Header
Sending
RFC
Profile
status
status
Allow
[26] 20.5
m
m
Contact
[26] 20.10 m
m
Error-Info
[26] 20.18 m
m
Supported
[26] 20.37 m
m
Ref.
1
2
3
5
c1:
Ref.
[50] 10
[26] 20.10
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
c1
i
i
Profile
status
i
c1
i
i
9
Table A.218F: Supported headers within the MESSAGE response
12
Item
Header
Ref.
1
2
3
5
6
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
13
205
Profile
status
m
m
m
m
m
Ref.
[50] 10
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i

3A.164/51 - - 404, 413, 480, 486, 500, 503, 600, 603
Table A.218G: Supported headers within the MESSAGE response
4
Item
Header
Ref.
1
2
4
5
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
m
m
m
m
Profile
status
m
m
m
m
Ref.
[50] 10
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
i
i
i
i
Profile
status
i
i
i
i
5
Table A.218H: Supported headers within the MESSAGE response
8
Item
Header
Ref.
1
2
4
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
9
Table A.218I: Supported headers within the MESSAGE response
12
Item
Header
Ref.
1
2
3
5
6
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
Profile
status
m
m
m
m
m
Ref.
[50] 10
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i
13
Table A.218J: Supported headers within the MESSAGE response
16
Item
Header
Ref.
1
2
3
4
5
7
Accept
Accept-Encoding
Accept-Language
Allow
Error-Info
Supported
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
m
m
m
17
206
Profile
status
m
m
m
m
m
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[50] 10
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
i
i
i
Profile
status
i
i
i
i
i
i

Table A.218K: Supported headers within the MESSAGE response
3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
m
m
[50] 10
i
i
Error-Info
[26] 20.18 m
m
[26] 20.18 i
i
Supported
[26] 20.37 m
m
[26] 20.37 i
i
Unsupported
[26] 20.40 m
m
[26] 20.40 c3
c3
Ref.
1
2
4
5
c3:
4
Table A.218L: Supported headers within the MESSAGE response
7
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
o
Security-Server
[48] 2
c1
c1
[48] 2
n/a
n/a
Supported
[26] 20.37 m
m
[26] 20.37 m
m
Ref.
1
2
3
4
c1:
8
Table A.218M: Supported headers within the MESSAGE response
11
Item
Header
Ref.
1
3
5
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[50] 10
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
12
Table A.218N: Supported message bodies within the MESSAGE response
14
Item
Header
Ref.
Sending
RFC
status
15
207
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.2.4.8
NOTIFY method

3
Table A.219: Supported headers within the NOTIFY request
208
Item
Header
Ref.
Profile
status
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
Ref.
i
i
i
i
c1
i
m
i
i
i
i
m
i
m
c2
m
i
m
i
i
i
i
m
i
m
c2
m
Profile
status
Accept
Accept-Encoding
Accept-Language
Allow
Allow-Events
5
6
6A
7
8
9
10
11
12
13
14
Authorization
Call-ID
Contact
Content-Disposition
Content-Encoding
Content-Language
Content-Length
Content-Type
Cseq
Date
Event
15
16
17
17A
17B
17C
From
m
m
m
m
Max-Forwards
m
m
m
m
MIME-Version
m
m
i
i
c16
c16
c17
c17
P-Asserted-Identity
c8
c8
c9
c9
c14
c15
c15
Addresses
P-Charging-Vector
[52] 4.6
c12
n/a
[52] 4.6
c13
n/a
[34] 9.2
x
x
[34] 9.2
c3
n/a
Privacy
[33] 4.2
c10
c10
[33] 4.2
c11
c11
Proxy-Authorization
[26] 20.28 m
m
[26] 20.28 c4
c4
Proxy-Require
[26] 20.29 m
m
[26] 20.29 m
m
Record-Route
[26] 20.30 m
m
[26] 20.30 c7
c7
Require
[26] 20.32 m
m
[26] 20.32 c5
c5
Route
[26] 20.34 m
m
[26] 20.34 m
m
Security-Client
[48] 2.3.1
x
x
[48] 2.3.1
c18
c18
Security-Verify
[48] 2.3.1
x
x
[48] 2.3.1
c18
c18
Subscription-State
[28] 8.2.3
m
m
[28] 8.2.3
i
i
Supported
[26] 20.37 m
m
[26] 20.37 c6
c6
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
IF A.162/14 THEN (IF A.162/22 OR A.162/27 THEN m ELSE o) ELSE i - - the requirement to be able to
insert itself in the subsequent transactions in a dialog or (the REFER method or SIP specific event
notification).
trust network.
c6:
c7:
c8:
c9:
209
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[28]
87.2.1
[26] 20.20
[26] 20.22
[26] 20.24
[52] 4.4
[34] 9.1
[52] 4.5
Receiving
RFC
status
i
i
i
i
c1
1
2
3
3A
4
17D
17E
17F
18
19
20
21
22
22A
22B
23
24
25
26
27
28
c1:
c2:
c3:
c4:
c5:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[28]
87.2.1
[26] 20.20
[26] 20.22
[26] 20.24
[52] 4.4
[34] 9.1
[52] 4.5
Sending
RFC
status
m
m
m
m
m
c10:
c11:
c12:
c13:
c14:
c15:
c16:
c17:
c18:
NOTE:
extension.
extension.
extension.
1
Table A.220: Supported message bodies within the NOTIFY request
3
Item
Header
Ref.
sipfrag
[37] 2
Sending
RFC
status
m
210
Profile
status
m
Ref.
[37] 2
Receiving
RFC
status
i
Profile
status
i
Table A.221: Supported headers within the NOTIFY response - all status-codes
2
Item
Header
Ref.
1
2
3
4
5
6
7
8
9
10
10A
10B
10C
10D
10E
10F
10G
10H
11
12
12A
13
14
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
Sending
RFC
status
m
m
m
m
m
m
m
m
m
m
c11
c3
c9
Profile
status
m
m
m
m
m
m
m
m
m
m
c11
c3
c9
Ref.
Receiving
RFC
status
m
i
i
i
m
i
m
c1
m
i
c12
c4
c10
Profile
status
m
i
i
i
m
i
m
c1
m
i
c12
c4
c10
Call-ID
[26] 20.8
[26] 20.8
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
[52] 4.4
[52] 4.4
P-Asserted-Identity
[34] 9.1
[34] 9.1
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c7
n/a
[52] 4.6
c8
n/a
[34] 9.2
x
x
[34] 9.2
c2
n/a
Privacy
[33] 4.2
c5
c5
[33] 4.2
c6
c6
Require
[26] 20.32 m
m
[26] 20.32 c13
c13
Server
[26] 20.35 m
m
[26] 20.35 i
i
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 m
m
[26] 20.43 i
i
trust network.
extension.
extension.
extension.
211
1
3Prerequisite: A.164/6 AND A.164/7 - - 2xx
4
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Authentication-Info
[26] 20.6
m
m
[26] 20.6
i
i
Contact
[26] 20.10 m
m
[26] 20.10 i
i
Record-Route
[26] 20.30 m
m
[26] 20.30 c3
c3
Supported
[26] 20.37 m
m
[26] 20.37 i
i
Ref.
0A
1
1A
2
5
c3:
5
8(Ambiguous)
9
Item
Header
Sending
RFC
Profile
status
status
Allow
[26] 20.5
m
m
Contact
[26] 20.10 m
m
Error-Info
[26] 20.18 m
m
Supported
[26] 20.37 m
m
Ref.
0A
1
2
5
c1:
Ref.
[26] 20.5
[26] 20.10
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
c1
i
i
Profile
status
i
c1
i
i
10
13
Item
Header
Ref.
0A
1
2
5
8
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
14
212
Profile
status
m
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i

3A.164/51 - - 404, 413, 480, 486, 500, 503, 600, 603
4
Item
Header
Ref.
0A
1
3
5
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
m
m
m
m
Profile
status
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
i
i
i
i
Profile
status
i
i
i
i
5
8
Item
Header
Ref.
1
2
5
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
9
12
Item
Header
Ref.
0A
1
2
5
6
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
Profile
status
m
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i
13
16
Item
Header
Ref.
1
2
3
3A
4
7
Accept
Accept-Encoding
Accept-Language
Allow
Error-Info
Supported
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
m
m
m
17
213
Profile
status
m
m
m
m
m
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
i
i
i
Profile
status
i
i
i
i
i
i

3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Error-Info
[26] 20.18 m
m
[26] 20.18 i
i
Supported
[26] 20.37 m
m
[26] 20.37 i
i
Unsupported
[26] 20.40 m
m
[26] 20.40 c3
c3
Ref.
0A
1
4
5
c3:
4
Table A.229A: Supported headers within the NOTIFY response
7
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
o
Security-Server
[48] 2
c1
c1
[48] 2
n/a
n/a
Supported
[26] 20.37 m
m
[26] 20.37 m
m
Ref.
1
2
3
4
c1:
8
11
Item
Header
Ref.
0A
1
4
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
12
15
Item
Header
Ref.
0A
1
3
c1:
NOTE:
Allow
Allow-Events
Sending
RFC
status
m
m
Profile
status
m
m
Ref.
Receiving
RFC
status
i
c1
Profile
status
[26] 20.5
[26] 20.5
i
[28]
[28]
c1
87.2.2
87.2.2
Error-Info
[26] 20.18 m
m
[26] 20.18 i
i
214
1
Table A.232: Supported message bodies within the NOTIFY response
3
Item
Header
Ref.
Sending
RFC
status
215
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.2.4.9
OPTIONS method

3
Table A.233: Supported headers within the OPTIONS request
216
Item
Header
Ref.
Profile
status
m
m
m
m
m
Ref.
Profile
status
Accept
Accept-Encoding
Accept-Language
Allow
Allow-Events
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
19A
19B
19C
19D
Authorization
m
m
i
i
Call-ID
m
m
m
m
Call-Info
m
m
c4
c4
Contact
m
m
i
i
Content-Disposition
m
m
i
i
Content-Encoding
m
m
i
i
Content-Language
m
m
i
i
Content-Length
m
m
m
m
Content-Type
m
m
i
i
Cseq
m
m
m
m
Date
m
m
c2
c2
From
m
m
m
m
Max-Forwards
m
m
m
m
MIME-Version
m
m
i
i
Organization
m
m
c3
c3
c23
c23
c24
c24
P-Asserted-Identity
c10
c10
c11
c11
P-Called-Party-ID
c14
c14
c15
c16
c21
c22
c22
Addresses
P-Charging-Vector
[52] 4.6
c19
c19
[52] 4.6
c20
c20
[34] 9.2
x
x
[34] 9.2
c9
c9
[52] 4.3
c17
n/a
[52] 4.3
c18
n/a
Privacy
[33] 4.2
c12
c12
[33] 4.2
c13
c13
Proxy-Authorization
[26] 20.28 m
m
[26] 20.28 c8
c8
Proxy-Require
[26] 20.29 m
m
[26] 20.29 m
m
Record-Route
[26] 20.30 m
m
[26] 20.30 c7
c7
Require
[26] 20.32 m
m
[26] 20.32 c5
c5
Route
[26] 20.34 m
m
[26] 20.34 m
m
Security-Client
[48] 2.3.1
x
x
[48] 2.3.1
c25
c25
Security-Verify
[48] 2.3.1
x
x
[48] 2.3.1
c25
c25
Supported
[26] 20.37 m
m
[26] 20.37 c6
c6
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
dialog.
c6:
c7:
c8:
c9:
c10:
c11:
217
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Receiving
RFC
status
i
i
i
i
c1
1
2
3
3A
4
19E
19F
19G
19H
20
21
22
23
24
24A
24B
25
26
27
28
29
c1:
c2:
c3:
c4:
c5:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Sending
RFC
status
m
m
m
m
m
i
i
i
i
c1
c12:
c13:
c14:
c15:
c16:
c17:
c18:
c19:
c20:
c21:
c22:
c23:
c24:
c25:
NOTE:
trust network.
extension.
extension.
extension.
1
Table A.234: Supported message bodies within the OPTIONS request
3
Item
Header
Ref.
Sending
RFC
status
Profile
status
Ref.
Receiving
RFC
status
Profile
status
Receiving
RFC
status
m
m
m
c1
m
m
m
Profile
status
m
m
m
c1
m
m
m
4
7
Item
Header
Sending
RFC
Profile
Ref.
status
status
Call-ID
[26] 20.8
m
m
[26] 20.8
Content-Length
[26] 20.14 m
m
[26] 20.14
Cseq
[26] 20.16 m
m
[26] 20.16
Date
[26] 20.17 m
m
[26] 20.17
From
[26] 20.20 m
m
[26] 20.20
To
[26] 20.39 m
m
[26] 20.39
Via
[26] 20.42 m
m
[26] 20.42
Ref.
1
2
3
4
5
6
7
c1:
218

2 Table A.236: Supported headers within the OPTIONS response - all remaining status-codes
219
Item
Header
Ref.
1
1A
2
3
4
5
6
7
8
9
10
11
11A
11B
11C
11D
11E
11F
11G
11H
12
13
13A
14
15
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
c14:
c15:
Sending
RFC
status
m
m
m
m
m
m
m
m
m
m
m
m
c13
c5
c11
Ref.
Receiving
RFC
status
m
c3
i
i
i
m
i
m
c1
m
i
c2
c14
c6
c12
Profile
status
m
c3
i
i
i
m
i
m
c1
m
i
c2
c14
c6
c12
Call-ID
[26] 20.8
[26] 20.8
Call-Info
[26] 20.9
[26] 20.9
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
Organization
[26] 20.25
[26] 20.25
[52] 4.4
[52] 4.4
P-Asserted-Identity
[34] 9.1
[34] 9.1
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c9
c9
[52] 4.6
c10
c10
[34] 9.2
x
x
[34] 9.2
c4
n/a
Privacy
[33] 4.2
c7
c7
[33] 4.2
c8
c8
Require
[26] 20.32 m
m
[26] 20.32 c15
c15
Server
[26] 20.35 m
m
[26] 20.35 i
i
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 m
m
[26] 20.43 i
i
trust network.
extension.
extension.
extension.
Profile
status
m
m
m
m
m
m
m
m
m
m
m
m
c13
c5
c11
220

3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Accept
[26] 20.1
m
m
[26] 20.1
i
i
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Authentication-Info
[26] 20.6
m
m
[26] 20.6
i
i
Contact
[26] 20.10 m
m
[26] 20.10 i
i
Record-Route
[26] 20.30 m
m
[26] 20.30 c3
c3
Supported
[26] 20.37 m
m
[26] 20.37 i
i
Ref.
1
2
3
5
9
12
c3:
4
7(Ambiguous)
8
Item
Header
Sending
RFC
Profile
status
status
Allow
[26] 20.5
m
m
Contact
[26] 20.10 m
m
Error-Info
[26] 20.18 m
m
Supported
[26] 20.37 m
m
Ref.
1
3
4
7
c1:
Ref.
[26] 20.5
[26] 20.10
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
c1
i
i
Profile
status
i
c1
i
i
9
12
Item
Header
Ref.
1
3
4
7
10
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
13
221
Profile
status
m
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i

3A.164/51 - - 404, 413, 480, 486, 500, 503, 600, 603
4
Item
Header
Ref.
1
3
5
7
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
m
m
m
m
Profile
status
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
i
i
i
i
Profile
status
i
i
i
i
5
8
Item
Header
Ref.
2
4
7
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
9
12
Item
Header
Ref.
1
3
4
7
8
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
Profile
status
m
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i
13
16
Item
Header
Ref.
1
2
3
4
5
8
Accept
Accept-Encoding
Accept-Language
Allow
Error-Info
Supported
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
m
m
m
17
222
Profile
status
m
m
m
m
m
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
i
i
i
Profile
status
i
i
i
i
i
i

3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Error-Info
[26] 20.18 m
m
[26] 20.18 i
i
Supported
[26] 20.37 m
m
[26] 20.37 i
i
Unsupported
[26] 20.40 m
m
[26] 20.40 c3
c3
Ref.
1
3
6
7
c3:
4
Table A.244A: Supported headers within the OPTIONS response
7
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
o
Security-Server
[48] 2
c1
c1
[48] 2
n/a
n/a
Supported
[26] 20.37 m
m
[26] 20.37 m
m
Ref.
1
2
3
4
c1:
8
11
Item
Header
Ref.
1
4
7
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
12
Table A.246: Supported message bodies within the OPTIONS response
14
Item
Header
Ref.
Sending
RFC
status
15
223
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.2.4.10 PRACK method

3
[CR481R1]Table A.247: Supported headers within the PRACK request
224
Item
Header
Ref.
Profile
status
m
m
m
m
m
Ref.
Profile
status
Accept
Accept-Encoding
Accept-Language
Allow
Allow-Events
5
6
7
8
9
10
11
12
13
14
15
16
16A
16B
Authorization
m
m
i
i
Call-ID
m
m
m
m
Content-Disposition
m
m
i
c3
Content-Encoding
m
m
i
c3
Content-Language
m
m
i
c3
Content-Length
m
m
m
m
Content-Type
m
m
i
c3
Cseq
m
m
m
m
Date
m
m
c2
c2
From
m
m
m
m
Max-Forwards
om
om
n/am
n/am
MIME-Version
m
m
i
c3
c14
c14
c15
c15
c12
c13
c13
Addresses
P-Charging-Vector
[52] 4.6
c10
n/a
[52] 4.6
c11
n/a
Privacy
[33] 4.2
c8
c8
[33] 4.2
c9
c9
Proxy-Authorization
[26] 20.28 m
m
[26] 20.28 c4
c4
Proxy-Require
[26] 20.29 m
m
[26] 20.29 m
m
RAck
[27] 7.2
m
m
[27] 7.2
i
i
Record-Route
[26] 20.30 m
m
[26] 20.30 c7
c7
Require
[26] 20.32 m
m
[26] 20.32 c5
c5
Route
[26] 20.34 m
m
[26] 20.34 m
m
Supported
[26] 20.37 m
m
[26] 20.37 c6
c6
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
IF A.162/14 THEN 0 ELSE i - - the requirement to be able to insert itself in the subsequent transactions in a
dialog.
extension.
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
c14:
225
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.22
[26] 20.24
[52] 4.4
[52] 4.5
Receiving
RFC
status
i
i
i
i
c1
1
2
3
3A
4
16C
16D
17
18
19
20
21
22
23
24
25
26
27
c1:
c2:
c3:
c4:
c5:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.22
[26] 20.24
[52] 4.4
[52] 4.5
Sending
RFC
status
m
m
m
m
m
i
i
i
i
c1
c15:
NOTE:
extension.
extension.
1
Table A.248: Supported message bodies within the PRACK request
3
Item
Header
Ref.
Sending
RFC
status
Profile
status
Ref.
Receiving
RFC
status
Profile
status
Receiving
RFC
status
m
m
m
c1
m
m
m
Profile
status
m
m
m
c1
m
m
m
4
7
Item
Header
Sending
RFC
Profile
Ref.
status
status
Call-ID
[26] 20.8
m
m
[26] 20.8
Content-Length
[26] 20.14 m
m
[26] 20.14
Cseq
[26] 20.16 m
m
[26] 20.16
Date
[26] 20.17 m
m
[26] 20.17
From
[26] 20.20 m
m
[26] 20.20
To
[26] 20.39 m
m
[26] 20.39
Via
[26] 20.42 m
m
[26] 20.42
Ref.
1
2
3
4
5
6
7
c1:
226
Table A.250: Supported headers within the PRACK response - all remaining status-codes
Item
Header
Ref.
1
2
3
4
5
6
7
8
9
10
10A
10B
10C
10D
10E
10F
11
12
12A
13
14
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
Sending
RFC
status
m
m
m
m
m
m
m
m
m
m
c9
c7
Profile
status
m
m
m
m
m
m
m
m
m
m
c9
c7
Ref.
Receiving
RFC
status
m
i
i
i
m
i
m
c1
m
i
c10
c8
Profile
status
m
c2
c2
c2
m
c2
m
c1
m
c2
c10
c8
Call-ID
[26] 20.8
[26] 20.8
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
[52] 4.4
[52] 4.4
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c5
n/a
[52] 4.6
c6
n/a
Privacy
[33] 4.2
c3
c3
[33] 4.2
c4
c4
Require
[26] 20.32 m
m
[26] 20.32 c11
c11
Server
[26] 20.35 m
m
[26] 20.35 i
i
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 m
m
[26] 20.43 i
i
extension.
extension.
extension.
227
1
4
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Authentication-Info
[26] 20.6
m
m
[26] 20.6
i
i
Record-Route
[26] 20.30 m
m
[26] 20.30 c3
c3
Supported
[26] 20.37 m
m
[26] 20.37 i
i
Ref.
0A
0B
1
4
c3:
5
8(Ambiguous)
9
Item
Header
Sending
RFC
Profile
status
status
Allow
[26] 20.5
m
m
Contact
[26] 20.10 m
m
Error-Info
[26] 20.18 m
m
Supported
[26] 20.37 m
m
Ref.
0A
1
2
5
c1:
Ref.
[26] 20.5
[26] 20.10
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
c1
i
i
Profile
status
i
c1
i
i
10
13
Item
Header
Ref.
0A
1
2
5
8
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
14
228
Profile
status
m
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i

3A.164/51 - - 404, 413, 480, 486, 500, 503, 600, 603
4
Item
Header
Ref.
0A
1
3
5
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
m
m
m
m
Profile
status
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
i
i
i
i
Profile
status
i
i
i
i
5
8
Item
Header
Ref.
1
2
5
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
9
12
Item
Header
Ref.
0A
1
2
5
6
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
Profile
status
m
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i
13
16
Item
Header
Ref.
1
2
3
3A
4
7
Accept
Accept-Encoding
Accept-Language
Allow
Error-Info
Supported
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
m
m
m
17
229
Profile
status
m
m
m
m
m
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
i
i
i
Profile
status
i
i
i
i
i
i

3
Item
Header
Ref.
0A
1
4
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
4
Table A.258A: Supported headers within the PRACK response
7
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
o
Security-Server
[48] 2
c1
c1
[48] 2
n/a
n/a
Supported
[26] 20.37 m
m
[26] 20.37 m
m
Ref.
1
2
3
4
c1:
8
11
Item
Header
Ref.
0A
1
4
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
12
Table A.260: Supported message bodies within the PRACK response
14
Item
Header
Ref.
Sending
RFC
status
15
230
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.2.4.11 REFER method

3
Table A.261: Supported headers within the REFER request
231
Item
Header
Ref.
Profile
status
m
m
m
m
m
Ref.
Profile
status
Accept
Accept-Encoding
Accept-Language
Allow
Allow-Events
3
4
5
5A
5B
5C
6
7
8
9
10
11
12
13
14
14A
14B
14C
14D
Authorization
m
m
i
i
Call-ID
m
m
m
m
Contact
m
m
i
i
Content-Disposition
m
m
i
i
Content-Encoding
m
m
i
i
Content-Language
m
m
i
i
Content-Length
m
m
m
m
Content-Type
m
m
i
i
Cseq
m
m
m
m
Date
m
m
c2
c2
Expires
m
m
i
i
From
m
m
m
m
Max-Forwards
m
m
m
m
MIME-Version
m
m
i
i
Organization
m
m
c3
c3
c22
c22
c23
c23
P-Asserted-Identity
c9
c9
c10
c10
P-Called-Party-ID
c13
c13
c14
c15
c20
c21
c21
Addresses
P-Charging-Vector
[52] 4.6
c18
c18
[52] 4.6
c19
c19
[34] 9.2
x
x
[34] 9.2
c8
c8
[52] 4.3
c16
n/a
[52] 4.3
c17
n/a
Privacy
[33] 4.2
c11
c11
[33] 4.2
c12
c12
Proxy-Authorization
[26] 20.28 m
m
[26] 20.28 c4
c4
Proxy-Require
[26] 20.29 m
m
[26] 20.29 m
m
Record-Route
[26] 20.30 m
m
[26] 20.30 c7
c7
Refer-To
[36] 3
c3
c3
[36] 3
c4
c4
Require
[26] 20.32 m
m
[26] 20.32 c5
c5
Route
[26] 20.34 m
m
[26] 20.34 m
m
Security-Client
[48] 2.3.1
x
x
[48] 2.3.1
c24
c24
Security-Verify
[48] 2.3.1
x
x
[48] 2.3.1
c24
c24
Subject
[26] 20.36 m
m
[26] 20.36 i
i
Supported
[26] 20.37 m
m
[26] 20.37 c6
c6
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
dialog.
c6:
c7:
c8:
c9:
232
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.19
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Receiving
RFC
status
i
i
i
i
c1
0A
0B
1
1A
2
14E
14F
14G
14H
15
16
17
18
19
20
20A
20B
20C
21
22
23
24
25
c1:
c2:
c3:
c4:
c5:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.19
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Sending
RFC
status
m
m
m
m
m
i
i
i
i
c1
c10:
c11:
c12:
c13:
c14:
c15:
c16:
c17:
c18:
c19:
c20:
c21:
c22:
c23:
c24:
NOTE:
trust network.
extension.
extension.
extension.
1
Table A.262: Supported message bodies within the REFER request
3
Item
Header
Ref.
Sending
RFC
status
Profile
status
Ref.
Receiving
RFC
status
Profile
status
Receiving
RFC
status
m
m
m
c1
m
m
m
Profile
status
m
m
m
c1
m
m
m
4
7
Item
Header
Sending
RFC
Profile
Ref.
status
status
Call-ID
[26] 20.8
m
m
[26] 20.8
Content-Length
[26] 20.14 m
m
[26] 20.14
Cseq
[26] 20.16 m
m
[26] 20.16
Date
[26] 20.17 m
m
[26] 20.17
From
[26] 20.20 m
m
[26] 20.20
To
[26] 20.39 m
m
[26] 20.39
Via
[26] 20.42 m
m
[26] 20.42
Ref.
1
2
3
4
5
6
7
c1:
233
Table A.264: Supported headers within the REFER response - all remaining status-codes
Item
Header
Ref.
1
1A
2
3
4
5
6
7
8
9
10
10A
10B
10C
10D
10E
10F
10G
10H
11
12
12A
13
14
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
c14:
Sending
RFC
status
m
m
m
m
m
m
m
m
m
m
m
c12
c4
c10
Ref.
Receiving
RFC
status
m
i
i
i
m
i
m
c1
m
i
c2
c13
c5
c11
Profile
status
m
i
i
i
m
i
m
c1
m
i
c2
c13
c5
c11
Call-ID
[26] 20.8
[26] 20.8
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
Organization
[26] 20.25
[26] 20.25
[52] 4.4
[52] 4.4
P-Asserted-Identity
[34] 9.1
[34] 9.1
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c8
c8
[52] 4.6
c9
c9
[34] 9.2
x
x
[34] 9.2
c3
n/a
Privacy
[33] 4.2
c6
c6
[33] 4.2
c7
c7
Require
[26] 20.32 m
m
[26] 20.32 c14
c14
Server
[26] 20.35 m
m
[26] 20.35 i
i
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 m
m
[26] 20.43 i
i
trust network.
extension.
extension.
extension.
Profile
status
m
m
m
m
m
m
m
m
m
m
m
c12
c4
c10
234

2Prerequisite: A.164/7 - - 202 (Accepted)
3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Authentication-Info
[26] 20.6
m
m
[26] 20.6
i
i
Contact
[26] 20.10 m
m
[26] 20.10 i
i
Record-Route
[26] 20.30 m
m
[26] 20.30 c3
c3
Supported
[26] 20.37 m
m
[26] 20.37 i
i
Ref.
1
2
3
5
8
c3:
4
7(Ambiguous)
8
Item
Header
Sending
RFC
Profile
status
status
Allow
[26] 20.5
m
m
Contact
[26] 20.10 m
m
Error-Info
[26] 20.18 m
m
Supported
[26] 20.37 m
m
Ref.
1
2
3
7
c1:
Ref.
[26] 20.5
[26] 20.10
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
c1
i
i
Profile
status
i
c1
i
i
9
11Prerequisite: A.164/8 OR A.164/9 OR A.164/10 OR A.164/11 OR A.164/12 - - 401 (Unauthorized)
12
Item
Header
Ref.
1
2
4
7
10
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
13
235
Profile
status
m
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i

3A.164/51 - - 404, 413, 480, 486, 500, 503, 600, 603
4
Item
Header
Ref.
1
3
6
8
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
m
m
m
m
Profile
status
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
i
i
i
i
Profile
status
i
i
i
i
5
8
Item
Header
Ref.
2
3
7
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
9
12
Item
Header
Ref.
1
2
4
7
8
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
o
m
m
Profile
status
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
o
i
i
Profile
status
i
i
i
i
13
16
Item
Header
Ref.
1
2
3
3A
4
8
Accept
Accept-Encoding
Accept-Language
Allow
Error-Info
Supported
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
m
m
m
17
236
Profile
status
m
m
m
m
m
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
i
i
i
Profile
status
i
i
i
i
i
i

3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Error-Info
[26] 20.18 m
m
[26] 20.18 i
i
Supported
[26] 20.37 m
m
[26] 20.37 i
i
Unsupported
[26] 20.40 m
m
[26] 20.40 c3
c3
Ref.
1
3
7
8
c3:
4
Table A.272A: Supported headers within the REFER response
7
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
o
Security-Server
[48] 2
c1
c1
[48] 2
n/a
n/a
Supported
[26] 20.37 m
m
[26] 20.37 m
m
Ref.
1
2
3
4
c1:
8
11
Item
Header
Ref.
1
3
7
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
12
Table A.274: Supported message bodies within the REFER response
14
Item
Header
Ref.
Sending
RFC
status
15
237
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.2.4.12 REGISTER method

3
[CR481R1]Table A.275: Supported headers within the REGISTER request
238
Item
Header
Ref.
Profile
status
m
m
m
m
m
Ref.
i
i
i
i
c1
Profile
status
Accept
Accept-Encoding
Accept-Language
Allow
Allow-Events
Authorization
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
20A
20B
Call-ID
m
m
m
m
Call-Info
m
m
c2
c2
Contact
m
m
i
i
Content-Disposition
m
m
i
i
Content-Encoding
m
m
i
i
Content-Language
m
m
i
i
Content-Length
m
m
m
m
Content-Type
m
m
i
i
Cseq
m
m
m
m
Date
m
m
m
m
Expires
m
m
i
i
From
m
m
m
m
Max-Forwards
m
m
m
m
MIME-Version
m
m
i
i
Organization
m
m
c3
c3
c16
c16
c17
c17
c14
c15
c15
Addresses
P-Charging-Vector
[52] 4.6
c12
c12
[52] 4.6
c13
c13
[52] 4.3
c10
c10
[52] 4.3
c11
c11
Path
[35] 4.2
c6
c6
[35] 4.2
c6
c6
Privacy
[33] 4.2
c8
c8
[33] 4.2
c9
c9
Proxy-Authorization
[26] 20.28 m
m
[26] 20.28 c7
c7
Proxy-Require
[26] 20.29 m
m
[26] 20.29 m
m
Require
[26] 20.32 m
m
[26] 20.32 c4
c4
Route
[26] 20.34 m
m
[26] 20.34 m
m
Security-Client
[48] 2.3.1
x
x
[48] 2.3.1
c18
c18
Security-Verify
[48] 2.3.1
x
x
[48] 2.3.1
c18
c18
Supported
[26] 20.37 m
m
[26] 20.37 c5
c5
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
IF A.162/29 THEN m ELSE n/a - - PATH header support.
c5:
c6:
c7:
c8:
c9:
c10:
c11:
c12:
239
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7,
[49]
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.19
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[52] 4.5
Receiving
RFC
status
i
i
i
i
c1
1
2
3
3A
4
20C
20D
20E
20F
21
22
23
24
24A
24B
25
26
27
28
29
c1:
c2:
c3:
c4:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7,
[49]
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.19
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[52] 4.5
Sending
RFC
status
m
m
m
m
m
c13:
c14:
c15:
c16:
c17:
c18:
NOTE:
extension.
extension.
extension.
1
Table A.276: Supported message bodies within the REGISTER request
3
Item
Header
Sending
RFC
status
Ref.
Profile
status
Ref.
Receiving
RFC
status
Profile
status
Receiving
RFC
status
m
m
m
m
m
m
m
Profile
status
m
m
m
m
m
m
m
4
7
Item
Header
Ref.
1
2
3
4
5
6
7
Call-ID
Content-Length
Cseq
Date
From
To
Via
[26] 20.8
[26] 20.14
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.39
[26] 20.42
Sending
RFC
status
m
m
m
m
m
m
m
240
Profile
status
m
m
m
m
m
m
m
Ref.
[26] 20.8
[26] 20.14
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.39
[26] 20.42

2 Table A.278: Supported headers within the REGISTER response - all remaining status-codes
Item
Header
Ref.
1
1A
2
3
4
5
6
7
8
9
10
11
11A
11B
11C
11D
11E
11F
12
13
13A
14
15
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
Sending
RFC
status
m
m
m
m
m
m
m
m
m
m
m
m
c9
c7
Ref.
Receiving
RFC
status
m
c2
i
i
i
m
i
m
m
m
i
c1
c10
c8
Profile
status
m
c2
i
i
i
m
i
m
m
m
i
c1
c10
c8
Call-ID
[26] 20.8
[26] 20.8
Call-Info
[26] 20.9
[26] 20.9
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
Organization
[26] 20.25
[26] 20.25
[52] 4.4
[52] 4.4
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c5
c5
[52] 4.6
c6
c6
Privacy
[33] 4.2
c3
c3
[33] 4.2
c4
c4
Require
[26] 20.32 m
m
[26] 20.32 c11
c11
Server
[26] 20.35 m
m
[26] 20.35 i
i
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 m
m
[26] 20.43 i
i
extension.
extension.
extension.
Profile
status
m
m
m
m
m
m
m
m
m
m
m
m
c9
c7
241

3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Accept
[26] 20.1
m
m
[26] 20.1
i
i
Accept-Encoding
[26] 20.2
m
m
[26] 20.2
i
i
Accept-Language
[26] 20.3
m
m
[26] 20.3
i
i
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Authentication-Info
[26] 20.6
m
m
[26] 20.6
i
i
Contact
[26] 20.10 m
m
[26] 20.10 i
i
P-Associated-URI
[52] 4.1
c8
c8
[52] 4.1
c9
c10
Path
[35] 4.2
c3
c3
[35] 4.2
c4
c4
Service-Route
[38] 6
c5
c5
[38] 6
c6
c7
Supported
[26] 20.37 m
m
[26] 20.37 i
i
IF A.3/2 OR A.3/3A THEN m ELSE n/a - - P-CSCF or I-CSCF (THIG).
IF A.162/29 THEN m ELSE n/a - - Path extension support.
IF A.162/29 THEN i ELSE n/a - - Path extension support.
IF A.162/32 THEN m ELSE n/a - - Service-Route extension support.
IF A.162/32 THEN i ELSE n/a - - Service-Route extension support.
IF A.162/32 THEN (IF A.3/2 THEN m ELSE i) ELSE n/a - - Service-Route extension and P-CSCF.
IF A.162/36 THEN m ELSE n/a - - the P-Associated-URI extension.
IF A.162/36 THEN i ELSE n/a - - the P-Associated-URI extension.
IF A.162/36 AND A.3/2 THEN m ELSE IF A.162/36 AND A.3/3 THEN i ELSE n/a - - the P-Associated-URI
extension and P-CSCF or I-CSCF.
Ref.
1
1A
1B
2
3
5
5A
6
8
9
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
4
7(Ambiguous)
8
Item
Header
Sending
RFC
Profile
status
status
Allow
[26] 20.5
m
m
Contact
[26] 20.10 m
m
Error-Info
[26] 20.18 m
m
Supported
[26] 20.37 m
m
Ref.
1
3
4
8
c2:
242
Ref.
[26] 20.5
[26] 20.10
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
c2
i
i
Profile
status
i
c2
i
i

3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Error-Info
[26] 20.18 m
m
[26] 20.18 i
i
Proxy-Authenticate
[26] 20.27 m
m
[26] 20.27 m
m
Security-Server
[48] 2
x
c1
[48] 2
n/a
n/a
Supported
[26] 20.37 m
m
[26] 20.37 i
i
WWW-Authenticate
[26] 20.44 m
m
[26] 20.44 i
i
Ref.
1
3
4
6
7
10
c1:
4
7A.164/51 - - 404, 413, 480, 486, 500, 503, 600, 603
8
Item
Header
Ref.
1
3
6
8
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
m
m
m
m
Profile
status
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
i
i
i
i
Profile
status
i
i
i
i
9
12
Item
Header
Ref.
2
4
8
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
13
16
Item
Header
Ref.
1
3
5
8
9
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
17
243
Profile
status
m
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i

3
Item
Header
Ref.
1
2
3
4
5
9
Accept
Accept-Encoding
Accept-Language
Allow
Error-Info
Supported
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
m
m
m
Profile
status
m
m
m
m
m
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
i
i
i
Profile
status
i
i
i
i
i
i
4
7
Item
Header
Ref.
1
3
7
8
c3:
Allow
Error-Info
Supported
Unsupported
IF A.162/17 THEN m ELSE.i
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Sending
RFC
status
m
m
m
m
Profile
status
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
[26] 20.40
Receiving
RFC
status
i
i
i
c3
Profile
status
i
i
i
c3
8
Table A.286A: Supported headers within the REGISTER response
11
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
o
Security-Server
[48] 2
c1
c1
[48] 2
n/a
n/a
Supported
[26] 20.37 m
m
[26] 20.37 m
m
Ref.
1
2
3
4
c1:
12
15
Item
Header
Ref.
1
3
5
8
Allow
Error-Info
Min-Expires
Supported
[26] 20.5
[26] 20.18
[26] 20.23
[26] 20.37
Sending
RFC
status
m
o
m
m
16
244
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.23
[26] 20.37
Receiving
RFC
status
i
o
i
i
Profile
status
i
i
i

3
Item
Header
Ref.
1
3
7
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
4
Table A.289: Supported message bodies within the REGISTER response
6
Item
Header
Ref.
Sending
RFC
status
245
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.2.4.13 SUBSCRIBE method

3
Table A.290: Supported headers within the SUBSCRIBE request
246
Item
Header
Ref.
Profile
status
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
Ref.
i
i
i
i
c1
i
m
i
i
i
i
m
i
m
c2
m
i
m
i
i
i
i
m
i
m
c2
m
Profile
status
Accept
Accept-Encoding
Accept-Language
Allow
Allow-Events
5
6
6A
7
8
9
10
11
12
13
14
Authorization
Call-ID
Contact
Content-Disposition
Content-Encoding
Content-Language
Content-Length
Content-Type
Cseq
Date
Event
15
16
17
18
18A
18B
18C
18D
18E
Expires
m
m
i
i
From
m
m
m
m
Max-Forwards
m
m
m
m
MIME-Version
m
m
i
i
Organization
m
m
c3
c3
c22
c22
c23
c23
P-Asserted-Identity
c9
c9
c10
c10
P-Called-Party-ID
c13
c13
c14
c15
c20
c21
c21
Addresses
P-Charging-Vector
[52] 4.6
c18
c18
[52] 4.6
c19
c19
[34] 9.2
x
x
[34] 9.2
c8
c8
[52] 4.3
c16
n/a
[52] 4.3
c17
n/a
Privacy
[33] 4.2
c11
c11
[33] 4.2
c12
c12
Proxy-Authorization
[26] 20.28 m
m
[26] 20.28 c4
c4
Proxy-Require
[26] 20.29 m
m
[26] 20.29 m
m
Record-Route
[26] 20.30 m
m
[26] 20.30 c7
c7
Require
[26] 20.32 m
m
[26] 20.32 c5
c5
Route
[26] 20.34 m
m
[26] 20.34 m
m
Security-Client
[48] 2.3.1
x
x
[48] 2.3.1
c24
c24
Security-Verify
[48] 2.3.1
x
x
[48] 2.3.1
c24
c24
Supported
[26] 20.37 m
m
[26] 20.37 c6
c6
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
dialog.
c6:
c7:
c8:
c9:
247
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[28]
87.2.1
[26] 20.19
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Receiving
RFC
status
i
i
i
i
c1
1
2
3
3A
4
18F
18G
18H
18I
19
20
21
22
23
23A
23B
24
25
26
27
28
c1:
c2:
c3:
c4:
c5:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[28]
87.2.1
[26] 20.19
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[34] 9.1
[52] 4.2
[52] 4.5
Sending
RFC
status
m
m
m
m
m
c10:
c11:
c12:
c13:
c14:
c15:
c16:
c17:
c18:
c19:
c20:
c21:
c22:
c23:
c24:
NOTE:
trust network.
extension.
extension.
extension.
1
Table A.291: Supported message bodies within the SUBSCRIBE request
3
Item
Header
Ref.
Sending
RFC
status
248
Profile
status
Ref.
Receiving
RFC
status
Profile
status
Table A.292: Supported headers within the SUBSCRIBE response - all status-codes
2
Item
Header
Ref.
1
2
3
4
5
6
7
8
9
10
10A
10B
10C
10D
10E
10F
10G
10H
10I
11
12
12A
13
14
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
c14:
Sending
RFC
status
m
m
m
m
m
m
m
m
m
m
m
c12
c4
c10
Profile
status
m
m
m
m
m
m
m
m
m
m
m
c12
c4
c10
Ref.
Receiving
RFC
status
m
i
i
i
m
i
m
c1
m
i
c2
c13
c5
c11
Profile
status
m
i
i
i
m
i
m
c1
m
i
c2
c13
c5
c11
Call-ID
[26] 20.8
[26] 20.8
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
Organization
[26] 20.25
[26] 20.25
[52] 4.4
[52] 4.4
P-Asserted-Identity
[34] 9.1
[34] 9.1
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c8
c8
[52] 4.6
c9
c9
[34] 9.2
x
x
[34] 9.2
c3
n/a
Privacy
[33] 4.2
c6
c6
[33] 4.2
c7
c7
Require
[26] 20.32 m
m
[26] 20.32 c14
c14
Server
[26] 20.35 m
m
[26] 20.35 i
i
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 m
m
[26] 20.43 i
i
trust network.
extension.
extension.
extension.
249
1
3Prerequisite: A.164/6 AND A.164/7 - - 2xx
4
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Authentication-Info
[26] 20.6
m
m
[26] 20.6
i
i
Contact
[26] 20.10 m
m
[26] 20.10 i
i
Expires
[26] 20.19 m
m
[26] 20.19 i
i
Record-Route
[26] 20.30 m
m
[26] 20.30 c3
c3
Supported
[26] 20.37 m
m
[26] 20.37 i
i
Ref.
0A
1
1A
2
3
6
c3:
5
8(Ambiguous)
9
Item
Header
Sending
RFC
Profile
status
status
Allow
[26] 20.5
m
m
Contact
[26] 20.10 m
m
Error-Info
[26] 20.18 m
m
Supported
[26] 20.37 m
m
Ref.
0A
1
2
5
c1:
Ref.
[26] 20.5
[26] 20.10
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
c1
i
i
Profile
status
i
c1
i
i
10
13
Item
Header
Ref.
0A
1
2
5
8
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
14
250
Profile
status
m
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i

2Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/50 OR A.164/51 - 3404, 413, 480, 486, 500, 600, 603
4
Item
Header
Ref.
0A
1
3
5
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
m
m
m
m
Profile
status
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
i
i
i
i
Profile
status
i
i
i
i
5
8
Item
Header
Ref.
1
2
5
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
9
12
Item
Header
Ref.
0A
1
2
5
6
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
Profile
status
m
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i
13
16
Item
Header
Ref.
1
2
3
4
5
7
Accept
Accept-Encoding
Accept-Language
Allow
Error-Info
Supported
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
m
m
m
17
251
Profile
status
m
m
m
m
m
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
i
i
i
Profile
status
i
i
i
i
i
i

3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Error-Info
[26] 20.18 m
m
[26] 20.18 i
i
Supported
[26] 20.37 m
m
[26] 20.37 i
i
Unsupported
[26] 20.40 m
m
[26] 20.40 c3
c3
Ref.
0A
1
4
5
c3:
4
7
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
o
Security-Server
[48] 2
c1
c1
[48] 2
n/a
n/a
Supported
[26] 20.37 m
m
[26] 20.37 m
m
Ref.
1
2
3
4
c1:
8
11
Item
Header
Ref.
0A
1
2
5
Allow
Error-Info
Min-Expires
Supported
[26] 20.5
[26] 20.18
[26] 20.23
[26] 20.37
Sending
RFC
status
m
m
m
m
Profile
status
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.23
[26] 20.37
Receiving
RFC
status
i
i
i
i
Profile
status
i
i
i
i
12
15
Item
Header
Ref.
0A
1
4
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
16
252
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i

3
Item
Header
Sending
RFC
status
m
m
Ref.
0A
1
3
c1:
NOTE:
Allow
Allow-Events
Profile
status
m
m
Ref.
Receiving
RFC
status
i
c1
Profile
status
[26] 20.5
[26] 20.5
i
[28]
[28]
c1
87.2.2
87.2.2
Error-Info
[26] 20.18 m
m
[26] 20.18 i
i
4
7
Item
Header
Ref.
0A
1
3
5
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
m
m
m
m
Profile
status
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
i
i
i
i
Profile
status
i
i
i
i
8
Table A.304: Supported message bodies within the SUBSCRIBE response
10
Item
Header
Ref.
Sending
RFC
status
11
253
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.2.2.4.14 UPDATE method

3
Table A.305: Supported headers within the UPDATE request
254
Item
Header
Ref.
Profile
status
m
m
m
m
m
Ref.
Profile
status
Accept
Accept-Encoding
Accept-Language
Allow
Allow-Events
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
20A
20B
Authorization
m
m
i
i
Call-ID
m
m
m
m
Call-Info
m
m
c8
c8
Contact
m
m
i
i
Content-Disposition
m
m
c4
c4
Content-Encoding
m
m
c4
c4
Content-Language
m
m
c4
c4
Content-Length
m
m
m
m
Content-Type
m
m
c4
c4
Cseq
m
m
m
m
Date
m
m
c2
c2
From
m
m
m
m
Max-Forwards
m
m
m
m
MIME-Version
m
m
i
c4
Organization
m
m
c3
c3
c16
c16
c17
c17
c14
c15
c15
Addresses
P-Charging-Vector
[52] 4.6
c12
c12
[52] 4.6
c13
c13
Privacy
[33] 4.2
c10
c10
[33] 4.2
c11
c11
Proxy-Authorization
[26] 20.28 m
m
[26] 20.28 c9
c9
Proxy-Require
[26] 20.29 m
m
[26] 20.29 m
m
Record-Route
[26] 20.30 m
m
[26] 20.30 c7
c7
Require
[26] 20.32 m
m
[26] 20.32 c5
c5
Security-Client
[48] 2.3.1
x
x
[48] 2.3.1
c18
c18
Security-Verify
[48] 2.3.1
x
x
[48] 2.3.1
c18
c18
Route
[26] 20.34 m
m
[26] 20.34 m
m
Supported
[26] 20.37 m
m
[26] 20.37 c6
c6
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
dialog.
extension.
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
255
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[52] 4.5
Receiving
RFC
status
i
i
i
i
c1
1
2
3
4
5
20C
20D
21
22
23
24
25A
25B
25
26
27
28
29
30
c1:
c2:
c3:
c4:
c5:
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[28]
87.2.2
[26] 20.7
[26] 20.8
[26] 20.9
[26] 20.10
[26] 20.11
[26] 20.12
[26] 20.13
[26] 20.14
[26] 20.15
[26] 20.16
[26] 20.17
[26] 20.20
[26] 20.22
[26] 20.24
[26] 20.25
[52] 4.4
[52] 4.5
Sending
RFC
status
m
m
m
m
m
i
i
i
i
c1
c14:
c15:
c16:
c17:
c18:
NOTE:

extension.
extension.
1
Table A.306: Supported message bodies within the UPDATE request
3
Item
Header
Ref.
Sending
RFC
status
256
Profile
status
Ref.
Receiving
RFC
status
Profile
status

2
Table A.307: Supported headers within the UPDATE response - all remaining status-codes
Item
Header
Ref.
1
1A
2
3
4
5
6
7
8
9
10
10A
10B
10C
10D
10E
10F
10G
11
12
12A
13
14
c1:
c2:
c3:
c4:
c5:
c6:
c7:
c8:
c9:
c10:
c11:
c12:
c13:
Sending
RFC
status
m
m
m
m
m
m
m
m
m
m
m
m
c11
c9
Profile
status
m
m
m
m
m
m
m
m
m
m
m
m
c11
c9
Ref.
Receiving
RFC
status
m
c4
i
i
i
m
i
m
c1
m
i
c2
c12
c10
Profile
status
m
c4
c3
c3
c3
m
c3
m
c1
m
c3
c2
c12
c10
Call-ID
[26] 20.8
[26] 20.8
Call-Info
[26] 20.9
[26] 20.9
Content-Disposition
[26] 20.11
[26] 20.11
Content-Encoding
[26] 20.12
[26] 20.12
Content-Language
[26] 20.13
[26] 20.13
Content-Length
[26] 20.14
[26] 20.14
Content-Type
[26] 20.15
[26] 20.15
Cseq
[26] 20.16
[26] 20.16
Date
[26] 20.17
[26] 20.17
From
[26] 20.20
[26] 20.20
MIME-Version
[26] 20.24
[26] 20.24
Organization
[26] 20.25
[26] 20.25
[52] 4.4
[52] 4.4
[52] 4.5
Addresses
P-Charging-Vector
[52] 4.6
c7
n/a
[52] 4.6
c8
n/a
Privacy
[33] 4.2
c5
c5
[33] 4.2
c6
c6
Require
[26] 20.32 m
m
[26] 20.32 c13
c13
Server
[26] 20.35 m
m
[26] 20.35 i
i
Timestamp
[26] 20.38 m
m
[26] 20.38 i
i
To
[26] 20.39 m
m
[26] 20.39 m
m
User-Agent
[26] 20.41 m
m
[26] 20.41 i
i
Via
[26] 20.42 m
m
[26] 20.42 m
m
Warning
[26] 20.43 m
m
[26] 20.43 i
i
extension.
extension.
extension.
257
1
4
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Accept
[26] 20.1
m
m
[26] 20.1
i
i
Accept-Encoding
[26] 20.2
m
m
[26] 20.2
i
i
Accept-Language
[26] 20.3
m
m
[26] 20.3
i
i
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Authentication-Info
[26] 20.6
m
m
[26] 20.6
i
i
Contact
[26] 20.10 m
m
[26] 20.10 i
i
Supported
[26] 20.37 m
m
[26] 20.37 i
i
Ref.
0A
0B
0C
1
2
3
6
c3:
5
7Prerequisite: A.164/8 OR A.164/9 OR A.164/10 OR A.164/11 OR A.164/12 - - 3xx
8
Item
Header
Sending
RFC
Profile
status
status
Allow
[26] 20.5
m
m
Contact
[26] 20.10 m
m
Error-Info
[26] 20.18 m
m
Supported
[26] 20.37 m
m
Ref.
1
2
3
7
c1:
Ref.
[26] 20.5
[26] 20.10
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
c1
i
i
Profile
status
i
c1
i
i
9
12
Item
Header
Ref.
1
2
3
5
6
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
13
258
Profile
status
m
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i

3A.164/51 - - 404, 413, 480, 486, 500, 503, 600, 603
4
Item
Header
Ref.
1
2
5
7
Allow
Error-Info
Retry-After
Supported
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Sending
RFC
status
m
m
m
m
Profile
status
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.33
[26] 20.37
Receiving
RFC
status
i
i
i
i
Profile
status
i
i
i
i
5
8
Item
Header
Ref.
1
3
7
Allow
Error-Info
Supported
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
Profile
status
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
Profile
status
i
i
i
9
12
Item
Header
Ref.
1
2
4
7
8
Allow
Error-Info
Proxy-Authenticate
Supported
WWW-Authenticate
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Sending
RFC
status
m
m
m
m
m
Profile
status
m
m
m
m
m
Ref.
[26] 20.5
[26] 20.18
[26] 20.27
[26] 20.37
[26] 20.44
Receiving
RFC
status
i
i
m
i
i
Profile
status
i
i
m
i
i
13
16
Item
Header
Ref.
1
2
3
4
6
10
Accept
Accept-Encoding
Accept-Language
Allow
Error-Info
Supported
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Sending
RFC
status
m
m
m
m
m
m
17
259
Profile
status
m
m
m
m
m
m
Ref.
[26] 20.1
[26] 20.2
[26] 20.3
[26] 20.5
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
i
i
i
i
i
Profile
status
i
i
i
i
i
i

3
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
m
m
[26] 20.5
i
i
Error-Info
[26] 20.18 m
m
[26] 20.18 i
i
Supported
[26] 20.37 m
m
[26] 20.37 i
i
Unsupported
[26] 20.40 m
m
[26] 20.40 c3
c3
Ref.
1
2
6
7
c3:
4
7
Item
Header
Sending
Receiving
RFC
Profile
Ref.
RFC
Profile
status
status
status
status
Allow
[26] 20.5
o
o
[26] 20.5
m
m
Error-Info
[26] 20.18 o
o
[26] 20.18 o
o
Security-Server
[48] 2
c1
c1
[48] 2
n/a
n/a
Supported
[26] 20.37 m
m
[26] 20.37 m
m
Ref.
1
2
3
4
c1:
8
10Prerequisite: A.164/35 - - 485 (Ambiguous)
11
Item
Header
Sending
RFC
Profile
status
status
Allow
[26] 20.5
m
m
Contact
[26] 20.10 m
m
Error-Info
[26] 20.18 m
m
Supported
[26] 20.37 m
m
Ref.
1
2
3
7
c1:
Ref.
[26] 20.5
[26] 20.10
[26] 20.18
[26] 20.37
Receiving
RFC
status
i
c1
i
i
Profile
status
i
c1
i
i
12
Table A.316: Supported message bodies within the UPDATE response
14
Item
Header
Ref.
Sending
RFC
status
15
260
Profile
status
Ref.
Receiving
RFC
status
Profile
status
1A.3
Profile definition for the Session Description Protocol

2as used in the present document
3A.3.1
Introduction
4Void.
5A.3.2
User agent role
7UA implementations.
8Prerequisite: A.2/1 -- user agent role

10
Item
22
23
24
25
c1:

Reference
Extensions
Integration of resource management
and SIP?
Grouping of media lines
Mapping of Media Streams to Resource
Reservation Flows
SDP Bandwidth Modifiers for RTCP
Bandwidth
IF A.3/1 THEN m ELSE n/a - - UE role.
RFC status
Profile status
[30]
[53]
[54]
o
o
c1
c1
[56B]
o (NOTE 1)
NOTE 1: For "video" and "audio" media types that utilise RTP/RTCP, it shall be specified. For other media types, it
may be specified.
11
261
1A.3.2.2 SDP types

Table A.318: SDP types
2
Item
Type
Ref.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Session level description

v= (protocol version)
o= (owner/creator and session
identifier)
s= (session name)
i= (session information)
u= (URI of description)
e= (email address)
p= (phone number)
c= (connection information)
b= (bandwidth information)
Sending
RFC
status
Profile
status
Ref.
Receiving
RFC
status
Profile
status
[39] 6
[39] 6
m
m
m
m
[39] 6
[39] 6
m
m
m
m
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
m
o
o
o
o
o
o
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
m
n/a
[39] 6
[39] 6
n/a
[39] 6
[39] 6
[39] 6
[39] 6
Time description (one or more per description)

t= (time the session is active)
[39] 6
m
r= (zero or more repeat times) [39] 6
o
Session level description (continued)
z= (time zone adjustments)
[39] 6
o
k= (encryption key)
[39] 6
o
a= (zero or more session
[39] 6
o
attribute lines)
Media description (zero or more per description)
m= (media name and
[39] 6
o
transport address)
i= (media title)
[39] 6
o
[39] 6
c1
[39] 6
o
19
20
n/a
n/a
n/a
o
(NOTE 1)
c1
o
(NOTE 1)
n/a
n/a
n/a
m
n/a
n/a
[39] 6
[39] 6
[39] 6
k= (encryption key)
[39] 6
o
[39] 6
a= (zero or more media
[39] 6
o
[39] 6
attribute lines)
c1:
IF A.318/15 THEN m ELSE n/a.
may be specified.
262
1Prerequisite A.318/14 OR A.318/20 - - a= (zero or more session/media attribute lines)
Table A.319: zero or more session / media attribute lines (a=)
2
Item
Field
Ref.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
c1:
c2:
c3:
c4:
c5:
c6:
category (a=cat)
keywords (a=keywds)
name and version of tool
(a=tool)
packet time (a=ptime)
maximum packet time
(a=maxptime)
receive-only mode
(a=recvonly)
send and receive mode
(a=sendrecv)
send-only mode (a=sendonly)
whiteboard orientation
(a=orient)
conference type (a=type)
character set (a=charset)
language tag (a=sdplang)
language tag (a=lang)
frame rate (a=framerate)
quality (a=quality)
format specific parameters
(a=fmtp)
rtpmap attribute (a=rtpmap)
current-status attribute
(a=curr)
desired-status attribute
(a=des)
confirm-status attribute
(a=conf)
media stream identification
attribute (a=mid)
group attribute (a=group)
IF A.317/22 THEN o ELSE n/a.
Sending
RFC
status
Ref.
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
Receiving
RFC
status
Profile
status
[39] 6
[30] 5
c1
c1
[39] 6
[30] 5
c2
c2
[30] 5
c1
c1
[30] 5
c2
c2
[30] 5
c1
c1
[30] 5
c2
c2
[53] 3
c3
c3
[53] 3
c4
c4
[53] 4
c5
c5
[53] 3
c6
c6
4A.3.2.3 SDP types parameters

5Prerequisite A.318/2 - - o= (owner/creator and session identifier)
Profile
status
263
Table A.320: owner/creator and session identifier type (o=)
1
Item
Field
Sending
RFC
status
m
m
m
m
m
m
Ref.
1
2
3
4
5
6
username
session id
version
network type
address type
address
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
Profile
status
m
m
m
m
m
m
Ref.
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
Receiving
RFC
status
m
m
m
m
m
m
Profile
status
n/a
m
m
n/a
n/a
n/a
Receiving
RFC
status
m
m
Profile
status
n/a
n/a
2
3Prerequisite A.318/10 - - t= (time the session is active)
Table A.321: time the session is active type (t=)
4
Item
Field
Sending
RFC
status
m
m
Ref.
1
2
start time
stop time
[39] 6
[39] 6
Profile
status
m
m
Ref.
[39] 6
[39] 6
5
6Prerequisite A.318/11 - - r= (zero or more repeat times)
Table A.322: zero or more repeat times (r=)
7
Item
Field
Ref.
1
2
3
repeat interval
active duration
list of offsets from start-time
Sending
RFC
status
[39] 6
[39] 6
[39] 6
Profile
status
n/a
n/a
n/a
Ref.
Receiving
RFC
status
[39] 6
[39] 6
[39] 6
Profile
status
n/a
n/a
n/a
8
9Prerquisite A.318/12 - - z= (time zone adjustments)
Table A.323: time zone adjustments type (z=)
10
Item
Field
Ref.
1
2
3
4
adjustment time
offset
adjustment time
offset
Sending
RFC
status
[39] 6
[39] 6
[39] 6
[39] 6
Profile
status
n/a
n/a
n/a
n/a
Ref.
Receiving
RFC
status
[39] 6
[39] 6
[39] 6
[39] 6
Profile
status
n/a
n/a
n/a
n/a
11
12Prerquisite A.318/13 - - k= (encryption key)
Table A.324: encryption key type (k=)
13
Item
Field
Ref.
1
2
method
encryption key
Sending
RFC
status
[39] 6
[39] 6
Ref.
[39] 6
[39] 6
14
Profile
status
264
Receiving
RFC
status
Profile
status
1Prerequisite A.318/15 - - m= (media name and transport address)
Table A.325: media name and transport address type (m=)
2
Item
Field
Sending
RFC
status
Ref.
1
media
`àudio''
``video''
`àpplication''
``data''
``control''
port
transport
fmt list
2
3
4
Profile
status
Ref.
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
Receiving
RFC
status
Profile
status
3
4
5
Editor's note: It is expected that this table will be expanded, as this is the principle table that will
distinguish operation of different entities within the IM CN subsystem.
6Prerequisite A.318/17 - - c= (connection information)
Table A.326: connection type (c=)
7
Item
Field
Ref.
1
2
3
network type
address type
connection address
Sending
RFC
status
Profile
status
[39] 6
[39] 6
[39] 6
Ref.
Receiving
RFC
status
Profile
status
Receiving
RFC
status
Profile
status
[39] 6
[39] 6
[39] 6
8
9Prerequisite A.318/18 - - b= (bandwidth information)
Table A.327: bandwidth information (b=)
10
Item
Field
Ref.
modifier
Sending
RFC
status
Profile
status
Ref.
[39] 6,
[56B]
[39] 6
o
[39] 6,
(NOTE 1) [56B]
2
bandwidth-value
o
[39] 6
(NOTE 2)
NOTE 1: For "video" and "audio" media types that utilise RTP/RTCP, the value shall be AS, RR or RS.
may be specified.
11
12A.3.2.4 SDP types parameters within attribute lines

13This subclause dos not intend to show an exhaustive list of all the possible attribute values
14Prerequisite A.319/22 - - group attribute (a=group)
265
Table A.327A: group semantics (a=group)
1
Item
Field
Sending
RFC
status
o
o
o
Ref.
1
2
3
Lip Synchronization (LS)

Flow Identification (FID)
Single Reservation Flow
(SRF)
[53] 4
[53] 4
[54] 2
Profile
status
o
o
m
Ref.
[53] 4
[53] 4
[54] 2
Receiving
RFC
status
m
m
m
Profile
status
m
m
m
3A.3.3
Proxy role
5proxy implementations.
6Prerequisite: A.2/2 -- proxy role

8
Item
1
2
3
4
c1:

Reference
Extensions
Integration of resource management
and SIP?
Grouping of media lines
Mapping of Media Streams to Resource
Reservation Flows
SDP Bandwidth Modifiers for RTCP
Bandwidth
IF A.3/2 THEN m ELSE n/a - - P-CSCF role.
Profile status
[30]
n/a
[53]
[54]
o
o
c1
c1
[56B]
c1
RFC status
266
1A.3.3.2 SDP types

Table A.329: SDP types
2
Item
Type
Ref.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Sending
RFC
status
Session level description

v= (protocol version)
[39] 6
m
o= (owner/creator and session [39] 6
m
identifier).
s= (session name)
[39] 6
m
i= (session information)
[39] 6
m
u= (URI of description)
[39] 6
m
e= (email address)
[39] 6
m
p= (phone number)
[39] 6
m
[39] 6
m
[39] 6
m
Time description (one or more per description)
t= (time the session is active)
[39] 6
m
r= (zero or more repeat times) [39] 6
m
Session level description (continued)
z= (time zone adjustments)
[39] 6
m
k= (encryption key)
[39] 6
m
a= (zero or more session
[39] 6
m
attribute lines)
Media description (zero or more per description)
m= (media name and
[39] 6
m
transport address)
i= (media title)
[39] 6
o
[39] 6
o
[39] 6
o
k= (encryption key)
[39] 6
o
a= (zero or more media
[39] 6
o
attribute lines)
267
Profile
status
Ref.
Receiving
RFC
status
Profile
status
m
m
[39] 6
[39] 6
m
i
m
i
m
m
m
m
m
m
m
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
i
i
i
i
i
i
i
i
i
i
i
i
i
i
m
m
[39] 6
[39] 6
i
i
i
i
m
m
m
[39] 6
[39] 6
[39] 6
i
i
i
i
i
i
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
1Prerequisite A.329/14 OR A.329/20 - - a= (zero or more session/media attribute lines)
Table A.330: zero or more session / media attribute lines (a=)
2
Item
Field
Ref.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
c2:
c3:
c4:
c5:
c6:
category (a=cat)
keywords (a=keywds)
name and version of tool
(a=tool)
packet time (a=ptime)
maximum packet time
(a=maxptime)
receive-only mode
(a=recvonly)
send and receive mode
(a=sendrecv)
send-only mode (a=sendonly)
whiteboard orientation
(a=orient)
conference type (a=type)
character set (a=charset)
language tag (a=sdplang)
language tag (a=lang)
frame rate (a=framerate)
quality (a=quality)
format specific parameters
(a=fmtp)
rtpmap attribute (a=rtpmap)
current-status attribute
(a=curr)
desired-status attribute
(a=des)
confirm-status attribute
(a=conf)
media stream identification
attribute (a=mid)
group attribute (a=group)
IF A.328/1 THEN m ELSE i.
Sending
RFC
status
Ref.
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
Receiving
RFC
status
Profile
status
[39] 6
[30] 5
[39] 6
[30] 5
c2
c2
[30] 5
[30] 5
c2
c2
[30] 5
[30] 5
c2
c2
[53] 3
c3
c3
[53] 3
c4
c4
[53] 4
c5
c6
[53] 3
c5
c6
4A.3.3.3 SDP types parameters

5Prerequisite A.329/2 - - o= (owner/creator and session identifier)
Profile
status
268
Table A.331: owner/creator and session identifier type (o=)
1
Item
Field
Sending
RFC
status
m
m
m
m
m
m
Ref.
1
2
3
4
5
6
username
session id
version
network type
address type
address
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
Profile
status
m
m
m
m
m
m
Ref.
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
Receiving
RFC
status
m
m
m
m
m
m
Profile
status
m
m
m
m
m
m
Receiving
RFC
status
Profile
status
Receiving
RFC
status
Profile
status
Receiving
RFC
status
Profile
status
Receiving
RFC
status
Profile
status
2
3Prerequisite A.329/10 - - t= (time the session is active)
Table A.332: time the session is active type (b=)
4
Item
Field
Sending
RFC
status
Ref.
1
2
start time
stop time
Profile
status
[39] 6
[39] 6
Ref.
[39] 6
[39] 6
5
6Prerequisite A.329/11 - - r= (zero or more repeat times)
Table A.333: zero or more repeat times (r=)
7
Item
Field
Ref.
1
2
3
repeat interval
active duration
list of offsets from start-time
Sending
RFC
status
Profile
status
[39] 6
[39] 6
[39] 6
Ref.
[39] 6
[39] 6
[39] 6
8
9Prerequisite A.329/12 - - z= (time zone adjustments)
Table A.334: time zone adjustments type (z=)
10
Item
Field
Ref.
1
2
3
4
adjustment time
offset
adjustment time
offset
Sending
RFC
status
Profile
status
[39] 6
[39] 6
[39] 6
[39] 6
Ref.
[39] 6
[39] 6
[39] 6
[39] 6
11
12Prerequisite A.329/13 - - k= (encryption key)
Table A.335: encryption key type (k=)
13
Item
Field
Ref.
1
2
method
encryption key
Sending
RFC
status
[39] 6
[39] 6
Ref.
[39] 6
[39] 6
14
Profile
status
269
1Prerequisite A.329/15 - - m= (media name and transport address)
Table A.336: media name and transport address type (m=)
2
Item
Field
Sending
RFC
status
Ref.
1
media
`àudio''
``video''
`àpplication''
``data''
``control''
port
transport
fmt list
2
3
4
Profile
status
Ref.
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
[39] 6
Receiving
RFC
status
Profile
status
3
4
5
Editor's note: It is expected that this table will be expanded, as this is the principle table that will
distinguish operation of different entities within the IM CN subsystem.
6Prerequisite A.329/17 - - c= (connection information)
Table A.337: connection type (c=)
7
Item
Field
Ref.
1
2
3
network type
address type
connection address
Sending
RFC
status
Profile
status
[39] 6
[39] 6
[39] 6
Ref.
Receiving
RFC
status
Profile
status
Receiving
RFC
status
Profile
status
[39] 6
[39] 6
[39] 6
8
9Prerequisite A.329/18 - - b= (bandwidth information)
Table A.338: bandwidth information (b=)
10
Item
Field
Ref.
modifier
bandwidth-value
Sending
RFC
status
Profile
status
[39] 6,
[56B]
[39] 6
Ref.
[39] 6,
[56B]
[39] 6
11
12A.3.3.4 SDP types parameters within attribute lines

13The subclause does not intend to show an exhaustive list of all the possible attribute values.
14Prerequisite A.330/22 -- group attribute (a=group)
Table A.339: group semantics (a=group)
15
Item
Field
Ref.
1
2
3
Lip Synchronization (LS)

Flow Identification (FID)
Single Reservation Flow
(SRF)
[53] 4
[53] 4
[54] 2
Sending
RFC
status
m
m
o
16
270
Profile
status
m
m
m
Ref.
[53] 4
[53] 4
[54] 2
Receiving
RFC
status
i
i
m
Profile
status
i
i
m
1A.4
Profile definition for other message bodies as used in

2the present document
3Void.
271

X.S0013-004 v100 - Post Ballot (Editor)

Uploaded by

Document Information

Original Description:

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

X.S0013-004 v100 - Post Ballot (Editor)

Uploaded by

Copyright:

Available Formats

13GPP2X.SP0013.

3GPP2 X.P0013.4 Cover Sheet

235 Application usage of SIP..............................................................................................12

556 Application usage of SDP............................................................................................67

Extensions within the present document....................................................................70

109 IP Connectivity Network aspects when connected to the IM CN subsystem..................77

the interface between the CSCF and any other CSCF;

the interface between the CSCF and an Application Server (AS);

the interface between the BGCF and the MGCF;

the interface between the CSCF and an external Multimedia IP network.

For non-specific 3GPP references the latest Release 5 applies.

For a specific reference, subsequent revisions do not apply.

3GPP2 X.SP0013.000: "3GPP2 All-IP Core Network - Multimedia Domain".

3GPP2 X.SP0013.003: "IP Multimedia (IM) Session Handling; IM call model".

3GPP2 X.SP0013.002: "IP multimedia subsystem; Stage 2"

10[10A] 3GPP2 XP.S00101-CB: "Wireless IP Network Standard".

3GPP2 X.SP0013.007: "IP Multimedia Subsystem - Charging Architecture".

3GPP TS 33.102: "3G Security; Security architecture".

21[19] 3GPP2 S.SP0086-0: "IMS Security Framework".

33[24] IETFRFC 2916 (September 2000): "E.164 number and DNS".

1[25] IETFRFC 2976 (October 2000): "The SIP INFO method".

11[32] IETFRFC 3320 (March 2002): "Signaling Compression (SigComp)"

Network Asserted Identity within Trusted Networks".

draft-ietf-mmusic-sdp-new-12 14 (SeptemberMarch 2003): "SDP: Session Description Protocol".

Initiation Protocol (SIP) Servers".

Protocol (SDP) static dictionary for Signaling Compression (SigComp)".

18 [57] IETFRFC 2131 (March 1997): Dynamic host configuration protocol.

Definitions and abbreviations

Back-to-Back User Agent (B2BUA)

Breakout Gateway Control Function (BGCF)

Protected Server Port

A status-code in the range 101 through 199, and excluding 100

Conformance of IM CN subsystem entities to SIP, SDP and other protocols

a) when acting as a subscriber to or the recipient of event information; and

URI and address assignments

Routeing principles of IM CN subsystem entities

In addition to the procedures specified in clause 5, procedures of [34] in relation to transmission

Charging correlation principles for IM CN subsystems

1. IM CN subsystem Charging Identifier (ICID);

2. Access network charging information:

3. Inter Operator Identifier (IOI);

4. Charging function addresses:

b. Event Charging Function (ECF).

IM CN subsystem charging identifier (ICID)

Access network charging information

144.5.3.2 IP Connectivity Network charging information

Inter operator identifier (IOI)

Charging function addresses

Application usage of SIP

Registration and authentication

Parameters contained in the UE

the private user identity;

one ore more public user identities; and

one or more P-CSCF addresses (specified as IP address or FQDN).

Security Association Negotiation

15.1.1.2 Initial registration

h) the Supported header containing the option tag "path"; and

i) if a security association exists, a P-Access-Network-Info header that contains information concerning

155.1.1.3 Initial subscription to the registration-state event package

d) an Event header set to the "reg" event package; and

395.1.1.4 User-initiated re-registration

h) the Supported header containing the option tag "path"; and