idnits 2.17.1 draft-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 : ---------------------------------------------------------------------------- == 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 (May 15, 2017) is 2538 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 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) May 15, 2017 5 Intended status: Standards Track 6 Expires: November 16, 2017 8 ISUP Cause Location Parameter for the SIP Reason Header Field 9 draft-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 November 16, 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 following values shall be used as location: 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 Note: These are the values defined within [Q.850] as location. Thus 127 other values are not within the scope of this document. 129 Depending on the direction the UAC or UAS shall include the isup- 130 cause-location when setting up the Reason header field with a [Q.850] 131 cause. This approach is only valid in cases when the ISUP [Q.850] 132 location is available. 134 5. Example 136 The following example shows a SIP 404 response message containing a 137 Reason header field with a [Q.850] cause value and a isup-cause- 138 location value. The 404 Response will be set up when a gateway 139 receives an ISUP Release with a [Q.850] cause set to 1 meaning 140 "Unallocated (unassigned) number", i.e. the number is not known in 141 the PSTN. 143 404 Not Found 145 SIP/2.0 404 Not Found 147 From: Alice ;tag=1234567 148 To: Bob ;tag=765432 149 Call-ID: 12345600@atlanta.example.com 150 CSeq: 1 INVITE 151 Reason: Q.850;cause=1;text="Unallocated (unassigned) number"; 152 location=LN 153 Content-Length: 0 155 Figure 2: Example Location in Reason header field. 157 6. Privacy Considerations 159 This document doesn't change any of the privacy considerations 160 described in [RFC3326]. While the addition of the isup-cause- 161 location parameter does provide an indicator of the entity that added 162 the location in the signaling path this provides little more exposure 163 than the [Q.850] cause itself. 165 7. Security Considerations 167 This document doesn't change any of the security considerations 168 described in [RFC3326]. The addition of the isup-cause-location 169 parameter does provide an indicator of the [Q.850] location where the 170 call was released within the PSTN. This information may be used for 171 specific location driven services but does not create any additional 172 security constrains. But since the [Q.850] location is very 173 imprecise the [Q.850] location value itself will not add any major 174 security constrain. The use of this parameter is not restricted to a 175 specific architecture. 177 8. IANA Considerations 179 8.1. Registration of isup-cause-location Parameter for reason header 180 field 182 This document calls for IANA to register a new SIP header parameter 183 as per the guidelines in [RFC3261], which will be added to header 184 sub-registry under http://www.iana.org/assignments/sip-parameters. 186 Header Field: Reason 188 Parameter Name: isup-cause-location 190 9. Acknowledgments 192 Thanks to Michael Kreipl, Thoams Belling, Marianne Mohali, Peter 193 Daws, Paul Kyzivat for the comments and review. 195 10. References 197 10.1. Normative References 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP 14, RFC 2119, 201 DOI 10.17487/RFC2119, March 1997, 202 . 204 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 205 A., Peterson, J., Sparks, R., Handley, M., and E. 206 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 207 DOI 10.17487/RFC3261, June 2002, 208 . 210 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 211 Header Field for the Session Initiation Protocol (SIP)", 212 RFC 3326, DOI 10.17487/RFC3326, December 2002, 213 . 215 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 216 Specifications: ABNF", STD 68, RFC 5234, 217 DOI 10.17487/RFC5234, January 2008, 218 . 220 10.2. Informative References 222 [Q.850] INTERNATIONAL TELECOMMUNICATION UNION, "Usage of cause and 223 location in the Digital Subscriber Signalling System No. 1 224 and the Signalling System No. 7 ISDN User Part", Q 850, 225 May 1998. 227 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