summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8606.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8606.txt')
-rw-r--r--doc/rfc/rfc8606.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc8606.txt b/doc/rfc/rfc8606.txt
new file mode 100644
index 0000000..5cbd264
--- /dev/null
+++ b/doc/rfc/rfc8606.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Jesske
+Request for Comments: 8606 Deutsche Telekom
+Updates: 3326 June 2019
+Category: Standards Track
+ISSN: 2070-1721
+
+
+ ISDN User Part (ISUP) Cause Location Parameter
+ for the SIP Reason Header Field
+
+Abstract
+
+ The SIP Reason header field is defined to carry ISUP (ISDN User Part)
+ cause values as well as SIP response codes. Some services in SIP
+ networks may need to know the ISUP location where the call was
+ released in the PSTN (Public Switched Telephone Network) to correctly
+ interpret the reason of release. This document updates RFC 3326 by
+ adding a location parameter for this purpose.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ 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). Further information on
+ Internet Standards is available in 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
+ https://www.rfc-editor.org/info/rfc8606.
+
+Copyright Notice
+
+ Copyright (c) 2019 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
+ (https://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.
+
+
+
+
+Jesske Standards Track [Page 1]
+
+RFC 8606 ISUP Release Location Parameter June 2019
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
+ 8.1. Registration of the Location Parameter for the Reason
+ Header Field . . . . . . . . . . . . . . . . . . . . . . 6
+ 9. Normative References . . . . . . . . . . . . . . . . . . . . 6
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
+
+1. Introduction
+
+ Section 3.4 of [RFC3326] describes a SIP message flow for canceling
+ an INVITE request when a REL (release) message is received from the
+ ISUP side. That document specifies the SIP Reason header field
+ [RFC3326] that is used to indicate the reason of release. The reason
+ of release indicates why a SIP Dialog or a PSTN call, in cases where
+ the call was interworked to the PSTN, was terminated. The
+ termination may be normal, based on a failure within an entity (e.g.
+ temporary failure) or caused by other factors (e.g., congestion).
+ The reason may be a SIP response or an ISUP release cause as
+ specified within [Q.850]. [RFC6432] specifies that an ISUP [Q.850]
+ cause code can be carried within a SIP response, but not the Q.850
+ location information. The [Q.850] location information identifies
+ the part of the ISUP network where the call was released.
+
+ This document adds a location value parameter to the reason-extension
+ parameter defined in [RFC3326] so that the [Q.850] location value can
+ be interworked from the PSTN. The interworking from the PSTN needs
+ only to include the location received by the interworking gateway.
+ [Q.850] describes the definitions of the cause code values and the
+ locations used in ISDN and DSS1 (Digital Subscriber Signalling System
+ No. 1) environments. The cause code is used for identifying the
+ reason of release of a call, and the location identifies where the
+ call was released.
+
+
+
+
+
+
+
+
+
+
+Jesske Standards Track [Page 2]
+
+RFC 8606 ISUP Release Location Parameter June 2019
+
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+3. Rationale
+
+ The primary intent of the parameter defined in this specification is
+ for use in IMS (IP Multimedia Subsystem) networks defined by 3GPP,
+ but it is also open to be used by any other networks that include
+ ISUP interworking gateways and use Q.850 reason codes. The purpose
+ of this parameter is to hold the location of the call release so that
+ it can be transported from the originating PSTN entity to the SIP
+ entity via a response or BYE message. The ISDN location is defined
+ in [Q.850].
+
+4. Mechanism
+
+ As defined by [RFC6432], any SIP Response message, with the exception
+ of 100 (Trying), MAY contain a Reason header field with a Q.850
+ [Q.850] cause code.
+
+ This specification adds a parameter with the ISUP location value
+ defined in [Q.850] to the Reason header field that identifies the
+ location of the call release in ISUP. The location is a 4-bit value
+ that reflects the possible locations where an ISUP call is released.
+ Some values are spare or reserved for national use. The Augmented
+ BNF (ABNF) [RFC5234] for this parameter is shown in Figure 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jesske Standards Track [Page 3]
+
+RFC 8606 ISUP Release Location Parameter June 2019
+
+
+ reason-extension =/ isup-cause-location
+ isup-cause-location = "location" EQUAL isup-location-value
+
+ isup-location-value =
+ "U" / ; for 0 0 0 0 user
+ "LPN" / ; for 0 0 0 1 private network serving the local user
+ "LN" / ; for 0 0 1 0 public network serving the local user
+ "TN" / ; for 0 0 1 1 transit network
+ "RLN" / ; for 0 1 0 0 public network serving the remote user
+ "RPN" / ; for 0 1 0 1 private network serving the remote user
+ "LOC-6" / ; for 0 1 1 0 spare
+ "INTL" / ; for 0 1 1 1 international network
+ "LOC-8" / ; for 1 0 0 0 spare
+ "LOC-9" / ; for 1 0 0 1 spare
+ "BI" / ; for 1 0 1 0 network beyond interworking point
+ "LOC-11" / ; for 1 0 1 1 spare
+ "LOC-12" / ; for 1 1 0 0 reserved for national use
+ "LOC-13" / ; for 1 1 0 1 reserved for national use
+ "LOC-14" / ; for 1 1 1 0 reserved for national use
+ "LOC-15" ; for 1 1 1 1 reserved for national use
+
+ Figure 1: ABNF for isup-cause-location
+
+ Note: These are the location values defined within [Q.850]. The
+ 'LOC-*' names are the wire codepoints for the values currently left
+ as 'spare' or 'reserved' in [Q.850]; these will continue to be the
+ wire codepoints in the case of future allocation or national usage of
+ the such values.
+
+ The UAC or UAS SHALL include the location parameter in a request or
+ response when setting up the Reason header field with a [Q.850] cause
+ when the ISUP [Q.850] location is available.
+
+ The use of the location parameter is restricted to Q.850 cause
+ values. Other values MUST be ignored if present.
+
+5. Example
+
+ The following example shows a SIP 404 response message containing a
+ Reason header field with a [Q.850] cause value and an isup-cause-
+ location value. The 404 Response will be sent when a gateway
+ receives an ISUP release with a [Q.850] cause set to 1, meaning
+ Unallocated (unassigned) number, i.e., the number is not known in the
+ PSTN.
+
+
+
+
+
+
+
+Jesske Standards Track [Page 4]
+
+RFC 8606 ISUP Release Location Parameter June 2019
+
+
+ SIP/2.0 404 Not Found
+ Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx5st
+ Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
+ From: Alice <sips:alice@atlanta.example.com>;tag=1234567
+ To: Bob <sips:bob@biloxi.example.com>;tag=765432
+ Call-ID: 12345600@atlanta.example.com
+ CSeq: 1 INVITE
+ Reason: Q.850;cause=1;text="Unallocated (unassigned) number";
+ location=LN
+ Content-Length: 0
+
+ Figure 2: Example of a Location in the Reason Header Field
+
+6. Privacy Considerations
+
+ While the addition of the location parameter provides an indicator of
+ the entity that added the location in the signaling path, it provides
+ little more exposure than the [Q.850] cause itself. The ISUP
+ location value itself will not reveal the identity of the originating
+ or terminating party of the call. It shows only the ISUP network
+ location of the device that released the call. The ISUP location
+ does not show the physical location of the caller or callee.
+
+7. Security Considerations
+
+ This document doesn't change any of the security considerations
+ described in [RFC3326]. The addition of the location parameter
+ provides an indicator of the [Q.850] location where the call was
+ released within the PSTN. This information may be used for specific
+ location-driven services but does not create any additional security
+ constraints. Because the [Q.850] location is very imprecise, the
+ [Q.850] location value itself will not add any major security
+ constraints. The use of this parameter is not restricted to a
+ specific architecture.
+
+ [RFC3398] describes detailed security considerations due to
+ interworking between ISUP and SIP. Beyond these considerations, the
+ addition of the location does not introduce new security concerns.
+ The location shows the network part where the call was released.
+ Knowing this does not increase the possibilities of extended fraud
+ scenarios.
+
+
+
+
+
+
+
+
+
+
+Jesske Standards Track [Page 5]
+
+RFC 8606 ISUP Release Location Parameter June 2019
+
+
+8. IANA Considerations
+
+8.1. Registration of the Location Parameter for the Reason Header Field
+
+ IANA has registered a new SIP header parameter in the "Header Field
+ Parameters and Parameter Values" subregistry of the "Session
+ Initiation Protocol (SIP) Parameters" registry
+ <https://www.iana.org/assignments/sip-parameters>, per the guidelines
+ in [RFC3968]:
+
+ Header Field: Reason
+
+ Parameter Name: location
+
+ Predefined Values: Yes
+
+ Reference: RFC 8606
+
+9. Normative References
+
+ [Q.850] ITU-T, "Usage of cause and location in the Digital
+ Subscriber Signalling System No. 1 and the Signalling
+ System No. 7 ISDN user part", Recommendation ITU-T Q.850,
+ October 2018, <https://www.itu.int/rec/T-REC-Q.850>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
+ Header Field for the Session Initiation Protocol (SIP)",
+ RFC 3326, DOI 10.17487/RFC3326, December 2002,
+ <https://www.rfc-editor.org/info/rfc3326>.
+
+ [RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong,
+ "Integrated Services Digital Network (ISDN) User Part
+ (ISUP) to Session Initiation Protocol (SIP) Mapping",
+ RFC 3398, DOI 10.17487/RFC3398, December 2002,
+ <https://www.rfc-editor.org/info/rfc3398>.
+
+ [RFC3968] Camarillo, G., "The Internet Assigned Number Authority
+ (IANA) Header Field Parameter Registry for the Session
+ Initiation Protocol (SIP)", BCP 98, RFC 3968,
+ DOI 10.17487/RFC3968, December 2004,
+ <https://www.rfc-editor.org/info/rfc3968>.
+
+
+
+
+
+Jesske Standards Track [Page 6]
+
+RFC 8606 ISUP Release Location Parameter June 2019
+
+
+ [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234,
+ DOI 10.17487/RFC5234, January 2008,
+ <https://www.rfc-editor.org/info/rfc5234>.
+
+ [RFC6432] Jesske, R. and L. Liess, "Carrying Q.850 Codes in Reason
+ Header Fields in SIP (Session Initiation Protocol)
+ Responses", RFC 6432, DOI 10.17487/RFC6432, November 2011,
+ <https://www.rfc-editor.org/info/rfc6432>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+Acknowledgments
+
+ Thanks to Michael Kreipl, Thomas Belling, Marianne Mohali, Peter
+ Daws, Paul Kyzivat, Dale Worley, Yehoshua Gev, and Keith Drage for
+ the comments and review.
+
+Author's Address
+
+ Roland Jesske
+ Deutsche Telekom
+ Heinrich-Hertz Str, 3-7
+ Darmstadt 64295
+ Germany
+
+ Email: r.jesske@telekom.de
+ URI: www.telekom.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jesske Standards Track [Page 7]
+