idnits 2.17.1 draft-ietf-sipcore-reason-q850-loc-03.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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 12, 2018) is 2264 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 219, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: RFC3326 (if approved) February 12, 2018 5 Intended status: Standards Track 6 Expires: August 16, 2018 8 ISUP Cause Location Parameter for the SIP Reason Header Field 9 draft-ietf-sipcore-reason-q850-loc-03.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. 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 16, 2018. 36 Copyright Notice 38 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8.1. Registration of location Parameter for Reason header 62 field . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 64 10. Normative References . . . . . . . . . . . . . . . . . . . . 5 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 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. It may be an SIP response or ISUP release 72 cause as specified within [Q.850]. [RFC3326] does specify that a 73 ISUP [Q.850] cause code can be carried within a SIP response. The 74 [Q.850] location information identifies the part of the ISUP network 75 where the call was released. 77 This document adds a location value parameter to the reason-extension 78 parameter in [RFC3326] so that the [Q.850] location value can be 79 interworked from the PSTN. The interworking from PTSN needs only to 80 include the location received by the interworking gateway. 82 2. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 3. Rationale 90 The primary intent of the parameter defined in this specification is 91 for use in IMS (IP Multimedia Subsystem) networks defined by 3GPP but 92 also open to be used by any other network. The purpose of this 93 parameter is to transport the location of call release from the 94 originating PSTN entity to the SIP entity receiving the response or 95 BYE message containing the location of the call release. The ISDN 96 location is defined in [Q.850]. 98 4. Mechanism 100 As defined by [RFC3326] a Reason header field MAY appear in any 101 request in a dialog, in any CANCEL request and in any response whose 102 status code explicitly allows the presence of this header field. The 103 syntax of the header field follows the standard SIP parameter syntax. 105 The mechanism employed adds a parameter with the ISUP location value 106 defined in [Q.850] to the Reason header field that identifies the 107 [Q.850] location of the call release in ISUP as defined in [Q.850] . 108 The location is a 4 bit value which reflects the possible locations 109 where an ISUP call is released. Some values are spare or reserved 110 for national use. The Augmented BNF (ABNF) [RFC5234] for this 111 parameter is shown in Figure 1. 113 reason-extension =/ isup-cause-location 114 isup-cause-location = "location" EQUAL string 116 The following values shall be used as location: 117 U for 0 0 0 0 user 118 LPN for 0 0 0 1 private network serving the local user 119 LN for 0 0 1 0 public network serving the local user 120 TN for 0 0 1 1 transit network 121 RLN for 0 1 0 0 public network serving the remote user 122 RPN for 0 1 0 1 private network serving the remote user 123 LOC-6 for 0 1 1 0 spare 124 INTL for 0 1 1 1 international network 125 LOC-8 for 1 0 0 0 spare 126 LOC-9 for 1 0 0 1 spare 127 BI for 1 0 1 0 network beyond interworking point 128 LOC-11 for 1 0 1 1 spare 129 LOC-12 for 1 1 0 0 reserved for national use 130 LOC-13 for 1 1 0 1 reserved for national use 131 LOC-14 for 1 1 1 0 reserved for national use 132 LOC-15 for 1 1 1 1 reserved for national use 134 Figure 1: isup-cause-location 136 Note: These are the values defined within [Q.850] as location. Thus 137 other values are not within the scope of this document. 139 Depending on the direction the UAC or UAS shall include the location 140 parameter when setting up the Reason header field with a [Q.850] 141 cause. This approach is only valid in cases when the ISUP [Q.850] 142 location is available. 144 The use of the location parameter is restricted to Q850 cause values 145 in other cases the location, if present, MUST be silently ignored. 147 5. Example 149 The following example shows a SIP 404 response message containing a 150 Reason header field with a [Q.850] cause value and a isup-cause- 151 location value. The 404 Response will be set up when a gateway 152 receives an ISUP Release with a [Q.850] cause set to 1 meaning 153 "Unallocated (unassigned) number", i.e. the number is not known in 154 the PSTN. 156 SIP/2.0 404 Not Found 158 From: Alice ;tag=1234567 159 To: Bob ;tag=765432 160 Call-ID: 12345600@atlanta.example.com 161 CSeq: 1 INVITE 162 Reason: Q.850;cause=1;text="Unallocated (unassigned) number"; 163 location=LN 164 Content-Length: 0 166 Figure 2: Example Location in Reason header field. 168 6. Privacy Considerations 170 This document doesn't change any of the privacy considerations 171 described in [RFC3326]. While the addition of the location parameter 172 does provide an indicator of the entity that added the location in 173 the signaling path this provides little more exposure than the 174 [Q.850] cause itself. 176 7. Security Considerations 178 This document doesn't change any of the security considerations 179 described in [RFC3326]. The addition of the location parameter does 180 provide an indicator of the [Q.850] location where the call was 181 released within the PSTN. This information may be used for specific 182 location driven services but does not create any additional security 183 constrains. But since the [Q.850] location is very imprecise the 184 [Q.850] location value itself will not add any major security 185 constraint. The use of this parameter is not restricted to a 186 specific architecture. 188 8. IANA Considerations 190 8.1. Registration of location Parameter for Reason header field 192 This document calls for IANA to register a new SIP header parameter 193 as per the guidelines in [RFC3968], which will be added to Header 194 Field Parameters sub-registry under http://www.iana.org/assignments/ 195 sip-parameters. 197 Header Field: Reason 199 Parameter Name: location 201 9. Acknowledgments 203 Thanks to Michael Kreipl, Thoams Belling, Marianne Mohali, Peter 204 Daws, Paul Kyzivat, Dale Worley, Yehoshua Gev, Keith Drage for the 205 comments and review. 207 10. Normative References 209 [Q.850] INTERNATIONAL TELECOMMUNICATION UNION, "Usage of cause and 210 location in the Digital Subscriber Signalling System No. 1 211 and the Signalling System No. 7 ISDN User Part", Q 850, 212 May 1998. 214 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 215 Requirement Levels", BCP 14, RFC 2119, 216 DOI 10.17487/RFC2119, March 1997, 217 . 219 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 220 A., Peterson, J., Sparks, R., Handley, M., and E. 221 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 222 DOI 10.17487/RFC3261, June 2002, 223 . 225 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 226 Header Field for the Session Initiation Protocol (SIP)", 227 RFC 3326, DOI 10.17487/RFC3326, December 2002, 228 . 230 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 231 (IANA) Header Field Parameter Registry for the Session 232 Initiation Protocol (SIP)", BCP 98, RFC 3968, 233 DOI 10.17487/RFC3968, December 2004, 234 . 236 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 237 Specifications: ABNF", STD 68, RFC 5234, 238 DOI 10.17487/RFC5234, January 2008, 239 . 241 Author's Address 243 Roland Jesske 244 Deutsche Telekom 245 Heinrich-Hertz Str, 3-7 246 Darmstadt 64295 247 Germany 249 Email: r.jesske@telekom.de 250 URI: www.telekom.de