idnits 2.17.1 draft-rosen-iptel-dialstring-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 253. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 243. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 25, 2006) is 6515 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: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 iptel B. Rosen 3 Internet-Draft NeuStar 4 Expires: December 27, 2006 June 25, 2006 6 Dialstring parameter for the Session Initiation Protocol Uniform 7 Resource Identifier 8 draft-rosen-iptel-dialstring-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 27, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 RFC3966 explicitly states that 'tel' URIs may not represent a dial 42 string. That leaves no way specify a dial string in a standardized 43 way. Great confusion exists with the SIP URI parameter "user=phone", 44 and specifically, if it can represent a dial string. This memo 45 creates a new value for the user parameter "dialstring", so that one 46 may specify "user=dialstring" to encode a dial string as a 'sip:' or 47 'sips:' URI. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 Intellectual Property and Copyright Statements . . . . . . . . . . 8 61 1. Introduction 63 A user at a phone often has a limited User Interface, and in some 64 cases, is limited to a 10 key pad (and sometimes a "flash" function 65 with the switchhook). The user enters a series of digits that invoke 66 some kind of function. The entered sequence, called a "dial string", 67 may be translated to a telephone number, or it may invoke a special 68 service. In many newer designs, the mapping between a dial string 69 and a phone number or service URI is contained within the phone 70 (digitmap). However, there are many phones and terminal adapters 71 that do not have internal translation mechanisms. Without a 72 translation mechanism in the phone, the phone must send the dial 73 string in a 'sip:' or 'sips:' URI [RFC3261] to an intermediary that 74 can transform the dial string to a phone number or a service 75 invocation. The intermediary is able to perform this transform 76 provided that it knows the context (i.e., dialing plan) within which 77 the number was dialed. 79 There is a problem here. The intermediary can apply its 80 transformation only if it recognizes that the user part of the SIP 81 URI is a dial string. However, there is currently no way to 82 distinguish an user part consisting of a dial string from an user 83 part that happens to be composed of characters that would appear in a 84 dial string. 86 Use of DTMF detectors after the initial number has been dialed is not 87 uncommon. A common function some systems have is to express a string 88 that incorporates fixed time delays, or in some cases, actual "wait 89 for call completion" after which additional DTMF signals are emitted. 90 For example, many voicemail systems use a common phone number, after 91 which the system expects the desired mailbox number as a series of 92 DTMF digits to deposit a message for. Many gateways have the ability 93 to interpret such strings, but there is no standardized way to 94 express them, leading to interoperability problems between endpoints. 95 This is another case where the ability to indicate that a dialstring 96 is being presented would be useful. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 It is assumed that the reader is familiar with the terminology and 105 acronyms defined in [RFC3261] 107 3. Requirements 109 A mechanism to express a dial string in a 'sip:' or 'sips:' URI is 110 required. A dial string consists of a sequence of 111 * The digits 0-9 112 * The special characters # and * 113 * The DTMF digits A-D 114 * characters representing a short Pause, and a "Wait for call 115 completion" in a dial string 116 Note: DTMF = Dual Tone MultiFrequency. Each "tone:" is actually 117 two frequencies superimposed. DTMF is a 4 x 4 matrix with four 118 row frequencies (697, 770, 852, 941 Hz) and four column 119 frequencies (1209, 1336, 1477, 1633). Most telephones only 120 implement 3 of the 4 columns, which are used just like the 121 telephone dial pad implies they are. Thus, the digit 2 is the 122 first row, second column, and consists of 770Hz and 1209Hz 123 frequencies mixed together. The fourth column is not used in the 124 PSTN. The "digits" for the fourth column are usually expressed 125 using the letters A through D. Thus, "C" is 852/1633Hz. Some 126 equipment does use these digits, so we include them in the 127 definition of the dial string. 129 A dial string always exists within a context. The context MUST be 130 specified when expressing a dial string. 132 It MUST be possible to distinguish between a dial string and an user 133 part that happens to consist of the same characters. 135 4. Solution 137 A new value for the "user" parameter of the 'sip:' or 'sips:' URI 138 schemes is defined, "dialstring". This value may be used in a 'sip:' 139 or 'sips:' URI when the user part is a dial string. The user part is 140 a sequence of the characters 0-9, A-F, P and X. E represents *, F 141 represents #, P is a pause (short wait, like a comma in a modem 142 string) and X represents "wait for call completion". 144 When the "user=dialstring" is used, a context parameter as defined in 145 [RFC3966] MUST be specified. The context parameter would normally be 146 a domain name. The domain name does not have to resolve to any 147 actual host but MUST be under the administrative control of the 148 entity managing the local phone context. The context parameter value 149 is normally configured in the user agent. 151 A proxy server or Back to Back User Agent (B2BUA) [RFC3261] which is 152 authoritative for the context may translate the dial string to a 153 telephone number or service invocation URI. If such a translation is 154 performed, the proxy server MUST change the URI parameter value from 155 "user=dialstring" to "user=phone". This translation MUST occur prior 156 to the call leaving the domain of the context. 158 Examples of dial string use include: 159 ; what a SIP Phone might emit when a user dials extension 123 160 sip:123@sippbx.example.com;user=dialstring; 161 phone-context=atlanta.example.com 163 ;existing voicemail systems have a local access extension, 164 ;then expect to see the extension number as DTMF for the mailbox 165 sips:4500X4123@sip.example.com;user=dialstring; 166 phone-context='biloxi.example.com' 168 5. IANA Considerations 170 [RFC3969] defines a 'sip:' or 'sips:' URI Parameter sub registry. 171 The "user" parameter is specified as having predefined values. 173 This RFC defines a new value for the "user" parameter, "dialstring". 174 This RFC must be added to the references listed for the "user" 175 parameter. 177 This RFC defines a new parameter in the sub-registry, "phone- 178 context", whose meaning and syntax are derived from the same 179 parameter in [RFC3966]. This parameter does not have a set of 180 predefined values. 182 6. Security Considerations 184 dial strings exposed to the Internet may reveal information about 185 internal network details or service invocations that could allow 186 attackers to use the PSTN or the Internet to attack such internal 187 systems. Dialstrings normally SHOULD NOT be sent beyond the domain 188 of the UAC. If they are sent across the Internet, they SHOULD be 189 protected against eavesdropping with TLS per the procedures in 190 [RFC3261]. 192 7. Normative References 194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 195 Requirement Levels", BCP 14, RFC 2119, March 1997. 197 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 198 A., Peterson, J., Sparks, R., Handley, M., and E. 199 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 200 June 2002. 202 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 203 RFC 3966, December 2004. 205 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 206 (IANA) Uniform Resource Identifier (URI) Parameter 207 Registry for the Session Initiation Protocol (SIP)", 208 BCP 99, RFC 3969, December 2004. 210 Author's Address 212 Brian Rosen 213 NeuStar 214 470 Conrad Dr 215 Mars, PA 16046 216 US 218 Phone: +1 724 382 1051 219 Email: br@brianrosen.net 221 Intellectual Property Statement 223 The IETF takes no position regarding the validity or scope of any 224 Intellectual Property Rights or other rights that might be claimed to 225 pertain to the implementation or use of the technology described in 226 this document or the extent to which any license under such rights 227 might or might not be available; nor does it represent that it has 228 made any independent effort to identify any such rights. Information 229 on the procedures with respect to rights in RFC documents can be 230 found in BCP 78 and BCP 79. 232 Copies of IPR disclosures made to the IETF Secretariat and any 233 assurances of licenses to be made available, or the result of an 234 attempt made to obtain a general license or permission for the use of 235 such proprietary rights by implementers or users of this 236 specification can be obtained from the IETF on-line IPR repository at 237 http://www.ietf.org/ipr. 239 The IETF invites any interested party to bring to its attention any 240 copyrights, patents or patent applications, or other proprietary 241 rights that may cover technology that may be required to implement 242 this standard. Please address the information to the IETF at 243 ietf-ipr@ietf.org. 245 Disclaimer of Validity 247 This document and the information contained herein are provided on an 248 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 249 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 250 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 251 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 252 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 253 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 255 Copyright Statement 257 Copyright (C) The Internet Society (2006). This document is subject 258 to the rights, licenses and restrictions contained in BCP 78, and 259 except as set forth therein, the authors retain all their rights. 261 Acknowledgment 263 Funding for the RFC Editor function is currently provided by the 264 Internet Society.