[要約] RFC 4769は、公衆交換電話網(PSTN)の信号情報を含むEnumserviceのIANA登録に関するものです。このRFCの目的は、PSTNの信号情報を効果的に管理し、Enumserviceの一貫性と互換性を確保することです。

Network Working Group                                       J. Livingood
Request for Comments: 4769                  Comcast Cable Communications
Category: Standards Track                                     R. Shockey
                                                                 NeuStar
                                                           November 2006
        

IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information

パブリックスイッチ付き電話ネットワーク(PSTN)シグナル伝達情報を含むencriviceのIANA登録

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 (2006).

Copyright(c)The IETF Trust(2006)。

Abstract

概要

This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype "sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where number portability exists.

このドキュメントは、URIスキーム「Tel」を使用してEnumserviceタイプ「PSTN」およびサブタイプ「Tel」を登録し、列挙仕様で定義されたIANA登録プロセスに従ってURIスキーム「SIP」を使用して「SIP」を使用してサブタイプ「SIP」を登録します。RFC3761.このEnumserviceは、数の携帯性が存在する国の電話のルーティングを促進するために使用されます。

Table of Contents

目次

   1. Introduction ....................................................3
   2. Distribution of Data ............................................4
   3. ENUM Service Registration for PSTN ..............................5
      3.1. ENUM Service Registration for PSTN with Subtype "tel" ......5
      3.2. ENUM Service Registration for PSTN with Subtype "sip" ......5
   4. Examples ........................................................6
      4.1. Example of a Ported Number, Using a 'tel' URI Scheme .......6
      4.2. Example of a Ported Number, Using a 'sip' URI Scheme .......6
      4.3. Example of a Non-Ported Number, Using a 'tel' URI Scheme ...7
      4.4. Example of a Non-Ported Number, Using a 'sip' URI Scheme ...7
      4.5. Example Using a Regular Expression .........................7
   5. Implementation Recommendations ..................................7
      5.1. Call Processing When Multiple Records Are Returned .........7
      5.2. NAPTR Configuration issues .................................8
   6. Examples of E2U+pstn in Call Processing .........................8
      6.1. Dialed Number Not Available On-Net .........................8
      6.2. Dialed Number Available On-Net and on the PSTN .............9
   7. Security Considerations .........................................9
   8. IANA Considerations ............................................10
   9. Acknowledgements ...............................................10
   10. References ....................................................10
      10.1. Normative References .....................................10
      10.2. Informative References ...................................11
        
1. Introduction
1. はじめに

ENUM (E.164 Number Mapping, RFC 3761 [1]) is a technology that transforms E.164 numbers (The International Public Telecommunication Numbering Plan, ITU-T Recommendation E.164 [2]) into domain names and then uses DNS (Domain Name System, RFC 1034 [3]) delegation through NS records and NAPTR records (Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database, RFC 3403 [4]) to look up what services are available for a specific domain name.

Enum(E.164 Number Mapping、RFC 3761 [1])は、E.164番号(国際的な電気通信番号計画、ITU-T推奨e.164 [2])をドメイン名に変換し、DNSを使用するテクノロジーです(DNS(ドメイン名システム、RFC 1034 [3])NSレコードとNAPTRレコード(Dynamic Delogation Discovery System(DDDS)パート3:ドメイン名システム(DNS)データベース、RFC 3403 [4])特定のドメイン名の場合。

This document registers Enumservices according to the guidelines given in RFC 3761 [1] to be used for provisioning in the services field of a NAPTR [4] resource record to indicate the types of functionality associated with an end point and/or telephone number. The registration is defined within the DDDS (Dynamic Delegation Discovery System [4][5][6][7][8]) hierarchy, for use with the "E2U" DDDS Application defined in RFC 3761.

このドキュメントは、NAPTR [4]リソースレコードのサービスフィールドでのプロビジョニングに使用されるRFC 3761 [1]に記載されているガイドラインに従って、エンクスサービスを登録して、エンドポイントおよび/または電話番号に関連する機能の種類を示します。登録は、DDDS(動的委任ディスカバリーシステム[4] [5] [6] [7] [8])階層内で定義され、RFC 3761で定義された「E2U」DDDSアプリケーションで使用します。

Number Portability allows telephone subscribers to keep their telephone numbers when they change service providers, move to a new location, or change the subscribed services [14]. In many countries, such as the United States and Canada, the functions of naming and addressing on the Public Switched Telephone Network (PSTN) have been abstracted. In the case of a ported number, the dialed number is not directly routable on the PSTN and must be translated into a routing number for call completion. Other numbers, which are not ported, and which can be routed directly on the PSTN based on the dialed number, are typically assigned to carriers and other entities in large blocks or pools. Number Portability and other numbering information are distributed in a variety of methods and formats around the world.

番号の移植性により、電話サブスクライバーは、サービスプロバイダーを変更したり、新しい場所に移動したり、購読されたサービスを変更したりするときに電話番号を保持できます[14]。米国やカナダなどの多くの国では、公共の切り替えた電話網(PSTN)での命名とアドレス指定の機能が抽象化されています。移植された番号の場合、ダイヤル番号はPSTNで直接ルーティングできず、通話完了のためにルーティング番号に翻訳する必要があります。移植されておらず、ダイヤル番号に基づいてPSTN上に直接ルーティングできる他の番号は、通常、大きなブロックまたはプールのキャリアや他のエンティティに割り当てられます。数の移植性やその他の番号付け情報は、世界中のさまざまな方法と形式で配布されています。

The Enumservices described here could enable service providers to place ported numbers, pooled numbers, and blocks of numbers and their associated PSTN contact information, into externally available or highly locally cached ENUM databases. This, in turn, could enable such parties to consolidate all telephone number lookups in their networks into a single ENUM lookup, thereby simplifying call routing and network operations, which would then result in either an on-net (IP-based) response or an off-net (PSTN-based) response.

ここで説明するEnumservicesは、サービスプロバイダーが移植された数値、プールされた数値、およびそれに関連するPSTN連絡先情報を外部的に利用可能または高度にローカルにキャッシュされたEnumデータベースに配置できるようにすることができます。これにより、このような関係者がネットワーク内のすべての電話番号検索を単一の列挙ルーティングとネットワーク操作を単純化することを可能にする可能性があります。Off-Net(PSTNベース)応答。

The following Enumservice is registered with this document: "pstn" to indicate PSTN routing data, including number portability data, non-ported telephone number data (individually or in number blocks), and other PSTN-oriented data that is associated with E.164 telephone numbers. The purpose of this Enumservice is to provide routing information for telephone numbers that do not designate an endpoint resident on the public Internet or a private/peered Internet Protocol (IP) network. Thus, these are numbers that are only routable via the traditional PSTN, even if the call originates from an IP network. The URIs returned in this service may use the TEL URI parameters defined in RFC 4694 [10], and implementations must be prepared to accept them.

次のEnumserviceは、このドキュメントに登録されています:「PSTN」は、番号の携帯性データ、非密集されていない電話番号データ(個別または数字ブロック)、およびE.164に関連付けられているその他のPSTN指向データを含むPSTNルーティングデータを示しています。電話番号。このEnumserviceの目的は、パブリックインターネットまたはプライベート/ピア付きインターネットプロトコル(IP)ネットワークのエンドポイント居住者を指定しない電話番号のルーティング情報を提供することです。したがって、これらは、電話がIPネットワークから発生した場合でも、従来のPSTNを介してのみルーティング可能な数値です。このサービスで返されたURIは、RFC 4694 [10]で定義されているTel URIパラメーターを使用し、それらを受け入れるために実装を準備する必要があります。

The service parameters defined in RFC 3761 indicate that a "type" and a "subtype" may be specified. Within this set of specifications, the convention is assumed that the "type" (being the more generic term) defines the service and the "subtype" defines the URI scheme.

RFC 3761で定義されているサービスパラメーターは、「タイプ」と「サブタイプ」が指定される可能性があることを示しています。この仕様のセット内で、条約は「タイプ」(より一般的な用語である)がサービスを定義し、「サブタイプ」がURIスキームを定義すると想定されています。

When only one URI scheme is associated with a given service, it should be assumed that an additional URI scheme to be used with this service may be added at a later time. Thus, the subtype is needed to identify the specific Enumservice intended.

1つのURIスキームのみが特定のサービスに関連付けられている場合、このサービスで使用する追加のURIスキームが後で追加される可能性があると想定する必要があります。したがって、意図した特定のEnumserviceを識別するためにサブタイプが必要です。

2. Distribution of Data
2. データの分布

The distribution of number portability data is often highly restricted, either by contract or regulation of a National Regulatory Authority (NRA); therefore, NAPTR records specified herein may or may not be part of the e164.arpa DNS tree.

数の携帯性データの分布は、多くの場合、契約または国家規制当局(NRA)の規制のいずれかによって非常に制限されています。したがって、ここで指定されているNAPTRレコードは、E164.ARPA DNSツリーの一部である場合とそうでない場合があります。

The authors believe that it is more likely that these records will be distributed on a purely private basis. Distribution of this NAPTR data could be either (a) on a private basis (within a service provider's internal network, or on a private basis between one or more parties using a variety of security mechanisms to prohibit general public access), (b) openly available or, (c) distributed by the relevant number portability organization or other industry organization, but possibly on a national basis and subject to or in accordance with national regulatory policy.

著者は、これらの記録が純粋にプライベートに分配される可能性が高いと考えています。このNAPTRデータの分布は、(a)民間ベース(サービスプロバイダーの内部ネットワーク内、または一般的なパブリックアクセスを禁止するためにさまざまなセキュリティメカニズムを使用して1つまたは複数の当事者間でプライベートベースで)のいずれかである可能性があります(b)公然と(c)関連する番号の移植性組織または他の業界組織によって配布されるが、おそらく国家ベースで、国家規制政策の対象であるか、またはそれに従って配布される。

If such data were distributed nationally, the national telephone numbering authority, or some other regulatory body or numbering organization, may have jurisdiction. Such a body may choose to restrict distribution of the data in such a way that it may not pass over that country's national borders.

そのようなデータが全国的に配布された場合、国家電話番号局、または他の規制機関または番号付けの組織には管轄権があるかもしれません。そのような機関は、その国の国境を越えないように、データの分布を制限することを選択する場合があります。

3. ENUM Service Registration for PSTN
3. PSTNの列挙サービス登録
3.1. ENUM Service Registration for PSTN with Subtype "tel"
3.1. サブタイプ「Tel」を使用したPSTNの列挙サービス登録

Enumservice Name: "pstn"

Enumservice名:「PSTN」

Enumservice Type: "pstn"

Enumserviceタイプ:「PSTN」

Enumservice Subtype: "tel"

Enumserviceサブタイプ: "Tel"

URI Scheme: 'tel:'

URIスキーム:「Tel:」

Functional Specification:

機能仕様:

These Enumservices indicate that the remote resource identified can be addressed by the associated URI scheme in order to initiate a telecommunication session, which may include two-way voice or other communications, to the PSTN. These URIs may contain number portability data as specified in RFC 4694 [10].

これらのEnumservicesは、識別されたリモートリソースが、双方向の音声やその他の通信を含む電気通信セッションをPSTNに開始するために、関連するURIスキームによって対処できることを示しています。これらのURIには、RFC 4694で指定されている数字の携帯性データが含まれている場合があります[10]。

Security Considerations: See Section 7.

セキュリティ上の考慮事項:セクション7を参照してください。

Intended Usage: COMMON

意図された使用法:共通

Authors:

著者:

Jason Livingood (jason_livingood@cable.comcast.com) Richard Shockey (richard.shockey@neustar.biz)

Jason Livingood(jason_livingood@cable.comcast.com)Richard Shockey(richard.shockey@neustar.biz)

Any other information the author deems interesting:

著者が興味深いと思うその他の情報:

A Number Portability Dip Indicator (npdi) should be used in practice (see examples below in Section 4).

実際には、数の携帯性DIPインジケーター(NPDI)を使用する必要があります(セクション4の以下の例を参照)。

3.2. ENUM Service Registration for PSTN with Subtype "sip"
3.2. サブタイプ「SIP」を備えたPSTNの列挙サービス登録

Enumservice Name: "pstn"

Enumservice名:「PSTN」

Enumservice Type: "pstn"

Enumserviceタイプ:「PSTN」

Enumservice Subtype: "sip"

Enumserviceサブタイプ:「SIP」

URI Scheme: 'sip:' Functional Specification:

URIスキーム: 'SIP:'機能仕様:

These Enumservices indicate that the remote resource identified can be addressed by the associated URI scheme in order to initiate a telecommunication session, which may include two-way voice or other communications, to the PSTN.

これらのEnumservicesは、識別されたリモートリソースが、双方向の音声やその他の通信を含む電気通信セッションをPSTNに開始するために、関連するURIスキームによって対処できることを示しています。

Security Considerations: See Section 7.

セキュリティ上の考慮事項:セクション7を参照してください。

Intended Usage: COMMON

意図された使用法:共通

Authors:

著者:

Jason Livingood (jason_livingood@cable.comcast.com) Richard Shockey (richard.shockey@neustar.biz)

Jason Livingood(jason_livingood@cable.comcast.com)Richard Shockey(richard.shockey@neustar.biz)

Any other information the author deems interesting:

著者が興味深いと思うその他の情報:

A Number Portability Dip Indicator (npdi) should be used in practice (see examples below in Section 4).

実際には、数の携帯性DIPインジケーター(NPDI)を使用する必要があります(セクション4の以下の例を参照)。

4. Examples
4. 例

The following sub-sections document several examples for illustrative purposes. These examples shall in no way limit the various forms that this Enumservice may take.

次のサブセクションでは、例示的な目的のためのいくつかの例を文書化します。これらの例は、このEnumserviceが取る可能性のあるさまざまな形式を決して制限しません。

4.1. Example of a Ported Number, Using a 'tel' URI Scheme
4.1. 「Tel」URIスキームを使用して、移植された番号の例

$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+pstn:tel" "!^.*$!tel:+1-215-555-0123;npdi;rn=+1-215-555-0199!".

$ origin 3.2.1.0.5.5.5.5.5.1.2.1.e164.arpa。Naptr 10 100 "U" "E2U PSTN:Tel"

In this example, a Routing Number (rn) and a Number Portability Dip Indicator (npdi) are used as shown in RFC 4694 [10]. The 'npdi' field is included in order to prevent subsequent lookups in legacy-style PSTN databases.

この例では、RFC 4694 [10]に示されているように、ルーティング番号(RN)と数の携帯性DIPインジケーター(NPDI)を使用しています。「NPDI」フィールドは、レガシースタイルのPSTNデータベースのその後の検索を防ぐために含まれています。

4.2. Example of a Ported Number, Using a 'sip' URI Scheme
4.2. 「SIP」URIスキームを使用して、移植された番号の例

$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+pstn:sip" "!^.*$!sip:+1-215-555-0123;npdi;rn=+1-215-555-0199 @gw.example.com;user=phone!".

$ origin 3.2.1.0.5.5.5.5.5.1.2.1.e164.arpa。naptr 10 100 "u" "e2u pstn:sip" "!」。

In this example, a Routing Number (rn) and a Number Portability Dip Indicator (npdi) are used as shown in RFC 4694 [10]. The 'npdi' field is included in order to prevent subsequent lookups in legacy- style PSTN databases. The method of conversion from a tel to a SIP URI is as demonstrated in RFC 3261, Section 19.1.6 [11], as well as in RFC 4694, Section 6 [10].

この例では、RFC 4694 [10]に示されているように、ルーティング番号(RN)と数の携帯性DIPインジケーター(NPDI)を使用しています。「NPDI」フィールドは、レガシースタイルのPSTNデータベースのその後の検索を防ぐために含まれています。TelからSIP URIへの変換方法は、RFC 3261、セクション19.1.6 [11]、およびRFC 4694、セクション6 [10]で実証されているとおりです。

4.3. Example of a Non-Ported Number, Using a 'tel' URI Scheme
4.3. 'tel' uriスキームを使用して、密指名されていない番号の例

$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+pstn:tel" "!^.*$!tel:+1-215-555-0123;npdi!".

$ origin 3.2.1.0.5.5.5.5.5.1.2.1.e164.arpa。naptr 10 100 "u" "e2u pstn:tel" "!^。*$!tel:1-215-555-0123; npdi!"。

In this example, a Number Portability Dip Indicator (npdi) is used [10]. The 'npdi' field is included in order to prevent subsequent lookups in legacy-style PSTN databases.

この例では、数の携帯性DIPインジケーター(NPDI)が使用されます[10]。「NPDI」フィールドは、レガシースタイルのPSTNデータベースのその後の検索を防ぐために含まれています。

4.4. Example of a Non-Ported Number, Using a 'sip' URI Scheme
4.4. 「SIP」URIスキームを使用して、密指名されていない番号の例

$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+pstn:sip" "!^.*$!sip:+1-215-555-0123;npdi@gw.example.com;user=phone!".

$ origin 3.2.1.0.5.5.5.5.5.1.2.1.e164.arpa。naptr 10 100 "u" "e2u pstn:sip" "!^。*$!sip:1-215-555-0123; npdi@gw.example.com; user =電話!"。

In this example, a Number Portability Dip Indicator (npdi) is used [10]. The 'npdi' field is included in order to prevent subsequent lookups in legacy-style PSTN databases. The method of conversion from a tel to a SIP URI is as demonstrated in RFC 3261, Section 19.1.6 [11], as well as in RFC 4694, Section 6 [10].

この例では、数の携帯性DIPインジケーター(NPDI)が使用されます[10]。「NPDI」フィールドは、レガシースタイルのPSTNデータベースのその後の検索を防ぐために含まれています。TelからSIP URIへの変換方法は、RFC 3261、セクション19.1.6 [11]、およびRFC 4694、セクション6 [10]で実証されているとおりです。

4.5. Example Using a Regular Expression
4.5. 正規表現を使用した例

$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+pstn:tel" "!(^.*)$!tel:\1;npdi!".

$ origin 3.2.1.0.5.5.5.5.5.1.2.1.e164.arpa。naptr 10 100 "u" "e2u pstn:tel" "!(^。*)$!tel:\ 1; npdi!"。

In this example, a regular expression replacement function is used to reduce the size of the NAPTR record. The tel URI uses "\1", which would dynamically replace the expression with the TN plus the leading "+" -- in this case, +1-215-555-0123.

この例では、正規表現置換機能を使用して、NAPTRレコードのサイズを縮小します。Tel URIは「\ 1」を使用します。これは、式をTNと主要な「」に動的に置き換えます。この場合、1-215-555-0123。

5. Implementation Recommendations
5. 実装の推奨事項
5.1. Call Processing When Multiple Records Are Returned
5.1. 複数のレコードが返されたときのコール処理

It is likely that both E2U+sip and E2U+pstn Enumservice type records will be returned for a given query. In this case, this could result in what is essentially an on-net and off-net pstn record. Thus, one record gives the associated address on an IP network, while the other gives the associated address on the PSTN. As with multiple records resulting from a typical ENUM query of the e164.arpa tree, it is up to the application using an ENUM resolver to determine which record(s) to use and which record(s) to ignore. Implementers should take this into consideration and build logic into their applications that can select appropriately from multiple records based on business, network, or other rules. For example, such a resolver could be configured to grant preference to the on-net record, or execute other logic, as required by the application.

特定のクエリに対して、E2U SIPとE2U PSTN Enumserviceタイプレコードの両方が返される可能性があります。この場合、これにより、本質的にオンネットおよびネットのPSTNレコードが生じる可能性があります。したがって、1つのレコードはIPネットワーク上の関連アドレスを提供し、もう1つのレコードはPSTNの関連アドレスを提供します。E164.ARPAツリーの典型的な列挙クエリに起因する複数のレコードと同様に、使用するレコードと無視するレコードを決定するために、列挙リゾルバーを使用してアプリケーション次第です。実装者は、これを考慮に入れて、ビジネス、ネットワーク、またはその他のルールに基づいて複数のレコードから適切に選択できるアプリケーションにロジックを構築する必要があります。たとえば、このようなリゾルバーは、アプリケーションで要求されているように、オンネットレコードに対する優先権を付与するか、他のロジックを実行するように構成できます。

5.2. NAPTR Configuration issues
5.2. NAPTR構成の問題

It has been suggested that tel URIs may be easier and more efficient to use in practice than SIP URIs. In addition, the use of tel URIs may result in somewhat smaller NAPTR records, which, when considering adding hundreds of millions of these records to the DNS, could have a substantial impact on the processing and storage requirements for service providers or other entities making use of this Enumservice type.

Telurisは、SIP URIよりも実際に使用する方が簡単で効率的である可能性があることが示唆されています。さらに、TelURISを使用すると、Naptrレコードがやや小さくなる可能性があり、これらの記録を数億をDNSに追加することを検討すると、サービスプロバイダーまたはその他のエンティティの処理およびストレージ要件に大きな影響を与える可能性があります。このEnumserviceタイプの。

Implementers may wish to consider using regular expressions in order to reduce the size of individual NAPTRs. This will have a significant effect on the overall size of the database involved. Using the example in Section 4.5, above, this is 11 bytes per record.

実装者は、個々のNAPTRのサイズを縮小するために、正規表現の使用を検討することをお勧めします。これは、関係するデータベースの全体的なサイズに大きな影響を与えます。上記のセクション4.5の例を使用すると、これはレコードごとに11バイトです。

6. Examples of E2U+pstn in Call Processing
6. コール処理におけるE2U PSTNの例

These are examples of how a switch, proxy, or other calling application may make use of this Enumservice type during the call initiation process.

これらは、スイッチ、プロキシ、またはその他の呼び出しアプリケーションが、呼び出し開始プロセス中にこのEnumserviceタイプをどのように使用するかの例です。

6.1. Dialed Number Not Available On-Net
6.1. ダイヤル番号では使用できません

When the dialed number is not available on-net, the call processing is as follows.

ダイヤル番号がネットで使用できない場合、コール処理は次のとおりです。

a) A user, which is connected to a calling application, dials an E.164 telephone number: +1-215-555-0123.

a) 呼び出しアプリケーションに接続されているユーザーは、E.164の電話番号:1-215-555-0123にダイヤルします。

b) The calling application uses the dialed number to form a NAPTR record: 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.

b) 呼び出しアプリケーションは、ダイヤル番号を使用してNAPTRレコードを形成します:3.2.1.0.5.5.5.5.5.55.1.2.1.E164.ARPA。

c) The DNS finds an E2U+pstn:tel record and returns a tel URI for processing by the calling application: tel:+1-215-555-0123;npdi.

c) DNSは、E2U PSTN:Tel Recordを見つけて、呼び出しアプリケーションによる処理のためにTel URIを返します:Tel:1-215-555-0123; NPDI。

d) The calling application uses routing logic to determine which media gateway is the closest to this number and routes the call appropriately.

d) 呼び出しアプリケーションは、ルーティングロジックを使用して、どのメディアゲートウェイがこの数に最も近いかを決定し、コールを適切にルーティングします。

6.2. Dialed Number Available On-Net and on the PSTN
6.2. on-netおよびPSTNで利用可能なダイヤル番号

When the dialed number is available on-net and on the PSTN, the call processing is as follows.

ダイヤル番号がオンネットおよびPSTNで利用可能である場合、コール処理は次のとおりです。

a) A user, which is connected to a calling application, dials an E.164 telephone number: 1-215-555-0123.

a) 呼び出しアプリケーションに接続されているユーザーは、E.164の電話番号:1-215-555-0123にダイヤルします。

b) The calling application uses the dialed number to form a NAPTR record: 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.

b) 呼び出しアプリケーションは、ダイヤル番号を使用してNAPTRレコードを形成します:3.2.1.0.5.5.5.5.5.55.1.2.1.E164.ARPA。

c) The DNS finds both an E2U+pstn record, as well as an E2U+sip record, since this number happens to be on the IP network of a connected network.

c) DNSは、この数値が接続されたネットワークのIPネットワーク上にあるため、E2U PSTNレコードとE2U SIPレコードの両方を見つけます。

d) The calling application prioritizes the on-net record first: sip:+1-215-555-0123;npdi@gw.example.com;user=phone.

d) 呼び出しアプリケーションは、最初にオンネットレコードを優先します:SIP:1-215-555-0123; npdi@gw.example.com; user =電話。

e) The calling application sets up the SIP call to gw.example.com.

e) 呼び出しアプリケーションは、gw.example.comへのSIPコールを設定します。

f) Should the IP call route fail for whatever reason, the calling application may be able to utilize the E2U+pstn record to invoke a fallback route to a media gateway that is connected to the PSTN.

f) IPコールルートが何らかの理由で失敗した場合、呼び出しアプリケーションはE2U PSTNレコードを利用して、PSTNに接続されているメディアゲートウェイへのフォールバックルートを呼び出すことができます。

7. Security Considerations
7. セキュリティに関する考慮事項

DNS, as used by ENUM, is a global, distributed database. Should implementers of this specification use e164.arpa or any other publicly available domain as the tree for maintaining PSTN Enumservice data, this information would be visible to anyone anonymously. While this is not qualitatively different from publication in a telephone directory, it does open or ease access to such data without any indication that such data has been accessed or by whom it has been accessed.

enumで使用されるDNSは、グローバルな分散データベースです。この仕様の実装者は、PSTN Enumserviceデータを維持するためのツリーとしてE164.ARPAまたはその他の公開ドメインを使用する場合、この情報は匿名で誰にでも表示されます。これは電話ディレクトリに公開されることと定性的に違いはありませんが、そのようなデータがアクセスされたり、誰がアクセスしたかを示すことなく、そのようなデータへのアクセスを開いたり容易にしたりします。

Such data harvesting by third parties is often used to generate lists of targets for unsolicited information. Thus, a third party could use this to generate a list that they can use to make unsolicited "telemarketing" phone calls. Many countries have do-not-call registries or other legal or regulatory mechanisms in place to deal with such abuses.

サードパーティによるこのようなデータ収穫は、しばしば未承諾情報のターゲットのリストを生成するために使用されます。したがって、サードパーティはこれを使用して、未承諾の「テレマーケティング」電話を作成するために使用できるリストを生成できます。多くの国では、そのような虐待に対処するために、継続的なレジストリまたはその他の法的または規制のメカニズムがあります。

As noted earlier, carriers, service providers, and other users may simply choose not to publish such information in the public e164.arpa tree. They may instead simply publish this in their internal ENUM routing database that is only able to be queried by trusted elements of their network, such as softswitches and SIP proxy servers. They may also choose to publish such information in a carrier-only branch of the E164.ARPA tree, should one be created.

前述のように、キャリア、サービスプロバイダー、およびその他のユーザーは、そのような情報を公開e164.arpaツリーに公開しないことを単に選択する場合があります。代わりに、ソフトスイッチやSIPプロキシサーバーなど、ネットワークの信頼できる要素によってのみクエリをかけることができる内部enumルーティングデータベースにこれを単純に公開する場合があります。また、そのような情報をE164.ARPAツリーのキャリア専用ブランチに公開することもできます。

Although an E.164 telephone number does not appear to reveal as much identity information about a user as a name in the format sip:username@hostname or email:username@hostname, the information is still publicly available; thus, there is still the risk of unwanted communication.

E.164の電話番号は、sip:username@hostnameまたはemail:username@hostnameの名前としてユーザーに関する多くの身元情報を明らかにしていないようですが、情報はまだ公開されています。したがって、不要なコミュニケーションのリスクがまだあります。

An analysis of threats specific to the dependence of ENUM on the DNS and the applicability of DNSSEC [12] to this is provided in RFC 3761 [1]. A thorough analysis of threats to the DNS itself is covered in RFC 3833 [13].

DNSへの酵素の依存性とDNSSECの適用可能性[12]に固有の脅威の分析は、RFC 3761 [1]で提供されています。DNS自体に対する脅威の徹底的な分析は、RFC 3833でカバーされています[13]。

8. IANA Considerations
8. IANAの考慮事項

This document registers the 'pstn' Enumservice type and the subtype "tel" and "sip" under the Enumservice registry described in the IANA considerations in RFC 3761. Details of this registration are provided in Section 3 of this document.

このドキュメントは、RFC 3761のIANAに関する考慮事項で説明されているEnumserviceレジストリの下で、「PSTN」Enumserviceタイプとサブタイプ「Tel」および「SIP」を登録します。この登録の詳細は、このドキュメントのセクション3に記載されています。

9. Acknowledgements
9. 謝辞

The authors wish to thank Lawrence Conroy, Tom Creighton, Jason Gaedtke, Jaime Jimenez, Chris Kennedy, Alexander Mayrhofer, Doug Ranalli, Jonathan Rosenberg, Bob Walter, and James Yu for their helpful discussions of this topic, and detailed reviews of this document. The authors also wish to thank the IETF's ENUM Working Group for helpful feedback in refining and developing this document.

著者は、ローレンス・コンロイ、トム・クレイトン、ジェイソン・ガエドケ、ハイメ・ジメネス、クリス・ケネディ、アレクサンダー・マイロファー、ダグ・ラナリ、ジョナサン・ローゼンバーグ、ボブ・ウォルター、ジェームズ・YUに、このトピックの役に立つ議論とこの文書の詳細なレビューに感謝します。著者はまた、このドキュメントを改良および開発する際の有用なフィードバックについて、IETFのEnumワーキンググループに感謝したいと考えています。

10. References
10. 参考文献
10.1. Normative References
10.1. 引用文献

[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.

[1] Faltstrom、P。and M. Mealling、「E.164へのユニフォームリソース識別子(URI)動的委任ディスカバリーシステム(DDDS)アプリケーション(ENUM)」、RFC 3761、2004年4月。

[2] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, February 2005.

[2] ITU-T、「国際公開通信番号計画」、勧告E.164、2005年2月。

[3] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[3] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。

[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.

[4] Mealling、M。、「Dynamic Delogation Discovery System(DDDS)パート3:ドメイン名システム(DNS)データベース」、RFC 3403、2002年10月。

[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.

[5] Mealling、M。、「Dynamic Delogation Discovery System(DDDS)パート1:包括的なDDDS」、RFC 3401、2002年10月。

[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.

[6] Mealling、M。、「Dynamic Delogation Discovery System(DDDS)パート2:アルゴリズム」、RFC 3402、2002年10月。

[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.

[7] Mealling、M。、「動的委任発見システム(DDDS)パート4:ユニフォームリソース識別子(URI)」、RFC 3404、2002年10月。

[8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", BCP 65, RFC 3405, October 2002.

[8] Mealling、M。、「動的委任発見システム(DDDS)パート5:URI.ARPA割り当て手順」、BCP 65、RFC 3405、2002年10月。

[9] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.

[9] Schulzrinne、H。、「電話番号のためのTel URI」、RFC 3966、2004年12月。

[10] Yu, J., "Number Portability Parameters for the "tel" Uniform Resource Identifier", RFC 4694, October 2006.

[10] Yu、J。、「「Tel」ユニフォームリソース識別子の数の携帯性パラメーター」、RFC 4694、2006年10月。

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

[11] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP:SESSION INIATIATION Protocol"、RFC 3261、2002年6月。

10.2. Informative References
10.2. 参考引用

[12] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.

[12] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、2005年3月。

[13] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.

[13] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析(DNS)」、RFC 3833、2004年8月。

[14] Foster, M., McGarry, T., and J. Yu, "Number Portability in the Global Switched Telephone Network (GSTN): An Overview", RFC 3482, February 2003.

[14] Foster、M.、McGarry、T。、およびJ. Yu、「グローバルスイッチド電話ネットワーク(GSTN)における数の移植性:概要」、RFC 3482、2003年2月。

Authors' Addresses

著者のアドレス

Jason Livingood Comcast Cable Communications 1500 Market Street Philadelphia, PA 19102 USA

Jason Livingood Comcast Cable Communications 1500 Market Street、Philadelphia、PA 19102 USA

   Phone: +1-215-981-7813
   EMail: jason_livingood@cable.comcast.com
        

Richard Shockey NeuStar 46000 Center Oak Plaza Sterling, VA 20166 USA

リチャードショッキーノイスター46000センターオークプラザスターリング、バージニア州20166 USA

   Phone: +1-571-434-5651
   EMail: richard.shockey@neustar.biz
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The IETF Trust (2006).

Copyright(c)The IETF Trust(2006)。

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エディター機能の資金は現在、インターネット協会によって提供されています。