GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7976

Internet Engineering Task Force (IETF) C. Holmberg Request for Comments: 7976 N. Biondic Updates: 7315 Ericsson Category: Informational G. Salgueiro ISSN: 2070-1721 Cisco

                                                        September 2016
        Updates to Private Header (P-Header) Extension Usage
    in Session Initiation Protocol (SIP) Requests and Responses

Abstract

 The Third Generation Partnership Project (3GPP) has identified cases
 where different SIP private header extensions referred to as "P-"
 header fields, and defined in RFC 7315, need to be included in SIP
 requests and responses currently not allowed according to RFC 7315.
 This document updates RFC 7315, in order to allow inclusion of the
 affected "P-" header fields in such requests and responses.
 This document also makes updates for RFC 7315 in order to fix
 misalignments that occurred when RFC 3455 was updated and obsoleted
 by RFC 7315.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7976.

Holmberg, et al. Informational [Page 1] RFC 7976 Updates to P-Header Usage September 2016

Copyright Notice

 Copyright (c) 2016 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
 2.  Misalignments and 3GPP Use Cases  . . . . . . . . . . . . . .   3
   2.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.2.  Misalignments . . . . . . . . . . . . . . . . . . . . . .   3
   2.3.  3GPP Use Cases  . . . . . . . . . . . . . . . . . . . . .   4
     2.3.1.  General . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.2.  P-Access-Network-Info . . . . . . . . . . . . . . . .   4
     2.3.3.  P-Charging-Vector . . . . . . . . . . . . . . . . . .   5
 3.  Updates to RFC 7315 . . . . . . . . . . . . . . . . . . . . .   6
 4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
 5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
   5.2.  Informative References  . . . . . . . . . . . . . . . . .   8
 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction

 The Third Generation Partnership Project (3GPP) has identified cases
 where different Session Initiation Protocol (SIP) [RFC3261] private
 header extensions referred to as "P-" header fields, and defined in
 [RFC7315], need to be included in SIP requests and responses
 currently not allowed according to RFC 7315.  This document updates
 RFC 7315, in order to allow inclusion of the affected "P-" header
 fields in such requests and responses.
 This document also makes updates for RFC 7315 in order to fix
 misalignments that occurred when RFC 3455 [RFC3455] was updated and
 obsoleted by RFC 7315.

Holmberg, et al. Informational [Page 2] RFC 7976 Updates to P-Header Usage September 2016

 As the "P-" header fields are mainly used in (and in most cases, only
 defined for) networks defined by the 3GPP, where the updates defined
 in this document are already defined [TS.3GPP.24.229], the updates
 are not seen to cause backward-compatibility concerns.

2. Misalignments and 3GPP Use Cases

2.1. General

 RFC 7315 contains contradicting statements regarding the usage of SIP
 "P-" header fields in SIP requests and responses, which leave the
 presence of the SIP "P-" header fields in the SIP requests and
 responses open to interpretation and different implementations.
 Statements in Section 5.7 of that RFC are not aligned with the
 definitions and usage of the SIP "P-" header fields specified in
 Section 4.  This section describes the misalignments that occurred
 when RFC 3455 was updated and obsoleted by RFC 7315, and how they are
 fixed.
 NOTE: In the case of the P-Called-Party-ID header field, allowing it
 in PUBLISH requests was deliberately done in RFC 7315.  Therefore, it
 is not considered a misalignment.
 Since RFC 7315 was published, 3GPP defined new use cases that require
 the RFC to be updated.  This section describes the 3GPP use cases
 behind the updates, and the updates needed to RFC 7315 in order to
 support the use cases.
 Section 3 updates RFC 7315, based on the misalignments and 3GPP use
 cases.

2.2. Misalignments

 The following updates are needed in order to fix the misalignments
 between RFCs 7315 and 3455:
 o  P-Associated-URI: Remove the statement that the header field can
    appear in the SIP REGISTER method.
 o  P-Called-Party-ID: Delete the statement that the P-Called-Party-ID
    header field can appear in SIP responses.  Add a statement that
    the P-Called-Party-ID header field can appear in the SIP REFER
    method.
 o  P-Visited-Network-ID: Delete the statement that the P-Visited-
    Network-ID header field can appear in SIP responses.  Add a
    statement that the P-Visited-Network-ID header field cannot appear
    in the SIP NOTIFY, PRACK, INFO, and UPDATE methods.

Holmberg, et al. Informational [Page 3] RFC 7976 Updates to P-Header Usage September 2016

 o  P-Access-Network-Info: Add a statement that the P-Access-Network-
    Info header field can appear in SIP responses.
 o  P-Charging-Vector: Add a statement that the P-Charging-Vector
    header field can appear in SIP responses.  Add a statement that
    the P-Charging-Vector header field cannot appear in the SIP ACK
    method.
 o  P-Charging-Function-Addresses: Add a statement that the
    P-Charging-Function-Addresses header field can appear in SIP
    responses.

2.3. 3GPP Use Cases

2.3.1. General

 The following updates are needed in order to implement the 3GPP use
 cases:
 o  P-Access-Network-Info: Add statement that the P-Access-Network-
    Info header field can appear in the SIP ACK method when triggered
    by a SIP 2xx response.
 o  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.
 This following sections describe, for individual "P-" header fields,
 the 3GPP use cases that are the basis for the updates.  The use cases
 are based on the procedures defined in [TS.3GPP.24.229].

2.3.2. P-Access-Network-Info

 The P-Access-Network-Info header field may contain the Network
 Provided Location Information (NPLI).  The NPLI is described in
 [TS.3GPP.23.228].
 A proxy in possession of appropriate information about the access
 technology might insert a P-Access-Network-Info header field with its
 own values.  Such values are identified by the string "network-
 provided" defined in RFC 7315.  Based on operator policy and/or
 roaming agreement, the local time of the visited network may be
 included.
 The Call Data Records (CDRs) generated within the IP Multimedia
 Subsystem (IMS) have to contain the NPLI in order to guarantee
 correct billing.  When an IMS session is modified, the NPLI also
 needs to be stored as the location of the user at the time when the

Holmberg, et al. Informational [Page 4] RFC 7976 Updates to P-Header Usage September 2016

 session is modified may generate a charging event.  In case of a
 session modification event at IMS, the NPLI needs to be provided:
 o  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 for the use of a newly negotiated codec.
 In some scenarios, the bearer modification may be triggered by the
 proxy upon reception of a Session Description Protocol (SDP) answer
 within SIP 2xx response to the SIP INVITE request.  In such case, the
 NPLI needs to be provided within the SIP ACK request.  However, RFC
 7315 does not allow the usage of the P-Access-Network-Info header
 field in SIP ACK request.
 Upon reception of the SDP answer within SIP 2xx response on the SIP
 INVITE request, a proxy may initiate procedures to obtain the NPLI
 and may include the P-Access-Network-Info header field with the NPLI
 in the SIP ACK request.
 The P-Access-Network-Info header field shall not be included in SIP
 ACK requests triggered by non-2xx responses.

2.3.3. P-Charging-Vector

 RFC 7315 defines an Inter Operator Identifier (IOI) to enable
 different operators involved in a SIP dialog or a transaction outside
 a dialog to identify each other by exchanging operator identification
 information within the P-Charging-Vector header field.
 In the interconnection scenarios in multi-operator environments,
 where one or more transit operators are between the originating and
 terminating operator, the identities of the involved transit
 operators are represented by a transit-ioi parameter of the
 P-Charging-Vector header field.
 Transit operators can be selected independently for each SIP method
 and direction of request.  A transit network will only have knowledge
 of an individual SIP request, and transit network selection will be
 an independent decision for each request and could be made based on
 load, cost, percentage, time of day, and other factors.  For this
 reason, it is necessary that the P-Charging-Vector header field,
 which carries the transit IOI information, is included in each SIP
 request and response.  However, RFC 7315 does not allow the usage of
 the P-Charging-Vector header field in the SIP ACK request.

Holmberg, et al. Informational [Page 5] RFC 7976 Updates to P-Header Usage September 2016

 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.
 The P-Charging-Vector header field shall not be included in SIP ACK
 requests triggered by SIP non-2xx responses.

3. Updates to RFC 7315

 This section implements the update to Section 5.7 of RFC 7315, in
 order to implement the misalignment fixes and the 3GPP requirements
 described in Section 2.
 Old text:
 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.
 New text:
 The P-Associated-URI header field can appear in SIP REGISTER 2xx
 responses.  The P-Called-Party-ID header field can appear in the SIP
 INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods.  The
 P-Visited-Network-ID header field can appear in all SIP methods
 except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO, and UPDATE.  The
 P-Access-Network-Info header field can appear in all SIP methods and
 non-100 responses, except in CANCEL methods, CANCEL responses, and
 ACK methods triggered by non-2xx responses.  The P-Charging-Vector
 header field can appear in all SIP methods and non-100 responses,
 except in CANCEL methods, CANCEL responses, and ACK methods triggered
 by non-2xx responses.  The P-Charging-Function-Addresses header field
 can appear in all SIP methods and non-100 responses, except in CANCEL
 methods, CANCEL responses, and ACK methods.

Holmberg, et al. Informational [Page 6] RFC 7976 Updates to P-Header Usage September 2016

4. Security Considerations

 The security considerations for these "P-" header fields are defined
 in [RFC7315].  This specification allows some header fields to be
 present in messages where they were previously not allowed, and the
 security considerations and assumptions described in [RFC7315] (e.g.,
 regarding only sending information to trusted entities) also apply to
 those messages.  In addition, this specification also disallows some
 header fields to be present in messages where they were previously
 allowed.  That does not cause any security issues, but implementors
 need to be aware that implementations may not have been updated
 according to this document, and take proper actions if a header field
 occurs, or does not occur, in a message where it should occur (or
 occurs in a message where it should not occur).  This document adds
 the ability to include P-Access-Network-Info in ACK requests.  As
 documented in [RFC7315], P-Access-Network-Info may include privacy
 sensitive information, including the user's location.  The security
 and privacy considerations for P-Access-Network-Info in ACK requests
 are similar to those for the other SIP requests discussed in
 [RFC7315].

5. References

5.1. Normative References

 [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
            A., Peterson, J., Sparks, R., Handley, M., and E.
            Schooler, "SIP: Session Initiation Protocol", RFC 3261,
            DOI 10.17487/RFC3261, June 2002,
            <http://www.rfc-editor.org/info/rfc3261>.
 [RFC7315]  Jesske, R., Drage, K., and C. Holmberg, "Private Header
            (P-Header) Extensions to the Session Initiation Protocol
            (SIP) for the 3GPP", RFC 7315, DOI 10.17487/RFC7315, July
            2014, <http://www.rfc-editor.org/info/rfc7315>.
 [TS.3GPP.23.228]
            3GPP, "IP multimedia call control protocol based on
            Session Initiation Protocol (SIP) and Session Description
            Protocol (SDP); Stage 3", 3GPP TS 23.228 13.6.0, June
            2016, <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
 [TS.3GPP.24.229]
            3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP
            TS 24.229 13.6.0, June 2016,
            <http://www.3gpp.org/ftp/Specs/html-info/24229.htm>.

Holmberg, et al. Informational [Page 7] RFC 7976 Updates to P-Header Usage September 2016

5.2. Informative References

 [RFC3455]  Garcia-Martin, M., Henrikson, E., and D. Mills, "Private
            Header (P-Header) Extensions to the Session Initiation
            Protocol (SIP) for the 3rd-Generation Partnership Project
            (3GPP)", RFC 3455, DOI 10.17487/RFC3455, January 2003,
            <http://www.rfc-editor.org/info/rfc3455>.

Acknowledgments

 Thanks to Paul Kyzivat, Jean Mahoney, Ben Campbell, and Adam Roach
 for providing comments on the document.

Authors' Addresses

 Christer Holmberg
 Ericsson
 Hirsalantie 11
 Jorvas  02420
 Finland
 Email: christer.holmberg@ericsson.com
 Nevenka Biondic
 Ericsson
 Krapinska 45
 Zagreb  10002
 Croatia
 Email: nevenka.biondic@ericsson.com
 Gonzalo Salgueiro
 Cisco Systems, Inc.
 7200-12 Kit Creek Road
 Research Triangle Park, NC  27709
 United States of America
 Email: gsalguei@cisco.com

Holmberg, et al. Informational [Page 8]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7976.txt · Last modified: 2016/09/19 21:33 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki