RFC 4967 - Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4967
タイトル : RFC 4967 - セッション開始プロトコルユニフォームリソース識別子のダイヤル文字列パラメーター
翻訳編集 : 自動生成

[要約] RFC 4967は、セッション開始プロトコル（SIP）のURIにおけるダイヤル文字列パラメータに関する仕様です。このRFCの目的は、SIP URI内のダイヤル文字列を正確に定義し、通信システムの相互運用性を向上させることです。

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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

著作権（c）The IETF Trust（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：」または 'sip：' 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

1. はじめに

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キーパッド（およびスイッチフックを使用した「フラッシュ」機能）に制限されます。ユーザーは、何らかの機能を呼び出す一連の数字を入力します。「ダイヤル文字列」と呼ばれる入力されたシーケンスは、電話番号に翻訳されるか、特別なサービスを呼び出す場合があります。多くの新しいデザインでは、ダイヤル文字列と電話番号またはサービスのマッピングが電話に含まれています（digitmap）。ただし、内部翻訳メカニズムがない多くの携帯電話とターミナルアダプターがあります。電話に翻訳メカニズムがなければ、電話は「sip： 'または' sips： 'uri [rfc3261]にダイヤル文字列を「sip：' 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数字として目的のメールボックス番号を予想します。多くのゲートウェイには、そのような文字列を解釈する能力がありますが、それらを表現する標準化された方法はありません。エンドポイント間の相互運用性の問題につながります。これは、ダイヤル文字列が提示されていることを示す能力が役立つ別のケースです。

2. Terminology

2. 用語

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].

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。

It is assumed that the reader is familiar with the terminology and acronyms defined in [RFC3261].

読者は、[RFC3261]で定義されている用語と頭字語に精通していると想定されています。

3. Requirements

3. 要件

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 =デュアルトーン多周波。各「トーン：」は、実際には2つの周波数が重ねられています。DTMFは、4列周波数（697、770、852、941 Hz）と4つの列周波数（1209、1336、1477、1633）の4 x 4マトリックスです。ほとんどの電話は、4列のうち3つの列のみを実装しています。これらは、電話ダイヤルパッドが示すように使用されます。したがって、数字2は最初の行、2番目の列であり、770Hzと1209Hzの周波数で構成されています。4番目の列は、PSTN（パブリックスイッチ付き電話ネットワーク）では使用されていません。4番目の列の「数字」は通常、文字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.

ダイヤル文字列とたまたま同じ文字で構成されるユーザーパーツを区別することは可能である必要があります。

4. Solution

4. 解決

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」パラメーターの新しい代替値。この値は、「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 value is normally configured in the user agent.

[user = 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:

コンテキストパラメーターの構文は、[rfc3966]の同じパラメーターと同じパラメーターと同じ規則に従います。つまり、uri：uri：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

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（レコードのアドレス）には使用しないでください。登録時にはパラメーターが無視されます。したがって、異なる電話コンテキストを持つ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に変換する場合があります。電話番号は、グローバルまたはローカルTel：uriとして表現される場合があります。または、sip：またはsips：uriパラメーター値が「user =」から「user = phone」に変更された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

   ;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

5. IANA Considerations

5. IANAの考慮事項

[RFC3969] defines a 'sip:' or 'sips:' URI Parameter sub registry. The "user" parameter is specified as having predefined values.

[RFC3969]は、「sip：」または 'sips：' uri parameter subレジストリを定義します。「ユーザー」パラメーターは、事前定義された値を持つとして指定されています。

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は、「ユーザー」パラメーター「ダイヤルストリング」の新しい値を定義します。このRFCは、「ユーザー」パラメーターにリストされている参照に追加されました。

6. Security Considerations

6. セキュリティに関する考慮事項

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（輸送層のセキュリティ）での盗聴から保護されるべきです。

7. Normative References

7. 引用文献

[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：SESSION INTIANIATION Protocol」、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] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）の数字権機関（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

Full Copyright Statement

完全な著作権声明

著作権（c）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。