idnits 2.17.1 draft-ietf-sipcore-reason-q850-loc-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3326, but the abstract doesn't seem to directly say this. It does mention RFC3326 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3326, updated by this document, for RFC5378 checks: 2002-04-23) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2019) is 1883 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3261' is defined on line 245, but no explicit reference was found in the text == Unused Reference: 'RFC3323' is defined on line 251, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sipcore R. Jesske 3 Internet-Draft Deutsche Telekom 4 Updates: 3326 (if approved) February 21, 2019 5 Intended status: Standards Track 6 Expires: August 25, 2019 8 ISUP Cause Location Parameter for the SIP Reason Header Field 9 draft-ietf-sipcore-reason-q850-loc-06.txt 11 Abstract 13 The SIP Reason header field is defined for carrying ISDN User Part 14 (ISUP) cause values as well as SIP response codes. Some services in 15 SIP networks may need to know the ISUP location where the call was 16 released in the PSTN network to correctly interpret the reason of 17 release. This document will update RFC3326. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 25, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8.1. Registration of location Parameter for Reason header 62 field . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 64 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 The SIP Reason header field specification [RFC3326] describes a SIP 70 header field that is used to indicate that a SIP request is carrying 71 the reason of release. The reason of release does indicate why a SIP 72 Dialog or an PSTN call, in case where the call was interworked to the 73 PSTN, was terminated. This may be a normal termination or a 74 termination based on a failure within an entity or other reasons like 75 congestion. The reason may be an SIP response or ISUP release cause 76 as specified within [Q.850]. [RFC3326] specifies that a ISUP [Q.850] 77 cause code can be carried within a SIP response, but not the Q.850 78 location information. The [Q.850] location information identifies 79 the part of the ISUP network where the call was released. 81 This document adds a location value parameter to the reason-extension 82 parameter in [RFC3326] so that the [Q.850] location value can be 83 interworked from the PSTN. The interworking from PTSN needs only to 84 include the location received by the interworking gateway. [Q.850] 85 describes the definition of cause code values and locations used in 86 ISDN and DSS1 environment. The cause code is used for identifying 87 the reason of release of a call and the location identifies where the 88 call was released. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in BCP 95 14 [RFC2119] [RFC8174] when, and only when, they appear in all 96 capitals, as shown here. 98 3. Rationale 100 The primary intent of the parameter defined in this specification is 101 for use in IMS (IP Multimedia Subsystem) networks defined by 3GPP but 102 also open to be used by any other network that includes ISUP 103 interworking gateways and uses Q.850 reason codes. The purpose of 104 this parameter is to transport the location of call release from the 105 originating PSTN entity to the SIP entity receiving the response or 106 BYE message containing the location of the call release. The ISDN 107 location is defined in [Q.850]. 109 4. Mechanism 111 As defined by [RFC3326] a Reason header field MAY appear in any 112 request in a dialog, in any CANCEL request and in any response whose 113 status code explicitly allows the presence of this header field. The 114 syntax of the header field follows the standard SIP parameter syntax. 116 This specification adds a parameter with the ISUP location value 117 defined in [Q.850] to the Reason header field that identifies the 118 location of the call release in ISUP. The location is a 4 bit value 119 which reflects the possible locations where an ISUP call is released. 120 Some values are spare or reserved for national use. The Augmented 121 BNF (ABNF) [RFC5234] for this parameter is shown in Figure 1. 123 reason-extension =/ isup-cause-location 124 isup-cause-location = "location" EQUAL string 126 The following values SHALL be used as location: 127 U for 0 0 0 0 user 128 LPN for 0 0 0 1 private network serving the local user 129 LN for 0 0 1 0 public network serving the local user 130 TN for 0 0 1 1 transit network 131 RLN for 0 1 0 0 public network serving the remote user 132 RPN for 0 1 0 1 private network serving the remote user 133 LOC-6 for 0 1 1 0 spare 134 INTL for 0 1 1 1 international network 135 LOC-8 for 1 0 0 0 spare 136 LOC-9 for 1 0 0 1 spare 137 BI for 1 0 1 0 network beyond interworking point 138 LOC-11 for 1 0 1 1 spare 139 LOC-12 for 1 1 0 0 reserved for national use 140 LOC-13 for 1 1 0 1 reserved for national use 141 LOC-14 for 1 1 1 0 reserved for national use 142 LOC-15 for 1 1 1 1 reserved for national use 144 Figure 1: isup-cause-location 146 Note: These are the values defined within [Q.850] as location. Thus 147 other values are not within the scope of this document. 149 Depending on whether the message is a request or a response the UAC 150 or UAS SHALL include the location parameter when setting up the 151 Reason header field with a [Q.850] cause. This approach is only 152 possible in cases when the ISUP [Q.850] location is available. 154 The use of the location parameter is restricted to Q850 cause values. 155 Other values MUST be ignored if present. 157 5. Example 159 The following example shows a SIP 404 response message containing a 160 Reason header field with a [Q.850] cause value and a isup-cause- 161 location value. The 404 Response will be sent when a gateway 162 receives an ISUP Release with a [Q.850] cause set to 1, meaning 163 "Unallocated (unassigned) number", i.e. the number is not known in 164 the PSTN. 166 SIP/2.0 404 Not Found 168 From: Alice ;tag=1234567 169 To: Bob ;tag=765432 170 Call-ID: 12345600@atlanta.example.com 171 CSeq: 1 INVITE 172 Reason: Q.850;cause=1;text="Unallocated (unassigned) number"; 173 location=LN 174 Content-Length: 0 176 Figure 2: Example Location in Reason header field. 178 6. Privacy Considerations 180 While the addition of the location parameter does provide an 181 indicator of the entity that added the location in the signaling path 182 this provides little more exposure than the [Q.850] cause itself. 183 The ISUP location value itself will not reveal the identity of the 184 originating or terminating party of the call. It shows only the ISUP 185 network location of the device that released the call. The ISUP 186 location does not show show the physical location of the caller or 187 callee. 189 7. Security Considerations 191 This document doesn't change any of the security considerations 192 described in [RFC3326]. The addition of the location parameter does 193 provide an indicator of the [Q.850] location where the call was 194 released within the PSTN. This information may be used for specific 195 location driven services but does not create any additional security 196 constrains. But since the [Q.850] location is very imprecise the 197 [Q.850] location value itself will not add any major security 198 constraint. The use of this parameter is not restricted to a 199 specific architecture. 201 [RFC3398] describes detailed security consideration due to 202 interworking between ISUP and SIP. Beyond these considerations the 203 addition of the location does not add additional security concerns. 204 The location shows the network part where the call is released. 205 Knowing this does not increase the possibilities of extended fraud 206 scenarios. 208 8. IANA Considerations 209 8.1. Registration of location Parameter for Reason header field 211 This document calls for IANA to register a new SIP header parameter 212 as per the guidelines in [RFC3968], which will be added to Header 213 Field Parameters sub-registry under http://www.iana.org/assignments/ 214 sip-parameters. 216 Header Field: Reason 218 Parameter Name: location 220 Predefined Values: yes 222 Reference: RFCXXXX 224 Note to RFC Editor: Please replace RFC XXXX with the RFC number of 225 this specification. 227 9. Acknowledgments 229 Thanks to Michael Kreipl, Thoams Belling, Marianne Mohali, Peter 230 Daws, Paul Kyzivat, Dale Worley, Yehoshua Gev, Keith Drage for the 231 comments and review. 233 10. Normative References 235 [Q.850] INTERNATIONAL TELECOMMUNICATION UNION, "Usage of cause and 236 location in the Digital Subscriber Signalling System No. 1 237 and the Signalling System No. 7 ISDN User Part", Q 850, 238 May 1998. 240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 241 Requirement Levels", BCP 14, RFC 2119, 242 DOI 10.17487/RFC2119, March 1997, 243 . 245 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 246 A., Peterson, J., Sparks, R., Handley, M., and E. 247 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 248 DOI 10.17487/RFC3261, June 2002, 249 . 251 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 252 Initiation Protocol (SIP)", RFC 3323, 253 DOI 10.17487/RFC3323, November 2002, 254 . 256 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 257 Header Field for the Session Initiation Protocol (SIP)", 258 RFC 3326, DOI 10.17487/RFC3326, December 2002, 259 . 261 [RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, 262 "Integrated Services Digital Network (ISDN) User Part 263 (ISUP) to Session Initiation Protocol (SIP) Mapping", 264 RFC 3398, DOI 10.17487/RFC3398, December 2002, 265 . 267 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 268 (IANA) Header Field Parameter Registry for the Session 269 Initiation Protocol (SIP)", BCP 98, RFC 3968, 270 DOI 10.17487/RFC3968, December 2004, 271 . 273 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 274 Specifications: ABNF", STD 68, RFC 5234, 275 DOI 10.17487/RFC5234, January 2008, 276 . 278 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 279 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 280 May 2017, . 282 Author's Address 284 Roland Jesske 285 Deutsche Telekom 286 Heinrich-Hertz Str, 3-7 287 Darmstadt 64295 288 Germany 290 Email: r.jesske@telekom.de 291 URI: www.telekom.de