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> <front>
<author initials="N." surname="Biondic" fullname="Nevenka Biondic"> <or <title abbrev="Update to Private Header">Updates to Private Header (P-Header
ganization>Ericsson</organization> <address> <postal> <stre ) Extension Usage
et>Krapinska 45</street> <city>Zagreb</city> <code>10002</code in Session Initiation Protocol (SIP) Requests and Responses</title>
> <country>Croatia</country> </postal> <phone/> <e <seriesInfo name="RFC" value="9878"/>
mail>nevenka.biondic.ext@ericsson.com</email> <uri/> </address> < <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
/author> <author initials="G." surname="Salgueiro" fullname="Gonzalo Salgueir <organization>Ericsson</organization>
o"> <organization>Cisco Systems, Inc.</organization> <address> <address>
<postal> <street>7200-12 Kit Creek Road</street> <city>Researc <postal>
h Triangle Park</city> <code>NC 27709</code> <country>United <street>Hirsalantie 11</street>
States of America</country> </postal> <phone/> <email>gsalg <city>Jorvas</city>
uei@cisco.com</email> <uri/> </address> </author> <author init <code>02420</code>
ials="R." surname="Jesske" fullname="Roland Jesske"> <organization>Deutsche <country>Finland</country>
Telekom</organization> <address> <postal> <street>Telekom </postal>
Allee 9</street> <city>Darmstadt</city> <code>64295</code> <email>christer.holmberg@ericsson.com</email>
<country>Germany</country> </postal> <phone/> <email> </address>
r.jesske@telekom.de</email> <uri>www.telekom.com</uri> </address> </author>
</author> <date year="2025"/> <area>ART</area> <workgroup>sipcore</wor <author initials="N." surname="Biondic" fullname="Nevenka Biondic">
kgroup> <keyword>Internet-Draft</keyword> <keyword>3GPP</keyword> <keyw <organization>Ericsson</organization>
ord>Visited</keyword> <keyword>ID</keyword> <abstract> <t> The Thir <address>
d Generation Partnership Project (3GPP) has identified cases where different SIP <postal>
private header extensions referred to as "P-" header fields, and defined in RFC <street>Krapinska 45</street>
7315, need to be included in SIP requests and responses currently not allowed a <city>Zagreb</city>
ccording to RFC 7315. This document updates RFC 7315, in order to allow inclusio <code>10002</code>
n of the affected "P-" header fields in such requests and responses. This Docume <country>Croatia</country>
nt obsoletes RFC 7976. The changes related to RFC7976 involve the inclusion of t </postal>
he P-Visited-Network-ID header field in SIP responses.</t><t> This docume <email>nevenka.biondic.ext@ericsson.com</email>
nt also makes updates for RFC 7315 in order to fix misalignments that occurred w </address>
hen RFC 3455 was updated and subsequently obsoleted by the publication of RFC 73 </author>
15. </t> </abstract> </front> <middle> <!-- *********************** <author initials="G." surname="Salgueiro" fullname="Gonzalo Salgueiro">
****************************************************************************** - <organization>Cisco Systems, Inc.</organization>
-> <section anchor="intro" numbered="true" toc="default"> <name> <address>
Introduction</name> <t> The Third Generation Partnership Proje <postal>
ct (3GPP) has identified cases where different Session Initiation Protocol (SIP) <street>7200-12 Kit Creek Road</street>
<xref target="RFC3261" format="default"/> private header extensions referr <city>Research Triangle Park</city>
ed to as "P-" header fields, and defined in <xref target="RFC7315" form <region>NC</region><code>27709</code>
at="default"/>, need to be included in SIP requests and responses curren <country>United States of America</country>
tly not allowed according to <xref target="RFC7315" format="default"/>. This do </postal>
cument updates <xref target="RFC7315" format="default"/>, in order to allow incl <email>gsalguei@cisco.com</email>
usion of the affected "P-" header fields in such requests and responses. </address>
</t><t> This document also makes updates for <xref target="RFC7315" fo </author>
rmat="default"/> in order to fix misalignments that occurred when <xref <author initials="R." surname="Jesske" fullname="Roland Jesske">
target="RFC3455" format="default"/> was updated and subsequently obsoleted by t <organization>Deutsche Telekom</organization>
he publication of <xref target="RFC7315" format="default"/>. </t> </s <address>
ection> <section anchor="Misalingment_3GPP_Use_Cases" numbered="true" toc="de <postal>
fault"> <name>Misalignments and 3GPP Use Cases</name> <section anchor= <street>Telekom Allee 9</street>
"General" numbered="true" toc="default"> <name>General</name> <t> <city>Darmstadt</city>
<code>64295</code>
<xref target="RFC7315" format="default"/> contains contradicting statements reg <country>Germany</country>
arding the usage of SIP "P-" header fi </postal>
elds in SIP requests and responses, which leave the presence of the SIP "P-" hea <email>r.jesske@telekom.de</email>
der fields in the SIP requests and respon <uri>www.telekom.com</uri>
ses open to interpretation and different implementations. Statements in Section </address>
5.7 of that RFC are not aligned with the </author>
definitions and usage of the SIP "P-" header fields specified in Section 4. T <date year="2025" month="October"/>
his section describes the misalignments that occurred <area>ART</area>
when <xref target="RFC3455" format="default"/> was updated and subsequ <workgroup>sipcore</workgroup>
ently obsoleted by the publication of <xref target="RFC7315" format="default"/>,
and how they are fixed. </t> <t> <keyword>3GPP</keyword>
NOTE: In the case of the P-Called-Party-ID header field, allowing it <keyword>Visited</keyword>
in PUBLISH requests was done deliberately in < <keyword>ID</keyword>
xref target="RFC7315" format="default"/>. Therefore, it
is not considered a misalignment. </t> <t> <abstract>
Since <xref target="RFC7315" format="default"/ <t>
> was published, 3GPP defined new use cases that require The Third Generation Partnership Project (3GPP) has identified cases where di
the RFC to be updated. This section describes the 3GPP use ca fferent SIP private header extensions referred to as "P-" header fields, and def
ses behind the updates, and the updates ne ined in RFC 7315, need to be included in SIP requests and responses where they w
eded to <xref target="RFC7315" format="default"/> in order to ere not allowed according to RFC 7315. This document updates RFC 7315, in order
support the use cases. </t> <t> to allow inclusion of the affected "P-" header fields in such requests and respo
Section 3 updates <xref target="RFC7315" format="defau nses. This document obsoletes RFC 7976. The changes related to RFC 7976 involve
lt"/>, based on the misalignments and 3GPP use the inclusion of the P-Visited-Network-ID header
cases. </t> </section> field in SIP responses.
<section anchor="Misalignments" numbered="true" toc="default"> <name> </t>
Misalignments</name> <t> <t>
The following updates are needed in order to fix the misalignments This document also makes updates to RFC 7315 in order to fix misalignments th
that occurred when <xref target="RFC3455" form at occurred when RFC 3455 was obsoleted by RFC 7315.
at="default"/> was updated and obsolated by <xref target="RFC7315" format="defau </t>
lt"/>: </t> <t> o P-A </abstract>
ssociated-URI: Remove the statement that the header field can </front>
appear in the SIP REGISTER method. </t> <middle>
<t> o P-Called-Party-ID:
Delete the statement that the P-Called-Party-ID <section anchor="intro" numbered="true" toc="default">
header field can appear in SIP responses. Add a statem <name>Introduction</name>
ent that the P-Called-Pa <t>
rty-ID header field can appear in the SIP REFER The Third Generation Partnership Project (3GPP) has identified cases w
method. </t> <t> here different Session Initiation Protocol (SIP) <xref target="RFC3261" format="
o P-Access-Network-Info: Add a statem default"/> private header extensions
ent that the P-Access-Network- referred to as "P-" header fields, and defined in <xref targe
Info header field can appear in SIP responses. </t> <t> t="RFC7315" format="default"/>, need to be included in SIP requests and response
o P-Charging-Vector: Add a statement that the s
P-Charging-Vector header where they were not allowed according to <xref target="RFC7315" format
field can appear in SIP responses. Add a statement that ="default"/>. This document updates <xref target="RFC7315" format="default"/>,
the P-Charging-Vector header field cannot appea in order to allow inclusion of the affected "P-" header
r in the SIP ACK method. fields in such requests and responses.
</t> <t> o P-C </t>
harging-Function-Addresses: Add a statement that the <t>
P-Charging-Function-Addresses header field can appear i This document also makes updates to <xref target="RFC7315" format="def
n SIP responses. </t> ault"/> in order to fix
<t> The following update is misalignments that occurred when <xref target="RFC3455" format="defaul
needed in order to clarify the usage of the header compared to <xref target="RFC t"/> was updated and subsequently obsoleted by the publication of <xref target="
7315" format="default"/>: </t> <t> RFC7315" format="default"/>.
o P-Visited-Network-ID: Add a
statement that the P-Visited-Network-ID header field ca </t>
nnot appear in the SIP NOTI </section>
FY, PRACK, INFO, and UPDATE methods. Add statement that the P-Visited-Network-ID <section anchor="Misalignment_3GPP_Use_Cases" numbered="true" toc="default">
header field can appear in all non-100 (Trying) responses. </t> <name>Misalignments and 3GPP Use Cases</name>
</section> <!-- ********************************************************* <section anchor="General" numbered="true" toc="default">
******************************************** --> <name>General</name>
<section anchor="_GPP_Use_Cases" numbered="true" toc="d <t>
efault"> <name>3GPP Use Cases</name> <!-- ************************
***************************************************************************** -- <xref target="RFC7315" format="default"/> contains contradictory statements reg
> arding the usage of SIP
<section anchor="General_use_case" numbered="true" toc="default"> <nam "P-" header fields in SIP requests and
e>General</name> <t> responses, which leave the presence of the SIP "P-" header fields in the SIP re
The following updates are needed in order to implement the 3GP quests and
P use cases: responses open to interpretation and d
</t> <t> ifferent implementations. Statements in <xref target="RFC7315" section="5.7"/> a
o P-Access-Network-Info: Add statement that the P-Access-Netw re not aligned with the
ork- definitions and usage of the SIP "P-"
Info header field can appear in the SIP ACK method when triggered header fields specified in <xref target="RFC7315" section="4"/>. This section d
by a SIP 2xx re escribes the misalignments that occurred
sponse. </t> <t> when <xref target="RFC3455" format="de
o P-Charging-Vector: Add statement that the P-Chargin fault"/> was updated and subsequently obsoleted by the publication of <xref targ
g-Vector header et="RFC7315" format="default"/>, and how they are fixed.
field can appear in the SIP ACK method when triggered by a SIP </t>
2xx <aside><t>
response. </t> <t> NOTE: In the case of the P-Called-Part
This following sections describe, for individual "P-" y-ID header field, allowing it
header fields, in PUBLISH requests was done deliberat
the 3GPP use cases that are the basis for the updates. The use cases ely in <xref target="RFC7315" format="default"/>. Therefore, it
are based on t is not considered a misalignment.
he procedures defined in <xref target="TS24.229" format="default"/>. < </t></aside>
/t> </section> <!-- ********************************************** <t>
******************************************************* --> Since <xref target="RFC7315" format="d
<section anchor="P-Access-Netwo efault"/> was published, 3GPP defined new use cases that require
rk-Info" numbered="true" toc="default"> <name>P-Access-Network-Info</na the RFC to be updated. This section d
me> <t> escribes the 3GPP use cases
The P-Access-N behind the updates, and the updates ne
etwork-Info header field may contain the Network eded to <xref target="RFC7315" format="default"/> in order to
Provided Location Information (NPLI). The NPL support the use cases.
I is described in </t>
<xref target="TS23.228" format="default"/>. </t> <t>
A proxy in possession <t>
of appropriate information about the access <xref target="Updates_to_RFC_7315"/> u
technology might insert a P-Access-Network-Info header pdates <xref target="RFC7315" format="default"/>, based on the misalignments and
field with its 3GPP use
own values. Such values are identified by the string "network- cases.
provided" defined in <xref tar
get="RFC7315" format="default"/>. Based on operator policy, roaming agreement o </t>
r both, the local time of the visited network may be </section>
included. </t> <t> <section anchor="Misalignments" numbered="true" toc="default">
The Call Data Records (CDRs) <name>Misalignments</name>
generated within the IP Multimedia <t>
Subsystem (IMS) have to contain the NPLI in order to g The following updates are needed
uarantee in order to fix the misalignments
correct billing. When an IMS session is modified, the NPLI also that occurred when <xref targe
needs to be stored as t="RFC3455" format="default"/> was obsoleted by <xref target="RFC7315" format="d
the location of the user at the time when the efault"/>:
session is modified may generate a charging </t>
event. In case of a
session modification event at IMS, the NPLI needs to be provide <ul spacing="normal">
d: </t> <t> <li>P-Associated-URI: Remove the statement that the header field can appear in
o when the bearer establishment is triggered, or </t> the SIP REGISTER method.</li>
<t> <li>P-Called-Party-ID: Delete the statement that the P-Called-Party-ID header
o at session release when the bearer deactivation is triggered, or < field can appear in SIP responses. Add a statement that the P-Called-Party-ID
/t> <t> header field can appear in the SIP REFER method.</li>
o when the bearer modification is triggered, e.g., a QoS <li>P-Access-Network-Info: Add a statement that the P-Access-Network- Info
modification fo header field can appear in SIP responses.</li>
r the use of a newly negotiated codec. </t> <t> <li>P-Charging-Vector: Add a statement that the P-Charging-Vector header field
In some scenarios, the can appear in SIP responses. Add a statement that the P-Charging-Vector
bearer modification may be triggered by the header field cannot appear in the SIP ACK method.</li>
proxy upon reception of a Session Description <li>P-Charging-Function-Addresses: Add a statement that the
Protocol (SDP) answer P-Charging-Function-Addresses header field can appear in SIP responses.</li>
within SIP 2xx response to the SIP INVITE request. In such case, the </ul>
NPLI n
eeds to be provided within the SIP ACK request. However, <xref target="RFC7315" <t>The following update is needed in order to clarify the usage of
format="default"/> does not allow the usage of the P-Access-Network-Info heade the header compared to <xref target="RFC7315" format="default"/>:</t>
r field <ul spacing="normal">
in SIP ACK request. </t> <t> <li>P-Visited-Network-ID: Add a statement that the P-Visited-Network-ID header
Upon reception of the SDP answer within SIP 2x field cannot appear in the SIP NOTIFY, PRACK, INFO, and UPDATE methods. Add
x response on the SIP statement that the P-Visited-Network-ID header field can appear in all non-100
INVITE request, a proxy may initiate procedures to obtain the NPLI (Trying) responses.</li>
and may includ </ul>
e the P-Access-Network-Info header field with the NPLI </section>
in the SIP ACK request. </t>
<t> <section anchor="_GPP_Use_Cases" numbered="true" toc="default">
The P-Access-Network-Info header field shall not be included in SIP <name>3GPP Use Cases</name>
ACK requests triggered
by non-2xx responses. </t> </section> <!-- ************* <section anchor="General_use_case" numbered="true" toc="default">
******************************************************************************** <name>General</name>
******** --> <!-- *** <t>The following updates are needed in order to implement the 3GPP
******************************************************************************** use cases:</t>
****************** -->
<section anchor="P-Charging-Vector" numbered="true" toc="defaul <ul spacing="normal">
t"> <name>P-Charging-Vector</name> <t> <li>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
<xref target="RFC7315" format="default"/> defines an I response.</li>
nter Operator Identifier (IOI) to enable <li>P-Charging-Vector: Add statement that the P-Charging-Vector header field
different operators involved in a SIP dialog or a tran can appear in the SIP ACK method when triggered by a SIP 2xx response.</li>
saction outside </ul>
a dialog to identify each other by exchanging operator identification
information within the <t>This following sections describe, for individual "P-" header fields, the
P-Charging-Vector header field. </t> <t> 3GPP use cases that are the basis for the updates. The use cases are based
In the interconnection scenarios in mu on the procedures defined in <xref target="TS24.229" format="default"/>.</t>
lti-operator environments, </section>
where one or more transit operators are between the originating and
terminating operator, <section anchor="P-Access-Network-Info" numbered="true" toc="default">
the identities of the involved transit <name>P-Access-Network-Info</name>
operators are represented by a transit-ioi parameter of the <t>
P-Charging-Vector head
er field. </t> <t> The P-Access-N
Transit operators can be selected independently for each SIP m etwork-Info header field may contain the Network
ethod and direction Provided Locat
of request. A transit network will only have knowledge ion Information (NPLI). The NPLI is described in
of an individual SIP request, and tran <xref target="
sit network selection will be TS23.228" format="default"/>.
an independent decision for each request and could be made based on
load, cost, percentage </t>
, time of day, and other factors. For this <t>
reason, it is necessary that the P-Charging-Vector hea A proxy in pos
der field, which session of appropriate information about the access
carries the transit IOI information, is included in each SIP technology mig
request and response. However, <xref ht insert a P-Access-Network-Info header field with its
target="RFC7315" format="default"/> does not allow the usage of own values. S
the P-Charging-Vector header f uch values are identified by the string "network-
ield in the SIP ACK request. provided" defi
</t> <t> ned in <xref target="RFC7315" format="default"/>. Based on operator policy, roa
A SIP proxy that supports this extension and receives the SIP ACK ming agreement, or both, the local time of the visited network may be
request may include a included.
P-Charging-Vector header field in the SIP ACK </t>
request. </t> <t> <t>The Call Data Records (CDRs) generated within the IP Multimedia
The P-Charging-Vector header field sha Subsystem (IMS) have to contain the NPLI in order to guarantee
ll not be included in SIP ACK correct billing. When an IMS session is modified, the NPLI also
requests triggered by SIP non-2xx responses. </t> </se needs to be stored, as the location of the user at the time when the
ction> <!-- ************************************************************* session is modified may generate a charging event. In case of a
**************************************** --> session modification event at IMS, the NPLI needs to be provided:</t>
</section> </section> <!-- ****************************************
******************************************************************************** <ul spacing="normal">
********************************** --> <section anchor="Updates_to_RFC_7315" <li>when the bearer establishment is triggered, or</li>
numbered="true" toc="default"> <name>Updates to RFC 7315</name> <t> <li>at session release when the bearer deactivation is triggered, or</li>
This section implements the update to Section 5.7 of <xref target="RFC <li>when the bearer modification is triggered, e.g., a QoS modification for
7315" format="default"/>, in order to implement the misalignment fixes and the use of a newly negotiated codec.</li>
the 3GPP requirements described in Section 2. </t> <t> Old te </ul>
xt: </t> <t> The P-Associated-URI header field can appear in SIP RE <t>
GISTER method and 2xx resonses. </t> <t> The P-Called-Part In som
y-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and e scenarios, the bearer modification may be triggered by the
MESSAGE methods and all responses. </t> <t> The P-Visi proxy
ted-Network-ID header field can appear in all SIP methods except ACK, upon reception of a Session Description Protocol (SDP) answer
BYE, and CANCEL and all responses. </t> <t>The P-Access-Netw within
ork-Info header field can appear in all SIP methods except ACK and CAN the SIP 2xx response to the SIP INVITE request. In such case, the
CEL. </t> <t>The P-Charging-Vector header field can appear in al NPLI n
l SIP methods except CANCEL. </t> <t>The P-Charging-Function-Addresses eeds to be provided within the SIP ACK request. However, <xref target="RFC7315"
header field can appear in all SIP methods except ACK and CANCEL. </ format="default"/> does not allow the usage of the P-Access-Network-Info heade
t> <t> New text: </t> <t> The P-Associated-URI h r
eader field can appear in SIP REGISTER 2xx responses. </t> <t> field
The P-Called-Party-ID header field can appear in the SIP INVITE, OPTION in a SIP ACK request.
S, PUBLISH, REFER, SUBSCRIBE, and MESSAGE requests. </t> <t> Th </t>
e P-Visited-Network-ID header field can appear in all SIP requests and the assoc <t>
iated non-100 response message except in ACK, BYE, CANCEL, NOTIFY, PRACK, INF Upon r
O, UPDATE. </t> <t> The P-Access-Network-Info header field can eception of the SDP answer within a SIP 2xx response on the SIP
appear in all SIP requests and the associated non-100 responses, except in C INVITE
ANCEL requests, CANCEL responses, and ACK methods triggered by non-2xx respo request, a proxy may initiate procedures to obtain the NPLI
nses. </t> <t> The P-Charging-Vector header field can appear in a and ma
ll SIP requests and the associated non-100 responses, except in CANCEL reque y include the P-Access-Network-Info header field with the NPLI
sts, CANCEL responses, and ACK requests triggered by non-2xx responses. in the
</t> <t> The P-Charging-Function-Addresses header field SIP ACK request.
can appear in all SIP methods and the associated non-100 responses, except in </t>
CANCEL requests, CANCEL responses, and ACK requests. </t> <t>
</section> <!-- ********************************************************** The P-
******************************************************************************** Access-Network-Info header field shall not be included in SIP
*************** --> <section anchor="IANA" numbered="true" toc="default"> < ACK re
name>IANA Considerations</name> <t> No IANA Considerations. quests triggered by non-2xx responses.
</t> </section> <section anchor="security" numbered="true" toc="defaul </t>
t"> <name>Security Considerations</name> <t> The security considerat </section>
ions for these "P-" header fields are defined in <xref target="RFC7315" format
="default"/>. This specification allows some header fields to be present in m <section anchor="P-Charging-Vector" numbered="true" toc="default">
essages where they were previously not allowed, and the security consideration <name>P-Charging-Vector</name>
s and assumptions described in <xref target="RFC7315" format="default"/> (e.g., <t>
regarding only sending information to trusted entities) also apply to those
messages. In addition, this specification also disallows some header field <xref target="
s to be present in messages where they were previously allowed. That does not RFC7315" format="default"/> defines an Inter Operator Identifier (IOI) to enable
cause any security issues, but implementors need to be aware that implementat different oper
ions may not have been updated according to this document, and take proper act ators involved in a SIP dialog or a transaction outside
ions if a header field occurs, or does not occur, in a message where it should a dialog to id
occur (or occurs in a message where it should not occur). This document a entify each other by exchanging operator identification
dds the ability to include P-Access-Network-Info in ACK requests. As docume information wi
nted in <xref target="RFC7315" format="default"/>, P-Access-Network-Info may inc thin the P-Charging-Vector header field.
lude privacy sensitive information, including the user's location. The securi </t>
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 In the interco
target="RFC7315" format="default"/>. The security and privacy considerations f nnection scenarios in multi-operator environments,
or the P-Visited-Network-ID header field are similar to those for the other S where one or m
IP responses discussed in Section 6.3 of <xref target="RFC7315" format="default" ore transit operators are between the originating and
/>. </t> </section> <!-- ******************************************** terminating op
********************************************************* --> <section numbe erator, the identities of the involved transit
red="true" toc="default"> <name>Operational considerations</name> <t> operators are
As the "P-" header fields are mainly used in (and in most cases, only represented by a transit-ioi parameter of the
defined for) networks defined by the 3GPP, where the updates define P-Charging-Vec
d in this document are already defined <xref target="TS24.229" forma tor header field.
t="default"/>, the updates are not seen to cause backward-compatibility </t>
concerns. </t> </section><!-- **************************** <t>
************************************************************************* --> < Transit operat
!-- **************************************************************************** ors can be selected independently for each SIP method
************************* --> <section numbered="true" toc="default"> < and direction
name>Changes since RFC7976</name> <t> The changes related to RFC7976 in of request. A transit network will only have knowledge
volve the inclusion of the P-Visited-Network-ID header field in SIP respons of an individu
es. Specifically, any SIP response message, with the exception of a 100 (Tr al SIP request, and transit network selection will be
ying) response, may include a P-Visited-Network-ID header field. </t> </ an independent
section><!-- ******************************************************************* decision for each request and could be made based on
********************************** --> <section numbered="true" toc="default load, cost, pe
"> <name>Acknowledgments</name> <t> The author would like to ackn rcentage, time of day, and other factors. For this
owledge the constructive feedback provided by Michael Kreipl, Charles Eckel an reason, it is
d Paul Kyzivat Thanks to Paul Kyzivat, Jean Mahoney, Ben Campbell, and Adam necessary that the P-Charging-Vector header field,
Roach for providing comments on the former version of the document. </t> which carries
</section> </middle> <back> <references> <name>References</name> the transit IOI information, is included in each SIP
<references> <name>Normative References</name> <reference request and re
anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3261"> <f sponse. However, <xref target="RFC7315" format="default"/> does not allow the u
ront> <title>SIP: Session Initiation Protocol</title> <aut sage of
hor fullname="J. Rosenberg" initials="J." surname="Rosenberg"/> <auth the P-Charging
or fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/> <a -Vector header field in the SIP ACK request.
uthor fullname="G. Camarillo" initials="G." surname="Camarillo"/> <au </t>
thor fullname="A. Johnston" initials="A." surname="Johnston"/> <autho <t>
r fullname="J. Peterson" initials="J." surname="Peterson"/> <author f A SIP proxy t
ullname="R. Sparks" initials="R." surname="Sparks"/> <author fullname hat supports this extension and receives the SIP ACK
="M. Handley" initials="M." surname="Handley"/> <author fullname="E. request may in
Schooler" initials="E." surname="Schooler"/> <date month="June" year= clude a P-Charging-Vector header field in the SIP ACK
"2002"/> <abstract> <t>This document describes Session I request.
nitiation Protocol (SIP), an application-layer control (signaling) protocol for </t>
creating, modifying, and terminating sessions with one or more participants. Th <t>
ese sessions include Internet telephone calls, multimedia distribution, and mult The P-Charging
imedia conferences. [STANDARDS-TRACK]</t> </abstract> </fron -Vector header field shall not be included in SIP ACK
t> <seriesInfo name="RFC" value="3261"/> <seriesInfo name="DOI requests trigg
" value="10.17487/RFC3261"/> </reference> <reference anchor="RFC73 ered by non-2xx responses.
15" target="https://www.rfc-editor.org/info/rfc7315"> <front>
<title>Private Header (P-Header) Extensions to the Session Initiation Protoco </t>
l (SIP) for the 3GPP</title> <author fullname="R. Jesske" initials="R </section>
." surname="Jesske"/> <author fullname="K. Drage" initials="K." surna </section>
me="Drage"/> <author fullname="C. Holmberg" initials="C." surname="Ho </section>
lmberg"/> <date month="July" year="2014"/> <abstract> <section anchor="Updates_to_RFC_7315" numbered="true" toc="default">
<t>This document describes a set of private header (P-header) Session I <name>Updates to RFC 7315</name>
nitiation Protocol (SIP) fields used by the 3GPP, along with their applicability <t>
, which is limited to particular environments. The P-header fields are used for
a variety of purposes within the networks that the partners implement, includin This section contains the update to <xref target="RFC7315" section="5.
g charging and information about the networks a call traverses. This document o 7"/>, in
bsoletes RFC 3455.</t> </abstract> </front> <series order to implement the misalignment fixes and the 3GPP requirements
Info name="RFC" value="7315"/> <seriesInfo name="DOI" value="10.17487/R described in <xref target="Misalignment_3GPP_Use_Cases"/>. In the old
FC7315"/> </reference> <reference anchor="TS23.228"> <fro text, blank lines have been added for readability.
nt> <title>3rd Generation Partnership Project; Technic </t>
al Specification Group Core Network and Terminals; "IP multimedia call control p
rotocol based on Session Initiation Protocol (SIP) and Session De <t>Old text:</t>
scription Protocol (SDP); </title> <author <blockquote>
> <organization abbrev="3GPP"> 3rd Generation Par <t>The P-Associated-URI header field can appear in SIP REGISTER method
tnership Project </organization> </author> <d and 2xx resonses [sic].</t>
ate month="June" year="2016"/> </front> <seriesInfo name="TS" <t>The P-Called-Party-ID header field can appear in
value="23.228"/> <seriesInfo name="V" value="13.6.0"/> </referen SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all
ce> <reference anchor="TS24.229"> <front> <title>3rd responses.</t>
Generation Partnership Project; Technical Specifi <t>The P-Visited-Network-ID header field can appear in all
cation Group Core Network and Terminals; IP multim SIP methods except ACK, BYE, and CANCEL and all responses.</t>
edia call control protocol based on Session Initiatio <t>The P-Access-Network-Info header field can appear in all SIP methods
n Protocol (SIP) and Session Description Protocol except ACK and CANCEL.</t>
(SDP); Stage 3 </title> <author> <t>The P-Charging-Vector header field can appear
<organization abbrev="3GPP"> 3rd Generation Partne in all SIP methods except CANCEL.</t>
rship Project </organization> </author> <date <t>The P-Charging-Function-Addresses
month="June" year="2016"/> </front> <seriesInfo name="TS" val header field can appear in all SIP methods except ACK and CANCEL.</t>
ue="24.229"/> <seriesInfo name="V" value="13.6.0"/> </reference> </blockquote>
</references> <references> <name>Informative References</name>
<reference anchor="RFC3455" target="https://www.rfc-editor.org/info/ <t>New text:</t>
rfc3455"> <front> <title>Private Header (P-Header) Extensio
ns to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership P <blockquote>
roject (3GPP)</title> <author fullname="M. Garcia-Martin" initials="M <t>The P-Associated-URI header field can appear in SIP REGISTER 2xx
." surname="Garcia-Martin"/> <author fullname="E. Henrikson" initials responses.
="E." surname="Henrikson"/> <author fullname="D. Mills" initials="D." </t>
surname="Mills"/> <date month="January" year="2003"/> <ab <t>
stract> <t>This document describes a set of private Session Initiat The P-Called-Party-ID header field can appear in the SIP INVITE,
ion Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Pr OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE requests.
oject (3GPP), along with their applicability, which is limited to particular env </t>
ironments. The P-headers are for a variety of purposes within the networks that <t>
the partners use, including charging and information about the networks a call The P-Visited-Network-ID header field can appear in all SIP requests
traverses. This memo provides information for the Internet community.</t> and the associated non-100 response message except in ACK, BYE,
</abstract> </front> <seriesInfo name="RFC" value="3455" CANCEL, NOTIFY, PRACK, INFO, UPDATE.
/> <seriesInfo name="DOI" value="10.17487/RFC3455"/> </reference </t>
> </references> </references> </back></rfc> <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"/>
<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>
</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.