| Network Working Group | C. Holmberg |
| Internet-Draft | N. Biondic |
| Updates: 7315 (if approved) | Ericsson |
| Intended status: Informational | G. Salgueiro |
| Expires: June 20, 2016 | Cisco |
| December 18, 2015 |
RFC 7315 Updates
draft-holmberg-dispatch-rfc7315-updates-03
The 3rd-Generation Partnership Project 3GPP has identified cases where different SIP private header extensions referred to as P- header fields, 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.
In order to get a complete picture, this document also contains a set of errata that are to be filed against RFC 7315, in order to fix misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 20, 2016.
Copyright (c) 2015 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.
The 3rd-Generation Partnership Project (3GPP) has identified cases where different Session Initiation Protocol (SIP) [RFC3261] private header extensions referred to as P- header fields, defined in RFC 7315 [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.
In order to get a complete picture, this document also contains a set of errata that are to be filed against RFC 7315, in order to fix misalignments that occurred when RFC 3455 [RFC3455] was updated and obsoleted by RFC 7315.
This document updates RFC 7315 [RFC7315], by allowing the insertion of the P-Access-Network-Info header field in SIP ACK requests.
As the P- header fields are mainly used in (and in most cases, only defined for) networks defined by the 3rd-Generation Partnership Project (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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
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 are not aligned with the definitions and usage of the SIP P- header fields specified in section 4.
This section defines the errata that is to be submitted against RFC 7315. The scope of the errata is only alignment between RFC 3455 and RFC 7315.
NOTE: In the case of the P-Called-Party-ID header field, allowing it in PUBLISH requests was deliberately done in RFC 7315. It will therefore not be impacted by the errata.
The errata makes the following changes:
Old text:
The P-Associated-URI header field can appear in SIP REGISTER method
and 2xx resonses. 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
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 responses, except in ACK and CANCEL methods and CANCEL responses.
The P-Charging-Vector header field can appear in all SIP methods and
responses, except in ACK and CANCEL methods and CANCEL responses.
The P-Charging-Function-Addresses header field can appear in all
SIP methods and responses, except in ACK and CANCEL methods and
CANCEL responses.
This section updates section 5.7 of RFC 7315, based on requirements from 3GPP. This section contains the 3GPP use-cases behind the updates, and the suggested changes.
The P-Access-Network-Info header field may contain the Network provided Location information (NPLI). The Network Provided Location Information (NPLI) is described in 3GPP TS 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, local time of visited network may be included.
The CDRs generated within IMS have to contain the NPLI in order to guarantee correct billing. When an IMS Session is modified the NPLI also needs to be stored as the location of the user at the time when the session is modified may generate a charging event. In case of a session modification event at IMS, the NPLI needs to be provided:
In some scenarios, the bearer modification may be triggered by the proxy upon reception of an 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 a 3xx-6xx response.
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 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 more. 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 responses. However, RFC 7315 does not allow the usage of the P-Charging- Vector header field in SIP ACK request.
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 a 3xx-6xx response.
Note that the old text incorporates the fixes done by the errata described above.
The following updates are done:
Old text:
The P-Associated-URI header field can appear in SIP REGISTER
2xx responses. The P-Called-Party-ID header field can appear in
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 responses, except in ACK and CANCEL methods and CANCEL responses.
The P-Charging-Vector header field can appear in all SIP methods and
responses, except in ACK and CANCEL methods and CANCEL responses.
The P-Charging-Function-Addresses header field can appear in all
SIP methods and responses, except in ACK and CANCEL methods and
CANCEL responses.
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
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 responses, except in CANCEL methods and CANCEL responses.
The P-Charging-Vector header field can appear in all SIP methods and
responses, except in CANCEL methods and CANCEL responses. The
P-Charging-Function-Addresses header field can appear in all
SIP methods and responses, except in ACK and CANCEL methods
and CANCEL responses.
The security considerations for the P-Access-Network-Info header field are defined in [RFC7315]. The update defined in this document does not impact the security considerations.
This document makes no requests from IANA.
TBD
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-holmberg-dispatch-rfc7315-updates-02
Changes from draft-holmberg-dispatch-rfc7315-updates-01
Changes from draft-holmberg-dispatch-rfc7315-updates-00
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [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. |
| [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. |
| [TS.3GPP.24.229] | 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);Stage 3", 3GPP TS 24.229 13.3.1, September 2015. |
| [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. |