<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" ipr="trust200902" updates="7315" docName="draft-ietf-sipcore-rfc7976bis-04" number="9878" consensus="true" obsoletes="7976" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" prepTime="2025-11-19T11:35:52" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc7976bis-04" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9878" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Update to Private Header">Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses</title>
    <seriesInfo name="RFC" value="9878" stream="IETF"/>
    <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
      <organization showOnFrontPage="true">Ericsson</organization>
      <address>
        <postal>
          <street>Hirsalantie 11</street>
          <city>Jorvas</city>
          <code>02420</code>
          <country>Finland</country>
        </postal>
        <email>christer.holmberg@ericsson.com</email>
      </address>
    </author>
    <author initials="N." surname="Biondic" fullname="Nevenka Biondic">
      <organization showOnFrontPage="true">ETSI</organization>
      <address>
        <postal>
          <street>650 route des Lucioles</street>
          <city>Sophia Antipolis cedex</city>
          <code>06921</code>
          <country>France</country>
        </postal>
        <email>Nevenka.Biondic@etsi.org</email>
      </address>
    </author>
    <author initials="G." surname="Salgueiro" fullname="Gonzalo Salgueiro">
      <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>7200-12 Kit Creek Road</street>
          <city>Research Triangle Park</city>
          <region>NC</region>
          <code>27709</code>
          <country>United States of America</country>
        </postal>
        <email>gsalguei@cisco.com</email>
      </address>
    </author>
    <author initials="R." surname="Jesske" fullname="Roland Jesske">
      <organization showOnFrontPage="true">Deutsche Telekom</organization>
      <address>
        <postal>
          <street>Deutsche-Telekom-Allee 9</street>
          <city>Darmstadt</city>
          <code>64295</code>
          <country>Germany</country>
        </postal>
        <email>r.jesske@telekom.de</email>
        <uri>www.telekom.com</uri>
      </address>
    </author>
    <date month="11" year="2025"/>
    <area>ART</area>
    <workgroup>sipcore</workgroup>
    <keyword>3GPP</keyword>
    <keyword>Visited</keyword>
    <keyword>ID</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
   The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses where they were not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses. This document obsoletes RFC 7976. The changes related to RFC 7976 involve the inclusion of the P-Visited-Network-ID header field in SIP responses.
</t>
      <t indent="0" pn="section-abstract-2">
   This document also makes updates to RFC 7315 in order to fix misalignments that occurred when RFC 3455 was obsoleted by RFC 7315.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9878" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-misalignments-and-3gpp-use-">Misalignments and 3GPP Use Cases</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general">General</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-misalignments">Misalignments</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-3gpp-use-cases">3GPP Use Cases</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2.3.2">
                  <li pn="section-toc.1-1.2.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.2.2.3.2.1.1"><xref derivedContent="2.3.1" format="counter" sectionFormat="of" target="section-2.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-2">General</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.2.2.3.2.2.1"><xref derivedContent="2.3.2" format="counter" sectionFormat="of" target="section-2.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-p-access-network-info">P-Access-Network-Info</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.2.2.3.2.3.1"><xref derivedContent="2.3.3" format="counter" sectionFormat="of" target="section-2.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-p-charging-vector">P-Charging-Vector</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-updates-to-rfc-7315">Updates to RFC 7315</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-considerations">Operational considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-since-rfc-7976">Changes since RFC 7976</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
	   The Third Generation Partnership Project (3GPP) has identified cases where different Session Initiation Protocol (SIP) <xref target="RFC3261" format="default" sectionFormat="of" derivedContent="RFC3261"/> private header extensions 
	   referred to 		as "P-" header fields, and defined in <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/>, need to be included in SIP requests and responses
	   where they were not allowed according to <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/>.  This document updates <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/>, in order to allow inclusion of the affected "P-" header
	   fields in such requests and responses.
      </t>
      <t indent="0" pn="section-1-2">
	   This document also makes updates to <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/> in order to fix
	   misalignments that occurred when <xref target="RFC3455" format="default" sectionFormat="of" derivedContent="RFC3455"/> was updated and subsequently obsoleted by the publication of <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/>.
	

      </t>
    </section>
    <section anchor="Misalignment_3GPP_Use_Cases" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-misalignments-and-3gpp-use-">Misalignments and 3GPP Use Cases</name>
      <section anchor="General" numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-general">General</name>
        <t indent="0" pn="section-2.1-1">  
										  <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/> contains contradictory statements regarding the usage of SIP
					   "P-" header fields in SIP requests and responses, which leave the presence of the SIP "P-" header fields in the SIP requests and
					   responses open to interpretation and different implementations. Statements in <xref target="RFC7315" section="5.7" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7315#section-5.7" derivedContent="RFC7315"/> are not aligned with the
					   definitions and usage of the SIP "P-" header fields specified in <xref target="RFC7315" section="4" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7315#section-4" derivedContent="RFC7315"/>.  This section describes the misalignments that occurred
					   when <xref target="RFC3455" format="default" sectionFormat="of" derivedContent="RFC3455"/> was updated and subsequently obsoleted by the publication of <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/>, and how they are fixed.
        </t>
        <aside pn="section-2.1-2">
          <t indent="0" pn="section-2.1-2.1"> 
					   NOTE: In the case of the P-Called-Party-ID header field, allowing it
					   in PUBLISH requests was done deliberately in <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/>.  Therefore, it
					   is not considered a misalignment.
          </t>
        </aside>
        <t indent="0" pn="section-2.1-3">
					   Since <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/> was published, 3GPP defined new use cases that require
					   the RFC to be updated.  This section describes the 3GPP use cases
					   behind the updates, and the updates needed to <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/> in order to
					   support the use cases. 
        </t>
        <t indent="0" pn="section-2.1-4"> 
					   <xref target="Updates_to_RFC_7315" format="default" sectionFormat="of" derivedContent="Section 3"/> updates <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/>, based on the misalignments and 3GPP use
					   cases.
					   
        </t>
      </section>
      <section anchor="Misalignments" numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-misalignments">Misalignments</name>
        <t indent="0" pn="section-2.2-1">  
						 The following updates are needed in order to fix the misalignments
						   that occurred when <xref target="RFC3455" format="default" sectionFormat="of" derivedContent="RFC3455"/> was obsoleted by <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/>:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.2-2">
          <li pn="section-2.2-2.1">P-Associated-URI: Remove the statement that the header field can appear in
the SIP REGISTER method.</li>
          <li pn="section-2.2-2.2">P-Called-Party-ID: Delete the statement that the P-Called-Party-ID header
field can appear in SIP responses.  Add a statement that the P-Called-Party-ID
header field can appear in the SIP REFER method.</li>
          <li pn="section-2.2-2.3">P-Access-Network-Info: Add a statement that the P-Access-Network- Info
header field can appear in SIP responses.</li>
          <li pn="section-2.2-2.4">P-Charging-Vector: Add a statement that the P-Charging-Vector header field
can appear in SIP responses.  Add a statement that the P-Charging-Vector
header field cannot appear in the SIP ACK method.</li>
          <li pn="section-2.2-2.5">P-Charging-Function-Addresses: Add a statement that the
P-Charging-Function-Addresses header field can appear in SIP responses.</li>
        </ul>
        <t indent="0" pn="section-2.2-3">The following update is needed in order to clarify the usage of
        the header compared to <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/>:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.2-4">
          <li pn="section-2.2-4.1">P-Visited-Network-ID: Add a statement that the P-Visited-Network-ID header
field cannot appear in the SIP NOTIFY, PRACK, INFO, and UPDATE methods. Add
statement that the P-Visited-Network-ID header field can appear in all non-100
(Trying) responses.</li>
        </ul>
      </section>
      <section anchor="_GPP_Use_Cases" numbered="true" toc="include" removeInRFC="false" pn="section-2.3">
        <name slugifiedName="name-3gpp-use-cases">3GPP Use Cases</name>
        <section anchor="General_use_case" numbered="true" toc="include" removeInRFC="false" pn="section-2.3.1">
          <name slugifiedName="name-general-2">General</name>
          <t indent="0" pn="section-2.3.1-1">The following updates are needed in order to implement the 3GPP
          use cases:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.3.1-2">
            <li pn="section-2.3.1-2.1">P-Access-Network-Info: Add statement that the P-Access-Network- Info
  header field can appear in the SIP ACK method when triggered by a SIP 2xx
  response.</li>
            <li pn="section-2.3.1-2.2">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>
          </ul>
          <t indent="0" pn="section-2.3.1-3">This following sections describe, for individual "P-" header fields, the
  3GPP use cases that are the basis for the updates.  The use cases are based
  on the procedures defined in <xref target="TS24.229" format="default" sectionFormat="of" derivedContent="TS24.229"/>.</t>
        </section>
        <section anchor="P-Access-Network-Info" numbered="true" toc="include" removeInRFC="false" pn="section-2.3.2">
          <name slugifiedName="name-p-access-network-info">P-Access-Network-Info</name>
          <t indent="0" pn="section-2.3.2-1">  
								  
								   The P-Access-Network-Info header field may contain the Network
								   Provided Location Information (NPLI).  The NPLI is described in
								   <xref target="TS23.228" format="default" sectionFormat="of" derivedContent="TS23.228"/>.
 
          </t>
          <t indent="0" pn="section-2.3.2-2">
								   A proxy in possession of appropriate information about the access
								   technology might insert a P-Access-Network-Info header field with its
								   own values.  Such values are identified by the string "network-
								   provided" defined in <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/>.  Based on operator policy, roaming agreement, or both, the local time of the visited network may be
								   included.
          </t>
          <t indent="0" pn="section-2.3.2-3">The Call Data Records (CDRs) generated within the IP Multimedia
          Subsystem (IMS) have to contain the NPLI in order to guarantee
          correct billing.  When an IMS session is modified, the NPLI also
          needs to be stored, as the location of the user at the time when the
          session is modified may generate a charging event.  In case of a
          session modification event at IMS, the NPLI needs to be provided:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.3.2-4">
            <li pn="section-2.3.2-4.1">when the bearer establishment is triggered, or</li>
            <li pn="section-2.3.2-4.2">at session release when the bearer deactivation is triggered, or</li>
            <li pn="section-2.3.2-4.3">when the bearer modification is triggered, e.g., a QoS modification for
  the use of a newly negotiated codec.</li>
          </ul>
          <t indent="0" pn="section-2.3.2-5">
									   In some scenarios, the bearer modification may be triggered by the
									   proxy upon reception of a Session Description Protocol (SDP) answer
									   within the SIP 2xx response to the SIP INVITE request.  In such case, the
									   NPLI needs to be provided within the SIP ACK request.  However, <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/>  does not allow the usage of the P-Access-Network-Info header
									   field in a SIP ACK request.
          </t>
          <t indent="0" pn="section-2.3.2-6">
									   Upon reception of the SDP answer within a SIP 2xx response on the SIP
									   INVITE request, a proxy may initiate procedures to obtain the NPLI
									   and may include the P-Access-Network-Info header field with the NPLI
									   in the SIP ACK request.
          </t>
          <t indent="0" pn="section-2.3.2-7">
									   The P-Access-Network-Info header field shall not be included in SIP
									   ACK requests triggered by non-2xx responses.
          </t>
        </section>
        <section anchor="P-Charging-Vector" numbered="true" toc="include" removeInRFC="false" pn="section-2.3.3">
          <name slugifiedName="name-p-charging-vector">P-Charging-Vector</name>
          <t indent="0" pn="section-2.3.3-1">  
								  
								   <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/> defines an Inter Operator Identifier (IOI) to enable
								   different operators involved in a SIP dialog or a transaction outside
								   a dialog to identify each other by exchanging operator identification
								   information within the P-Charging-Vector header field.
          </t>
          <t indent="0" pn="section-2.3.3-2">
								   In the interconnection scenarios in multi-operator environments,
								   where one or more transit operators are between the originating and
								   terminating operator, the identities of the involved transit
								   operators are represented by a transit-ioi parameter of the
								   P-Charging-Vector header field.
          </t>
          <t indent="0" pn="section-2.3.3-3">
								   Transit operators can be selected independently for each SIP method
								   and direction of request.  A transit network will only have knowledge
								   of an individual SIP request, and transit network selection will be
								   an independent decision for each request and could be made based on
								   load, cost, percentage, time of day, and other factors.  For this
								   reason, it is necessary that the P-Charging-Vector header field,
								   which carries the transit IOI information, is included in each SIP
								   request and response.  However, <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/> does not allow the usage of
								   the P-Charging-Vector header field in the SIP ACK request.
          </t>
          <t indent="0" pn="section-2.3.3-4">
								    A SIP proxy that supports this extension and receives the SIP ACK
								   request may include a P-Charging-Vector header field in the SIP ACK
								   request.
          </t>
          <t indent="0" pn="section-2.3.3-5">
								   The P-Charging-Vector header field shall not be included in SIP ACK
								   requests triggered by non-2xx responses.

          </t>
        </section>
      </section>
    </section>
    <section anchor="Updates_to_RFC_7315" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-updates-to-rfc-7315">Updates to RFC 7315</name>
      <t indent="0" pn="section-3-1">
    
	   This section contains the update to <xref target="RFC7315" section="5.7" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7315#section-5.7" derivedContent="RFC7315"/>, in
	   order to implement the misalignment fixes and the 3GPP requirements
	   described in <xref target="Misalignment_3GPP_Use_Cases" format="default" sectionFormat="of" derivedContent="Section 2"/>. In the old text, blank lines have been added for readability.
      </t>
      <t indent="0" pn="section-3-2">Old text:</t>
      <blockquote pn="section-3-3">
        <t indent="0" pn="section-3-3.1">The P-Associated-URI header field can appear in SIP REGISTER method
and 2xx resonses [sic].</t>
        <t indent="0" pn="section-3-3.2">The P-Called-Party-ID header field can appear in
SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all
responses.</t>
        <t indent="0" pn="section-3-3.3">The P-Visited-Network-ID header field can appear in all
SIP methods except ACK, BYE, and CANCEL and all responses.</t>
        <t indent="0" pn="section-3-3.4">The P-Access-Network-Info header field can appear in all SIP methods
except ACK and CANCEL.</t>
        <t indent="0" pn="section-3-3.5">The P-Charging-Vector header field can appear
in all SIP methods except CANCEL.</t>
        <t indent="0" pn="section-3-3.6">The P-Charging-Function-Addresses
header field can appear in all SIP methods except ACK and CANCEL.</t>
      </blockquote>
      <t indent="0" pn="section-3-4">New text:</t>
      <blockquote pn="section-3-5">
        <t indent="0" pn="section-3-5.1">The P-Associated-URI header field can appear in SIP REGISTER 2xx
      responses.
        </t>
        <t indent="0" pn="section-3-5.2">
       The P-Called-Party-ID header field can appear in the SIP INVITE,
       OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE requests.
        </t>
        <t indent="0" pn="section-3-5.3">
	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 indent="0" pn="section-3-5.4">
       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 indent="0" pn="section-3-5.5">
	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 indent="0" pn="section-3-5.6">
       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="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-4-1">
	  This document has no IANA actions.
      </t>
    </section>
    <section anchor="security" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">
   The security considerations for these "P-" header fields are defined
   in <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/>.  This specification allows some header fields to be
   present in messages where they were previously not allowed, and the
   security considerations and assumptions described in <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/> (e.g.,
   regarding only sending information to trusted entities) also apply to
   those messages.  
   In addition, this specification also disallows some
   header fields to be present in messages where they were previously
   allowed.  That does not cause any security issues, but implementors
   need to be aware that implementations may not have been updated
   according to this document, and take proper actions if a header field
   occurs, or does not occur, in a message where it should occur (or
   occurs in a message where it should not occur).  
   This document adds
   the ability to include P-Access-Network-Info in ACK requests.  As
   documented in <xref target="RFC7315" format="default" sectionFormat="of" derivedContent="RFC7315"/>, P-Access-Network-Info may include privacy
   sensitive information, including the user's location.  The security
   and privacy considerations for P-Access-Network-Info in ACK requests
   are similar to those for the other SIP requests discussed in 
   <xref target="RFC7315" section="6.4" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7315#section-6.4" derivedContent="RFC7315"/>.
   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="RFC7315" section="6.3" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7315#section-6.3" derivedContent="RFC7315"/>.

      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-operational-considerations">Operational considerations</name>
      <t indent="0" pn="section-6-1">
      	   As the "P-" header fields are mainly used in (and in most cases, only defined for) 
      	   networks defined by the 3GPP, where the updates defined in this document are already 
	   defined  <xref target="TS24.229" format="default" sectionFormat="of" derivedContent="TS24.229"/>, the updates are not seen to cause 
	   backward-compatibility concerns.
	   
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-changes-since-rfc-7976">Changes since RFC 7976</name>
      <t indent="0" pn="section-7-1"> 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>
  </middle>
  <back>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3261" quoteTitle="true" derivedAnchor="RFC3261">
          <front>
            <title>SIP: Session Initiation Protocol</title>
            <author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
            <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
            <author fullname="G. Camarillo" initials="G." surname="Camarillo"/>
            <author fullname="A. Johnston" initials="A." surname="Johnston"/>
            <author fullname="J. Peterson" initials="J." surname="Peterson"/>
            <author fullname="R. Sparks" initials="R." surname="Sparks"/>
            <author fullname="M. Handley" initials="M." surname="Handley"/>
            <author fullname="E. Schooler" initials="E." surname="Schooler"/>
            <date month="June" year="2002"/>
            <abstract>
              <t indent="0">This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3261"/>
          <seriesInfo name="DOI" value="10.17487/RFC3261"/>
        </reference>
        <reference anchor="RFC7315" target="https://www.rfc-editor.org/info/rfc7315" quoteTitle="true" derivedAnchor="RFC7315">
          <front>
            <title>Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP</title>
            <author fullname="R. Jesske" initials="R." surname="Jesske"/>
            <author fullname="K. Drage" initials="K." surname="Drage"/>
            <author fullname="C. Holmberg" initials="C." surname="Holmberg"/>
            <date month="July" year="2014"/>
            <abstract>
              <t indent="0">This document describes a set of private header (P-header) Session Initiation Protocol (SIP) fields used by the 3GPP, along with their applicability, which is limited to particular environments. The P-header fields are used for a variety of purposes within the networks that the partners implement, including charging and information about the networks a call traverses. This document obsoletes RFC 3455.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7315"/>
          <seriesInfo name="DOI" value="10.17487/RFC7315"/>
        </reference>
        <reference anchor="TS23.228" target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=821" quoteTitle="true" derivedAnchor="TS23.228">
          <front>
            <title>IP Multimedia Subsystem (IMS); Stage 2</title>
            <author>
              <organization abbrev="3GPP" showOnFrontPage="true">3rd Generation Partnership Project</organization>
            </author>
          </front>
          <seriesInfo name="3GPP TS" value="23.228"/>
        </reference>
        <reference anchor="TS24.229" target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1055" quoteTitle="true" derivedAnchor="TS24.229">
          <front>
            <title>IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3</title>
            <author>
              <organization abbrev="3GPP" showOnFrontPage="true">3rd Generation Partnership Project</organization>
            </author>
          </front>
          <seriesInfo name="3GPP TS" value="24.229"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC3455" target="https://www.rfc-editor.org/info/rfc3455" quoteTitle="true" derivedAnchor="RFC3455">
          <front>
            <title>Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)</title>
            <author fullname="M. Garcia-Martin" initials="M." surname="Garcia-Martin"/>
            <author fullname="E. Henrikson" initials="E." surname="Henrikson"/>
            <author fullname="D. Mills" initials="D." surname="Mills"/>
            <date month="January" year="2003"/>
            <abstract>
              <t indent="0">This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3455"/>
          <seriesInfo name="DOI" value="10.17487/RFC3455"/>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">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 indent="0" pn="section-appendix.a-2">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>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
        <organization showOnFrontPage="true">Ericsson</organization>
        <address>
          <postal>
            <street>Hirsalantie 11</street>
            <city>Jorvas</city>
            <code>02420</code>
            <country>Finland</country>
          </postal>
          <email>christer.holmberg@ericsson.com</email>
        </address>
      </author>
      <author initials="N." surname="Biondic" fullname="Nevenka Biondic">
        <organization showOnFrontPage="true">ETSI</organization>
        <address>
          <postal>
            <street>650 route des Lucioles</street>
            <city>Sophia Antipolis cedex</city>
            <code>06921</code>
            <country>France</country>
          </postal>
          <email>Nevenka.Biondic@etsi.org</email>
        </address>
      </author>
      <author initials="G." surname="Salgueiro" fullname="Gonzalo Salgueiro">
        <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <street>7200-12 Kit Creek Road</street>
            <city>Research Triangle Park</city>
            <region>NC</region>
            <code>27709</code>
            <country>United States of America</country>
          </postal>
          <email>gsalguei@cisco.com</email>
        </address>
      </author>
      <author initials="R." surname="Jesske" fullname="Roland Jesske">
        <organization showOnFrontPage="true">Deutsche Telekom</organization>
        <address>
          <postal>
            <street>Deutsche-Telekom-Allee 9</street>
            <city>Darmstadt</city>
            <code>64295</code>
            <country>Germany</country>
          </postal>
          <email>r.jesske@telekom.de</email>
          <uri>www.telekom.com</uri>
        </address>
      </author>
    </section>
  </back>
</rfc>
