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