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.