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