idnits 2.17.1 draft-jesske-sipcore-reason-q850-loc-00.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == 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 (March 27, 2017) is 2586 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: 'RFC6432' is defined on line 216, but no explicit reference was found in the text Summary: 1 error (**), 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: RFC6442 (if approved) March 27, 2017 5 Intended status: Standards Track 6 Expires: September 28, 2017 8 ISUP Cause Location Parameter for the SIP Reason Header Field 9 draft-jesske-sipcore-reason-q850-loc-00.txt 11 Abstract 13 The SIP Reason header field is defined for carrying ISUP cause values 14 as well as SIP response codes. Some services in SIP networks may 15 need to know the ISUP location where the call was released in the 16 PSTN network to correctly interpret the reason of release. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 28, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 8.1. Registration of isup-cause-location Parameter for reason 61 header field . . . . . . . . . . . . . . . . . . . . . . 4 62 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 10.2. Informative References . . . . . . . . . . . . . . . . . 5 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 The SIP Reason header field specification [RFC3326] describes a SIP 71 header field that is used to indicate that a SIP request is carrying 72 the reason of release. It may be an SIP response or ISUP release 73 cause as specified within [Q.850]. [RFC3326] does specify that a 74 ISUP [Q.850] cause code can be carried within a SIP response. The 75 [Q.850] location information identifies the part of the ISUP network 76 where the call was released. 78 This document adds a location value parameter to the reason-extension 79 parameter in [RFC3326] so that the [Q.850] location value can be 80 interworked from the PSTN. The interworking from PTSN needs only to 81 include the location received by the interworking gateway. 83 2. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 3. Rationale 91 The primary intent of the parameter defined in this specification is 92 for use in IMS networks defined by 3GPP but also open to be used by 93 any other network. The purpose of this parameter is to transport the 94 location of call release from the originating PSTN entity to the SIP 95 entity receiving the response or BYE message containing the location 96 of the call release. The ISDN 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 Augmented BNF (ABNF) [RFC5234] for this parameter is shown in 109 Figure 1. 111 reason-extension =/ isup-cause-location 112 isup-cause-location = "location" EQUAL string 114 The values to be used as location are: 115 U for user 116 LPN for private network serving the local user 117 LN for public network serving the local user 118 TN for transit network 119 RLN for public network serving the remote user 120 RPN for private network serving the remote user 121 INTL for international network 122 BI for network beyond interworking point 124 Figure 1: isup-cause-location 126 Depending on the direction the UAC or UAS shall include the isup- 127 cause-location when setting up the Reason header field with a [Q.850] 128 cause. This approach is only valid in cases when the ISUP [Q.850] 129 location is available. 131 5. Example 133 The following example shows a SIP 404 response message containing a 134 Reason header field with a [Q.850] cause value and a isup-cause- 135 location value. The 404 Response will be set up when a gateway 136 receives an ISUP Release with a [Q.850] cause set to 1 meaning 137 "Unallocated (unassigned) number", i.e. the number is not known in 138 the PSTN. 140 404 Not Found 142 SIP/2.0 404 Not Found 144 From: Alice ;tag=1234567 145 To: Bob ;tag=765432 146 Call-ID: 12345600@atlanta.example.com 147 CSeq: 1 INVITE 148 Reason: Q.850;cause=1;text="Unallocated (unassigned) number"; location=LN 149 Content-Length: 0 151 Figure 2: Example Location in Reason header field. 153 6. Privacy Considerations 155 This document doesn't change any of the privacy considerations 156 described in [RFC3326]. While the addition of the isup-cause- 157 location parameter does provide an indicator of the entity that added 158 the location in the signaling path this provides little more exposure 159 than the [Q.850] cause itself. 161 7. Security Considerations 163 This document doesn't change any of the security considerations 164 described in [RFC3326]. The addition of the isup-cause-location 165 parameter does provide an indicator of the [Q.850] location where the 166 call was released within the PSTN. This information may be used for 167 specific location driven services but does not create any additional 168 security constrains. But since the [Q.850] location is very 169 imprecise the [Q.850] location value itself will not add any major 170 security constrain. The use of this parameter is not restricted to a 171 specific architecture. 173 8. IANA Considerations 175 8.1. Registration of isup-cause-location Parameter for reason header 176 field 178 This document calls for IANA to register a new SIP header parameter 179 as per the guidelines in [RFC3261], which will be added to header 180 sub-registry under http://www.iana.org/assignments/sip-parameters. 182 Header Field: Reason 184 Parameter Name: isup-cause-location 186 9. Acknowledgments 188 Thanks to Michael Kreipl, Thoams Belling, Marianne Mohali, Peter Daws 189 for the comments and review. 191 10. References 193 10.1. Normative References 195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 196 Requirement Levels", BCP 14, RFC 2119, 197 DOI 10.17487/RFC2119, March 1997, 198 . 200 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 201 A., Peterson, J., Sparks, R., Handley, M., and E. 202 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 203 DOI 10.17487/RFC3261, June 2002, 204 . 206 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 207 Header Field for the Session Initiation Protocol (SIP)", 208 RFC 3326, DOI 10.17487/RFC3326, December 2002, 209 . 211 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 212 Specifications: ABNF", STD 68, RFC 5234, 213 DOI 10.17487/RFC5234, January 2008, 214 . 216 [RFC6432] Jesske, R. and L. Liess, "Carrying Q.850 Codes in Reason 217 Header Fields in SIP (Session Initiation Protocol) 218 Responses", RFC 6432, DOI 10.17487/RFC6432, November 2011, 219 . 221 10.2. Informative References 223 [Q.850] INTERNATIONAL TELECOMMUNICATION UNION, "Usage of cause and 224 location in the Digital Subscriber Signalling System No. 1 225 and the Signalling System No. 7 ISDN User Part", Q 850, 226 May 1998. 228 Author's Address 229 Roland Jesske 230 Deutsche Telekom 231 Heinrich-Hertz Str, 3-7 232 Darmstadt 64295 233 Germany 235 Email: r.jesske@telekom.de 236 URI: www.telekom.de