RFC4769 日本語訳

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

Livingoodがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4769年のコムキャスト有線通信カテゴリ: 標準化過程R.ショッキーNeuStar2006年11月

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

情報に合図しながら公衆電話交換網(PSTN)を含むEnumserviceのための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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The IETF Trust (2006).

IETFが信じる著作権(C)(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"を登録します、ENUM仕様に基づき定義されたIANA登録手続に従ってURI体系'一口'を使用する「副-タイプ」「一口」と同様に、RFC3761。 このEnumserviceは、ナンバーポータビリティが存在するそれらの国で通話のルーティングを容易にするのに使用されます。

Livingood & Shockey        Standards Track                      [Page 1]

RFC 4769                    PSTN Enumservice               November 2006

LivingoodとショッキーStandardsはPSTN Enumservice2006年11月にRFC4769を追跡します[1ページ]。

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. 序論…3 2. データの分配…4 3. ENUMはPSTNのために登録を修理します…5 3.1. ENUMはPSTNのためにSubtype"tel"で登録を修理します…5 3.2. ENUMはPSTNのためにSubtype「一口」で登録を修理します…5 4. 例…6 4.1. 'tel'URI体系を使用する移植された数に関する例…6 4.2. '一口'URI体系を使用する移植された数に関する例…6 4.3. 'tel'URI体系を使用する非移植された数に関する例…7 4.4. '一口'URI体系を使用する非移植された数に関する例…7 4.5. 正規表現を使用する例…7 5. 実装推薦…7 5.1. 複数の記録を返すときには処理に電話をしてください…7 5.2. NAPTR Configuration問題…8 6. 呼び出し処理におけるE2U+pstnに関する例…8 6.1. 利用可能なオンネットではなく、番号にダイヤルします…8 6.2. ネットの上と、そして、PSTNの上で有効な番号にダイヤルします…9 7. セキュリティ問題…9 8. IANA問題…10 9. 承認…10 10. 参照…10 10.1. 標準の参照…10 10.2. 有益な参照…11

Livingood & Shockey        Standards Track                      [Page 2]

RFC 4769                    PSTN Enumservice               November 2006

LivingoodとショッキーStandardsはPSTN Enumservice2006年11月にRFC4769を追跡します[2ページ]。

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、RFC3761[1])がE.164番号を変える技術である、(国際Public Telecommunication Numbering Plan、ドメイン名と次に、用途へのITU-T Recommendation E.164[2])DNS、(ドメインネームシステム、NSを通したRFC1034[3])委譲が記録して、NAPTRが記録する、(ダイナミックなDelegationディスカバリーSystem(DDDS)はThreeを分けます: ドメインネームシステム(DNS)データベース(どんなサービスが特定のドメイン名に利用可能であるか見せるRFC3403[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]のサービス分野でリソースに食糧を供給するのに使用されるためにRFC3761[1]で与えられたガイドラインに従ったこのドキュメントレジスタEnumservicesは、エンドポイント、そして/または、電話番号に関連している機能性のタイプを示すために記録します。 登録はDDDSの中で定義されます。(「E2U」というDDDSアプリケーションがRFC3761で定義されている使用のためのダイナミックなDelegationディスカバリーSystem[4][5][6][7][8])階層構造。

   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.

数のPortabilityは電話加入者にそれらがサービスプロバイダーを変えるとき、彼らの電話番号を保つか、新しい位置に移行するか、または申し込まれたサービス[14]を変えさせます。 合衆国やカナダなどの多くの国では、Public Switched Telephone Networkで(PSTN)を命名して、扱う機能が抜き取られました。 移植された数の場合では、ダイヤルされた数をPSTNで直接発送可能でなく、呼び出し完成のルーティング番号に翻訳しなければなりません。 他の数(移植しないで、直接ダイヤルされた数に基づくPSTNで発送できる)は大量株かプールでキャリヤーと他の実体に通常配属されます。 数のPortabilityと他の付番情報は世界中のさまざまなメソッドと形式で分配されます。

   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データベースに。 これは、そのようなパーティーがそれらのネットワークにおけるすべての電話番号ルックアップをただ一つのENUMルックアップに統合するのを順番に可能にするかもしれません、その結果、呼び出しルーティングとネットワーク操作を簡素化します。(次に、操作は、ネットにおける(IPベース)の応答かオフネット(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

以下のEnumserviceはこのドキュメントに登録されます: PSTNを示すナンバーポータビリティデータ、非移植された電話番号データ(個別か数のブロックの)、および他のE.164電話番号に関連しているPSTN指向のデータを含むデータを発送する"pstn"。 このEnumserviceの目的は公共のインターネットか個人的であるかじっと見たインターネットプロトコルで終点の居住者を任命しない電話番号のためのルーティング情報を提供することです。

Livingood & Shockey        Standards Track                      [Page 3]

RFC 4769                    PSTN Enumservice               November 2006

LivingoodとショッキーStandardsはPSTN Enumservice2006年11月にRFC4769を追跡します[3ページ]。

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

(IP) ネットワークでつなぎます。 したがって、これらは伝統的なPSTNを通して発送可能であるだけである数です、呼び出しがIPネットワークから発しても。 このサービスで返されたURIはRFC4694[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.

RFC3761で定義されたサービスパラメタは、「タイプ」と"「副-タイプ」"が指定されるかもしれないのを示します。 このセットの仕様の中では、コンベンションは想定されます。「タイプ(より多くの総称である)」がサービスと"「副-タイプ」"を定義するのが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.

ナンバーポータビリティデータの分配はしばしば高く制限されます、National Regulatory Authority(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データの分配は個人的ベース(サービスプロバイダーの内部のネットワークか、一般アクセスを禁止するのにさまざまなセキュリティー対策を使用している1回以上のパーティーの間の個人的ベースの上の)の(a)であるかもしれません、オープンに利用可能な(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.

そのようなデータが全国的に分配されたなら、ある他の国家の電話付番権威、取締機関または付番組織が管轄するかもしれません。 そのようなボディーは、その国の国境を通り過ぎないかもしれないような方法における、データの分配を制限するのを選ぶかもしれません。

Livingood & Shockey        Standards Track                      [Page 4]

RFC 4769                    PSTN Enumservice               November 2006

LivingoodとショッキーStandardsはPSTN Enumservice2006年11月にRFC4769を追跡します[4ページ]。

3.  ENUM Service Registration for PSTN

3. PSTNのためのENUMサービス登録

3.1.  ENUM Service Registration for PSTN with Subtype "tel"

3.1. Subtype"tel"があるPSTNのためのENUMサービス登録

   Enumservice Name: "pstn"

Enumserviceは以下を命名します。 "pstn"

   Enumservice Type: "pstn"

Enumserviceはタイプします: "pstn"

   Enumservice Subtype: "tel"

Enumservice Subtype: "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は、両用声か他のコミュニケーションを含むかもしれない電気通信セッションを開始するために関連URI体系で特定された遠隔資源は扱うことができるのを示します、PSTNに。 これらのURIはRFC4694[10]の指定されるとしてのナンバーポータビリティデータを含むかもしれません。

   Security Considerations: See Section 7.

セキュリティ問題: セクション7を見てください。

   Intended Usage: COMMON

意図している用法: 一般的

   Authors:

作者:

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

ジェイソンLivingood( jason_livingood@cable.comcast.com )リチャード・ショッキー( 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).

Number Portability Dip Indicator(npdi)は実際には使用されるべきです(セクション4で以下の例を見てください)。

3.2.  ENUM Service Registration for PSTN with Subtype "sip"

3.2. Subtype「一口」があるPSTNのためのENUMサービス登録

   Enumservice Name: "pstn"

Enumserviceは以下を命名します。 "pstn"

   Enumservice Type: "pstn"

Enumserviceはタイプします: "pstn"

   Enumservice Subtype: "sip"

Enumservice Subtype: 「一口」

   URI Scheme: 'sip:'

URI体系: 'ちびちび飲んでください'

Livingood & Shockey        Standards Track                      [Page 5]

RFC 4769                    PSTN Enumservice               November 2006

LivingoodとショッキーStandardsはPSTN Enumservice2006年11月にRFC4769を追跡します[5ページ]。

   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.

これらのEnumservicesは、両用声か他のコミュニケーションを含むかもしれない電気通信セッションを開始するために関連URI体系で特定された遠隔資源は扱うことができるのを示します、PSTNに。

   Security Considerations: See Section 7.

セキュリティ問題: セクション7を見てください。

   Intended Usage: COMMON

意図している用法: 一般的

   Authors:

作者:

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

ジェイソンLivingood( jason_livingood@cable.comcast.com )リチャード・ショッキー( 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).

Number Portability Dip Indicator(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!".

$発生源3.2.1.0.5.5.5.5.1.2.1.e164.arpa。 「NAPTR10 100「」 「E2U+はtelに以下をpstnします!」u」 ^*$!tel:+1-215-555-0123; npdi; Rnは+1-215-555-0199と等しいです!」

   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.

この例では、ルート設定Number(Rn)とNumber Portability Dip Indicator(npdi)はRFC4694[10]に示されるように使用されています。 'npdi'分野は、レガシースタイルPSTNデータベースのその後のルックアップを防ぐために含まれています。

4.2.  Example of a Ported Number, Using a 'sip' URI Scheme

4.2. '一口'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!".

$発生源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!".

   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-

この例では、ルート設定Number(Rn)とNumber Portability Dip Indicator(npdi)はRFC4694[10]に示されるように使用されています。 'npdi'分野は、レガシーにおけるその後のルックアップを防ぐために含まれています。

Livingood & Shockey        Standards Track                      [Page 6]

RFC 4769                    PSTN Enumservice               November 2006

LivingoodとショッキーStandardsはPSTN Enumservice2006年11月にRFC4769を追跡します[6ページ]。

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

PSTNデータベースを流行に合わせてください。 telからSIP URIまでの変換のメソッドがRFC3261、セクション19.1.6[11]に示される、およびRFC4694(セクション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!".

$発生源3.2.1.0.5.5.5.5.1.2.1.e164.arpa。 「NAPTR10 100「」 「E2U+はtelに以下をpstnします!」u」 ^*$!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.

この例では、Number Portability Dip Indicator(npdi)は中古の[10]です。 'npdi'分野は、レガシースタイルPSTNデータベースのその後のルックアップを防ぐために含まれています。

4.4.  Example of a Non-Ported Number, Using a 'sip' URI Scheme

4.4. '一口'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!".

$発生源3.2.1.0.5.5.5.5.1.2.1.e164.arpa。 「NAPTR10 100「u」$!一口: + 「E2U+pstn: 一口」」 ^* 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].

この例では、Number Portability Dip Indicator(npdi)は中古の[10]です。 'npdi'分野は、レガシースタイルPSTNデータベースのその後のルックアップを防ぐために含まれています。 telからSIP URIまでの変換のメソッドがRFC3261、セクション19.1.6[11]に示される、およびRFC4694(セクション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!".

$発生源3.2.1.0.5.5.5.5.1.2.1.e164.arpa。 「NAPTR10 100「」 「E2U+はtelに以下をpstnします!」u」 (^*)$!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インチ。(その1インチはダイナミックにこの場合、+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

与えられた質問のためにE2U+一口とE2U+pstn Enumserviceタイプ記録の両方を返しそうでしょう。 この場合、これは本質的にはネットの、そして、オフ正味のpstn記録であることをもたらすかもしれません。 したがって、1つの記録がIPネットワークに関する関連アドレスを与えます、もう片方がPSTNに関する関連アドレスを与えますが。 複数の記録がe164.arpa木の典型的なENUM質問から生じていて、どれを決定するかにENUMレゾルバを使用することでアプリケーションまで達しているとき

Livingood & Shockey        Standards Track                      [Page 7]

RFC 4769                    PSTN Enumservice               November 2006

LivingoodとショッキーStandardsはPSTN Enumservice2006年11月にRFC4769を追跡します[7ページ]。

   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.

使用への(s)とどの記録を無視したらよいか記録してください。 Implementersはこれを考慮に入れて、論理を適切に商用で基づく複数の記録、ネットワーク、または他の規則から選び抜くことができる彼らのアプリケーションに組み込むはずです。 例えば、ネットに関する記録に好みを承諾するか、または必要に応じてアプリケーションで他の論理を実行するためにそのようなレゾルバを構成できました。

5.2.  NAPTR Configuration issues

5.2. NAPTR Configuration問題

   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.

tel URIが実際には使用するためにSIP URIよりさらに簡単であって、効率的であるかもしれないと示唆されました。 さらに、tel URIの使用はいくらか小さい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.

Implementersは、個々のNAPTRsのサイズを減少させるのに正規表現を使用すると考えたがっているかもしれません。 これで、データベースの総合的なサイズへの重要な効果はかかわるでしょう。 セクション4.5の例を使用して、1記録あたりこれは上では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.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が記録的であることがわかって、処理のために呼ぶアプリケーションで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) どのメディアゲートウェイを決定するかために論理を発送するアプリケーションが使用する呼ぶのは、この数の最も近くにあって、適切に呼び出しを発送します。

Livingood & Shockey        Standards Track                      [Page 8]

RFC 4769                    PSTN Enumservice               November 2006

LivingoodとショッキーStandardsはPSTN Enumservice2006年11月にRFC4769を追跡します[8ページ]。

6.2.  Dialed Number Available On-Net and on the PSTN

6.2. ネットの上と、そして、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.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は、両方がE2U+pstn記録であることがわかります、E2U+一口記録と同様に、この数が接続ネットワークのIPネットワークにたまたまあるので。

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

d) 呼ぶアプリケーションは最初に、ネットに関する記録を最優先させます: ちびちび飲んでください: + 1-215-555-0123;npdi@gw.example.com;user =電話。

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

e) SIPへの呼んでいるアプリケーションセットはgw.example.comに呼びかけます。

   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呼び出しルートが理由、呼ぶアプリケーションがそうすることなら何でものために失敗するはずであるなら、PSTNに接続されるメディアゲートウェイへ後退ルートを呼び出すのにE2U+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がaグローバルである、分散データベース。 この仕様のimplementersが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

より早く注意されるように、キャリヤー、サービスプロバイダー、および他のユーザは、公共のe164.arpa木でそのような情報を発表しないのを単に選ぶかもしれません。 彼らは代わりに信じられた要素で質問できるだけである自分達の内部のENUMルーティングデータベースで単にこれを発行するかもしれません。

Livingood & Shockey        Standards Track                      [Page 9]

RFC 4769                    PSTN Enumservice               November 2006

LivingoodとショッキーStandardsはPSTN Enumservice2006年11月にRFC4769を追跡します[9ページ]。

   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.

softswitchesやSIPプロキシサーバなどのそれらのネットワークについて。 また、作成されるなら、彼らは、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電話番号は形式の一口: username@hostname かメール: 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へのENUMの依存とDNSSEC[12]のこれへの適用性に特定の脅威の分析をRFC3761[1]に提供します。 DNS自身への脅威の徹底的な分析はRFC3833[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.

このドキュメントはEnumserviceがタイプして、Enumservice登録の下の「副-タイプ」"tel"と「一口」がRFC3761のIANA問題で説明した'pstn'を登録します。 この登録の詳細はこのドキュメントのセクション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.

作者は彼らのこの話題の役立つ議論、およびこのドキュメントの詳細なレビューについてローレンス・コンロイ、トム・クレートン、ジェイソンGaedtke、ハイメ・ヒメネス、クリス・ケネディ、アレクサンダー・マイルホーファー、ダグRanalli、ジョナサン・ローゼンバーグ、ボブ・ウォルター、およびジェームス・ユーに感謝したがっています。 また、作者は役立っているフィードバックについてこのドキュメントを洗練して、開発する際に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.とM.食事、「Uniform Resource Identifier(URI)ダイナミックな委譲発見システム(DDDS)アプリケーション(ENUM)へのE.164」、RFC3761、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.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

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

[4] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。

Livingood & Shockey        Standards Track                     [Page 10]

RFC 4769                    PSTN Enumservice               November 2006

LivingoodとショッキーStandardsはPSTN Enumservice2006年11月にRFC4769を追跡します[10ページ]。

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

[5] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」、2002年10月のRFC3401。

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

[6] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は2を分けます」。 「アルゴリズム」、RFC3402、2002年10月。

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

[7] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は4を分けます」。 「Uniform Resource Identifier(URI)」、RFC3404、2002年10月。

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

[8] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は5を分けます」。 「URI.ARPA課題手順」、BCP65、RFC3405、2002年10月。

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

[9]Schulzrinne、2004年12月のH.、「Telephone民数記のためのtel URI」RFC3966。

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

[10] ユー、J.、「"tel"Uniform Resource Identifierのためのナンバーポータビリティパラメタ」、RFC4694、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] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月。

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

[13] アトキンスとD.とR.Austein、「ドメインネームシステム(DNS)の脅威分析」、RFC3833、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] フォスター、M.、McGarry、T.、およびJ.ユー、「グローバルのナンバーポータビリティは電話網(GSTN)を切り換えました」。 「概要」、RFC3482、2003年2月。

Livingood & Shockey        Standards Track                     [Page 11]

RFC 4769                    PSTN Enumservice               November 2006

LivingoodとショッキーStandardsはPSTN Enumservice2006年11月にRFC4769を追跡します[11ページ]。

Authors' Addresses

作者のアドレス

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

ジェイソンLivingoodコムキャスト有線通信1500市場通りPA19102フィラデルフィア(米国)

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

以下に電話をしてください。 +1-215-981-7813 メールしてください: jason_livingood@cable.comcast.com

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

リチャードショッキーNeuStar46000センターオーク広場英貨、ヴァージニア20166米国

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

以下に電話をしてください。 +1-571-434-5651 メールしてください: richard.shockey@neustar.biz

Livingood & Shockey        Standards Track                     [Page 12]

RFC 4769                    PSTN Enumservice               November 2006

LivingoodとショッキーStandardsはPSTN Enumservice2006年11月にRFC4769を追跡します[12ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2006).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

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

Livingood & Shockey        Standards Track                     [Page 13]

Livingoodとショッキー標準化過程[13ページ]