6 Control plane interconnection

29.1653GPPInter-IMS Network to Network Interface (NNI)Release 18TS

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

6.1 Definition of Inter-IMS Network to Network Interconnection

6.1.1 SIP methods and header fields

6.1.1.1 General

The functional entity closest to the border of an II-NNI (see reference model in clause 5) shall provide the capabilities specified for that network element in clause A.2 of 3GPP TS 24.229 [5] with modifications as described in the following clauses.

6.1.1.2 SIP methods

3GPP TS 24.229 [5] defines the methods allowing an IBCF to interconnect to an IBCF placed in another IM CN subsystem.

The following SIP methods are supported on the II-NNI as defined in table 6.1.

The following table is based on table A.5 and table A.163 of 3GPP TS 24.229 [5] and endorsed for this document:

Table 6.1: Supported SIP methods

Item	Method	Ref.	II-NNI
Item	Method	Ref.	Sending	Receiving
1	ACK request	IETF RFC 3261 [13]	m	m
2	BYE request	IETF RFC 3261 [13]	m	m
3	BYE response	IETF RFC 3261 [13]	m	m
4	CANCEL request	IETF RFC 3261 [13]	m	m
5	CANCEL response	IETF RFC 3261 [13]	m	m
5A	INFO request	IETF RFC 6086 [39]	o	o
5B	INFO response	IETF RFC 6086 [39]	o	o
8	INVITE request	IETF RFC 3261 [13]	m	m
9	INVITE response	IETF RFC 3261 [13]	m	m
9A	MESSAGE request	IETF RFC 3428 [19]	o	o
9B	MESSAGE response	IETF RFC 3428 [19]	o	o
10	NOTIFY request	IETF RFC 6665 [20]	c1	c1
11	NOTIFY response	IETF RFC 6665 [20]	c1	c1
12	OPTIONS request	IETF RFC 3261 [13]	m	m
13	OPTIONS response	IETF RFC 3261 [13]	m	m
14	PRACK request	IETF RFC 3262 [18]	m	m
15	PRACK response	IETF RFC 3262 [18]	m	m
15A	PUBLISH request	IETF RFC 3903 [21]	c1	c1
15B	PUBLISH response	IETF RFC 3903 [21]	c1	c1
16	REFER request	IETF RFC 3515 [22]	o	o
17	REFER response	IETF RFC 3515 [22]	o	o
18	REGISTER request	IETF RFC 3261 [13]	c2	c2
19	REGISTER response	IETF RFC 3261 [13]	c2	c2
20	SUBSCRIBE request	IETF RFC 6665 [20]	c1	c1
21	SUBSCRIBE response	IETF RFC 6665 [20]	c1	c1
22	UPDATE request	IETF RFC 3311 [23]	m	m
23	UPDATE response	IETF RFC 3311 [23]	m	m
c1: In case of roaming II-NNI, the support of the method is m, else o. c2: In case of roaming II-NNI, the support of the method is m, else n/a.
NOTE: In the above table, m, o and c and n/a have the meanings indicated in table 6.3

6.1.1.3 SIP header fields

6.1.1.3.0 General

The IBCF shall provide the capabilities to manage and modify SIP header fields according to clause 5.10 and annex A of 3GPP TS 24.229 [5] with modifications as described in the following clauses.

6.1.1.3.1 Trust and no trust relationship

The IBCF acting as exit point applies the procedures described in clause 5.10.2 of 3GPP TS 24.229 [5] before forwarding the SIP signalling to the IBCF acting as entry point. The IBCF acting as entry point applies the procedures described in clause 5.10.3 of 3GPP TS 24.229 [5].

Additionally, in case there is no trust relationship between the two IM CN subsystems connected by II-NNI, the IBCF applies the procedures described in clause 4.4 of 3GPP TS 24.229 [5], before forwarding the SIP signalling.

These procedures may be utilized on a per header field basis to realize overall trust as well as per service level screening of header fields. Trust relationships and trust domains may be defined by inter-operator agreements for individual services and/or individual SIP header fields.

The management of the SIP header fields (if present) over II-NNI in case of a presence or not of a trust relationship between the two interconnected IM CN subsystems is wrapped up in the following table.

Table 6.2: Management of SIP header fields and parameters over II-NNI in presence or not of a trust relationship

6.1.1.3.2 Derivation of applicable SIP header fields from 3GPP TS 24.229 [5]

For any method in table 6.1, the SIP header fields applicable on the II-NNI are detailed in the corresponding method tables for the UA role and proxy role sending behaviour in annex A of 3GPP TS 24.229 [5]. Unless other information is specified in the normative part of the present specification, the applicability of header fields at the II-NNI can be derived for each method from the corresponding tables in annex A of 3GPP TS 24.229 [5] as follows:

– All header fields not present in the corresponding tables in annex A of 3GPP TS 24.229 [5] or marked as "n/a" in both the "RFC status" and "profile status" columns for the UA role and proxy role sending behaviour of that tables are not applicable at the II-NNI.

NOTE 1: Operators could choose to apply header fields for other SIP extensions on an II-NNI based on bilateral agreements, but this is outside the scope of the present specification.

– All header fields which are marked as "o" in at least one of the "RFC status" or the "profile status" profile columns for the sending behaviour in the corresponding UA role and proxy role tables in annex A of 3GPP TS 24.229 [5] and as "n/a" or "o" in the other such columns are applicable at II-NNI based on bilateral agreement between operators.

– All header fields which are marked as "m" in at least one of the "RFC status" or the "profile status" columns for the sending behaviour in the corresponding UA role or proxy role table in annex A of 3GPP TS 24.229 [5] and as "n/a", "o", or "m" in the other such columns are applicable at the II-NNI.

– If conditions are specified, they are also applicable at the II-NNI and the above rules are applicable to the "n/a", "o" and "m" values within the conditions.

NOTE 2: In the above rules, the RFC profile columns are taken into account in order to enable interworking with non-3GPP networks.

An informative summary of SIP header fields to be used over the II-NNI is proposed in annex A.

6.1.1.3.3 Applicability of SIP header fields on a roaming II-NNI

The following SIP header fields are applicable on a roaming II-NNI but not on a non-roaming II-NNI:

– Authentication-Info

– Authorization

– P-Associated-URI

– P-Called-Party-ID

– P-Preferred-Service

– P-Profile-Key

– P-Served-User

– P-Visited-Network-ID

– Path

– Priority-Share

– Proxy-Authenticate

– Proxy-Authorization

– Resource-Share

– Restoration-Info

– Service-Route

– WWW-Authenticate

6.1.1.3.4 Applicability of SIP header fields on a non-roaming II-NNI

The following SIP header fields are only applicable on a non-roaming II-NNI:

– P-Refused-URI-List;

– Identity;

– Attestation-Info;

– Origination-Id; and

– Priority-Verstat.

6.1.1.4 Notations of the codes

In the table 6.1 the status codes "m", "o", "c" and "n/a" have the following meanings:

Table 6.3: Key to notation codes for SIP messages

Notation code	Notation name	Sending side	Receiving side
m	mandatory	The message shall be supported at II-NNI. Supporting sending a SIP message at the II-NNI means that this message shall be sent over the II-NNI if received from the serving network. It does not imply that network elements inside the serving network or user equipment connected to this network shall support this message.	Supporting receiving a SIP message at the II-NNI means that this message shall be forwarded to the serving network unless the operator’s policy is applied as defined in clause 5.10.1 of 3GPP TS 24.229 [5]. It does not imply that network elements inside the serving network or user equipment connected to this network are supporting this message.
o	optional	The message may or may not be supported at II-NNI. The support of the message is provided based on bilateral agreement between the operators.	Same as for sending side.
n/a	not applicable	It is impossible to use/support the message.	It is impossible to use/support the message. This message will be discarded by the IBCF.
c <integer>	conditional	The requirement on the message ("m", "o" or "n/a") depends on the support of other optional or conditional items. <integer> is the identifier of the conditional expression.	Same as for sending side.

6.1.1.5 Modes of signalling

Overlap signalling may be used if agreement exists between operators to use overlap and which method to be used, otherwise enbloc shall be used at the II-NNI.

6.1.2 SDP protocol

6.1.2.1 General

The functional entity closest to the border of an II-NNI (see reference model in clause 5) shall provide the capabilities specified for that network element in clause A.3 of 3GPP TS 24.229 [5].

The "application/sdp" MIME bodies shall be encoded as described in IETF RFC 3261 [13] and in IETF RFC 4566 [147].

The offer/answer model with the SDP as defined in IETF RFC 3264 [146] shall be applied.

The procedures and the SDP rules as defined in IETF RFC 4145 [162] may be applied if media streams with TCP is used.

6.1.3 Major capabilities

This clause contains the major capabilities to be supported over the II-NNI.

The table 6.1.3.1 specifies which capabilities are applicable for II-NNI. The profile status codes within table 6.1.3.1 are defined in table 6.1.3.2.

For the "Basic SIP" capabilities part of table 6.1.3.1, the last column "Profile status over II-NNI" specifies the general status of applicability of the IETF RFC 3261 [13] main mechanisms described in the 2^nd column "Capability over the Ici".

For the "Extensions to basic SIP" capabilities part, the last column "Profile status over II-NNI" specifies the general status of applicability of the RFC referenced in the 2^nd column "Capability over the Ici".

If necessary, the applicability of RFCs at the II-NNI level is further detailed in the present Technical Specification.

The columns "Reference item in 3GPP TS 24.229 [5] for the profile status" provide informative references for comparison purposes into the UA and Proxy role major capabilities tables in 3GPP TS 24.229 [5], where the capabilities are defined via additional references.

Table 6.1.3.1: Major capabilities over II-NNI

Item		Capability over the Ici		Reference item in 3GPP TS 24.229 [5] for the profile status			Profile status over II-NNI
				UA Role (NOTE 1)		Proxy role (NOTE 2)
	Basic SIP (IETF RFC 3261 [13])
1	registrations		1, 2, 2A		–		c2
2	initiating a session		2B, 3, 4		–		m
3	terminating a session		5		3		m
4	General proxy behaviour		–		4, 5, 14, 15		n/a
5	Managing several responses due to forking		9,10		6		m
6	support of indication of TLS connections in the Record-Route header		–		7, 8		n/a
7	Support of authentication		7, 8, 8A		8A		c2
8	Timestamped requests (Timestamp header field)		6		–		m
9	Presence of date in requests and responses (Date header field)		11		9		m
10	Presence of alerting information data (Alert-info header field)		12		10		o
11	Support and handling of the Require header field for REGISTER and other requests or responses for methods other than REGISTER		–		11, 12, 13		m
12	Support and reading of the Supported and Unsupported header fields		–		16, 17, 18		m
13	Support of the Error-Info header field in 3xx – 6xx responses		–		19		o
14	Support and handling of the Organization header field		–		19A, 19B		m
15	Support and handling of the Call-Info header field		–		19C, 19D		m
16	Support of the Contact header field in 3xx response		–		19E		m
16A	Proxy reading the contents of a body or including a body in a request or response		–		19F		n/a
	Extensions to basic SIP
16B	3GPP TS 24.237 [131]: proxy modifying the content of a body		–		19G		n/a
17	IETF RFC 6086 [39]: SIP INFO method and package framework		13		20		o
17A	IETF RFC 6086 [39]: legacy INFO usage		13A		20A		o
18	IETF RFC 3262 [18]: reliability of provisional responses in SIP (PRACK method)		14		21		m
19	IETF RFC 3515 [22]: the SIP REFER method		15		22		o
19A	IETF RFC 7647 [194]: Clarifications for the Use of REFER with RFC6665		15A		22A		n/a
19B	IETF RFC 7614 [195]: Explicit Subscriptions for the REFER Method		15B		22B		o
20	IETF RFC 3312 [40] and IETF RFC 4032 [41]: integration of resource management and SIP (Preconditions framework)		2C, 16		23		o
21	IETF RFC 3311 [23]: the SIP UPDATE method		17		24		m
22	IETF RFC 3313 [42]: SIP extensions for media authorization (P-Media-Authorization header field)		19		26		n/a
23	IETF RFC 6665 [20]: SIP specific event notification (SUBSCRIBE/NOTIFY methods)		20, 22, 23		27		c1
23A	IETF RFC 7621 [196]: A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol SIP Event Notification Framework		22A		28		n/a
24	IETF RFC 3327 [43]: session initiation protocol extension header field for registering non-adjacent contacts (Path header field)		24		29		c2
25	IETF RFC 3325 [44]: private extensions to the Session Initiation Protocol (SIP) for network asserted identity within trusted networks		25		30		c4
26	IETF RFC 3325 [44]: the P-Preferred-Identity header field extension		–		–		n/a
27	IETF RFC 3325 [44]: the P-Asserted-Identity header field extension		–		–		c4
28	IETF RFC 3323 [34], IETF RFC 3325 [44] and IETF RFC 7044 [25]: a privacy mechanism for the Session Initiation Protocol (SIP) (Privacy header field)		26, 26A, 26B, 26C, 26D, 26E, 26F, 26G, 26H		31, 31A, 31B, 31C, 31D, 31E, 31F, 31G, 31H		m
29	IETF RFC 3428 [19]: a messaging mechanism for the Session Initiation Protocol (SIP) (MESSAGE method)		27		33		o
30	IETF RFC 3608 [45]: session initiation protocol extension header field for service route discovery during registration (Service-Route header field)		28		32		c2
31	IETF RFC 3486 [46]: compressing the session initiation protocol		29		34		n/a
32	IETF RFC 7315 [24]: private header extensions to the session initiation protocol for the 3^rd-Generation Partnership Project (3GPP)		30		35		o
32A	IETF RFC 3325 [44]: act as first entity within the trust domain for asserted identity		30A		30A		n/a
32B	IETF RFC 3325 [44]: act as entity within trust network that can route outside the trust network		30B		30B		n/a
32C	IETF RFC 3325 [44]: act as entity passing on identity transparently independent of trust domain		30C		30C		n/a
33	IETF RFC 7315 [24] and IETF RFC 7976 [24A]: the P-Associated-URI header field extension		31		36		c2
34	IETF RFC 7315 [24] and IETF RFC 7976 [24A]: the P-Called-Party-ID header field extension		32		37		c2
35	IETF RFC 7315 [24] and IETF RFC 7976 [24A]: the P-Visited-Network-ID header field extension		33		38, 39		c2
36	IETF RFC 7315 [24], IETF RFC 7976 [24A] and IETF RFC 7913 [24B]: the P-Access-Network-Info header field extension		34		41, 42, 43		c4
37	IETF RFC 7315 [24] and IETF RFC 7976 [24A]: the P-Charging-Function-Addresses header field extension		35		44, 44A		n/a
38	IETF RFC 7315 [24] and IETF RFC 7976 [24A]: the P-Charging-Vector header field extension		36		45, 46		c1
39	IETF RFC 3329 [47]: security mechanism agreement for the session initiation protocol		37		47		n/a
39A	3GPP TS 24.229 [5] clause 7.2A.7: Capability Exchange for Media Plane Security		37A		47A		n/a
40	IETF RFC 3326 [48]: the Reason header field for the session initiation protocol		38		48		o
41	IETF RFC 6432 [49]: carrying Q.850 codes in reason header fields in SIP (Session Initiation Protocol) responses		38A		48A		c4
41A	IETF RFC 8606 [214]: the Location Parameter for the SIP Reason Header Field		38B		48B		o
41B	IETF draft-ietf-stir-identity-header-errors-handling [220]: Identity Header Error Handling (carrying STIR codes in Reason header fields in SIP responses)		38C		48C		c5
41C	IETF draft-ietf-sipcore-multiple-reasons [221]: Multiple SIP Reason Header Field Values		38D		48D		c5
42	IETF RFC 3581 [50]: an extension to the session initiation protocol for symmetric response routeing		39		49		o
43	IETF RFC 3841 [51]: caller preferences for the session initiation protocol (Accept-Contact, Reject-Contact and Request-Disposition header fields)		40, 40A, 40B, 40C, 40D, 40E, 40F		50, 50A, 50B, 50C, 50D, 50E, 50F		m
44	IETF RFC 3903 [21]: an event state publication extension to the session initiation protocol (PUBLISH method)		41		51		c1
45	IETF RFC 4028 [52]: SIP session timer (Session-Expires and Min-SE headers)		42		52		m
46	IETF RFC 3892 [53]: the SIP Referred-By mechanism		43		53		m
47	IETF RFC 3891 [54]: the Session Initiation Protocol (SIP) "Replaces" header		44		54		o
48	IETF RFC 3911 [55]: the Session Initiation Protocol (SIP) "Join" header		45		55		o
49	IETF RFC 3840 [56]: the callee capabilities		46		56		o
50	IETF RFC 7044 [25]: an extension to the session initiation protocol for request history information (History-Info header field)		47		57		o
50A	IETF RFC 7044 [25]: the "mp" header field parameter		47A		57A		o
50B	IETF RFC 7044 [25]: the "rc" header field parameter		47B		57B		o
50C	IETF RFC 7044 [25]: the "np" header field parameter		47C		57C		o
51	IETF RFC 5079 [57]: Rejecting anonymous requests in the session initiation protocol		48		58		o
52	IETF RFC 4458 [58]: session initiation protocol URIs for applications such as voicemail and interactive voice response (NOTE 3)		49		59		o
52A	IETF RFC 8119 [193]: Session Initiation Protocol (SIP) Cause URI parameter for Service Number translation		49A		59A		o
53	IETF RFC 4320 [59]: Session Initiation Protocol’s (SIP) non-INVITE transactions		50		61		m
54	IETF RFC 4457 [60]: the P-User-Database private header field extension		51		60		n/a
55	IETF RFC 5031 [61]: A Uniform Resource Name (URN) for Emergency and Other Well-Known Services		52		62		c7
56	IETF RFC 5627 [62]: obtaining and using GRUUs in the Session Initiation Protocol (SIP)		53		63		c1
57	Void
58	IETF RFC 4168 [27]: the Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)		55		65		o
59	IETF RFC 5002 [64]: the SIP P-Profile-Key private header field extension		56		66, 66A, 66B		c3
60	IETF RFC 5626 [65]: managing client initiated connections in SIP		57		67		c1
61	IETF RFC 5768 [66]: indicating support for interactive connectivity establishment in SIP		58		68		n/a
62	IETF RFC 5365 [67]: multiple-recipient MESSAGE requests in the session initiation protocol		59		69		o if 29, else n/a
63	IETF RFC 6442 [68]: Location conveyance for the Session Initiation Protocol		60		70, 70A, 70B		m
64	IETF RFC 5368 [69]: referring to multiple resources in the session initiation protocol		61		71		o if 19, else n/a
65	IETF RFC 5366 [70]: conference establishment using request-contained lists in the session initiation protocol		62		72		o
66	IETF RFC 5367 [71]: subscriptions to request-contained resource lists in the session initiation protocol		63		73		o if 23, else n/a
67	IETF RFC 4967 [72]: dialstring parameter for the session initiation protocol uniform resource identifier		64		74		c2
68	IETF RFC 4964 [73]: the P-Answer-State header extension to the session initiation protocol for the open mobile alliance push to talk over cellular		65		75		o
69	IETF RFC 5009 [74]: the SIP P-Early-Media private header field extension for authorization of early media		66		76		c4
70	IETF RFC 4694 [75]: number portability parameters for the ‘tel’ URI		67, 67A, 67B		77, 77A, 77B		o
71	Void
72	IETF RFC 4411 [77]: extending the session initiation protocol Reason header for preemption events		69		79		o
73	IETF RFC 4412 [78]: communications resource priority for the session initiation protocol (Resource-Priority header field)		70, 70A, 70B		80, 80A, 80B		o
74	IETF RFC 5393 [79]: addressing an amplification vulnerability in session initiation protocol forking proxies		71		81		m
75	IETF RFC 5049 [80]: the remote application identification of applying signalling compression to SIP		72		82		n/a
76	IETF RFC 5688 [81]: a session initiation protocol media feature tag for MIME application sub-types		73		83		c1
77	IETF RFC 6050 [26]: Identification of communication services in the session initiation protocol		74		84, 84A		o
78	IETF RFC 5360 [82]: a framework for consent-based communications in SIP		75, 75A, 75B		85		o
79	IETF RFC 7433 [83]: a mechanism for transporting user-to-user call control information in SIP		76		86		c1
79A	IETF RFC 7434 [83A]: interworking ISDN call control user information with SIP		76A		–		c1
80	IETF RFC 7316 [84]: The SIP P-Private-Network-Indication private header (P-Header)		77		87		c1
81	IETF RFC 5502 [85]: the SIP P-Served-User private header		78		88		c2
82	IETF 8498 [203]: the SIP P-Served-User header extension for Originating CDIV session case		79		89		n/a
83	IETF RFC 8497 [87]: marking SIP messages to be logged		80		90		o
84	IETF RFC 6228 [88]: the 199 (Early Dialog Terminated) response code		81		91		m
85	IETF RFC 5621 [89]: message body handling in SIP		82		92		m
86	IETF RFC 6223 [90]: indication of support for keep-alive		83		93		o
87	IETF RFC 5552 [91]: SIP Interface to VoiceXML Media Services		84		94		n/a
88	IETF RFC 3862 [92]: common presence and instant messaging (CPIM): message format		85		95		o
89	IETF RFC 5438 [93]: instant message disposition notification		86		96		o
90	IETF RFC 5373 [94]: requesting answering modes for SIP (Answer-Mode and Priv-Answer-Mode header fields)		87		97, 97A		o
91	Void
92	IETF RFC 3959 [96]: the early session disposition type for SIP		89		99		o
93	Void
94	IETF RFC 7989 [124]: End-to-End Session Identification in IP-Based Multimedia Communication Networks		91		101		o
95	IETF RFC 6026 [125]: correct transaction handling for 200 responses to Session Initiation Protocol INVITE requests		92		102		m
96	IETF RFC 5658 [126]: addressing Record-Route issues in the Session Initiation Protocol (SIP)		93		103		o
97	IETF RFC 5954 [127]: essential correction for IPv6 ABNF and URI comparison in IETF RFC 3261 [13]		94		104		m
98	IETF RFC 4488 [135]: suppression of session initiation protocol REFER method implicit subscription		95		105		m if 19, else n/a
99	IETF RFC 7462 [136]: Alert-Info URNs for the Session Initiation Protocol		96		106		o
100	3GPP TS 24.229 [5] clause 3.1: multiple registrations		97		107		c2
101	IETF RFC 5318 [141]: the SIP P-Refused-URI-List private-header		98		108		c5
102	IETF RFC 4538 [140]: request authorization through dialog Identification in the session initiation protocol (Target-Dialog header field)		99		109		o
103	IETF RFC 6809 [143]: Mechanism to indicate support of features and capabilities in the Session Initiation Protocol (SIP)		100		110		o
104	IETF RFC 6140 [160]: registration of bulk number contacts		101		111		c3
105	IETF RFC 6230 [161]: media control channel framework		102		112		o
105A	3GPP TS 24.229 [5] clause 4.14: S-CSCF restoration procedures		103		113		c3
106	IETF RFC 6357 [164]: SIP overload control		104		114		o
107	IETF RFC 7339 [165]: feedback control		104A		114A		o
108	IETF RFC 7200 [167]: distribution of load filters		104B		114B		o
109	3GPP TS 24.229 [5] clauses 5.1.2A.1.1, 5.1.3.1, 5.1.6.8, and 5.2.10: Handling of a 380 (Alternative service) response		105		115		n/a
110	IETF RFC 7090 [184]: Public Safety Answering Point (PSAP) Callback		107		117		o
111	IETF RFC 8055 [185]: Via header field parameter to indicate received realm		106		116		n/a
112	IETF RFC 7549 [188]: SIP URI parameter to indicate traffic leg		108		118		o (NOTE 4)
113	3GPP TS 24.229 [5] clause 4.14: PCF or PCRF based P-CSCF restoration		109		119		c3
114	3GPP TS 24.229 [5] clause 4.14: UDM/HSS or HSS based P-CSCF restoration		110		120		c3
115	3GPP TS 24.229 [5] clause 7.2.12: the Relayed-Charge header extension		111		121		n/a
116	3GPP TS 24.229 [5]: resource sharing		112		122		c3
117	3GPP TS 24.229 [5] clause 7.2.15: the Cellular-Network-Info header extension		113		123		c4
118	3GPP TS 24.229 [5] clause 7.2.16: the Priority-Share header field		114		124		c3
119	IETF RFC 8224 [206]: Authenticated Identity Management in the Session Initiation Protocol (SIP)		116		126		c5
120	IETF RFC 8197 [207]: A SIP Response Code for Unwanted Calls		117		127		o
121	3GPP TS 24.229 [5] clause 7.2.17: the Response-Source header extension		115		125		c6
121A	3GPP TS 24.229 [5]: the 3GPP PS data off extension		118		–		c3
121B	3GPP TS 24.229 [5]: Next-Generation Pan-European eCall emergency service		120		–		c8
122	IETF RFC 8262 [216]: Content-ID Header Field in the Session Initiation Protocol (SIP)		119		–		o
123	3GPP TS 24.229 [5] clause 7.2.18: the Attestation-Info header field		121		128		c5
124	3GPP TS 24.229 [5] clause 7.2.19: the Origination-Id		122		129		c5
125	3GPP TS 24.229 [5] clause 4.18: Dynamic services interactions		123		130		c6
126	3GPP TS 24.229 [5] clause 7.2.20: the Additional-Identity		124		131		c6
127	3GPP TS 24.229 [5] clause 4.19: RLOS		125		132		c3
128		3GPP TS 24.229 [5] clause 7.2.21: the Priority-Verstat header field		126		133	c6
c1: m in case of roaming II-NNI, else o c2: m in case of roaming II-NNI, else n/a c3: o in case of roaming II-NNI, else n/a c4: m in case of trust relationship between the interconnected networks, else n/a c5: o in case of non-roaming II-NNI and loopback traversal scenario, else n/a c6: o in case of trust relationship between the interconnected networks, else n/a c7: m in case of IMS emergency session traversal scenario on non-roaming II-NNI, else n/a c8: o in case of IMS emergency session traversal scenario on non-roaming II-NNI, else n/a
NOTE 1: The item numbering corresponds to the one provided in table A.4 in 3GPP TS 24.229 [5]. NOTE 2: The item numbering corresponds to the one provided in table A.162 in 3GPP TS 24.229 [5]. NOTE 3: A common URI namespace is required to apply this feature on the II-NNI. NOTE 4: For the roaming II-NNI the support of this major capability is recommended.

Table 6.1.3.2: Key to notation codes for major capabilities

Notation code	Notation name	Explanation
m	mandatory	The capability shall be supported at II-NNI. SIP message relating to this capability shall be sent over the II-NNI if received from the serving network, unless they also make use of other unsupported capabilities. SIP headers or other information elements relating to this capability shall be passed over the II-NNI if received from the sending side. This does not imply that network elements inside the serving network or served network or user equipment connected to these networks shall support this capability.
o	optional	The capability may or may not be supported at II-NNI. The support of the capability is provided based on bilateral agreement between the operators.
n/a	not applicable	It is impossible to use/support the capability at the II-NNI.
c <integer>	conditional	The support of the capability ("m", "o" or "n/a") depends on the support of other optional or conditional items. <integer> is the identifier of the conditional expression.

6.1.4 SIP message bodies

The MIME type "application/sdp" and multipart message bodies (multipart/mixed, multipart/related and multipart/alternative) shall be supported according to IETF RFC 5621 [89] over the II-NNI. Other MIME types may be supported over the II-NNI based on agreement between operators.

The SDP message bodies contained in the INVITE request shall not be encrypted over the II-NNI.

NOTE 1: Some MIME types in SIP requests and responses are listed in annex A of 3GPP TS 24.229 [5].

NOTE 2: The multipart message bodies are used for carrying two or more message body types as described in IETF RFC 5621 [89].

NOTE 3: The IBCF can provide the capabilities to examine the length of a SIP message body and take an appropriate action (e.g. reject the request, remove the body) as specified in clause 5.10.6.3 of 3GPP TS 24.229 [5].

NOTE 4: In the INVITE request, the SDP message body is present over the II-NNI, except when the INVITE request without SDP message body is required to provide services (e.g. 3rd party call control).

Table 6.1.4.1: List of MIME bodies

Item	MIME body name	II-NNI requirements in ref (NOTE 1)	Defined in ref (NOTE 2)
1	application/3gpp-ims+xml	–	3GPP TS 24.229 [5], clause 7.6
3	message/cpim	–	IETF RFC 3862 [92]
4	message/imdn+xml	–	IETF RFC 5438 [93]
5	application/im-iscomposing+xml	clause 16.2	IETF RFC 3994 [175]
6	multipart/mixed	clause 15.1, clause 15.4, clause 15.6.2, clause 15.6.3, clause 15.6.4, clause 18.3.3	IETF RFC 2046 [169]
7	multipart/related	clause 15.1, clause 15.2, clause 15.6.5	IETF RFC 2387 [170]
8	multipart/alternative	–	IETF RFC 2046 [169]
9	application/pidf+xml	clause 15.1, clause 28.2.3.2, clause 28.2.9	IETF RFC 3863 [174]
10	application/pidf-diff+xml	clause 15.1	IETF RFC 5262 [179]
11	application/resource-lists+xml	clause 12.19, clause 15.1, clause 15.6.3, clause 16.5, clause 28.2.1, clause 28.2.7	IETF RFC 4826 [178]
12	application/rlmi+xml	clause 15.2, clause 15.6.5	IETF RFC 4662 [177]
13	application/sdp	–	IETF RFC 4566 [147]
14	application/simple-filter+xml	clause 15.1, clause 15.6.4, clause 28.2.3.2	IETF RFC 4661 [176]
15	application/simple-message-summary+xml	clause 12.9	IETF RFC 3842 [172]
16	message/sipfrag	clause 12.13, clause 18.2, clause 18.3.1	IETF RFC 3420 [171]
17	application/vnd.3gpp.access-transfer-events+xml	clause 14.5.3	3GPP TS 24.237 [131], clause D.5.4
18	application/vnd.3gpp.cw+xml	clause 12.7	3GPP TS 24.615 [37], clause C.1.1
19	application/vnd.3gpp.iut+xml	clause 18.3.2, clause 18.3.3	3GPP TS 24.337 [149], clause C.2.3
20	application/vnd.3gpp.mid-call+xml	clause 14.4	3GPP TS 24.237 [131], clause D.1.3
21	application/vnd.3gpp.replication+xml	clause 18.4.1, clause 18.4.2	3GPP TS 24.337 [149], clause C.1.3
22	application/vnd.3gpp.sms	–
23	application/vnd.3gpp.srvcc-ext+xml	clause 14.5.1	3GPP TS 24.237 [131], clause D.4.4
24	application/vnd.3gpp.srvcc-info+xml	clause 14.2.3	3GPP TS 24.237 [131], clause D.3.4
25	application/vnd.3gpp.state-and-event-info+xml	clause 14.2.2, clause 14.4	3GPP TS 24.237 [131], clause D.2.4
26	application/vnd.3gpp.ussd	clause 12.24	3GPP TS 24.390 [163], clause 5.1.3
27	application/vnd.etsi.aoc+xml	clause 12.22	3GPP TS 24.647 [122], clause E.1.1
28	application/vnd.etsi.cug+xml	clause 12.16	3GPP TS 24.654 [103], clause 4.4.1
29	application/vnd.etsi.mcid+xml	clause 12.2	3GPP TS 24.616 [33], clause 4.4
30	application/vnd.etsi.pstn+xml	–	3GPP TS 29.163 [168], clause F.2
31	application/vnd.oma.suppnot+xml	clause 15.6.2, clause 15.6.3	OMA-SUP-XSD_prs_suppnotFilter-V1_0 [182]
32	application/watcherinfo+xml	clause 15.3	IETF RFC 3858 [173]
33	application/xcap-diff+xml	clause 15.4, clause 15.6.5	IETF RFC 5874 [180]
34	application/session-info	–	3GPP TS 29.163 [168], clause G.2
35	application/load-control+xml	clause 21	IETF RFC 7200 [167]
36	application/vnd.etsi.sci+xml	clause 11.3	3GPP TS 29.658 [186]
37	text/plain	–	IETF RFC 2646 [197]
38	application/x-www-form-urlencoded	–	IETF RFC 1866 [198], clause 8.2.1 (NOTE 3)
39	application/vnd.3gpp.crs+xml	clause 12.15	3GPP TS 24.183 [98], clause D.1
40	message/sip	–	IETF RFC 3261 [13]
41	application/vnd.3gpp.mcptt-info+xml	clause 28.2.1, clause 28.2.3.2, clause 28.2.3.3, clause 28.2.4, clause 28.2.5, clause 28.2.6, clause 28.2.7, clause 28.2.9	3GPP TS 24.379 [201], clause F.1
42	application/vnd.3gpp.mcptt-mbms-usage-info+xml	clause 28.2.2	3GPP TS 24.379 [201], clause F.2
42A	application/vnd.3gpp.mcvideo-mbms-usage-info+xml	clause 28.2.2	3GPP TS 24.281 [210], clause F.2
43	application/vnd.3gpp.mcptt-location-info+xml	clause 28.2.2	3GPP TS 24.379 [201], clause F.3
43A	application/vnd.3gpp.mcvideo-location-info+xml	clause 28.2.2	3GPP TS 24.281 [210], clause F.3
44	application/conference-info+xml	clause 12.19, clause 28.2.4, clause 16.5	IETF RFC 4575 [204]
45	application/poc-settings+xml	clause 28.2.5	IETF RFC 4354 [205]
46	application/vnd.3gpp.mcptt-floor-request+xml	clause 28.2.7	3GPP TS 24.379 [201], clause F.5
47	application/vnd.3gpp.mcptt-affiliation-command+xml	clause 28.2.3.3	3GPP TS 24.379 [201], clause F.4
47A	application/vnd.3gpp.mcptt-signed+xml	clause 28.2.5, clause 28.2.6	3GPP TS 24.379 [201], clause F.6
48	application/call-completion	clause 12.11, clause 12.12, clause 12.23	IETF RFC 6910 [208]
49	application/vnd.3gpp.mcvideo-info+xml	clause 28.2.1 clause 28.2.3.2, clause 28.2.3.3, clause 28.2.5, clause 28.2.4, clause 28.2.6,	3GPP TS 24.281 [210], clause F.1
50	application/vnd.3gpp.mcvideo-affiliation-command+xml	clause 28.2.3.3	3GPP TS 24.281 [210], clause F.4
51	application/vnd.3gpp.mcdata-signalling	clause 28.2.1, clause 28.2.8	3GPP TS 24.282 [211], clause E.1
52	application/vnd.3gpp.mcdata-payload	clause 28.2.8	3GPP TS 24.282 [211], clause E.2
53	application/vnd.3gpp.mcdata-info+xml	clause 28.2.1 clause 28.2.3.2, clause 28.2.3.3, clause 28.2.5, clause 28.2.6, clause 28.2.8	3GPP TS 24.282 [211], clause D.1.4
54	application/vnd.3gpp.mcdata-affiliation-command+xml	clause 28.2.3.3	3GPP TS 24.282 [211], clause D.3.4
NOTE 1: When no specific II-NNI requirements are defined, the II-NNI requirements may be derived from the additional information about MIME types in SIP requests and responses in annex A of 3GPP TS 24.229 [5]. NOTE 2: This column references the definition of the MIME body for informative purpose only, the usage is defined in other specifications not listed here. NOTE 3 The MIME body contains a string that is coded as described in the IETF RFC 1866 [198].

Applicable characteristics of the SIP message body MIMEs (i.e. the value(s) of Content-Disposition header field and Content-Language header field) over the II-NNI may be a subject of operator agreements.

6.2 Control Plane Transport

6.2.1 General

The control plane transport of the II-NNI shall comply with clause 4.2A of 3GPP TS 24.229 [5].

Support of SCTP as specified in IETF RFC 4168 [27] is optional for an IBCF connected by II-NNI. Nevertheless this option is favourable if the operators would like to improve reliability over the Ici.

6.3 SIP timers

Table 6.3.1 shows values of SIP timers that should be supported at II-NNI. It contains the following items:

– the first column, titled "SIP Timer", shows the timer names as defined in IETF RFC 3261 [13] or IETF RFC 6026 [125];

– the second column reflects the timer meaning as defined in IETF RFC 3261 [13];

– the third column reflects the reference to the proper clause in the IETF RFC 3261 [13] and in 3GPP TS 24.229 [5] and

– the final column lists the values recommended for the functional entities closest to the border of an II-NNI (see reference model in clause 5).

Table 6.3.1 reports information from 3GPP TS 24.229 [5], table 7.7.1. Values between IM CN subsystem elements shown in the second column in 3GPP TS 24.229 [5], table 7.7.1 are applicable for the II-NNI and are reported in the fourth column of table 6.3.1. If there are any differences between table 6.3.1 and 3GPP TS 24.229 [5], table 7.7.1, the information within 3GPP TS 24.229 [5], table 7.7.1 is applicable.

Table 6.3.1: SIP timers at II-NNI

SIP Timer	Meaning	Reference	Recommended values
T1	RTT estimate	[13] clause 17.1.1.1 [5] table 7.7.1	500ms default (see NOTE)
T2	The maximum retransmit interval for non-INVITE requests and INVITE responses	[13] clause 17.1.2.2 [5] table 7.7.1	4s (see NOTE)
T4	Maximum duration a message will remain in the network	[13] clause 17.1.2.2 [5] table 7.7.1	5s (see NOTE)
Timer A	INVITE request retransmit interval, for UDP only	[13] clause 17.1.1.2 [5] table 7.7.1	initially T1
Timer B	INVITE transaction timeout timer	[13] clause 17.1.1.2 [5] table 7.7.1	64*T1
Timer C	proxy INVITE transaction timeout	[13] clause 16.6 [5] table 7.7.1	> 3min
Timer D	Wait time for response retransmits	[13] clause 17.1.1.2 [5] table 7.7.1	> 32s for UDP
Timer D	Wait time for response retransmits	[13] clause 17.1.1.2 [5] table 7.7.1	0s for TCP/SCTP
Timer E	non-INVITE request retransmit interval, UDP only	[13] clause 17.1.2.2 [5] table 7.7.1	initially T1
Timer F	non-INVITE transaction timeout timer	[13] clause 17.1.2.2 [5] table 7.7.1	64*T1
Timer G	INVITE response retransmit interval	[13] clause 17.2.1 [5] table 7.7.1	initially T1
Timer H	Wait time for ACK receipt.	[13] clause 17.2.1 [5] table 7.7.1	64*T1
Timer I	Wait time for ACK retransmits	[13] clause 17.2.1 [5] table 7.7.1	T4 for UDP
Timer I	Wait time for ACK retransmits	[13] clause 17.2.1 [5] table 7.7.1	0s for TCP/SCTP
Timer J	Wait time for non-INVITE request retransmits	[13] clause 17.2.2 [5] table 7.7.1	64*T1 for UDP
Timer J	Wait time for non-INVITE request retransmits	[13] clause 17.2.2 [5] table 7.7.1	0s for TCP/SCTP
Timer K	Wait time for response retransmits	[13] clause 17.1.2.2 [5] table 7.7.1	T4 for UDP
Timer K	Wait time for response retransmits	[13] clause 17.1.2.2 [5] table 7.7.1	0s for TCP/SCTP
Timer L	Wait time for accepted INVITE request retransmits	[125] clause 8.11 [5] table 7.7.1	64*T1
Timer M	Wait time for retransmission of 2xx to INVITE or additional 2xx from other branches of a forked INVITE	[125] clause 8.11 [5] table 7.7.1	64*T1
Timer N	Wait time for receipt of a NOTIFY request upon sending SUBSCRIBE	[20] clause 4.1.2 [5] table 7.7.1	64*T1
NOTE: As a network option, SIP T1 Timer’s value can be extended, along with the necessary modifications of SIP T2 and SIP T4 Timer values, to take into account the specificities of the supported services when the MRFC and the controlling AS are under the control of the same operator and the controlling AS knows, based on local configuration, that the MRFC implements a longer value of SIP T1 Timer.