rfc9878.original.xml   rfc9878.xml 
<?xml version='1.0' encoding='utf-8'?><!DOCTYPE rfc [ <!ENTITY nbsp "&#160;" <?xml version='1.0' encoding='UTF-8'?>
> <!ENTITY zwsp "&#8203;"> <!ENTITY nbhy "&#8209;"> <!ENTITY wj "&#82
88;">]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?><rfc xmlns:xi="htt <!DOCTYPE rfc [
p://www.w3.org/2001/XInclude" category="info" ipr="trust200902" updates="7315" d <!ENTITY nbsp "&#160;">
ocName="draft-ietf-sipcore-rfc7976bis-04" obsoletes="7976" submissionType="IETF" <!ENTITY zwsp "&#8203;">
xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" ver <!ENTITY nbhy "&#8209;">
sion="3"> <!-- xml2rfc v2v3 conversion 3.17.3 --> <front> <title abbrev="Up <!ENTITY wj "&#8288;">
date to Private Header">Updates to Private Header (P-Header) Extension Usage ]>
in Session Initiation Protocol (SIP) Requests and Responses</title> <series
Info name="Internet-Draft" value="draft-ietf-sipcore-rfc7976bis-04"/> <author <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902
initials="C." surname="Holmberg" fullname="Christer Holmberg"> <organizati " updates="7315" docName="draft-ietf-sipcore-rfc7976bis-04" number="9878" consen
on>Ericsson</organization> <address> <postal> <street>Hirsa sus="true" obsoletes="7976" submissionType="IETF" xml:lang="en" tocInclude="true
lantie 11</street> <city>Jorvas</city> <code>02420</code> " tocDepth="4" symRefs="true" sortRefs="true" version="3">
<country>Finland</country> </postal> <phone/> <email>c
hrister.holmberg@ericsson.com</email> <uri/> </address> </author> <!-- [rfced] Because this document updates RFC 7315, please
<author initials="N." surname="Biondic" fullname="Nevenka Biondic"> <or review the errata reported for RFC 7315
ganization>Ericsson</organization> <address> <postal> <stre (https://www.rfc-editor.org/errata/rfc7315)
et>Krapinska 45</street> <city>Zagreb</city> <code>10002</code and let us know if you confirm our opinion that none of them
> <country>Croatia</country> </postal> <phone/> <e are relevant to the content of this document.
mail>nevenka.biondic.ext@ericsson.com</email> <uri/> </address> < -->
/author> <author initials="G." surname="Salgueiro" fullname="Gonzalo Salgueir
o"> <organization>Cisco Systems, Inc.</organization> <address> <!-- [rfced] Because this document obsoletes RFC 7976, please
<postal> <street>7200-12 Kit Creek Road</street> <city>Researc review the errata reported for RFC 7976
h Triangle Park</city> <code>NC 27709</code> <country>United (https://www.rfc-editor.org/errata/rfc7976)
States of America</country> </postal> <phone/> <email>gsalg and let us know if you confirm our opinion that none of them
uei@cisco.com</email> <uri/> </address> </author> <author init are relevant to the content of this document.
ials="R." surname="Jesske" fullname="Roland Jesske"> <organization>Deutsche -->
Telekom</organization> <address> <postal> <street>Telekom
Allee 9</street> <city>Darmstadt</city> <code>64295</code> <front>
<country>Germany</country> </postal> <phone/> <email> <title abbrev="Update to Private Header">Updates to Private Header (P-Header
r.jesske@telekom.de</email> <uri>www.telekom.com</uri> </address> ) Extension Usage
</author> <date year="2025"/> <area>ART</area> <workgroup>sipcore</wor in Session Initiation Protocol (SIP) Requests and Responses</title>
kgroup> <keyword>Internet-Draft</keyword> <keyword>3GPP</keyword> <keyw <seriesInfo name="RFC" value="9878"/>
ord>Visited</keyword> <keyword>ID</keyword> <abstract> <t> The Thir <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
d Generation Partnership Project (3GPP) has identified cases where different SIP <organization>Ericsson</organization>
private header extensions referred to as "P-" header fields, and defined in RFC <address>
7315, need to be included in SIP requests and responses currently not allowed a <postal>
ccording to RFC 7315. This document updates RFC 7315, in order to allow inclusio <street>Hirsalantie 11</street>
n of the affected "P-" header fields in such requests and responses. This Docume <city>Jorvas</city>
nt obsoletes RFC 7976. The changes related to RFC7976 involve the inclusion of t <code>02420</code>
he P-Visited-Network-ID header field in SIP responses.</t><t> This docume <country>Finland</country>
nt also makes updates for RFC 7315 in order to fix misalignments that occurred w </postal>
hen RFC 3455 was updated and subsequently obsoleted by the publication of RFC 73 <email>christer.holmberg@ericsson.com</email>
15. </t> </abstract> </front> <middle> <!-- *********************** </address>
****************************************************************************** - </author>
-> <section anchor="intro" numbered="true" toc="default"> <name> <author initials="N." surname="Biondic" fullname="Nevenka Biondic">
Introduction</name> <t> The Third Generation Partnership Proje <organization>Ericsson</organization>
ct (3GPP) has identified cases where different Session Initiation Protocol (SIP) <address>
<xref target="RFC3261" format="default"/> private header extensions referr <postal>
ed to as "P-" header fields, and defined in <xref target="RFC7315" form <street>Krapinska 45</street>
at="default"/>, need to be included in SIP requests and responses curren <city>Zagreb</city>
tly not allowed according to <xref target="RFC7315" format="default"/>. This do <code>10002</code>
cument updates <xref target="RFC7315" format="default"/>, in order to allow incl <country>Croatia</country>
usion of the affected "P-" header fields in such requests and responses. </postal>
</t><t> This document also makes updates for <xref target="RFC7315" fo <email>nevenka.biondic.ext@ericsson.com</email>
rmat="default"/> in order to fix misalignments that occurred when <xref </address>
target="RFC3455" format="default"/> was updated and subsequently obsoleted by t </author>
he publication of <xref target="RFC7315" format="default"/>. </t> </s <author initials="G." surname="Salgueiro" fullname="Gonzalo Salgueiro">
ection> <section anchor="Misalingment_3GPP_Use_Cases" numbered="true" toc="de <organization>Cisco Systems, Inc.</organization>
fault"> <name>Misalignments and 3GPP Use Cases</name> <section anchor= <address>
"General" numbered="true" toc="default"> <name>General</name> <t> <postal>
<street>7200-12 Kit Creek Road</street>
<xref target="RFC7315" format="default"/> contains contradicting statements reg <city>Research Triangle Park</city>
arding the usage of SIP "P-" header fi <region>NC</region><code>27709</code>
elds in SIP requests and responses, which leave the presence of the SIP "P-" hea <country>United States of America</country>
der fields in the SIP requests and respon </postal>
ses open to interpretation and different implementations. Statements in Section <email>gsalguei@cisco.com</email>
5.7 of that RFC are not aligned with the </address>
definitions and usage of the SIP "P-" header fields specified in Section 4. T </author>
his section describes the misalignments that occurred <author initials="R." surname="Jesske" fullname="Roland Jesske">
when <xref target="RFC3455" format="default"/> was updated and subsequ <organization>Deutsche Telekom</organization>
ently obsoleted by the publication of <xref target="RFC7315" format="default"/>, <address>
and how they are fixed. </t> <t> <postal>
NOTE: In the case of the P-Called-Party-ID header field, allowing it <street>Telekom Allee 9</street>
in PUBLISH requests was done deliberately in < <city>Darmstadt</city>
xref target="RFC7315" format="default"/>. Therefore, it <code>64295</code>
is not considered a misalignment. </t> <t> <country>Germany</country>
Since <xref target="RFC7315" format="default"/ </postal>
> was published, 3GPP defined new use cases that require <email>r.jesske@telekom.de</email>
the RFC to be updated. This section describes the 3GPP use ca <uri>www.telekom.com</uri>
ses behind the updates, and the updates ne </address>
eded to <xref target="RFC7315" format="default"/> in order to </author>
support the use cases. </t> <t> <date year="2025" month="October"/>
Section 3 updates <xref target="RFC7315" format="defau <area>ART</area>
lt"/>, based on the misalignments and 3GPP use <workgroup>sipcore</workgroup>
cases. </t> </section>
<section anchor="Misalignments" numbered="true" toc="default"> <name> <keyword>3GPP</keyword>
Misalignments</name> <t> <keyword>Visited</keyword>
The following updates are needed in order to fix the misalignments <keyword>ID</keyword>
that occurred when <xref target="RFC3455" form
at="default"/> was updated and obsolated by <xref target="RFC7315" format="defau <abstract>
lt"/>: </t> <t> o P-A <t>
ssociated-URI: Remove the statement that the header field can <!--[rfced] Abstract and Introduction: Please review if the first sentence
appear in the SIP REGISTER method. </t> conveys the intended meaning. Specifically, should "currently not allowed"
<t> o P-Called-Party-ID: be rephrased? This text is directly from RFC 7976, published in 2016. What
Delete the statement that the P-Called-Party-ID is the subject of "not allowed"? It can be read as the requests and responses
header field can appear in SIP responses. Add a statem are not allowed.
ent that the P-Called-Pa
rty-ID header field can appear in the SIP REFER Based on "This specification allows some header fields to be present
method. </t> <t> in messages where they were previously not allowed" (Section 5),
o P-Access-Network-Info: Add a statem we make the following suggestion.
ent that the P-Access-Network-
Info header field can appear in SIP responses. </t> <t> Original:
o P-Charging-Vector: Add a statement that the The Third Generation Partnership Project (3GPP) has identified cases
P-Charging-Vector header where different SIP private header extensions referred to as "P-"
field can appear in SIP responses. Add a statement that header fields, and defined in RFC 7315, need to be included in SIP
the P-Charging-Vector header field cannot appea requests and responses currently not allowed according to RFC 7315.
r in the SIP ACK method.
</t> <t> o P-C Perhaps:
harging-Function-Addresses: Add a statement that the The Third Generation Partnership Project (3GPP) has identified cases
P-Charging-Function-Addresses header field can appear i where different SIP private header extensions referred to as "P-"
n SIP responses. </t> header fields, and defined in RFC 7315, need to be included in SIP
<t> The following update is requests and responses where they were not allowed according to RFC 7315.
needed in order to clarify the usage of the header compared to <xref target="RFC -->
7315" format="default"/>: </t> <t> The Third Generation Partnership Project (3GPP) has identified cases where di
o P-Visited-Network-ID: Add a fferent SIP private header extensions referred to as "P-" header fields, and def
statement that the P-Visited-Network-ID header field ca ined in RFC 7315, need to be included in SIP requests and responses currently no
nnot appear in the SIP NOTI t allowed according to RFC 7315. This document updates RFC 7315, in order to all
FY, PRACK, INFO, and UPDATE methods. Add statement that the P-Visited-Network-ID ow inclusion of the affected "P-" header fields in such requests and responses.
header field can appear in all non-100 (Trying) responses. </t> This document obsoletes RFC 7976. The changes related to RFC 7976 involve the in
</section> <!-- ********************************************************* clusion of the P-Visited-Network-ID header
******************************************** --> field in SIP responses.
<section anchor="_GPP_Use_Cases" numbered="true" toc="d </t>
efault"> <name>3GPP Use Cases</name> <!-- ************************ <!--[rfced] Abstract and Introduction: Please clarify "when RFC 3455 was
***************************************************************************** -- updated and subsequently obsoleted by the publication of RFC 7315".
>
<section anchor="General_use_case" numbered="true" toc="default"> <nam In the RFC series, "updated" has a specific meaning, distinct from "obsoleted".
e>General</name> <t> RFC 3455 has not been updated by any other RFCs, so the original sentence
The following updates are needed in order to implement the 3GP is not accurate. We suggest simply "obsoleted" as follows. Please let us
P use cases: know if you prefer otherwise.
</t> <t>
o P-Access-Network-Info: Add statement that the P-Access-Netw Original:
ork- This document also makes updates for RFC 7315 in order to fix
Info header field can appear in the SIP ACK method when triggered misalignments that occurred when RFC 3455 was updated and
by a SIP 2xx re subsequently obsoleted by the publication of RFC 7315.
sponse. </t> <t>
o P-Charging-Vector: Add statement that the P-Chargin Perhaps:
g-Vector header This document also makes updates for RFC 7315 in order to fix
field can appear in the SIP ACK method when triggered by a SIP misalignments that occurred when RFC 3455 was obsoleted by
2xx RFC 7315.
response. </t> <t>
This following sections describe, for individual "P-" Or (if you prefer to explain):
header fields, This document also makes updates for RFC 7315 in order to fix
the 3GPP use cases that are the basis for the updates. The use cases misalignments that occurred when RFC 3455 was obsoleted by
are based on t RFC 7315, i.e., when the content of RFC 3455 was completely replaced.
he procedures defined in <xref target="TS24.229" format="default"/>. < -->
/t> </section> <!-- ********************************************** <t>
******************************************************* --> This document also makes updates to RFC 7315 in order to fix misalignments th
<section anchor="P-Access-Netwo at occurred when RFC 3455 was updated and subsequently obsoleted by the publicat
rk-Info" numbered="true" toc="default"> <name>P-Access-Network-Info</na ion of RFC 7315.
me> <t> </t>
The P-Access-N </abstract>
etwork-Info header field may contain the Network </front>
Provided Location Information (NPLI). The NPL <middle>
I is described in
<xref target="TS23.228" format="default"/>. </t> <t> <section anchor="intro" numbered="true" toc="default">
A proxy in possession <name>Introduction</name>
of appropriate information about the access <t>
technology might insert a P-Access-Network-Info header The Third Generation Partnership Project (3GPP) has identified cases w
field with its here different Session Initiation Protocol (SIP) <xref target="RFC3261" format="
own values. Such values are identified by the string "network- default"/> private header extensions
provided" defined in <xref tar referred to as "P-" header fields, and defined in <xref targe
get="RFC7315" format="default"/>. Based on operator policy, roaming agreement o t="RFC7315" format="default"/>, need to be included in SIP requests and response
r both, the local time of the visited network may be s
included. </t> <t> currently not allowed according to <xref target="RFC7315" format="defa
The Call Data Records (CDRs) ult"/>. This document updates <xref target="RFC7315" format="default"/>, in ord
generated within the IP Multimedia er to allow inclusion of the affected "P-" header
Subsystem (IMS) have to contain the NPLI in order to g fields in such requests and responses.
uarantee </t>
correct billing. When an IMS session is modified, the NPLI also <t>
needs to be stored as This document also makes updates to <xref target="RFC7315" format="def
the location of the user at the time when the ault"/> in order to fix
session is modified may generate a charging misalignments that occurred when <xref target="RFC3455" format="defaul
event. In case of a t"/> was updated and subsequently obsoleted by the publication of <xref target="
session modification event at IMS, the NPLI needs to be provide RFC7315" format="default"/>.
d: </t> <t>
o when the bearer establishment is triggered, or </t> </t>
<t> </section>
o at session release when the bearer deactivation is triggered, or < <section anchor="Misalignment_3GPP_Use_Cases" numbered="true" toc="default">
/t> <t> <name>Misalignments and 3GPP Use Cases</name>
o when the bearer modification is triggered, e.g., a QoS <section anchor="General" numbered="true" toc="default">
modification fo <name>General</name>
r the use of a newly negotiated codec. </t> <t> <t>
In some scenarios, the
bearer modification may be triggered by the <xref target="RFC7315" format="default"/> contains contradictory statements reg
proxy upon reception of a Session Description arding the usage of SIP
Protocol (SDP) answer "P-" header fields in SIP requests and
within SIP 2xx response to the SIP INVITE request. In such case, the responses, which leave the presence of the SIP "P-" header fields in the SIP re
NPLI n quests and
eeds to be provided within the SIP ACK request. However, <xref target="RFC7315" responses open to interpretation and d
format="default"/> does not allow the usage of the P-Access-Network-Info heade ifferent implementations. Statements in <xref target="RFC7315" section="5.7"/> a
r field re not aligned with the
in SIP ACK request. </t> <t> definitions and usage of the SIP "P-"
Upon reception of the SDP answer within SIP 2x header fields specified in <xref target="RFC7315" section="4"/>. This section d
x response on the SIP escribes the misalignments that occurred
INVITE request, a proxy may initiate procedures to obtain the NPLI when <xref target="RFC3455" format="de
and may includ fault"/> was updated and subsequently obsoleted by the publication of <xref targ
e the P-Access-Network-Info header field with the NPLI et="RFC7315" format="default"/>, and how they are fixed.
in the SIP ACK request. </t> </t>
<t> <!-- [rfced] Would you like the note in this document to be in an
The P-Access-Network-Info header field shall not be included in SIP <aside> element, or remain as is? It is defined as "a container for
ACK requests triggered content that is semantically less important or tangential to the
by non-2xx responses. </t> </section> <!-- ************* content that surrounds it" (https://authors.ietf.org/rfcxml-vocabulary#aside).
********************************************************************************
******** --> <!-- *** Original:
******************************************************************************** NOTE: In the case of the P-Called-Party-ID header field, allowing it
****************** --> in PUBLISH requests was done deliberately in [RFC7315]. Therefore,
<section anchor="P-Charging-Vector" numbered="true" toc="defaul it is not considered a misalignment.
t"> <name>P-Charging-Vector</name> <t> -->
<xref target="RFC7315" format="default"/> defines an I <t>
nter Operator Identifier (IOI) to enable NOTE: In the case of the P-Called-Part
different operators involved in a SIP dialog or a tran y-ID header field, allowing it
saction outside in PUBLISH requests was done deliberat
a dialog to identify each other by exchanging operator identification ely in <xref target="RFC7315" format="default"/>. Therefore, it
information within the is not considered a misalignment.
P-Charging-Vector header field. </t> <t> </t>
In the interconnection scenarios in mu <t>
lti-operator environments, Since <xref target="RFC7315" format="d
where one or more transit operators are between the originating and efault"/> was published, 3GPP defined new use cases that require
terminating operator, the RFC to be updated. This section d
the identities of the involved transit escribes the 3GPP use cases
operators are represented by a transit-ioi parameter of the behind the updates, and the updates ne
P-Charging-Vector head eded to <xref target="RFC7315" format="default"/> in order to
er field. </t> <t> support the use cases.
Transit operators can be selected independently for each SIP m </t>
ethod and direction
of request. A transit network will only have knowledge <t>
of an individual SIP request, and tran <xref target="Updates_to_RFC_7315"/> u
sit network selection will be pdates <xref target="RFC7315" format="default"/>, based on the misalignments and
an independent decision for each request and could be made based on 3GPP use
load, cost, percentage cases.
, time of day, and other factors. For this
reason, it is necessary that the P-Charging-Vector hea </t>
der field, which </section>
carries the transit IOI information, is included in each SIP <section anchor="Misalignments" numbered="true" toc="default">
request and response. However, <xref <name>Misalignments</name>
target="RFC7315" format="default"/> does not allow the usage of <t>
the P-Charging-Vector header f The following updates are needed
ield in the SIP ACK request. in order to fix the misalignments
</t> <t> that occurred when <xref targe
A SIP proxy that supports this extension and receives the SIP ACK t="RFC3455" format="default"/> was obsoleted by <xref target="RFC7315" format="d
request may include a efault"/>:
P-Charging-Vector header field in the SIP ACK </t>
request. </t> <t>
The P-Charging-Vector header field sha <ul spacing="normal">
ll not be included in SIP ACK <li>P-Associated-URI: Remove the statement that the header field can appear in
requests triggered by SIP non-2xx responses. </t> </se the SIP REGISTER method.</li>
ction> <!-- ************************************************************* <li>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
</section> </section> <!-- **************************************** header field can appear in the SIP REFER method.</li>
******************************************************************************** <li>P-Access-Network-Info: Add a statement that the P-Access-Network- Info
********************************** --> <section anchor="Updates_to_RFC_7315" header field can appear in SIP responses.</li>
numbered="true" toc="default"> <name>Updates to RFC 7315</name> <t> <li>P-Charging-Vector: Add a statement that the P-Charging-Vector header field
This section implements the update to Section 5.7 of <xref target="RFC can appear in SIP responses. Add a statement that the P-Charging-Vector
7315" format="default"/>, in order to implement the misalignment fixes and header field cannot appear in the SIP ACK method.</li>
the 3GPP requirements described in Section 2. </t> <t> Old te <li>P-Charging-Function-Addresses: Add a statement that the
xt: </t> <t> The P-Associated-URI header field can appear in SIP RE P-Charging-Function-Addresses header field can appear in SIP responses.</li>
GISTER method and 2xx resonses. </t> <t> The P-Called-Part </ul>
y-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and
MESSAGE methods and all responses. </t> <t> The P-Visi <t>The following update is needed in order to clarify the usage of
ted-Network-ID header field can appear in all SIP methods except ACK, the header compared to <xref target="RFC7315" format="default"/>:</t>
BYE, and CANCEL and all responses. </t> <t>The P-Access-Netw <ul spacing="normal">
ork-Info header field can appear in all SIP methods except ACK and CAN <li>P-Visited-Network-ID: Add a statement that the P-Visited-Network-ID header
CEL. </t> <t>The P-Charging-Vector header field can appear in al field cannot appear in the SIP NOTIFY, PRACK, INFO, and UPDATE methods. Add
l SIP methods except CANCEL. </t> <t>The P-Charging-Function-Addresses statement that the P-Visited-Network-ID header field can appear in all non-100
header field can appear in all SIP methods except ACK and CANCEL. </ (Trying) responses.</li>
t> <t> New text: </t> <t> The P-Associated-URI h </ul>
eader field can appear in SIP REGISTER 2xx responses. </t> <t> </section>
The P-Called-Party-ID header field can appear in the SIP INVITE, OPTION
S, PUBLISH, REFER, SUBSCRIBE, and MESSAGE requests. </t> <t> Th <section anchor="_GPP_Use_Cases" numbered="true" toc="default">
e P-Visited-Network-ID header field can appear in all SIP requests and the assoc <name>3GPP Use Cases</name>
iated non-100 response message except in ACK, BYE, CANCEL, NOTIFY, PRACK, INF
O, UPDATE. </t> <t> The P-Access-Network-Info header field can <section anchor="General_use_case" numbered="true" toc="default">
appear in all SIP requests and the associated non-100 responses, except in C <name>General</name>
ANCEL requests, CANCEL responses, and ACK methods triggered by non-2xx respo <t>The following updates are needed in order to implement the 3GPP
nses. </t> <t> The P-Charging-Vector header field can appear in a use cases:</t>
ll SIP requests and the associated non-100 responses, except in CANCEL reque
sts, CANCEL responses, and ACK requests triggered by non-2xx responses. <ul spacing="normal">
</t> <t> The P-Charging-Function-Addresses header field <li>P-Access-Network-Info: Add statement that the P-Access-Network- Info
can appear in all SIP methods and the associated non-100 responses, except in header field can appear in the SIP ACK method when triggered by a SIP 2xx
CANCEL requests, CANCEL responses, and ACK requests. </t> response.</li>
</section> <!-- ********************************************************** <li>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.</li>
*************** --> <section anchor="IANA" numbered="true" toc="default"> < </ul>
name>IANA Considerations</name> <t> No IANA Considerations.
</t> </section> <section anchor="security" numbered="true" toc="defaul <t>This following sections describe, for individual "P-" header fields, the
t"> <name>Security Considerations</name> <t> The security considerat 3GPP use cases that are the basis for the updates. The use cases are based
ions for these "P-" header fields are defined in <xref target="RFC7315" format on the procedures defined in <xref target="TS24.229" format="default"/>.</t>
="default"/>. This specification allows some header fields to be present in m </section>
essages where they were previously not allowed, and the security consideration
s and assumptions described in <xref target="RFC7315" format="default"/> (e.g., <section anchor="P-Access-Network-Info" numbered="true" toc="default">
regarding only sending information to trusted entities) also apply to those <name>P-Access-Network-Info</name>
messages. In addition, this specification also disallows some header field <t>
s to be present in messages where they were previously allowed. That does not
cause any security issues, but implementors need to be aware that implementat The P-Access-N
ions may not have been updated according to this document, and take proper act etwork-Info header field may contain the Network
ions if a header field occurs, or does not occur, in a message where it should Provided Locat
occur (or occurs in a message where it should not occur). This document a ion Information (NPLI). The NPLI is described in
dds the ability to include P-Access-Network-Info in ACK requests. As docume <xref target="
nted in <xref target="RFC7315" format="default"/>, P-Access-Network-Info may inc TS23.228" format="default"/>.
lude privacy sensitive information, including the user's location. The securi
ty and privacy considerations for P-Access-Network-Info in ACK requests are </t>
similar to those for the other SIP requests discussed in Section 6.4 of <xref <t>
target="RFC7315" format="default"/>. The security and privacy considerations f A proxy in pos
or the P-Visited-Network-ID header field are similar to those for the other S session of appropriate information about the access
IP responses discussed in Section 6.3 of <xref target="RFC7315" format="default" technology mig
/>. </t> </section> <!-- ******************************************** ht insert a P-Access-Network-Info header field with its
********************************************************* --> <section numbe own values. S
red="true" toc="default"> <name>Operational considerations</name> <t> uch values are identified by the string "network-
As the "P-" header fields are mainly used in (and in most cases, only provided" defi
defined for) networks defined by the 3GPP, where the updates define ned in <xref target="RFC7315" format="default"/>. Based on operator policy, roa
d in this document are already defined <xref target="TS24.229" forma ming agreement, or both, the local time of the visited network may be
t="default"/>, the updates are not seen to cause backward-compatibility included.
concerns. </t> </section><!-- **************************** </t>
************************************************************************* --> < <!--[rfced] To prevent misreading this sentence (i.e., "the NPLI needs to
!-- **************************************************************************** be stored as the location of the user"), may we add a comma as follows?
************************* --> <section numbered="true" toc="default"> <
name>Changes since RFC7976</name> <t> The changes related to RFC7976 in Original:
volve the inclusion of the P-Visited-Network-ID header field in SIP respons When an IMS session is modified, the NPLI also
es. Specifically, any SIP response message, with the exception of a 100 (Tr needs to be stored as the location of the user at the time when the
ying) response, may include a P-Visited-Network-ID header field. </t> </ session is modified may generate a charging event.
section><!-- *******************************************************************
********************************** --> <section numbered="true" toc="default Suggested:
"> <name>Acknowledgments</name> <t> The author would like to ackn When an IMS session is modified, the NPLI also
owledge the constructive feedback provided by Michael Kreipl, Charles Eckel an needs to be stored, as the location of the user at the time when the
d Paul Kyzivat Thanks to Paul Kyzivat, Jean Mahoney, Ben Campbell, and Adam session is modified may generate a charging event.
Roach for providing comments on the former version of the document. </t> -->
</section> </middle> <back> <references> <name>References</name> <t>The Call Data Records (CDRs) generated within the IP Multimedia
<references> <name>Normative References</name> <reference Subsystem (IMS) have to contain the NPLI in order to guarantee
anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3261"> <f correct billing. When an IMS session is modified, the NPLI also
ront> <title>SIP: Session Initiation Protocol</title> <aut needs to be stored as the location of the user at the time when the
hor fullname="J. Rosenberg" initials="J." surname="Rosenberg"/> <auth session is modified may generate a charging event. In case of a
or fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/> <a session modification event at IMS, the NPLI needs to be provided:</t>
uthor fullname="G. Camarillo" initials="G." surname="Camarillo"/> <au
thor fullname="A. Johnston" initials="A." surname="Johnston"/> <autho <ul spacing="normal">
r fullname="J. Peterson" initials="J." surname="Peterson"/> <author f <li>when the bearer establishment is triggered, or</li>
ullname="R. Sparks" initials="R." surname="Sparks"/> <author fullname <li>at session release when the bearer deactivation is triggered, or</li>
="M. Handley" initials="M." surname="Handley"/> <author fullname="E. <li>when the bearer modification is triggered, e.g., a QoS modification for
Schooler" initials="E." surname="Schooler"/> <date month="June" year= the use of a newly negotiated codec.</li>
"2002"/> <abstract> <t>This document describes Session I </ul>
nitiation Protocol (SIP), an application-layer control (signaling) protocol for <!--[rfced] We suggest adding articles ('the' and 'a') as follows; please let
creating, modifying, and terminating sessions with one or more participants. Th us know if this is acceptable. (We note that RFC 7976 did not use
ese sessions include Internet telephone calls, multimedia distribution, and mult articles in similar text, but 'a SIP 2xx response' appears in other RFCs.)
imedia conferences. [STANDARDS-TRACK]</t> </abstract> </fron
t> <seriesInfo name="RFC" value="3261"/> <seriesInfo name="DOI Original: ... within SIP 2xx response to the SIP INVITE request.
" value="10.17487/RFC3261"/> </reference> <reference anchor="RFC73 Perhaps: ... within the SIP 2xx response to the SIP INVITE request.
15" target="https://www.rfc-editor.org/info/rfc7315"> <front>
<title>Private Header (P-Header) Extensions to the Session Initiation Protoco Original: Upon reception of the SDP answer within SIP 2xx response ..
l (SIP) for the 3GPP</title> <author fullname="R. Jesske" initials="R Perhaps: Upon reception of the SDP answer within a SIP 2xx response ...
." surname="Jesske"/> <author fullname="K. Drage" initials="K." surna -->
me="Drage"/> <author fullname="C. Holmberg" initials="C." surname="Ho <t>
lmberg"/> <date month="July" year="2014"/> <abstract> In som
<t>This document describes a set of private header (P-header) Session I e scenarios, the bearer modification may be triggered by the
nitiation Protocol (SIP) fields used by the 3GPP, along with their applicability proxy
, which is limited to particular environments. The P-header fields are used for upon reception of a Session Description Protocol (SDP) answer
a variety of purposes within the networks that the partners implement, includin within
g charging and information about the networks a call traverses. This document o SIP 2xx response to the SIP INVITE request. In such case, the
bsoletes RFC 3455.</t> </abstract> </front> <series NPLI n
Info name="RFC" value="7315"/> <seriesInfo name="DOI" value="10.17487/R eeds to be provided within the SIP ACK request. However, <xref target="RFC7315"
FC7315"/> </reference> <reference anchor="TS23.228"> <fro format="default"/> does not allow the usage of the P-Access-Network-Info heade
nt> <title>3rd Generation Partnership Project; Technic r
al Specification Group Core Network and Terminals; "IP multimedia call control p field
rotocol based on Session Initiation Protocol (SIP) and Session De in a SIP ACK request.
scription Protocol (SDP); </title> <author </t>
> <organization abbrev="3GPP"> 3rd Generation Par <t>
tnership Project </organization> </author> <d Upon r
ate month="June" year="2016"/> </front> <seriesInfo name="TS" eception of the SDP answer within SIP 2xx response on the SIP
value="23.228"/> <seriesInfo name="V" value="13.6.0"/> </referen INVITE
ce> <reference anchor="TS24.229"> <front> <title>3rd request, a proxy may initiate procedures to obtain the NPLI
Generation Partnership Project; Technical Specifi and ma
cation Group Core Network and Terminals; IP multim y include the P-Access-Network-Info header field with the NPLI
edia call control protocol based on Session Initiatio in the
n Protocol (SIP) and Session Description Protocol SIP ACK request.
(SDP); Stage 3 </title> <author> </t>
<organization abbrev="3GPP"> 3rd Generation Partne <t>
rship Project </organization> </author> <date The P-
month="June" year="2016"/> </front> <seriesInfo name="TS" val Access-Network-Info header field shall not be included in SIP
ue="24.229"/> <seriesInfo name="V" value="13.6.0"/> </reference> ACK re
</references> <references> <name>Informative References</name> quests triggered by non-2xx responses.
<reference anchor="RFC3455" target="https://www.rfc-editor.org/info/ </t>
rfc3455"> <front> <title>Private Header (P-Header) Extensio </section>
ns to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership P
roject (3GPP)</title> <author fullname="M. Garcia-Martin" initials="M <section anchor="P-Charging-Vector" numbered="true" toc="default">
." surname="Garcia-Martin"/> <author fullname="E. Henrikson" initials <name>P-Charging-Vector</name>
="E." surname="Henrikson"/> <author fullname="D. Mills" initials="D." <t>
surname="Mills"/> <date month="January" year="2003"/> <ab
stract> <t>This document describes a set of private Session Initiat <xref target="
ion Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Pr RFC7315" format="default"/> defines an Inter Operator Identifier (IOI) to enable
oject (3GPP), along with their applicability, which is limited to particular env different oper
ironments. The P-headers are for a variety of purposes within the networks that ators involved in a SIP dialog or a transaction outside
the partners use, including charging and information about the networks a call a dialog to id
traverses. This memo provides information for the Internet community.</t> entify each other by exchanging operator identification
</abstract> </front> <seriesInfo name="RFC" value="3455" information wi
/> <seriesInfo name="DOI" value="10.17487/RFC3455"/> </reference thin the P-Charging-Vector header field.
> </references> </references> </back></rfc> </t>
<t>
In the interco
nnection scenarios in multi-operator environments,
where one or m
ore transit operators are between the originating and
terminating op
erator, the identities of the involved transit
operators are
represented by a transit-ioi parameter of the
P-Charging-Vec
tor header field.
</t>
<t>
Transit operat
ors can be selected independently for each SIP method
and direction
of request. A transit network will only have knowledge
of an individu
al SIP request, and transit network selection will be
an independent
decision for each request and could be made based on
load, cost, pe
rcentage, 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 re
sponse. However, <xref target="RFC7315" format="default"/> does not allow the u
sage of
the P-Charging
-Vector header field in the SIP ACK request.
</t>
<t>
A SIP proxy t
hat supports this extension and receives the SIP ACK
request may in
clude a P-Charging-Vector header field in the SIP ACK
request.
</t>
<!--[rfced] non-2xx response vs. SIP non-2xx respsonse
In other instances in this document, "SIP" does not appear before
"non-2xx repsonse"; may it be removed here, or is it necessary?
Original:
The P-Charging-Vector header field shall not be included in SIP ACK
requests triggered by SIP non-2xx responses.
Perhaps (to match usage in Sections 2.3.2 and 3):
The P-Charging-Vector header field shall not be included in SIP ACK
requests triggered by non-2xx responses.
-->
<t>
The P-Charging
-Vector header field shall not be included in SIP ACK
requests trigg
ered by SIP non-2xx responses.
</t>
</section>
</section>
</section>
<section anchor="Updates_to_RFC_7315" numbered="true" toc="default">
<name>Updates to RFC 7315</name>
<t>
This section contains the update to <xref target="RFC7315" section="5.
7"/>, in
order to implement the misalignment fixes and the 3GPP requirements
described in <xref target="Misalignment_3GPP_Use_Cases"/>.
</t>
<!--[rfced] FYI, in Section 3, the quote of RFC 7315 ("Old text") has
been updated to exactly match the RFC. If you prefer to keep the blank
lines between each sentence, then please let us know and we would suggest
adding text to note that it does not match the original, e.g., "Blank
lines have been added for readability."
-->
<t>Old text:</t>
<blockquote>
<t>
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.
</t>
</blockquote>
<t>New text:</t>
<blockquote>
<t>The P-Associated-URI header field can appear in SIP REGISTER 2xx
responses.
</t>
<t>
The P-Called-Party-ID header field can appear in the SIP INVITE,
OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE requests.
</t>
<t>
The P-Visited-Network-ID header field can appear in all SIP requests
and the associated non-100 response message except in ACK, BYE,
CANCEL, NOTIFY, PRACK, INFO, UPDATE.
</t>
<t>
The P-Access-Network-Info header field can appear in all SIP requests
and the associated non-100 responses, except in CANCEL requests, CANCEL
responses, and ACK methods triggered by non-2xx responses.
</t>
<t>
The P-Charging-Vector header field can appear in all SIP requests and
the associated non-100 responses, except in CANCEL requests, CANCEL
responses, and ACK requests triggered by non-2xx responses.
</t>
<t>
The P-Charging-Function-Addresses header field can appear in all SIP
methods and the associated non-100 responses, except in CANCEL
requests, CANCEL responses, and ACK requests.
</t>
</blockquote>
</section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
This document has no IANA actions.
</t>
</section>
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
The security considerations for these "P-" header fields are defined
in <xref target="RFC7315" format="default"/>. 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 <xref target="RFC7315" f
ormat="default"/> (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 <xref target="RFC7315" format="default"/>, P-Access-Network-Inf
o 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
<xref target="RFC7315" section="6.4"/>.
The security and privacy considerations for the P-Visited-Network-ID header
field are
similar to those for the other SIP responses discussed in <xref target="RFC73
15" section="6.3"/>.
</t>
</section>
<section numbered="true" toc="default">
<name>Operational considerations</name>
<t>
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 docume
nt are already
defined <xref target="TS24.229" format="default"/>, the updates are n
ot seen to cause
backward-compatibility concerns.
</t>
</section>
<section numbered="true" toc="default">
<name>Changes since RFC 7976</name> <t> The changes related to RFC 7976
involve the inclusion of the P-Visited-Network-ID header field in SIP
responses. Specifically, any SIP response message, with the exception of
a 100 (Trying) response, may include a P-Visited-Network-ID header
field.
</t>
</section>
<section numbered="true" toc="default">
<name>Acknowledgments</name>
<t>The author would like to acknowledge the constructive feedback provided
by <contact fullname="Michael Kreipl"/>, <contact fullname="Charles
Eckel"/>, and <contact fullname="Paul Kyzivat"/>.</t>
<t>Thanks to <contact fullname="Paul Kyzivat"/>, <contact fullname="Jean
Mahoney"/>, <contact fullname="Ben Campbell"/>, and <contact fullname="Adam
Roach"/> for providing comments on an earlier draft version of this document.
</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
261.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
315.xml"/>
<!-- [rfced] FYI, we updated the 3GPP reference titles to match
the titles provided by 3GPP. We have also added URLs that point to
the specific version used in the references. Please review.
We note the version referenced in this document is from 2016 and there have
been several updates over the years. Would you like to update this
reference to a more current version? Or would you like these
references to point to the 3GPP Technical Specifications in general?
Current:
[TS23.228] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", Version
13.6.0, Release 13, 3GPP TS 23.228, June 2016,
<https://www.3gpp.org/ftp//Specs/
archive/23_series/23.228/23228-g30.zip>.
[TS24.229] 3GPP, "IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description
Protocol (SDP); Stage 3", Version 13.6.0, Release 13, 3GPP
TS 24.229, June 2016, <https://www.3gpp.org/ftp/Specs/
archive/24_series/24.229/24229-d60.zip>.
Perhaps:
[TS23.228]
3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP
TS 23.228,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=821>.
[TS24.229]
3GPP, "IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description
Protocol (SDP); Stage 3", 3GPP TS 24.229,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=1055>.
-->
<reference anchor="TS23.228" target="https://www.3gpp.org/ftp//Specs/arc
hive/23_series/23.228/23228-g30.zip">
<front>
<title>IP Multimedia Subsystem (IMS); Stage 2
</title>
<author>
<organization abbrev="3GPP">
3rd Generation Partnership Project
</organization>
</author>
<date month="June" year="2016"/>
</front>
<seriesInfo name="3GPP TS" value="23.228"/>
<refcontent>Version 13.6.0, Release 13</refcontent>
</reference>
<!--[options, dependent on author reply]
General version of 3GPP references (if authors want to go with these)
<reference anchor="TS23.228" target="https://portal.3gpp.org/desktopmodu
les/Specifications/SpecificationDetails.aspx?specificationId=821">
<front>
<title>IP Multimedia Subsystem (IMS); Stage 2
</title>
<author>
<organization abbrev="3GPP">
3rd Generation Partnership Project
</organization>
</author>
</front>
<seriesInfo name="3GPP TS" value="23.228"/>
</reference>
<reference anchor="TS24.229" target="https://portal.3gpp.org/desktopmodu
les/Specifications/SpecificationDetails.aspx?specificationId=1055">
<front>
<title>IP multimedia call control protocol based on Session Initiati
on Protocol (SIP) and Session Description Protocol (SDP); Stage 3
</title>
<author>
<organization abbrev="3GPP">
3rd Generation Partnership Project
</organization>
</author>
</front>
<seriesInfo name="3GPP TS" value="24.229"/>
</reference>
-->
<reference anchor="TS24.229" target="https://www.3gpp.org/ftp/Specs/arch
ive/24_series/24.229/24229-d60.zip">
<front>
<title>IP multimedia call control protocol based on Session Initiati
on Protocol (SIP) and Session Description Protocol (SDP); Stage 3
</title>
<author>
<organization abbrev="3GPP">
3rd Generation Partnership Project
</organization>
</author>
<date month="June" year="2016"/>
</front>
<seriesInfo name="3GPP TS" value="24.229"/>
<refcontent>Version 13.6.0, Release 13</refcontent>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
455.xml"/>
</references>
</references>
</back>
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</rfc>
 End of changes. 1 change blocks. 
lines changed or deleted lines changed or added

This html diff was produced by rfcdiff 1.48.