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はダイヤル文字列を表さないかもしれないと述べています。これは、標準化された方法でのダイヤル文字列を指定しない方法を残しません。それはダイヤル文字列を表すことができれば素晴らしい混乱は、特にSIP URIパラメータ「ユーザー=電話」で存在し、そして。 「SIP：」このメモは、1つのようにダイヤル文字列を符号化するために「ユーザ= dialstringと入力」を指定することができるように、ユーザパラメータ「dialstringと入力」の新しい値を作成または「一口：」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
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キーパッドに限定されています。ユーザーは、機能のいくつかの種類を呼び出す一連の数字を入力します。 「ダイヤルストリング」と呼ばれる入力されたシーケンスは、電話番号に変換することができる、またはそれは、特別なサービスを呼び出すことができます。多くの新しい設計では、ダイヤル文字列と電話番号またはサービスURIとの間のマッピングは、電話（digitmap）内に含まれます。しかし、内部の変換メカニズムを持っていない多くの携帯電話と端末アダプタがあります。電話での変換メカニズムがなければ、電話がでダイヤル文字列を送信する必要があります「一口：」または「一口：」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.
ここでの問題があります。仲介者は、それがSIP URIのユーザー部分がダイヤル文字列であることを認識した場合にのみ、その変換を適用することができます。しかし、ダイヤル文字列に表示される文字で構成され、たまたまユーザ部からのダイヤル文字列からなるユーザ部分を区別するための方法はありません。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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：」または「一口：」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は、4行の周波数（697、770、852、941ヘルツ）と4つの列の周波数（1209、1336、1477、1633）を用いて4×4行列です。ほとんどの電話は、電話のダイヤルパッドを暗示同じように使用されている4列、の3を実装します。このように、数字2は、第1行第2列であり、そして混合770Hzと1209Hzの周波数で構成されています。 4列目は、PSTN（公衆交換電話網）で使用されていません。 4列目は、「数字」は、通常、このようD.介して文字Aを用いて表現され、「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".
「userinfoを」パラメータの新しい代替値「一口：」または「一口：」URIスキームが定義されている、「dialstringと入力」。 「SIP：」この値は、で使用してもよいし、「一口：」URIのユーザ部分がダイヤル文字列である場合。ダイヤル文字列は、文字0-9、A-F、P、X、 '*' と '＃' の順序です。 Eは、Pは、（モデムストリングにコンマと同様に、短い待ち時間）ポーズであり、X「は呼完了を待つ」を表し、Fは＃を表し、*表します。
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 value is normally configured in the user agent.
「ユーザ= dialstringと入力」を使用する場合、コンテキスト・パラメータは、[RFC3966]で定義されるように、指定しなければなりません。コンテキストパラメータは、通常はドメイン名になります。ドメイン名は、任意の実際のホストに解決する必要はありませんが、ローカルの電話コンテキストを管理するエンティティの管理下でなければなりません。コンテキストパラメータの値は、通常、ユーザエージェントで構成されています。
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:
コンテキストパラメータの構文は、それが数字とURIのuserinfoを[RFC3261]で「@」の間に表示される、つまり、[RFC3966]で同じパラメータと同じ規則に従います。
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.
ダイヤル文字列は、REGISTERでのAoR（レコードのアドレス）には使用しないでください。パラメータは、登録に無視されます。このように、異なる電話コンテキストを持つ2件の登録は、おそらく望ましくない相当する、と考えられます。
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にダイヤル文字列を翻訳することができます。電話番号は、グローバルまたはローカル電話のように表すことができる：URI、又はそれは、SIPのように残してもよい：または一口：URIパラメータ値を持つURI「は、ユーザ=電話」に「=ユーザー」から。
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
;どのSIP電話機は、ユーザがダイヤル延長123 SIP発するかもしれない：123; phone-context=atlanta.example.com@example.com;ユーザー= 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
;既存のボイスメールシステムは、ローカルアクセスの拡張子を持っている。そして、メールボックスのSIPのためのDTMFとして内線番号を期待：450X123; phone-context=biloxi.example.com@example.com;ユーザー= dialstringと入力
[RFC3969] defines a 'sip:' or 'sips:' URI Parameter sub registry. The "user" parameter is specified as having predefined values.
又は '一口：' URIパラメータサブレジストリ：[RFC3969]は 'SIP' を定義します。 「ユーザ」パラメータは、所定の値を有するように指定されています。
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と入力」、「user」パラメータの新しい値を定義します。この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 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].
インターネットに公開された文字列は、攻撃者がこのような内部のシステムを攻撃するためにPSTNまたはインターネットを使用する可能性があり、内部ネットワークの詳細やサービスの呼び出しについての情報を明らかにすることができるダイヤルします。通常の文字列をダイヤルUAC（ユーザエージェントクライアント）のドメインを超えて送るべきではありません。彼らは、インターネット経由で送信された場合は、[RFC3261]の手順ごとのTLS（Transport Layer Security）を持つ盗聴から保護されるべきです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966] Schulzrinneと、H.、 "電話番号については、TEL 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]キャマリロ、G.、BCP 99、RFC 3969、2004年12月 "セッション開始プロトコル（SIP）のための番号機関（IANA）のURI（Uniform Resource Identifier）パラメータレジストリの割り当てインターネット"。
Author's Address
著者のアドレス
Brian Rosen NeuStar 470 Conrad Dr Mars, PA 16046 USA
ブライアン・ローゼンNeuStar 470コンラッド博士火星、PA 16046 USA
Phone: +1 724 382 1051 EMail: br@brianrosen.net
電話：+1 724 382 1051 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。