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
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
|
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 7976 N. Biondic
Updates: 7315 Ericsson
Category: Informational G. Salgueiro
ISSN: 2070-1721 Cisco
September 2016
Updates to Private Header (P-Header) Extension Usage
in Session Initiation Protocol (SIP) Requests and Responses
Abstract
The Third Generation Partnership Project (3GPP) has identified cases
where different SIP private header extensions referred to as "P-"
header fields, and defined in RFC 7315, need to be included in SIP
requests and responses currently not allowed according to RFC 7315.
This document updates RFC 7315, in order to allow inclusion of the
affected "P-" header fields in such requests and responses.
This document also makes updates for RFC 7315 in order to fix
misalignments that occurred when RFC 3455 was updated and obsoleted
by RFC 7315.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7976.
Holmberg, et al. Informational [Page 1]
^L
RFC 7976 Updates to P-Header Usage September 2016
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Misalignments and 3GPP Use Cases . . . . . . . . . . . . . . 3
2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Misalignments . . . . . . . . . . . . . . . . . . . . . . 3
2.3. 3GPP Use Cases . . . . . . . . . . . . . . . . . . . . . 4
2.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.2. P-Access-Network-Info . . . . . . . . . . . . . . . . 4
2.3.3. P-Charging-Vector . . . . . . . . . . . . . . . . . . 5
3. Updates to RFC 7315 . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Normative References . . . . . . . . . . . . . . . . . . 7
5.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The Third Generation Partnership Project (3GPP) has identified cases
where different Session Initiation Protocol (SIP) [RFC3261] private
header extensions referred to as "P-" header fields, and defined in
[RFC7315], need to be included in SIP requests and responses
currently not allowed according to RFC 7315. This document updates
RFC 7315, in order to allow inclusion of the affected "P-" header
fields in such requests and responses.
This document also makes updates for RFC 7315 in order to fix
misalignments that occurred when RFC 3455 [RFC3455] was updated and
obsoleted by RFC 7315.
Holmberg, et al. Informational [Page 2]
^L
RFC 7976 Updates to P-Header Usage September 2016
As the "P-" header fields are mainly used in (and in most cases, only
defined for) networks defined by the 3GPP, where the updates defined
in this document are already defined [TS.3GPP.24.229], the updates
are not seen to cause backward-compatibility concerns.
2. Misalignments and 3GPP Use Cases
2.1. General
RFC 7315 contains contradicting statements regarding the usage of SIP
"P-" header fields in SIP requests and responses, which leave the
presence of the SIP "P-" header fields in the SIP requests and
responses open to interpretation and different implementations.
Statements in Section 5.7 of that RFC are not aligned with the
definitions and usage of the SIP "P-" header fields specified in
Section 4. This section describes the misalignments that occurred
when RFC 3455 was updated and obsoleted by RFC 7315, and how they are
fixed.
NOTE: In the case of the P-Called-Party-ID header field, allowing it
in PUBLISH requests was deliberately done in RFC 7315. Therefore, it
is not considered a misalignment.
Since RFC 7315 was published, 3GPP defined new use cases that require
the RFC to be updated. This section describes the 3GPP use cases
behind the updates, and the updates needed to RFC 7315 in order to
support the use cases.
Section 3 updates RFC 7315, based on the misalignments and 3GPP use
cases.
2.2. Misalignments
The following updates are needed in order to fix the misalignments
between RFCs 7315 and 3455:
o P-Associated-URI: Remove the statement that the header field can
appear in the SIP REGISTER method.
o P-Called-Party-ID: Delete the statement that the P-Called-Party-ID
header field can appear in SIP responses. Add a statement that
the P-Called-Party-ID header field can appear in the SIP REFER
method.
o P-Visited-Network-ID: Delete the statement that the P-Visited-
Network-ID header field can appear in SIP responses. Add a
statement that the P-Visited-Network-ID header field cannot appear
in the SIP NOTIFY, PRACK, INFO, and UPDATE methods.
Holmberg, et al. Informational [Page 3]
^L
RFC 7976 Updates to P-Header Usage September 2016
o P-Access-Network-Info: Add a statement that the P-Access-Network-
Info header field can appear in SIP responses.
o P-Charging-Vector: Add a statement that the P-Charging-Vector
header field can appear in SIP responses. Add a statement that
the P-Charging-Vector header field cannot appear in the SIP ACK
method.
o P-Charging-Function-Addresses: Add a statement that the
P-Charging-Function-Addresses header field can appear in SIP
responses.
2.3. 3GPP Use Cases
2.3.1. General
The following updates are needed in order to implement the 3GPP use
cases:
o P-Access-Network-Info: Add statement that the P-Access-Network-
Info header field can appear in the SIP ACK method when triggered
by a SIP 2xx response.
o P-Charging-Vector: Add statement that the P-Charging-Vector header
field can appear in the SIP ACK method when triggered by a SIP 2xx
response.
This following sections describe, for individual "P-" header fields,
the 3GPP use cases that are the basis for the updates. The use cases
are based on the procedures defined in [TS.3GPP.24.229].
2.3.2. P-Access-Network-Info
The P-Access-Network-Info header field may contain the Network
Provided Location Information (NPLI). The NPLI is described in
[TS.3GPP.23.228].
A proxy in possession of appropriate information about the access
technology might insert a P-Access-Network-Info header field with its
own values. Such values are identified by the string "network-
provided" defined in RFC 7315. Based on operator policy and/or
roaming agreement, the local time of the visited network may be
included.
The Call Data Records (CDRs) generated within the IP Multimedia
Subsystem (IMS) have to contain the NPLI in order to guarantee
correct billing. When an IMS session is modified, the NPLI also
needs to be stored as the location of the user at the time when the
Holmberg, et al. Informational [Page 4]
^L
RFC 7976 Updates to P-Header Usage September 2016
session is modified may generate a charging event. In case of a
session modification event at IMS, the NPLI needs to be provided:
o when the bearer establishment is triggered, or
o at session release when the bearer deactivation is triggered, or
o when the bearer modification is triggered, e.g., a QoS
modification for the use of a newly negotiated codec.
In some scenarios, the bearer modification may be triggered by the
proxy upon reception of a Session Description Protocol (SDP) answer
within SIP 2xx response to the SIP INVITE request. In such case, the
NPLI needs to be provided within the SIP ACK request. However, RFC
7315 does not allow the usage of the P-Access-Network-Info header
field in SIP ACK request.
Upon reception of the SDP answer within SIP 2xx response on the SIP
INVITE request, a proxy may initiate procedures to obtain the NPLI
and may include the P-Access-Network-Info header field with the NPLI
in the SIP ACK request.
The P-Access-Network-Info header field shall not be included in SIP
ACK requests triggered by non-2xx responses.
2.3.3. P-Charging-Vector
RFC 7315 defines an Inter Operator Identifier (IOI) to enable
different operators involved in a SIP dialog or a transaction outside
a dialog to identify each other by exchanging operator identification
information within the P-Charging-Vector header field.
In the interconnection scenarios in multi-operator environments,
where one or more transit operators are between the originating and
terminating operator, the identities of the involved transit
operators are represented by a transit-ioi parameter of the
P-Charging-Vector header field.
Transit operators can be selected independently for each SIP method
and direction of request. A transit network will only have knowledge
of an individual SIP request, and transit network selection will be
an independent decision for each request and could be made based on
load, cost, percentage, time of day, and other factors. For this
reason, it is necessary that the P-Charging-Vector header field,
which carries the transit IOI information, is included in each SIP
request and response. However, RFC 7315 does not allow the usage of
the P-Charging-Vector header field in the SIP ACK request.
Holmberg, et al. Informational [Page 5]
^L
RFC 7976 Updates to P-Header Usage September 2016
A SIP proxy that supports this extension and receives the SIP ACK
request may include a P-Charging-Vector header field in the SIP ACK
request.
The P-Charging-Vector header field shall not be included in SIP ACK
requests triggered by SIP non-2xx responses.
3. Updates to RFC 7315
This section implements the update to Section 5.7 of RFC 7315, in
order to implement the misalignment fixes and the 3GPP requirements
described in Section 2.
Old text:
The P-Associated-URI header field can appear in SIP REGISTER method
and 2xx resonses [sic]. The P-Called-Party-ID header field can
appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE
methods and all responses. The P-Visited-Network-ID header field can
appear in all SIP methods except ACK, BYE, and CANCEL and all
responses. The P-Access-Network-Info header field can appear in all
SIP methods except ACK and CANCEL. The P-Charging-Vector header
field can appear in all SIP methods except CANCEL. The
P-Charging-Function-Addresses header field can appear in all SIP
methods except ACK and CANCEL.
New text:
The P-Associated-URI header field can appear in SIP REGISTER 2xx
responses. The P-Called-Party-ID header field can appear in the SIP
INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods. The
P-Visited-Network-ID header field can appear in all SIP methods
except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO, and UPDATE. The
P-Access-Network-Info header field can appear in all SIP methods and
non-100 responses, except in CANCEL methods, CANCEL responses, and
ACK methods triggered by non-2xx responses. The P-Charging-Vector
header field can appear in all SIP methods and non-100 responses,
except in CANCEL methods, CANCEL responses, and ACK methods triggered
by non-2xx responses. The P-Charging-Function-Addresses header field
can appear in all SIP methods and non-100 responses, except in CANCEL
methods, CANCEL responses, and ACK methods.
Holmberg, et al. Informational [Page 6]
^L
RFC 7976 Updates to P-Header Usage September 2016
4. Security Considerations
The security considerations for these "P-" header fields are defined
in [RFC7315]. This specification allows some header fields to be
present in messages where they were previously not allowed, and the
security considerations and assumptions described in [RFC7315] (e.g.,
regarding only sending information to trusted entities) also apply to
those messages. In addition, this specification also disallows some
header fields to be present in messages where they were previously
allowed. That does not cause any security issues, but implementors
need to be aware that implementations may not have been updated
according to this document, and take proper actions if a header field
occurs, or does not occur, in a message where it should occur (or
occurs in a message where it should not occur). This document adds
the ability to include P-Access-Network-Info in ACK requests. As
documented in [RFC7315], P-Access-Network-Info may include privacy
sensitive information, including the user's location. The security
and privacy considerations for P-Access-Network-Info in ACK requests
are similar to those for the other SIP requests discussed in
[RFC7315].
5. References
5.1. Normative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC7315] Jesske, R., Drage, K., and C. Holmberg, "Private Header
(P-Header) Extensions to the Session Initiation Protocol
(SIP) for the 3GPP", RFC 7315, DOI 10.17487/RFC7315, July
2014, <http://www.rfc-editor.org/info/rfc7315>.
[TS.3GPP.23.228]
3GPP, "IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description
Protocol (SDP); Stage 3", 3GPP TS 23.228 13.6.0, June
2016, <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
[TS.3GPP.24.229]
3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP
TS 24.229 13.6.0, June 2016,
<http://www.3gpp.org/ftp/Specs/html-info/24229.htm>.
Holmberg, et al. Informational [Page 7]
^L
RFC 7976 Updates to P-Header Usage September 2016
5.2. Informative References
[RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private
Header (P-Header) Extensions to the Session Initiation
Protocol (SIP) for the 3rd-Generation Partnership Project
(3GPP)", RFC 3455, DOI 10.17487/RFC3455, January 2003,
<http://www.rfc-editor.org/info/rfc3455>.
Acknowledgments
Thanks to Paul Kyzivat, Jean Mahoney, Ben Campbell, and Adam Roach
for providing comments on the document.
Authors' Addresses
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Nevenka Biondic
Ericsson
Krapinska 45
Zagreb 10002
Croatia
Email: nevenka.biondic@ericsson.com
Gonzalo Salgueiro
Cisco Systems, Inc.
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
United States of America
Email: gsalguei@cisco.com
Holmberg, et al. Informational [Page 8]
^L
|
