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] While we understand the original document (RFC 7976) was
	appear in the SIP REGISTER method. </t>		published with the text in some of the questions below, the opportunity
	<t> o P-Called-Party-ID:		with the "bis" document is to make the text as clear as possible.
	Delete the statement that the P-Called-Party-ID		If you decide to make changes, you have the option to add text to
	header field can appear in SIP responses. Add a statem		Section 7 to mention minor editorial updates.
	ent that the P-Called-Pa		-->
	rty-ID header field can appear in the SIP REFER
	method. </t> <t>		<!--[rfced] Abstract and Introduction: Please review if the first sentence
	o P-Access-Network-Info: Add a statem		conveys the intended meaning. Specifically, should "currently not allowed"
	ent that the P-Access-Network-		be rephrased? This text is directly from RFC 7976, published in 2016. What
	Info header field can appear in SIP responses. </t> <t>		is the subject of "not allowed"? It can be read as the requests and responses
	o P-Charging-Vector: Add a statement that the		are not allowed.
	P-Charging-Vector header
	field can appear in SIP responses. Add a statement that		Based on "This specification allows some header fields to be present
	the P-Charging-Vector header field cannot appea		in messages where they were previously not allowed" (Section 5),
	r in the SIP ACK method.		we make the following suggestion.
	</t> <t> o P-C
	harging-Function-Addresses: Add a statement that the		Original:
	P-Charging-Function-Addresses header field can appear i		The Third Generation Partnership Project (3GPP) has identified cases
	n SIP responses. </t>		where different SIP private header extensions referred to as "P-"
	<t> The following update is		header fields, and defined in RFC 7315, need to be included in SIP
	needed in order to clarify the usage of the header compared to <xref target="RFC		requests and responses currently not allowed according to RFC 7315.
	7315" format="default"/>: </t> <t>
	o P-Visited-Network-ID: Add a		Perhaps:
	statement that the P-Visited-Network-ID header field ca		The Third Generation Partnership Project (3GPP) has identified cases
	nnot appear in the SIP NOTI		where different SIP private header extensions referred to as "P-"
	FY, PRACK, INFO, and UPDATE methods. Add statement that the P-Visited-Network-ID		header fields, and defined in RFC 7315, need to be included in SIP
	header field can appear in all non-100 (Trying) responses. </t>		requests and responses where they were not allowed according to RFC 7315.
	</section> <!-- *********************************************************		-->
	******************************************** -->		The Third Generation Partnership Project (3GPP) has identified cases where di
	<section anchor="_GPP_Use_Cases" numbered="true" toc="d		fferent SIP private header extensions referred to as "P-" header fields, and def
	efault"> <name>3GPP Use Cases</name> <!-- ************************		ined in RFC 7315, need to be included in SIP requests and responses currently no
	***************************************************************************** --		t allowed according to RFC 7315. This document updates RFC 7315, in order to all
	>		ow inclusion of the affected "P-" header fields in such requests and responses.
	<section anchor="General_use_case" numbered="true" toc="default"> <nam		This document obsoletes RFC 7976. The changes related to RFC 7976 involve the in
	e>General</name> <t>		clusion of the P-Visited-Network-ID header
	The following updates are needed in order to implement the 3GP		field in SIP responses.
	P use cases:		</t>
	</t> <t>		<!--[rfced] Abstract and Introduction: Please clarify "when RFC 3455 was
	o P-Access-Network-Info: Add statement that the P-Access-Netw		updated and subsequently obsoleted by the publication of RFC 7315".
	ork-		In the RFC series, "updated" and "obsoleted" have distinct meanings
	Info header field can appear in the SIP ACK method when triggered		regarding the relationships between RFCs.
	by a SIP 2xx re
	sponse. </t> <t>		RFC 3455 has not been updated by any other RFCs, so the original sentence
	o P-Charging-Vector: Add statement that the P-Chargin		is not accurate. We suggest simply "obsoleted" as follows. Please let us
	g-Vector header		know if this is acceptable.
	field can appear in the SIP ACK method when triggered by a SIP
	2xx		Original:
	response. </t> <t>		This document also makes updates for RFC 7315 in order to fix
	This following sections describe, for individual "P-"		misalignments that occurred when RFC 3455 was updated and
	header fields,		subsequently obsoleted by the publication of RFC 7315.
	the 3GPP use cases that are the basis for the updates. The use cases
	are based on t		Perhaps:
	he procedures defined in <xref target="TS24.229" format="default"/>. <		This document also makes updates for RFC 7315 in order to fix
	/t> </section> <!-- **********************************************		misalignments that occurred when RFC 3455 was obsoleted by
	******************************************************* -->		RFC 7315.
	<section anchor="P-Access-Netwo
	rk-Info" numbered="true" toc="default"> <name>P-Access-Network-Info</na		Or (if you prefer to explain "obsoleted"):
	me> <t>		This document also makes updates for RFC 7315 in order to fix
	The P-Access-N		misalignments that occurred when RFC 3455 was obsoleted by
	etwork-Info header field may contain the Network		RFC 7315, i.e., when the content of RFC 3455 was completely replaced.
	Provided Location Information (NPLI). The NPL
	I is described in		FYI, similarly, we have updated Section 2.2 as follows for accuracy.
	<xref target="TS23.228" format="default"/>. </t> <t>
	A proxy in possession		Original: when [RFC3455] was updated and obsolated by [RFC7315]
	of appropriate information about the access		Current: when [RFC3455] was obsoleted by [RFC7315]
	technology might insert a P-Access-Network-Info header		-->
	field with its		<t>
	own values. Such values are identified by the string "network-		This document also makes updates to RFC 7315 in order to fix misalignments th
	provided" defined in <xref tar		at occurred when RFC 3455 was updated and subsequently obsoleted by the publicat
	get="RFC7315" format="default"/>. Based on operator policy, roaming agreement o		ion of RFC 7315.
	r both, the local time of the visited network may be		</t>
	included. </t> <t>		</abstract>
	The Call Data Records (CDRs)		</front>
	generated within the IP Multimedia		<middle>
	Subsystem (IMS) have to contain the NPLI in order to g
	uarantee		<section anchor="intro" numbered="true" toc="default">
	correct billing. When an IMS session is modified, the NPLI also		<name>Introduction</name>
	needs to be stored as		<t>
	the location of the user at the time when the		The Third Generation Partnership Project (3GPP) has identified cases w
	session is modified may generate a charging		here different Session Initiation Protocol (SIP) <xref target="RFC3261" format="
	event. In case of a		default"/> private header extensions
	session modification event at IMS, the NPLI needs to be provide		referred to as "P-" header fields, and defined in <xref targe
	d: </t> <t>		t="RFC7315" format="default"/>, need to be included in SIP requests and response
	o when the bearer establishment is triggered, or </t>		s
	<t>		currently not allowed according to <xref target="RFC7315" format="defa
	o at session release when the bearer deactivation is triggered, or <		ult"/>. This document updates <xref target="RFC7315" format="default"/>, in ord
	/t> <t>		er to allow inclusion of the affected "P-" header
	o when the bearer modification is triggered, e.g., a QoS		fields in such requests and responses.
	modification fo		</t>
	r the use of a newly negotiated codec. </t> <t>		<t>
	In some scenarios, the		This document also makes updates to <xref target="RFC7315" format="def
	bearer modification may be triggered by the		ault"/> in order to fix
	proxy upon reception of a Session Description		misalignments that occurred when <xref target="RFC3455" format="defaul
	Protocol (SDP) answer		t"/> was updated and subsequently obsoleted by the publication of <xref target="
	within SIP 2xx response to the SIP INVITE request. In such case, the		RFC7315" format="default"/>.
	NPLI n
	eeds to be provided within the SIP ACK request. However, <xref target="RFC7315"		</t>
	format="default"/> does not allow the usage of the P-Access-Network-Info heade		</section>
	r field		<section anchor="Misalignment_3GPP_Use_Cases" numbered="true" toc="default">
	in SIP ACK request. </t> <t>		<name>Misalignments and 3GPP Use Cases</name>
	Upon reception of the SDP answer within SIP 2x		<section anchor="General" numbered="true" toc="default">
	x response on the SIP		<name>General</name>
	INVITE request, a proxy may initiate procedures to obtain the NPLI		<t>
	and may includ
	e the P-Access-Network-Info header field with the NPLI		<xref target="RFC7315" format="default"/> contains contradictory statements reg
	in the SIP ACK request. </t>		arding the usage of SIP
	<t>		"P-" header fields in SIP requests and
	The P-Access-Network-Info header field shall not be included in SIP		responses, which leave the presence of the SIP "P-" header fields in the SIP re
	ACK requests triggered		quests and
	by non-2xx responses. </t> </section> <!-- *************		responses open to interpretation and d
	********************************************************************************		ifferent implementations. Statements in <xref target="RFC7315" section="5.7"/> a
	******** --> <!-- ***		re not aligned with the
	********************************************************************************		definitions and usage of the SIP "P-"
	****************** -->		header fields specified in <xref target="RFC7315" section="4"/>. This section d
	<section anchor="P-Charging-Vector" numbered="true" toc="defaul		escribes the misalignments that occurred
	t"> <name>P-Charging-Vector</name> <t>		when <xref target="RFC3455" format="de
			fault"/> was updated and subsequently obsoleted by the publication of <xref targ
	<xref target="RFC7315" format="default"/> defines an I		et="RFC7315" format="default"/>, and how they are fixed.
	nter Operator Identifier (IOI) to enable		</t>
	different operators involved in a SIP dialog or a tran		<!-- [rfced] Would you like the note in this document to be in an
	saction outside		<aside> element, or remain as is? It is defined as "a container for
	a dialog to identify each other by exchanging operator identification		content that is semantically less important or tangential to the
	information within the		content that surrounds it" (https://authors.ietf.org/rfcxml-vocabulary#aside).
	P-Charging-Vector header field. </t> <t>
	In the interconnection scenarios in mu		Original:
	lti-operator environments,		NOTE: In the case of the P-Called-Party-ID header field, allowing it
	where one or more transit operators are between the originating and		in PUBLISH requests was done deliberately in [RFC7315]. Therefore,
	terminating operator,		it is not considered a misalignment.
	the identities of the involved transit		-->
	operators are represented by a transit-ioi parameter of the
	P-Charging-Vector head		<t>
	er field. </t> <t>		NOTE: In the case of the P-Called-Part
	Transit operators can be selected independently for each SIP m		y-ID header field, allowing it
	ethod and direction		in PUBLISH requests was done deliberat
	of request. A transit network will only have knowledge		ely in <xref target="RFC7315" format="default"/>. Therefore, it
	of an individual SIP request, and tran		is not considered a misalignment.
	sit network selection will be		</t>
	an independent decision for each request and could be made based on		<t>
	load, cost, percentage		Since <xref target="RFC7315" format="d
	, time of day, and other factors. For this		efault"/> was published, 3GPP defined new use cases that require
	reason, it is necessary that the P-Charging-Vector hea		the RFC to be updated. This section d
	der field, which		escribes the 3GPP use cases
	carries the transit IOI information, is included in each SIP		behind the updates, and the updates ne
	request and response. However, <xref		eded to <xref target="RFC7315" format="default"/> in order to
	target="RFC7315" format="default"/> does not allow the usage of		support the use cases.
	the P-Charging-Vector header f		</t>
	ield in the SIP ACK request.
	</t> <t>		<t>
	A SIP proxy that supports this extension and receives the SIP ACK		<xref target="Updates_to_RFC_7315"/> u
	request may include a		pdates <xref target="RFC7315" format="default"/>, based on the misalignments and
	P-Charging-Vector header field in the SIP ACK		3GPP use
	request. </t> <t>		cases.
	The P-Charging-Vector header field sha
	ll not be included in SIP ACK		</t>
	requests triggered by SIP non-2xx responses. </t> </se		</section>
	ction> <!-- *************************************************************		<section anchor="Misalignments" numbered="true" toc="default">
	**************************************** -->		<name>Misalignments</name>
	</section> </section> <!-- ****************************************		<t>
	********************************************************************************		The following updates are needed
	********************************** --> <section anchor="Updates_to_RFC_7315"		in order to fix the misalignments
	numbered="true" toc="default"> <name>Updates to RFC 7315</name> <t>		that occurred when <xref targe
	This section implements the update to Section 5.7 of <xref target="RFC		t="RFC3455" format="default"/> was obsoleted by <xref target="RFC7315" format="d
	7315" format="default"/>, in order to implement the misalignment fixes and		efault"/>:
	the 3GPP requirements described in Section 2. </t> <t> Old te		</t>
	xt: </t> <t> The P-Associated-URI header field can appear in SIP RE
	GISTER method and 2xx resonses. </t> <t> The P-Called-Part		<ul spacing="normal">
	y-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and		<li>P-Associated-URI: Remove the statement that the header field can appear in
	MESSAGE methods and all responses. </t> <t> The P-Visi		the SIP REGISTER method.</li>
	ted-Network-ID header field can appear in all SIP methods except ACK,		<li>P-Called-Party-ID: Delete the statement that the P-Called-Party-ID header
	BYE, and CANCEL and all responses. </t> <t>The P-Access-Netw		field can appear in SIP responses. Add a statement that the P-Called-Party-ID
	ork-Info header field can appear in all SIP methods except ACK and CAN		header field can appear in the SIP REFER method.</li>
	CEL. </t> <t>The P-Charging-Vector header field can appear in al		<li>P-Access-Network-Info: Add a statement that the P-Access-Network- Info
	l SIP methods except CANCEL. </t> <t>The P-Charging-Function-Addresses		header field can appear in SIP responses.</li>
	header field can appear in all SIP methods except ACK and CANCEL. </		<li>P-Charging-Vector: Add a statement that the P-Charging-Vector header field
	t> <t> New text: </t> <t> The P-Associated-URI h		can appear in SIP responses. Add a statement that the P-Charging-Vector
	eader field can appear in SIP REGISTER 2xx responses. </t> <t>		header field cannot appear in the SIP ACK method.</li>
	The P-Called-Party-ID header field can appear in the SIP INVITE, OPTION		<li>P-Charging-Function-Addresses: Add a statement that the
	S, PUBLISH, REFER, SUBSCRIBE, and MESSAGE requests. </t> <t> Th		P-Charging-Function-Addresses header field can appear in SIP responses.</li>
	e P-Visited-Network-ID header field can appear in all SIP requests and the assoc		</ul>
	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		<t>The following update is needed in order to clarify the usage of
	appear in all SIP requests and the associated non-100 responses, except in C		the header compared to <xref target="RFC7315" format="default"/>:</t>
	ANCEL requests, CANCEL responses, and ACK methods triggered by non-2xx respo		<ul spacing="normal">
	nses. </t> <t> The P-Charging-Vector header field can appear in a		<li>P-Visited-Network-ID: Add a statement that the P-Visited-Network-ID header
	ll SIP requests and the associated non-100 responses, except in CANCEL reque		field cannot appear in the SIP NOTIFY, PRACK, INFO, and UPDATE methods. Add
	sts, CANCEL responses, and ACK requests triggered by non-2xx responses.		statement that the P-Visited-Network-ID header field can appear in all non-100
	</t> <t> The P-Charging-Function-Addresses header field		(Trying) responses.</li>
	can appear in all SIP methods and the associated non-100 responses, except in		</ul>
	CANCEL requests, CANCEL responses, and ACK requests. </t>		</section>
	</section> <!-- **********************************************************
	********************************************************************************		<section anchor="_GPP_Use_Cases" numbered="true" toc="default">
	*************** --> <section anchor="IANA" numbered="true" toc="default"> <		<name>3GPP Use Cases</name>
	name>IANA Considerations</name> <t> No IANA Considerations.
	</t> </section> <section anchor="security" numbered="true" toc="defaul		<section anchor="General_use_case" numbered="true" toc="default">
	t"> <name>Security Considerations</name> <t> The security considerat		<name>General</name>
	ions for these "P-" header fields are defined in <xref target="RFC7315" format		<t>The following updates are needed in order to implement the 3GPP
	="default"/>. This specification allows some header fields to be present in m		use cases:</t>
	essages where they were previously not allowed, and the security consideration
	s and assumptions described in <xref target="RFC7315" format="default"/> (e.g.,		<ul spacing="normal">
	regarding only sending information to trusted entities) also apply to those		<li>P-Access-Network-Info: Add statement that the P-Access-Network- Info
	messages. In addition, this specification also disallows some header field		header field can appear in the SIP ACK method when triggered by a SIP 2xx
	s to be present in messages where they were previously allowed. That does not		response.</li>
	cause any security issues, but implementors need to be aware that implementat		<li>P-Charging-Vector: Add statement that the P-Charging-Vector header field
	ions may not have been updated according to this document, and take proper act		can appear in the SIP ACK method when triggered by a SIP 2xx response.</li>
	ions if a header field occurs, or does not occur, in a message where it should		</ul>
	occur (or occurs in a message where it should not occur). This document a
	dds the ability to include P-Access-Network-Info in ACK requests. As docume		<t>This following sections describe, for individual "P-" header fields, the
	nted in <xref target="RFC7315" format="default"/>, P-Access-Network-Info may inc		3GPP use cases that are the basis for the updates. The use cases are based
	lude privacy sensitive information, including the user's location. The securi		on the procedures defined in <xref target="TS24.229" format="default"/>.</t>
	ty and privacy considerations for P-Access-Network-Info in ACK requests are		</section>
	similar to those for the other SIP requests discussed in Section 6.4 of <xref
	target="RFC7315" format="default"/>. The security and privacy considerations f		<section anchor="P-Access-Network-Info" numbered="true" toc="default">
	or the P-Visited-Network-ID header field are similar to those for the other S		<name>P-Access-Network-Info</name>
	IP responses discussed in Section 6.3 of <xref target="RFC7315" format="default"		<t>
	/>. </t> </section> <!-- ********************************************
	********************************************************* --> <section numbe		The P-Access-N
	red="true" toc="default"> <name>Operational considerations</name> <t>		etwork-Info header field may contain the Network
	As the "P-" header fields are mainly used in (and in most cases, only		Provided Locat
	defined for) networks defined by the 3GPP, where the updates define		ion Information (NPLI). The NPLI is described in
	d in this document are already defined <xref target="TS24.229" forma		<xref target="
	t="default"/>, the updates are not seen to cause backward-compatibility		TS23.228" format="default"/>.
	concerns. </t> </section><!-- ****************************
	************************************************************************* --> <		</t>
	!-- ****************************************************************************		<t>
	************************* --> <section numbered="true" toc="default"> <		A proxy in pos
	name>Changes since RFC7976</name> <t> The changes related to RFC7976 in		session of appropriate information about the access
	volve the inclusion of the P-Visited-Network-ID header field in SIP respons		technology mig
	es. Specifically, any SIP response message, with the exception of a 100 (Tr		ht insert a P-Access-Network-Info header field with its
	ying) response, may include a P-Visited-Network-ID header field. </t> </		own values. S
	section><!-- *******************************************************************		uch values are identified by the string "network-
	********************************** --> <section numbered="true" toc="default		provided" defi
	"> <name>Acknowledgments</name> <t> The author would like to ackn		ned in <xref target="RFC7315" format="default"/>. Based on operator policy, roa
	owledge the constructive feedback provided by Michael Kreipl, Charles Eckel an		ming agreement, or both, the local time of the visited network may be
	d Paul Kyzivat Thanks to Paul Kyzivat, Jean Mahoney, Ben Campbell, and Adam		included.
	Roach for providing comments on the former version of the document. </t>		</t>
	</section> </middle> <back> <references> <name>References</name>		<!--[rfced] To prevent misreading this sentence (i.e., "the NPLI needs to
	<references> <name>Normative References</name> <reference		be stored as the location of the user"), may we add a comma as follows?
	anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3261"> <f
	ront> <title>SIP: Session Initiation Protocol</title> <aut		Original:
	hor fullname="J. Rosenberg" initials="J." surname="Rosenberg"/> <auth		When an IMS session is modified, the NPLI also
	or fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/> <a		needs to be stored as the location of the user at the time when the
	uthor fullname="G. Camarillo" initials="G." surname="Camarillo"/> <au		session is modified may generate a charging event.
	thor fullname="A. Johnston" initials="A." surname="Johnston"/> <autho
	r fullname="J. Peterson" initials="J." surname="Peterson"/> <author f		Suggested:
	ullname="R. Sparks" initials="R." surname="Sparks"/> <author fullname		When an IMS session is modified, the NPLI also
	="M. Handley" initials="M." surname="Handley"/> <author fullname="E.		needs to be stored, as the location of the user at the time when the
	Schooler" initials="E." surname="Schooler"/> <date month="June" year=		session is modified may generate a charging event.
	"2002"/> <abstract> <t>This document describes Session I		-->
	nitiation Protocol (SIP), an application-layer control (signaling) protocol for		<t>The Call Data Records (CDRs) generated within the IP Multimedia
	creating, modifying, and terminating sessions with one or more participants. Th		Subsystem (IMS) have to contain the NPLI in order to guarantee
	ese sessions include Internet telephone calls, multimedia distribution, and mult		correct billing. When an IMS session is modified, the NPLI also
	imedia conferences. [STANDARDS-TRACK]</t> </abstract> </fron		needs to be stored as the location of the user at the time when the
	t> <seriesInfo name="RFC" value="3261"/> <seriesInfo name="DOI		session is modified may generate a charging event. In case of a
	" value="10.17487/RFC3261"/> </reference> <reference anchor="RFC73		session modification event at IMS, the NPLI needs to be provided:</t>
	15" target="https://www.rfc-editor.org/info/rfc7315"> <front>
	<title>Private Header (P-Header) Extensions to the Session Initiation Protoco		<ul spacing="normal">
	l (SIP) for the 3GPP</title> <author fullname="R. Jesske" initials="R		<li>when the bearer establishment is triggered, or</li>
	." surname="Jesske"/> <author fullname="K. Drage" initials="K." surna		<li>at session release when the bearer deactivation is triggered, or</li>
	me="Drage"/> <author fullname="C. Holmberg" initials="C." surname="Ho		<li>when the bearer modification is triggered, e.g., a QoS modification for
	lmberg"/> <date month="July" year="2014"/> <abstract>		the use of a newly negotiated codec.</li>
	<t>This document describes a set of private header (P-header) Session I		</ul>
	nitiation Protocol (SIP) fields used by the 3GPP, along with their applicability		<!--[rfced] We suggest adding articles ('the' and 'a') as follows; please let
	, which is limited to particular environments. The P-header fields are used for		us know if this is acceptable. (We note that RFC 7976 did not use
	a variety of purposes within the networks that the partners implement, includin		articles in similar text, but 'a SIP 2xx response' appears in other RFCs.)
	g charging and information about the networks a call traverses. This document o
	bsoletes RFC 3455.</t> </abstract> </front> <series		Original: ... within SIP 2xx response to the SIP INVITE request.
	Info name="RFC" value="7315"/> <seriesInfo name="DOI" value="10.17487/R		Perhaps: ... within the SIP 2xx response to the SIP INVITE request.
	FC7315"/> </reference> <reference anchor="TS23.228"> <fro
	nt> <title>3rd Generation Partnership Project; Technic		Original: Upon reception of the SDP answer within SIP 2xx response ..
	al Specification Group Core Network and Terminals; "IP multimedia call control p		Perhaps: Upon reception of the SDP answer within a SIP 2xx response ...
	rotocol based on Session Initiation Protocol (SIP) and Session De		-->
	scription Protocol (SDP); </title> <author		<t>
	> <organization abbrev="3GPP"> 3rd Generation Par		In som
	tnership Project </organization> </author> <d		e scenarios, the bearer modification may be triggered by the
	ate month="June" year="2016"/> </front> <seriesInfo name="TS"		proxy
	value="23.228"/> <seriesInfo name="V" value="13.6.0"/> </referen		upon reception of a Session Description Protocol (SDP) answer
	ce> <reference anchor="TS24.229"> <front> <title>3rd		within
	Generation Partnership Project; Technical Specifi		SIP 2xx response to the SIP INVITE request. In such case, the
	cation Group Core Network and Terminals; IP multim		NPLI n
	edia call control protocol based on Session Initiatio		eeds to be provided within the SIP ACK request. However, <xref target="RFC7315"
	n Protocol (SIP) and Session Description Protocol		format="default"/> does not allow the usage of the P-Access-Network-Info heade
	(SDP); Stage 3 </title> <author>		r
	<organization abbrev="3GPP"> 3rd Generation Partne		field
	rship Project </organization> </author> <date		in a SIP ACK request.
	month="June" year="2016"/> </front> <seriesInfo name="TS" val		</t>
	ue="24.229"/> <seriesInfo name="V" value="13.6.0"/> </reference>		<t>
	</references> <references> <name>Informative References</name>		Upon r
	<reference anchor="RFC3455" target="https://www.rfc-editor.org/info/		eception of the SDP answer within SIP 2xx response on the SIP
	rfc3455"> <front> <title>Private Header (P-Header) Extensio		INVITE
	ns to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership P		request, a proxy may initiate procedures to obtain the NPLI
	roject (3GPP)</title> <author fullname="M. Garcia-Martin" initials="M		and ma
	." surname="Garcia-Martin"/> <author fullname="E. Henrikson" initials		y include the P-Access-Network-Info header field with the NPLI
	="E." surname="Henrikson"/> <author fullname="D. Mills" initials="D."		in the
	surname="Mills"/> <date month="January" year="2003"/> <ab		SIP ACK request.
	stract> <t>This document describes a set of private Session Initiat		</t>
	ion Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Pr		<t>
	oject (3GPP), along with their applicability, which is limited to particular env		The P-
	ironments. The P-headers are for a variety of purposes within the networks that		Access-Network-Info header field shall not be included in SIP
	the partners use, including charging and information about the networks a call		ACK re
	traverses. This memo provides information for the Internet community.</t>		quests triggered by non-2xx responses.
	</abstract> </front> <seriesInfo name="RFC" value="3455"		</t>
	/> <seriesInfo name="DOI" value="10.17487/RFC3455"/> </reference		</section>
	> </references> </references> </back></rfc>
			<section anchor="P-Charging-Vector" numbered="true" toc="default">
			<name>P-Charging-Vector</name>
			<t>
			<xref target="
			RFC7315" format="default"/> defines an Inter Operator Identifier (IOI) to enable
			different oper
			ators involved in a SIP dialog or a transaction outside
			a dialog to id
			entify each other by exchanging operator identification
			information wi
			thin the P-Charging-Vector header field.
			</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 response
			In other instances in this document, "SIP" does not appear before
			"non-2xx response"; 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.