Network Working Group B. Rosen
Request for Comments: 4967 NeuStar
Category: Standards Track July 2007
Network Working Group B. Rosen
Request for Comments: 4967 NeuStar
Category: Standards Track July 2007
Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier
会话启动协议统一资源标识符的拨号字符串参数
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
RFC 3966 explicitly states that 'tel' URIs may not represent a dial string. That leaves no way specify a dial string in a standardized way. Great confusion exists with the SIP URI parameter "user=phone", and specifically, if it can represent a dial string. This memo creates a new value for the user parameter "dialstring", so that one may specify "user=dialstring" to encode a dial string as a 'sip:' or 'sips:' URI.
RFC 3966明确声明“tel”URI不能表示拨号字符串。这样就无法以标准化的方式指定拨号字符串。SIPURI参数“user=phone”存在很大的混淆，特别是它是否可以表示拨号字符串。此备忘录为用户参数“dialstring”创建了一个新值，因此可以指定“user=dialstring”将拨号字符串编码为“sip:”或“sips:”URI。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
7. Normative References . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
7. Normative References . . . . . . . . . . . . . . . . . . . . . 5
A user at a phone often has a limited User Interface, and in some cases, is limited to a 10 key pad (and sometimes a "flash" function with the switchhook). The user enters a series of digits that invoke some kind of function. The entered sequence, called a "dial string", may be translated to a telephone number, or it may invoke a special service. In many newer designs, the mapping between a dial string and a phone number or service URI is contained within the phone (digitmap). However, there are many phones and terminal adapters that do not have internal translation mechanisms. Without a translation mechanism in the phone, the phone must send the dial string in a 'sip:' or 'sips:' URI [RFC3261] to an intermediary that can transform the dial string to a phone number or a service invocation. The intermediary is able to perform this transform provided that it knows the context (i.e., dialing plan) within which the number was dialed.
手机上的用户通常具有有限的用户界面，在某些情况下，仅限于一个10键的键盘（有时还带有switchhook的“flash”功能）。用户输入一系列调用某种函数的数字。输入的序列称为“拨号字符串”，可以转换为电话号码，也可以调用特殊服务。在许多较新的设计中，拨号字符串与电话号码或服务URI之间的映射包含在电话中（digitmap）。但是，有许多电话和终端适配器没有内部转换机制。如果电话中没有转换机制，则电话必须以“sip:”或“sips:”URI[RFC3261]将拨号字符串发送给中介，中介可以将拨号字符串转换为电话号码或服务调用。只要中介体知道拨打号码的上下文（即拨号计划），它就能够执行此转换。
There is a problem here. The intermediary can apply its transformation only if it recognizes that the user part of the SIP URI is a dial string. However, there is currently no way to distinguish a user part consisting of a dial string from a user part that happens to be composed of characters that would appear in a dial string.
这里有个问题。中介体只有在识别SIPURI的用户部分是拨号字符串时才能应用其转换。但是，目前无法区分由拨号字符串组成的用户部分和碰巧由拨号字符串中出现的字符组成的用户部分。
Use of DTMF (dual tone multi-frequency) detectors after the initial number has been dialed is not uncommon. A common function some systems have is to express a string that incorporates fixed time delays, or in some cases, an actual "wait for call completion" after which additional DTMF signals are emitted. For example, many voicemail systems use a common phone number, after which the system expects the desired mailbox number as a series of DTMF digits to deposit a message for. Many gateways have the ability to interpret such strings, but there is no standardized way to express them, leading to interoperability problems between endpoints. This is another case where the ability to indicate that a dial string is being presented would be useful.
在拨打初始号码后使用DTMF（双音多频）检测器并不少见。一些系统的一个常见功能是表示一个包含固定时间延迟的字符串，或者在某些情况下，表示一个实际的“等待呼叫完成”，之后会发出额外的DTMF信号。例如，许多语音邮件系统使用一个公用电话号码，之后系统希望所需的邮箱号码作为一系列DTMF数字来存放信息。许多网关都能够解释这些字符串，但是没有标准化的方式来表达它们，这导致端点之间的互操作性问题。这是另一种情况，在这种情况下，指示正在显示拨号字符串的功能将非常有用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
It is assumed that the reader is familiar with the terminology and acronyms defined in [RFC3261].
假设读者熟悉[RFC3261]中定义的术语和首字母缩略词。
A mechanism to express a dial string in a 'sip:' or 'sips:' URI is required. A dial string consists of a sequence of
需要一种在“sip:”或“sips:”URI中表示拨号字符串的机制。拨号字符串由一系列
* the digits 0-9
* 数字0-9
* the special characters # and *
* 特殊人物#和*
* the DTMF digits A-D
* DTMF数字A-D
* characters representing a short pause, and a "Wait for call completion" in a dial string
* 表示短暂停和拨号字符串中的“等待呼叫完成”的字符
Note: DTMF = dual tone multi-frequency. Each "tone:" is actually two frequencies superimposed. DTMF is a 4 x 4 matrix with four row frequencies (697, 770, 852, 941 Hz) and four column frequencies (1209, 1336, 1477, 1633). Most telephones only implement 3 of the 4 columns, which are used just as the telephone dial pad implies. Thus, the digit 2 is the first row, second column, and consists of 770Hz and 1209Hz frequencies mixed together. The fourth column is not used in the PSTN (Public Switched Telephone Network). The "digits" for the fourth column are usually expressed using the letters A through D. Thus, "C" is 852/1633Hz. Some systems do use these digits, so we include them in the definition of the dial string.
注：DTMF=双音多频。每个“音调：”实际上是两个频率的叠加。DTMF是一个4x4矩阵，具有四行频率（69770852941Hz）和四列频率（1209133614771633）。大多数电话仅实现4列中的3列，这与电话拨号板的含义相同。因此，数字2是第一行第二列，由770Hz和1209Hz频率混合而成。第四列不用于PSTN（公共交换电话网）。第四列的“数字”通常用字母A到D表示。因此，“C”为852/1633Hz。有些系统确实使用这些数字，因此我们将它们包含在拨号字符串的定义中。
A dial string always exists within a context. The context MUST be specified when expressing a dial string.
拨号字符串始终存在于上下文中。表示拨号字符串时必须指定上下文。
It MUST be possible to distinguish between a dial string and a user part that happens to consist of the same characters.
必须能够区分拨号字符串和恰好由相同字符组成的用户部分。
A new alternative value for the "userinfo" parameter of the 'sip:' or 'sips:' URI schemes is defined, "dialstring". This value may be used in a 'sip:' or 'sips:' URI when the user part is a dial string. The dial string is a sequence of the characters 0-9, A-F, P, X, '*' and '#'. E represents *, F represents #, P is a pause (short wait, like a comma in a modem string) and X represents "wait for call completion".
为'sip:'或'sips:'URI方案的“userinfo”参数定义了一个新的可选值“dialstring”。当用户部分是拨号字符串时，此值可在“sip:”或“sips:”URI中使用。拨号字符串是由字符0-9、a-F、P、X、“*”和“#”组成的序列。E表示*，F表示#，P表示暂停（短等待，如调制解调器字符串中的逗号），X表示“等待呼叫完成”。
When the "user=dialstring" is used, a context parameter, as defined in [RFC3966], MUST be specified. The context parameter would normally be a domain name. The domain name does not have to resolve to any actual host but MUST be under the administrative control of the entity managing the local phone context. The context parameter
使用“user=dialstring”时，必须指定[RFC3966]中定义的上下文参数。上下文参数通常是域名。域名不必解析为任何实际主机，但必须由管理本地电话上下文的实体进行管理控制。上下文参数
value is normally configured in the user agent.
值通常在用户代理中配置。
The syntax of the context parameter follows the same conventions as the same parameter in [RFC3966], that is, it appears between the digits and the "@" in the userinfo [RFC3261] of the URI:
上下文参数的语法遵循与[RFC3966]中相同参数相同的约定，即它出现在URI的userinfo[RFC3261]中的数字和“@”之间：
dialstring = dialstring-digits context; context from RFC 3966
dialstring-digits = *dialstring-element dialstring-digit
*dialstring-element
dialstring-digit = HEXDIG / "*" / "#"; HEXDIG from RFC 3966
dialstring-element = dialstring-digit / "P" / "X" /
visual-separator; visual-separator from RFC 3966
dialstring = dialstring-digits context; context from RFC 3966
dialstring-digits = *dialstring-element dialstring-digit
*dialstring-element
dialstring-digit = HEXDIG / "*" / "#"; HEXDIG from RFC 3966
dialstring-element = dialstring-digit / "P" / "X" /
visual-separator; visual-separator from RFC 3966
A dial string SHOULD NOT be used for an AoR (Address of Record) in a REGISTER. Parameters are ignored in registration. Thus, two registrations with different phone-contexts would be considered equivalent, which is probably not desirable.
拨号字符串不应用于寄存器中的AoR（记录地址）。参数在注册时被忽略。因此，具有不同电话上下文的两个注册将被认为是等效的，这可能是不可取的。
A proxy server or Back to Back User Agent (B2BUA) [RFC3261], which is authoritative for the context, may translate the dial string to a telephone number or service invocation URI. The telephone number MAY be expressed as a global or local tel: URI, or it MAY be left as a sip: or sips: URI with the URI parameter value changed from "user= " to "user=phone".
对于上下文具有权威性的代理服务器或背对背用户代理（B2BUA）[RFC3261]可以将拨号字符串转换为电话号码或服务调用URI。电话号码可以表示为全局或本地tel:URI，也可以保留为sip:或sips:URI，URI参数值从“user=”更改为“user=phone”。
Examples of dial string use include:
拨号串使用的示例包括：
;what a SIP Phone might emit when a user dials extension 123
sip:123;phone-context=atlanta.example.com@example.com;user=dialstring
;what a SIP Phone might emit when a user dials extension 123
sip:123;phone-context=atlanta.example.com@example.com;user=dialstring
;existing voicemail systems have a local access extension,
;then expect to see the extension number as DTMF for the mailbox
sip:450X123;phone-context=biloxi.example.com@example.com;user=dialstring
;existing voicemail systems have a local access extension,
;then expect to see the extension number as DTMF for the mailbox
sip:450X123;phone-context=biloxi.example.com@example.com;user=dialstring
[RFC3969] defines a 'sip:' or 'sips:' URI Parameter sub registry. The "user" parameter is specified as having predefined values.
[RFC3969]定义“sip:”或“sips:”URI参数子注册表。“用户”参数被指定为具有预定义值。
This RFC defines a new value for the "user" parameter, "dialstring". This RFC has been added to the references listed for the "user" parameter.
此RFC为“用户”参数“dialstring”定义了一个新值。此RFC已添加到为“用户”参数列出的参考中。
Dial strings exposed to the Internet may reveal information about internal network details or service invocations that could allow attackers to use the PSTN or the Internet to attack such internal
暴露于Internet的拨号字符串可能会泄露有关内部网络详细信息或服务调用的信息，这些信息可能允许攻击者使用PSTN或Internet攻击此类内部网络
systems. Dial strings normally SHOULD NOT be sent beyond the domain of the UAC (User Agent Client). If they are sent across the Internet, they SHOULD be protected against eavesdropping with TLS (Transport Layer Security) per the procedures in [RFC3261].
系统。拨号字符串通常不应发送到UAC（用户代理客户端）的域之外。如果它们是通过互联网发送的，则应根据[RFC3261]中的程序，使用TLS（传输层安全）保护它们免受窃听。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[RFC3969]Camarillo，G.“会话启动协议（SIP）的Internet分配号码管理机构（IANA）统一资源标识符（URI）参数注册表”，BCP 99，RFC 3969，2004年12月。
Author's Address
作者地址
Brian Rosen NeuStar 470 Conrad Dr Mars, PA 16046 USA
布莱恩·罗森·纽斯塔470康拉德·马尔斯博士，宾夕法尼亚州，美国16046
Phone: +1 724 382 1051
EMail: br@brianrosen.net
Phone: +1 724 382 1051
EMail: br@brianrosen.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。