<?xml version='1.0'encoding='utf-8'?><!DOCTYPEencoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj"⁠">]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?><rfc"⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" 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" version="3"> <!--xml2rfc v2v3 conversion 3.17.3[rfced] Because this document updates RFC 7315, please review the errata reported for RFC 7315 (https://www.rfc-editor.org/errata/rfc7315) and let us know if you confirm our opinion that none of them are relevant to the content of this document. --> <!-- [rfced] Because this document obsoletes RFC 7976, please review the errata reported for RFC 7976 (https://www.rfc-editor.org/errata/rfc7976) and let us know if you confirm our opinion that none of them are relevant to the content of this document. --> <front> <title abbrev="Update to Private Header">Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses</title> <seriesInfoname="Internet-Draft" value="draft-ietf-sipcore-rfc7976bis-04"/>name="RFC" value="9878"/> <author initials="C." surname="Holmberg" fullname="Christer Holmberg"> <organization>Ericsson</organization> <address> <postal> <street>Hirsalantie 11</street> <city>Jorvas</city> <code>02420</code> <country>Finland</country> </postal><phone/><email>christer.holmberg@ericsson.com</email><uri/></address> </author> <author initials="N." surname="Biondic" fullname="Nevenka Biondic"> <organization>Ericsson</organization> <address> <postal> <street>Krapinska 45</street> <city>Zagreb</city> <code>10002</code> <country>Croatia</country> </postal><phone/><email>nevenka.biondic.ext@ericsson.com</email><uri/></address> </author> <author initials="G." surname="Salgueiro" fullname="Gonzalo Salgueiro"> <organization>Cisco Systems, Inc.</organization> <address> <postal> <street>7200-12 Kit Creek Road</street> <city>Research Triangle Park</city><code>NC 27709</code><region>NC</region><code>27709</code> <country>United States of America</country> </postal><phone/><email>gsalguei@cisco.com</email><uri/></address> </author> <author initials="R." surname="Jesske" fullname="Roland Jesske"> <organization>Deutsche Telekom</organization> <address> <postal> <street>Telekom Allee 9</street> <city>Darmstadt</city> <code>64295</code> <country>Germany</country> </postal><phone/><email>r.jesske@telekom.de</email> <uri>www.telekom.com</uri> </address> </author> <dateyear="2025"/>year="2025" month="October"/> <area>ART</area> <workgroup>sipcore</workgroup><keyword>Internet-Draft</keyword><keyword>3GPP</keyword> <keyword>Visited</keyword> <keyword>ID</keyword> <abstract> <t> <!--[rfced] Abstract and Introduction: Please review if the first sentence conveys the intended meaning. Specifically, should "currently not allowed" be rephrased? This text is directly from RFC 7976, published in 2016. What is the subject of "not allowed"? It can be read as the requests and responses are not allowed. Based on "This specification allows some header fields to be present in messages where they were previously not allowed" (Section 5), we make the following suggestion. Original: The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315. Perhaps: 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. --> The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses. ThisDocumentdocument obsoletes RFC 7976. The changes related toRFC7976RFC 7976 involve the inclusion of the P-Visited-Network-ID header field in SIPresponses.</t><t>responses. </t> <!--[rfced] Abstract and Introduction: Please clarify "when RFC 3455 was updated and subsequently obsoleted by the publication of RFC 7315". In the RFC series, "updated" has a specific meaning, distinct from "obsoleted". RFC 3455 has not been updated by any other RFCs, so the original sentence is not accurate. We suggest simply "obsoleted" as follows. Please let us know if you prefer otherwise. Original: This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and subsequently obsoleted by the publication of RFC 7315. Perhaps: This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was obsoleted by RFC 7315. Or (if you prefer to explain): This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was obsoleted by RFC 7315, i.e., when the content of RFC 3455 was completely replaced. --> <t> This document also makes updates to RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and subsequently obsoleted by the publication of RFC 7315. </t> </abstract> </front> <middle><!-- ***************************************************************************************************** --><section anchor="intro" numbered="true" toc="default"> <name>Introduction</name> <t> The Third Generation Partnership Project (3GPP) has identified cases where different Session Initiation Protocol (SIP) <xref target="RFC3261" format="default"/> private header extensions referred to as "P-" header fields, and defined in <xref target="RFC7315" format="default"/>, need to be included in SIP requests and responses currently not allowed according to <xref target="RFC7315" format="default"/>. This document updates <xref target="RFC7315" format="default"/>, in order to allow inclusion of the affected "P-" header fields in such requests and responses.</t><t></t> <t> This document also makes updatesforto <xref target="RFC7315" format="default"/> in order to fix misalignments that occurred when <xref target="RFC3455" format="default"/> was updated and subsequently obsoleted by the publication of <xref target="RFC7315" format="default"/>. </t> </section> <sectionanchor="Misalingment_3GPP_Use_Cases"anchor="Misalignment_3GPP_Use_Cases" numbered="true" toc="default"> <name>Misalignments and 3GPP Use Cases</name> <section anchor="General" numbered="true" toc="default"> <name>General</name> <t> <xref target="RFC7315" format="default"/> containscontradictingcontradictory 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 inSection 5.7 of that RFC<xref target="RFC7315" section="5.7"/> are not aligned with the definitions and usage of the SIP "P-" header fields specified inSection 4.<xref target="RFC7315" section="4"/>. This section describes the misalignments that occurred when <xref target="RFC3455" format="default"/> was updated and subsequently obsoleted by the publication of <xref target="RFC7315" format="default"/>, and how they are fixed. </t> <!-- [rfced] Would you like the note in this document to be in an <aside> element, or remain as is? It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/rfcxml-vocabulary#aside). Original: NOTE: In the case of the P-Called-Party-ID header field, allowing it in PUBLISH requests was done deliberately in [RFC7315]. Therefore, it is not considered a misalignment. --> <t> 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"/>. Therefore, it is not considered a misalignment. </t> <t> Since <xref target="RFC7315" format="default"/> 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"/> in order to support the use cases. </t> <t>Section 3<xref target="Updates_to_RFC_7315"/> updates <xref target="RFC7315" format="default"/>, based on the misalignments and 3GPP use cases. </t> </section> <section anchor="Misalignments" numbered="true" toc="default"> <name>Misalignments</name> <t> The following updates are needed in order to fix the misalignments that occurred when <xref target="RFC3455" format="default"/> wasupdated and obsolatedobsoleted by <xref target="RFC7315" format="default"/>: </t><t> o P-Associated-URI:<ul spacing="normal"> <li>P-Associated-URI: Remove the statement that the header field can appear in the SIP REGISTERmethod. </t> <t> o P-Called-Party-ID:method.</li> <li>P-Called-Party-ID: Delete the statement that the P-Called-Party-ID header field can appear in SIP responses. Add a statement that the P-Called-Party-ID header field can appear in the SIP REFERmethod. </t> <t> o P-Access-Network-Info:method.</li> <li>P-Access-Network-Info: Add a statement that the P-Access-Network- Info header field can appear in SIPresponses. </t> <t> o P-Charging-Vector:responses.</li> <li>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 ACKmethod. </t> <t> o P-Charging-Function-Addresses:method.</li> <li>P-Charging-Function-Addresses: Add a statement that the P-Charging-Function-Addresses header field can appear in SIPresponses. </t> <t> Theresponses.</li> </ul> <t>The following update is needed in order to clarify the usage of the header compared to <xref target="RFC7315"format="default"/>: </t> <t> o P-Visited-Network-ID:format="default"/>:</t> <ul spacing="normal"> <li>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. </t>responses.</li> </ul> </section><!-- ***************************************************************************************************** --><section anchor="_GPP_Use_Cases" numbered="true" toc="default"> <name>3GPP Use Cases</name><!-- ***************************************************************************************************** --><section anchor="General_use_case" numbered="true" toc="default"> <name>General</name><t> The<t>The following updates are needed in order to implement the 3GPP usecases: </t> <t> o P-Access-Network-Info:cases:</t> <ul spacing="normal"> <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 2xxresponse. </t> <t> o P-Charging-Vector:response.</li> <li>P-Charging-Vector: Add statement that the P-Charging-Vector header field can appear in the SIP ACK method when triggered by a SIP 2xxresponse. </t> <t> Thisresponse.</li> </ul> <t>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"/>. </t>format="default"/>.</t> </section><!-- ***************************************************************************************************** --><section anchor="P-Access-Network-Info" numbered="true" toc="default"> <name>P-Access-Network-Info</name> <t> 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"/>. </t> <t> 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"/>. Based on operator policy, roamingagreementagreement, or both, the local time of the visited network may be included. </t><t> The<!--[rfced] To prevent misreading this sentence (i.e., "the NPLI needs to be stored as the location of the user"), may we add a comma as follows? Original: 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. Suggested: 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. --> <t>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 beprovided: </t> <t> o whenprovided:</t> <ul spacing="normal"> <li>when the bearer establishment is triggered,or </t> <t> o ator</li> <li>at session release when the bearer deactivation is triggered,or </t> <t> o whenor</li> <li>when the bearer modification is triggered, e.g., a QoS modification for the use of a newly negotiatedcodec. </t>codec.</li> </ul> <!--[rfced] We suggest adding articles ('the' and 'a') as follows; please let us know if this is acceptable. (We note that RFC 7976 did not use articles in similar text, but 'a SIP 2xx response' appears in other RFCs.) Original: ... within SIP 2xx response to the SIP INVITE request. Perhaps: ... within the SIP 2xx response to the SIP INVITE request. Original: Upon reception of the SDP answer within SIP 2xx response .. Perhaps: Upon reception of the SDP answer within a SIP 2xx response ... --> <t> In some scenarios, the bearer modification may be triggered by the proxy upon reception of a Session Description Protocol (SDP) answer within SIP 2xx response to the SIP INVITE request. In such case, the NPLI needs to be provided within the SIP ACK request. However, <xref target="RFC7315" format="default"/> does not allow the usage of the P-Access-Network-Info header field in a SIP ACK request. </t> <t> Upon reception of the SDP answer within SIP 2xx response on the SIP INVITE request, a proxy may initiate procedures to obtain the NPLI and may include the P-Access-Network-Info header field with the NPLI in the SIP ACK request. </t> <t> 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="default"> <name>P-Charging-Vector</name> <t> <xref target="RFC7315" format="default"/> 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> 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> 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"/> does not allow the usage of the P-Charging-Vector header field in the SIP ACK request. </t> <t> 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> <!--[rfced] non-2xx response vs. SIP non-2xx respsonse In other instances in this document, "SIP" does not appear before "non-2xx repsonse"; may it be removed here, or is it necessary? Original: The P-Charging-Vector header field shall not be included in SIP ACK requests triggered by SIP non-2xx responses. Perhaps (to match usage in Sections 2.3.2 and 3): The P-Charging-Vector header field shall not be included in SIP ACK requests triggered by non-2xx responses. --> <t> The P-Charging-Vector header field shall not be included in SIP ACK requests triggered 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 sectionimplementscontains the update toSection 5.7 of<xref target="RFC7315"format="default"/>,section="5.7"/>, in order to implement the misalignment fixes and the 3GPP requirements described inSection 2. </t> <t> Old text:<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 2xxresonses. </t> <t>resonses [sic]. The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all responses.</t> <t>The P-Visited-Network-ID header field can appear in all SIP methods except ACK, BYE, and CANCEL and all responses.</t> <t>TheThe P-Access-Network-Info header field can appear in all SIP methods except ACK and CANCEL.</t> <t>TheThe P-Charging-Vector header field can appear in all SIP methods except CANCEL.</t> <t>TheThe P-Charging-Function-Addresses header field can appear in all SIP methods except ACK and CANCEL. </t><t> New text: </t> <t> The</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>NoThis document has no IANAConsiderations.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" format="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-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 inSection 6.4 of<xref target="RFC7315"format="default"/>.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 inSection 6.3 of<xref target="RFC7315"format="default"/>.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 document are already defined <xref target="TS24.229" format="default"/>, the updates are not seen to cause backward-compatibility concerns. </t></section><!-- ***************************************************************************************************** --> <!-- ***************************************************************************************************** --></section> <section numbered="true" toc="default"> <name>Changes sinceRFC7976</name>RFC 7976</name> <t> The changes related toRFC7976RFC 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> <section numbered="true" toc="default"> <name>Acknowledgments</name><t> The<t>The author would like to acknowledge the constructive feedback provided byMichael Kreipl, Charles Eckel and Paul Kyzivat Thanks to Paul Kyzivat, Jean Mahoney, Ben Campbell, and Adam Roach<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 onthe formeran earlier draft version ofthethis document. </t> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name><reference anchor="RFC3261" target="https://www.rfc-editor.org/info/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>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"> <front> <title>Private Header (P-Header) Extensions to<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7315.xml"/> <!-- [rfced] FYI, we updated theSession Initiation Protocol (SIP) for3GPP reference titles to match the3GPP</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>This document describes a set of private header (P-header) Session Initiation Protocol (SIP) fields usedtitles provided bythe 3GPP, along with their applicability, which is limited3GPP. We have also added URLs that point toparticular environments. The P-header fields arethe specific version usedfor a variety of purposes withinin thenetworks thatreferences. Please review. We note thepartners implement, including chargingversion referenced in this document is from 2016 andinformation aboutthere have been several updates over thenetworksyears. Would you like to update this reference to acall 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"> <front> <title>3rd Generation Partnership Project;more current version? Or would you like these references to point to the 3GPP TechnicalSpecification Group Core NetworkSpecifications 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) andTerminals;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/archive/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> <seriesInfoname="TS"name="3GPP TS" value="23.228"/><seriesInfo name="V" value="13.6.0"/><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) <referenceanchor="TS24.229">anchor="TS23.228" target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=821"> <front><title>3rd<title>IP Multimedia Subsystem (IMS); Stage 2 </title> <author> <organization abbrev="3GPP"> 3rd Generation PartnershipProject; Technical Specification Group Core Network and Terminals; IPProject </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"> <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"> 3rd Generation Partnership Project </organization> </author><date month="June" year="2016"/></front> <seriesInfoname="TS"name="3GPP TS" value="24.229"/><seriesInfo name="V" value="13.6.0"/></reference></references> <references> <name>Informative References</name>--> <referenceanchor="RFC3455" target="https://www.rfc-editor.org/info/rfc3455">anchor="TS24.229" target="https://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-d60.zip"> <front><title>Private Header (P-Header) Extensions to the<title>IP multimedia call control protocol based on 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>This document describes a set of privateand SessionInitiationDescription Protocol(SIP) headers (P-headers) used by the 3rd-Generation(SDP); Stage 3 </title> <author> <organization abbrev="3GPP"> 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></organization> </author> <date month="June" year="2016"/> </front> <seriesInfoname="RFC" value="3455"/> <seriesInfo name="DOI" value="10.17487/RFC3455"/>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.3455.xml"/> </references> </references></back></rfc></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>