rfc9878.original | rfc9878.txt | |||
---|---|---|---|---|
sipcore C. Holmberg | Internet Engineering Task Force (IETF) C. Holmberg | |||
Internet-Draft N. Biondic | Request for Comments: 9878 N. Biondic | |||
Obsoletes: 7976 (if approved) Ericsson | Obsoletes: 7976 Ericsson | |||
Updates: 7315 (if approved) G. Salgueiro | Updates: 7315 G. Salgueiro | |||
Intended status: Informational Cisco Systems, Inc. | Category: Informational Cisco Systems, Inc. | |||
Expires: 20 February 2026 R. Jesske | ISSN: 2070-1721 R. Jesske | |||
Deutsche Telekom | Deutsche Telekom | |||
19 August 2025 | October 2025 | |||
Updates to Private Header (P-Header) Extension Usage in Session | Updates to Private Header (P-Header) Extension Usage in Session | |||
Initiation Protocol (SIP) Requests and Responses | Initiation Protocol (SIP) Requests and Responses | |||
draft-ietf-sipcore-rfc7976bis-04.txt | ||||
Abstract | Abstract | |||
The Third Generation Partnership Project (3GPP) has identified cases | The Third Generation Partnership Project (3GPP) has identified cases | |||
where different SIP private header extensions referred to as "P-" | where different SIP private header extensions referred to as "P-" | |||
header fields, and defined in RFC 7315, need to be included in SIP | header fields, and defined in RFC 7315, need to be included in SIP | |||
requests and responses currently not allowed according to RFC 7315. | requests and responses currently not allowed according to RFC 7315. | |||
This document updates RFC 7315, in order to allow inclusion of the | This document updates RFC 7315, in order to allow inclusion of the | |||
affected "P-" header fields in such requests and responses. This | affected "P-" header fields in such requests and responses. This | |||
Document obsoletes RFC 7976. The changes related to RFC7976 involve | document obsoletes RFC 7976. The changes related to RFC 7976 involve | |||
the inclusion of the P-Visited-Network-ID header field in SIP | the inclusion of the P-Visited-Network-ID header field in SIP | |||
responses. | responses. | |||
This document also makes updates for RFC 7315 in order to fix | This document also makes updates to RFC 7315 in order to fix | |||
misalignments that occurred when RFC 3455 was updated and | misalignments that occurred when RFC 3455 was updated and | |||
subsequently obsoleted by the publication of RFC 7315. | subsequently obsoleted by the publication of RFC 7315. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This document is not an Internet Standards Track specification; it is | |||
provisions of BCP 78 and BCP 79. | published for informational purposes. | |||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | 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. | ||||
This Internet-Draft will expire on 20 February 2026. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
https://www.rfc-editor.org/info/rfc9878. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2025 IETF Trust and the persons identified as the | Copyright (c) 2025 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
extracted from this document must include Revised BSD License text as | to this document. Code Components extracted from this document must | |||
described in Section 4.e of the Trust Legal Provisions and are | include Revised BSD License text as described in Section 4.e of the | |||
provided without warranty as described in the Revised BSD License. | Trust Legal Provisions and are provided without warranty as described | |||
in the Revised BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction | |||
2. Misalignments and 3GPP Use Cases . . . . . . . . . . . . . . 3 | 2. Misalignments and 3GPP Use Cases | |||
2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. General | |||
2.2. Misalignments . . . . . . . . . . . . . . . . . . . . . . 3 | 2.2. Misalignments | |||
2.3. 3GPP Use Cases . . . . . . . . . . . . . . . . . . . . . 4 | 2.3. 3GPP Use Cases | |||
2.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.3.1. General | |||
2.3.2. P-Access-Network-Info . . . . . . . . . . . . . . . . 4 | 2.3.2. P-Access-Network-Info | |||
2.3.3. P-Charging-Vector . . . . . . . . . . . . . . . . . . 5 | 2.3.3. P-Charging-Vector | |||
3. Updates to RFC 7315 . . . . . . . . . . . . . . . . . . . . . 6 | 3. Updates to RFC 7315 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 4. IANA Considerations | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 5. Security Considerations | |||
6. Operational considerations . . . . . . . . . . . . . . . . . 7 | 6. Operational considerations | |||
7. Changes since RFC7976 . . . . . . . . . . . . . . . . . . . . 7 | 7. Changes since RFC 7976 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 | 8. Acknowledgments | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 9. References | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 | 9.1. Normative References | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 8 | 9.2. Informative References | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
The Third Generation Partnership Project (3GPP) has identified cases | The Third Generation Partnership Project (3GPP) has identified cases | |||
where different Session Initiation Protocol (SIP) [RFC3261] private | where different Session Initiation Protocol (SIP) [RFC3261] private | |||
header extensions referred to as "P-" header fields, and defined in | header extensions referred to as "P-" header fields, and defined in | |||
[RFC7315], need to be included in SIP requests and responses | [RFC7315], need to be included in SIP requests and responses | |||
currently not allowed according to [RFC7315]. This document updates | currently not allowed according to [RFC7315]. This document updates | |||
[RFC7315], in order to allow inclusion of the affected "P-" header | [RFC7315], in order to allow inclusion of the affected "P-" header | |||
fields in such requests and responses. | fields in such requests and responses. | |||
This document also makes updates for [RFC7315] in order to fix | This document also makes updates to [RFC7315] in order to fix | |||
misalignments that occurred when [RFC3455] was updated and | misalignments that occurred when [RFC3455] was updated and | |||
subsequently obsoleted by the publication of [RFC7315]. | subsequently obsoleted by the publication of [RFC7315]. | |||
2. Misalignments and 3GPP Use Cases | 2. Misalignments and 3GPP Use Cases | |||
2.1. General | 2.1. General | |||
[RFC7315] contains contradicting statements regarding the usage of | [RFC7315] contains contradictory statements regarding the usage of | |||
SIP "P-" header fields in SIP requests and responses, which leave the | SIP "P-" header fields in SIP requests and responses, which leave the | |||
presence of the SIP "P-" header fields in the SIP requests and | presence of the SIP "P-" header fields in the SIP requests and | |||
responses open to interpretation and different implementations. | responses open to interpretation and different implementations. | |||
Statements in Section 5.7 of that RFC are not aligned with the | Statements in Section 5.7 of [RFC7315] are not aligned with the | |||
definitions and usage of the SIP "P-" header fields specified in | definitions and usage of the SIP "P-" header fields specified in | |||
Section 4. This section describes the misalignments that occurred | Section 4 of [RFC7315]. This section describes the misalignments | |||
when [RFC3455] was updated and subsequently obsoleted by the | that occurred when [RFC3455] was updated and subsequently obsoleted | |||
publication of [RFC7315], and how they are fixed. | by the publication of [RFC7315], and how they are fixed. | |||
NOTE: In the case of the P-Called-Party-ID header field, allowing it | NOTE: In the case of the P-Called-Party-ID header field, allowing it | |||
in PUBLISH requests was done deliberately in [RFC7315]. Therefore, | in PUBLISH requests was done deliberately in [RFC7315]. Therefore, | |||
it is not considered a misalignment. | it is not considered a misalignment. | |||
Since [RFC7315] was published, 3GPP defined new use cases that | Since [RFC7315] was published, 3GPP defined new use cases that | |||
require the RFC to be updated. This section describes the 3GPP use | require the RFC to be updated. This section describes the 3GPP use | |||
cases behind the updates, and the updates needed to [RFC7315] in | cases behind the updates, and the updates needed to [RFC7315] in | |||
order to support the use cases. | order to support the use cases. | |||
Section 3 updates [RFC7315], based on the misalignments and 3GPP use | Section 3 updates [RFC7315], based on the misalignments and 3GPP use | |||
cases. | cases. | |||
2.2. Misalignments | 2.2. Misalignments | |||
The following updates are needed in order to fix the misalignments | The following updates are needed in order to fix the misalignments | |||
that occurred when [RFC3455] was updated and obsolated by [RFC7315]: | that occurred when [RFC3455] was obsoleted by [RFC7315]: | |||
o P-Associated-URI: Remove the statement that the header field can | * P-Associated-URI: Remove the statement that the header field can | |||
appear in the SIP REGISTER method. | appear in the SIP REGISTER method. | |||
o P-Called-Party-ID: Delete the statement that the P-Called-Party-ID | * 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 | header field can appear in SIP responses. Add a statement that | |||
P-Called-Party-ID header field can appear in the SIP REFER method. | the P-Called-Party-ID header field can appear in the SIP REFER | |||
method. | ||||
o P-Access-Network-Info: Add a statement that the P-Access-Network- | * P-Access-Network-Info: Add a statement that the P-Access-Network- | |||
Info header field can appear in SIP responses. | Info header field can appear in SIP responses. | |||
o P-Charging-Vector: Add a statement that the P-Charging-Vector | * P-Charging-Vector: Add a statement that the P-Charging-Vector | |||
header field can appear in SIP responses. Add a statement that the | header field can appear in SIP responses. Add a statement that | |||
P-Charging-Vector header field cannot appear in the SIP ACK method. | the P-Charging-Vector header field cannot appear in the SIP ACK | |||
method. | ||||
o P-Charging-Function-Addresses: Add a statement that the P-Charging- | * P-Charging-Function-Addresses: Add a statement that the P- | |||
Function-Addresses header field can appear in SIP responses. | Charging-Function-Addresses header field can appear in SIP | |||
responses. | ||||
The following update is needed in order to clarify the usage of the | The following update is needed in order to clarify the usage of the | |||
header compared to [RFC7315]: | header compared to [RFC7315]: | |||
o P-Visited-Network-ID: Add a statement that the P-Visited-Network-ID | * P-Visited-Network-ID: Add a statement that the P-Visited-Network- | |||
header field cannot appear in the SIP NOTIFY, PRACK, INFO, and UPDATE | ID header field cannot appear in the SIP NOTIFY, PRACK, INFO, and | |||
methods. Add statement that the P-Visited-Network-ID header field | UPDATE methods. Add statement that the P-Visited-Network-ID | |||
can appear in all non-100 (Trying) responses. | header field can appear in all non-100 (Trying) responses. | |||
2.3. 3GPP Use Cases | 2.3. 3GPP Use Cases | |||
2.3.1. General | 2.3.1. General | |||
The following updates are needed in order to implement the 3GPP use | The following updates are needed in order to implement the 3GPP use | |||
cases: | cases: | |||
o P-Access-Network-Info: Add statement that the P-Access-Network- | * P-Access-Network-Info: Add statement that the P-Access-Network- | |||
Info header field can appear in the SIP ACK method when triggered by | Info header field can appear in the SIP ACK method when triggered | |||
a SIP 2xx response. | by a SIP 2xx response. | |||
o P-Charging-Vector: Add statement that the P-Charging-Vector header | * 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 | field can appear in the SIP ACK method when triggered by a SIP 2xx | |||
response. | response. | |||
This following sections describe, for individual "P-" header fields, | This following sections describe, for individual "P-" header fields, | |||
the 3GPP use cases that are the basis for the updates. The use cases | the 3GPP use cases that are the basis for the updates. The use cases | |||
are based on the procedures defined in [TS24.229]. | are based on the procedures defined in [TS24.229]. | |||
2.3.2. P-Access-Network-Info | 2.3.2. P-Access-Network-Info | |||
The P-Access-Network-Info header field may contain the Network | The P-Access-Network-Info header field may contain the Network | |||
Provided Location Information (NPLI). The NPLI is described in | Provided Location Information (NPLI). The NPLI is described in | |||
[TS23.228]. | [TS23.228]. | |||
A proxy in possession of appropriate information about the access | A proxy in possession of appropriate information about the access | |||
technology might insert a P-Access-Network-Info header field with its | technology might insert a P-Access-Network-Info header field with its | |||
own values. Such values are identified by the string "network- | own values. Such values are identified by the string "network- | |||
provided" defined in [RFC7315]. Based on operator policy, roaming | provided" defined in [RFC7315]. Based on operator policy, roaming | |||
agreement or both, the local time of the visited network may be | agreement, or both, the local time of the visited network may be | |||
included. | included. | |||
The Call Data Records (CDRs) generated within the IP Multimedia | The Call Data Records (CDRs) generated within the IP Multimedia | |||
Subsystem (IMS) have to contain the NPLI in order to guarantee | Subsystem (IMS) have to contain the NPLI in order to guarantee | |||
correct billing. When an IMS session is modified, the NPLI also | 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 | 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 is modified may generate a charging event. In case of a | |||
session modification event at IMS, the NPLI needs to be provided: | session modification event at IMS, the NPLI needs to be provided: | |||
o when the bearer establishment is triggered, or | * when the bearer establishment is triggered, or | |||
o at session release when the bearer deactivation is triggered, or | ||||
o when the bearer modification is triggered, e.g., a QoS modification | * at session release when the bearer deactivation is triggered, or | |||
for the use of a newly negotiated codec. | ||||
* when the bearer modification is triggered, e.g., a QoS | ||||
modification for the use of a newly negotiated codec. | ||||
In some scenarios, the bearer modification may be triggered by the | In some scenarios, the bearer modification may be triggered by the | |||
proxy upon reception of a Session Description Protocol (SDP) answer | proxy upon reception of a Session Description Protocol (SDP) answer | |||
within SIP 2xx response to the SIP INVITE request. In such case, the | within SIP 2xx response to the SIP INVITE request. In such case, the | |||
NPLI needs to be provided within the SIP ACK request. However, | NPLI needs to be provided within the SIP ACK request. However, | |||
[RFC7315] does not allow the usage of the P-Access-Network-Info | [RFC7315] does not allow the usage of the P-Access-Network-Info | |||
header field in SIP ACK request. | header field in a SIP ACK request. | |||
Upon reception of the SDP answer within SIP 2xx response on the SIP | Upon reception of the SDP answer within SIP 2xx response on the SIP | |||
INVITE request, a proxy may initiate procedures to obtain the NPLI | INVITE request, a proxy may initiate procedures to obtain the NPLI | |||
and may include the P-Access-Network-Info header field with the NPLI | and may include the P-Access-Network-Info header field with the NPLI | |||
in the SIP ACK request. | in the SIP ACK request. | |||
The P-Access-Network-Info header field shall not be included in SIP | The P-Access-Network-Info header field shall not be included in SIP | |||
ACK requests triggered by non-2xx responses. | ACK requests triggered by non-2xx responses. | |||
2.3.3. P-Charging-Vector | 2.3.3. P-Charging-Vector | |||
skipping to change at page 6, line 10 ¶ | skipping to change at line 248 ¶ | |||
A SIP proxy that supports this extension and receives the SIP ACK | 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 may include a P-Charging-Vector header field in the SIP ACK | |||
request. | request. | |||
The P-Charging-Vector header field shall not be included in SIP ACK | The P-Charging-Vector header field shall not be included in SIP ACK | |||
requests triggered by SIP non-2xx responses. | requests triggered by SIP non-2xx responses. | |||
3. Updates to RFC 7315 | 3. Updates to RFC 7315 | |||
This section implements the update to Section 5.7 of [RFC7315], in | This section contains the update to Section 5.7 of [RFC7315], in | |||
order to implement the misalignment fixes and the 3GPP requirements | order to implement the misalignment fixes and the 3GPP requirements | |||
described in Section 2. | described in Section 2. | |||
Old text: | Old text: | |||
The P-Associated-URI header field can appear in SIP REGISTER method | | The P-Associated-URI header field can appear in SIP REGISTER | |||
and 2xx resonses. | | method and 2xx resonses [sic]. The P-Called-Party-ID header field | |||
| can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE | ||||
The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, | | methods and all responses. The P-Visited-Network-ID header field | |||
PUBLISH, SUBSCRIBE, and MESSAGE methods and all responses. | | can appear in all SIP methods except ACK, BYE, and CANCEL and all | |||
| responses. The P-Access-Network-Info header field can appear in | ||||
The P-Visited-Network-ID header field can appear in all SIP methods | | all SIP methods except ACK and CANCEL. The P-Charging-Vector | |||
except ACK, BYE, and CANCEL and all responses. | | header field can appear in all SIP methods except CANCEL. The P- | |||
| Charging-Function-Addresses header field can appear in all SIP | ||||
The P-Access-Network-Info header field can appear in all SIP methods | | methods except ACK and CANCEL. | |||
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. | ||||
New text: | New text: | |||
The P-Associated-URI header field can appear in SIP REGISTER 2xx | | The P-Associated-URI header field can appear in SIP REGISTER 2xx | |||
responses. | | responses. | |||
| | ||||
The P-Called-Party-ID header field can appear in the SIP INVITE, | | The P-Called-Party-ID header field can appear in the SIP INVITE, | |||
OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE requests. | | OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE requests. | |||
| | ||||
The P-Visited-Network-ID header field can appear in all SIP requests | | The P-Visited-Network-ID header field can appear in all SIP | |||
and the associated non-100 response message except in ACK, BYE, | | requests and the associated non-100 response message except in | |||
CANCEL, NOTIFY, PRACK, INFO, UPDATE. | | ACK, BYE, CANCEL, NOTIFY, PRACK, INFO, UPDATE. | |||
| | ||||
The P-Access-Network-Info header field can appear in all SIP requests | | The P-Access-Network-Info header field can appear in all SIP | |||
and the associated non-100 responses, except in CANCEL requests, | | requests and the associated non-100 responses, except in CANCEL | |||
CANCEL responses, and ACK methods triggered by non-2xx responses. | | requests, CANCEL responses, and ACK methods triggered by non-2xx | |||
| responses. | ||||
The P-Charging-Vector header field can appear in all SIP requests and | | | |||
the associated non-100 responses, except in CANCEL requests, CANCEL | | The P-Charging-Vector header field can appear in all SIP requests | |||
responses, and ACK requests triggered by non-2xx responses. | | and the associated non-100 responses, except in CANCEL requests, | |||
| CANCEL responses, and ACK requests triggered by non-2xx responses. | ||||
The P-Charging-Function-Addresses header field can appear in all SIP | | | |||
methods and the associated non-100 responses, except in CANCEL | | The P-Charging-Function-Addresses header field can appear in all | |||
requests, CANCEL responses, and ACK requests. | | SIP methods and the associated non-100 responses, except in CANCEL | |||
| requests, CANCEL responses, and ACK requests. | ||||
4. IANA Considerations | 4. IANA Considerations | |||
No IANA Considerations. | This document has no IANA actions. | |||
5. Security Considerations | 5. Security Considerations | |||
The security considerations for these "P-" header fields are defined | The security considerations for these "P-" header fields are defined | |||
in [RFC7315]. This specification allows some header fields to be | in [RFC7315]. This specification allows some header fields to be | |||
present in messages where they were previously not allowed, and the | present in messages where they were previously not allowed, and the | |||
security considerations and assumptions described in [RFC7315] (e.g., | security considerations and assumptions described in [RFC7315] (e.g., | |||
regarding only sending information to trusted entities) also apply to | regarding only sending information to trusted entities) also apply to | |||
those messages. In addition, this specification also disallows some | those messages. In addition, this specification also disallows some | |||
header fields to be present in messages where they were previously | header fields to be present in messages where they were previously | |||
skipping to change at page 7, line 43 ¶ | skipping to change at line 324 ¶ | |||
for the P-Visited-Network-ID header field are similar to those for | for the P-Visited-Network-ID header field are similar to those for | |||
the other SIP responses discussed in Section 6.3 of [RFC7315]. | the other SIP responses discussed in Section 6.3 of [RFC7315]. | |||
6. Operational considerations | 6. Operational considerations | |||
As the "P-" header fields are mainly used in (and in most cases, only | 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 | defined for) networks defined by the 3GPP, where the updates defined | |||
in this document are already defined [TS24.229], the updates are not | in this document are already defined [TS24.229], the updates are not | |||
seen to cause backward-compatibility concerns. | seen to cause backward-compatibility concerns. | |||
7. Changes since RFC7976 | 7. Changes since RFC 7976 | |||
The changes related to RFC7976 involve the inclusion of the P- | The changes related to RFC 7976 involve the inclusion of the P- | |||
Visited-Network-ID header field in SIP responses. Specifically, any | Visited-Network-ID header field in SIP responses. Specifically, any | |||
SIP response message, with the exception of a 100 (Trying) response, | SIP response message, with the exception of a 100 (Trying) response, | |||
may include a P-Visited-Network-ID header field. | may include a P-Visited-Network-ID header field. | |||
8. Acknowledgments | 8. Acknowledgments | |||
The author would like to acknowledge the constructive feedback | The author would like to acknowledge the constructive feedback | |||
provided by Michael Kreipl, Charles Eckel and Paul Kyzivat Thanks to | provided by Michael Kreipl, Charles Eckel, and Paul Kyzivat. | |||
Paul Kyzivat, Jean Mahoney, Ben Campbell, and Adam Roach for | ||||
providing comments on the former version of the document. | Thanks to Paul Kyzivat, Jean Mahoney, Ben Campbell, and Adam Roach | |||
for providing comments on an earlier draft version of this document. | ||||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, | [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, | |||
A., Peterson, J., Sparks, R., Handley, M., and E. | A., Peterson, J., Sparks, R., Handley, M., and E. | |||
Schooler, "SIP: Session Initiation Protocol", RFC 3261, | Schooler, "SIP: Session Initiation Protocol", RFC 3261, | |||
DOI 10.17487/RFC3261, June 2002, | DOI 10.17487/RFC3261, June 2002, | |||
<https://www.rfc-editor.org/info/rfc3261>. | <https://www.rfc-editor.org/info/rfc3261>. | |||
[RFC7315] Jesske, R., Drage, K., and C. Holmberg, "Private Header | [RFC7315] Jesske, R., Drage, K., and C. Holmberg, "Private Header | |||
(P-Header) Extensions to the Session Initiation Protocol | (P-Header) Extensions to the Session Initiation Protocol | |||
(SIP) for the 3GPP", RFC 7315, DOI 10.17487/RFC7315, July | (SIP) for the 3GPP", RFC 7315, DOI 10.17487/RFC7315, July | |||
2014, <https://www.rfc-editor.org/info/rfc7315>. | 2014, <https://www.rfc-editor.org/info/rfc7315>. | |||
[TS23.228] 3GPP, "3rd Generation Partnership Project; Technical | [TS23.228] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", Version | |||
Specification Group Core Network and Terminals; "IP | 13.6.0, Release 13, 3GPP TS 23.228, June 2016, | |||
multimedia call control protocol based on Session | <https://www.3gpp.org/ftp//Specs/ | |||
Initiation Protocol (SIP) and Session Description Protocol | archive/23_series/23.228/23228-g30.zip>. | |||
(SDP);", TS 23.228, V 13.6.0, June 2016. | ||||
[TS24.229] 3GPP, "3rd Generation Partnership Project; Technical | [TS24.229] 3GPP, "IP multimedia call control protocol based on | |||
Specification Group Core Network and Terminals; IP | Session Initiation Protocol (SIP) and Session Description | |||
multimedia call control protocol based on Session | Protocol (SDP); Stage 3", Version 13.6.0, Release 13, 3GPP | |||
Initiation Protocol (SIP) and Session Description Protocol | TS 24.229, June 2016, <https://www.3gpp.org/ftp/Specs/ | |||
(SDP); Stage 3", TS 24.229, V 13.6.0, June 2016. | archive/24_series/24.229/24229-d60.zip>. | |||
9.2. Informative References | 9.2. Informative References | |||
[RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private | [RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private | |||
Header (P-Header) Extensions to the Session Initiation | Header (P-Header) Extensions to the Session Initiation | |||
Protocol (SIP) for the 3rd-Generation Partnership Project | Protocol (SIP) for the 3rd-Generation Partnership Project | |||
(3GPP)", RFC 3455, DOI 10.17487/RFC3455, January 2003, | (3GPP)", RFC 3455, DOI 10.17487/RFC3455, January 2003, | |||
<https://www.rfc-editor.org/info/rfc3455>. | <https://www.rfc-editor.org/info/rfc3455>. | |||
Authors' Addresses | Authors' Addresses | |||
skipping to change at page 9, line 4 ¶ | skipping to change at line 374 ¶ | |||
9.2. Informative References | 9.2. Informative References | |||
[RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private | [RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private | |||
Header (P-Header) Extensions to the Session Initiation | Header (P-Header) Extensions to the Session Initiation | |||
Protocol (SIP) for the 3rd-Generation Partnership Project | Protocol (SIP) for the 3rd-Generation Partnership Project | |||
(3GPP)", RFC 3455, DOI 10.17487/RFC3455, January 2003, | (3GPP)", RFC 3455, DOI 10.17487/RFC3455, January 2003, | |||
<https://www.rfc-editor.org/info/rfc3455>. | <https://www.rfc-editor.org/info/rfc3455>. | |||
Authors' Addresses | Authors' Addresses | |||
Christer Holmberg | Christer Holmberg | |||
Ericsson | Ericsson | |||
Hirsalantie 11 | Hirsalantie 11 | |||
FI-02420 Jorvas | FI-02420 Jorvas | |||
Finland | Finland | |||
Email: christer.holmberg@ericsson.com | Email: christer.holmberg@ericsson.com | |||
Nevenka Biondic | Nevenka Biondic | |||
Ericsson | Ericsson | |||
Krapinska 45 | Krapinska 45 | |||
HR-10002 Zagreb | HR-10002 Zagreb | |||
Croatia | Croatia | |||
Email: nevenka.biondic.ext@ericsson.com | Email: nevenka.biondic.ext@ericsson.com | |||
Gonzalo Salgueiro | Gonzalo Salgueiro | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
7200-12 Kit Creek Road | 7200-12 Kit Creek Road | |||
Research Triangle Park, NC 27709 | Research Triangle Park, NC 27709 | |||
United States of America | United States of America | |||
Email: gsalguei@cisco.com | Email: gsalguei@cisco.com | |||
Roland Jesske | Roland Jesske | |||
Deutsche Telekom | Deutsche Telekom | |||
Telekom Allee 9 | Telekom Allee 9 | |||
64295 Darmstadt | 64295 Darmstadt | |||
Germany | Germany | |||
Email: r.jesske@telekom.de | Email: r.jesske@telekom.de | |||
URI: www.telekom.com | URI: www.telekom.com | |||
End of changes. 38 change blocks. | ||||
138 lines changed or deleted | 136 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |