RFC5346 日本語訳
5346 Operational Requirements for ENUM-Based Softswitch Use. J. Lim,W. Kim, C. Park, L. Conroy. October 2008. (Format: TXT=31050 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Lim
Request for Comments: 5346 W. Kim
Category: Informational C. Park
NIDA
L. Conroy
RMRL
October 2008
コメントを求めるワーキンググループJ.リムの要求をネットワークでつないでください: 5346年のW.キムカテゴリ: 情報のC.の公園ナイダL.コンロイRMRL2008年10月
Operational Requirements for ENUM-Based Softswitch Use
ENUMベースのSoftswitch使用のための操作上の要件
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean Voice over IP (VoIP) carriers, gained during the ENUM pre-commercial trial hosted by the National Internet Development Agency of Korea (NIDA) in 2006.
このドキュメントはENUMベースのsoftswitchesのために2006年に韓国(ナイダ)のNationalインターネットDevelopment Agencyによって主催されたENUMのプレ商業のトライアルの間に獲得された2個の韓国のボイス・オーバー IP(VoIP)キャリヤーの間の呼び出しルーティングに関して操作上の要件といくつかの問題の経験について説明します。
These experiences show that an interim solution can maintain the stability of ongoing commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls.
これらの経験は、当座の解決策が、ENUMサービスの初期の間進行中の市販のsoftswitchシステムの安定性が操作であることを支持できるのを示します。(そこでは、DNSが呼び出しの大部分の十分なデータを持っていません)。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Call Routing on Softswitch . . . . . . . . . . . . . . . . . . 2
3. Infrastructure ENUM Trial in Korea . . . . . . . . . . . . . . 3
4. Operational Requirements for ENUM-Based Softswitches . . . . . 4
4.1. Call Routing Cases for DNS Response Codes . . . . . . . . 4
4.1.1. Trial Policies . . . . . . . . . . . . . . . . . . . . 4
4.1.2. Trial ENUM Lookup Rules . . . . . . . . . . . . . . . 6
4.2. Call Routing Cases for Domainparts . . . . . . . . . . . . 7
5. Trial Results . . . . . . . . . . . . . . . . . . . . . . . . 9
6. 'e164.arpa' Considerations . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 Softswitch. . . . . . . . . . . . . . . . . . 2 3でルート設定に電話をしてください。 韓国. . . . . . . . . . . . . . 3 4でのインフラストラクチャENUMトライアル。 ENUMベースのSoftswitches. . . . . 4 4.1のための操作上の要件。 DNS応答コード. . . . . . . . 4 4.1のためのルート設定ケースを.1と呼んでください。 トライアル方針. . . . . . . . . . . . . . . . . . . . 4 4.1.2。 トライアルENUMルックアップ規則. . . . . . . . . . . . . . . 6 4.2。 Domainparts. . . . . . . . . . . . 7 5のためにケースにルート設定に電話をしてください。 トライアル結果. . . . . . . . . . . . . . . . . . . . . . . . 9 6。 'e164.arpa'問題. . . . . . . . . . . . . . . . . . 9 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 10 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 10 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 11 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 11
Lim, et al. Informational [Page 1] RFC 5346 Enum-Based Softswitch Use October 2008
リム、他 情報[1ページ]のRFC5346のEnumベースのSoftswitchは2008年10月を使用します。
1. Introduction
1. 序論
ENUM [RFC3761] is a mapping system based on DNS [RFC1034] [RFC1035] that converts from an E.164 [E164] number to a domain name using the Naming Authority Pointer (NAPTR) [RFC3403] resource record type. ENUM is able to store different service types (such as fax, email, homepage, SIP, H.323 and so on) for every E.164 number. It originally focused on how end-users could gain access to other end- users' communication contact information through the Internet.
ENUM[RFC3761]はNaming Authority Pointer(NAPTR)[RFC3403]リソースレコード種類を使用することでE.164[164E]番号からドメイン名まで変換するDNS[RFC1034][RFC1035]に基づくマッピングシステムです。 ENUMはあらゆるE.164番号において異なったサービスタイプを格納できます(ファックス、メール、ホームページ、SIP、H.323などなどの)。 それは元々、エンドユーザがどう他の終わりのユーザのコミュニケーション問い合わせ先へのアクセスをインターネットを通して得ることができたかに焦点を合わせました。
Recently, discussion on the need to update RFC 3761 has begun to ensure that the standard also works in the "Infrastructure ENUM" scenario, where ENUM provides routing information between carriers. This resulted in two documents, the updated ENUM specification [RFC3761bis] and an Enumservice guide [ENUMSERVICE-GUIDE].
最近、RFC3761をアップデートする必要性についての議論は、また、規格が「インフラストラクチャENUM」というシナリオで働くのを保証し始めました。(そこでは、ENUMがルーティング情報をキャリヤーの間に供給します)。 これは2通のドキュメント、アップデートされたENUM仕様[RFC3761bis]、およびEnumserviceガイド[ENUMSERVICE-ガイド]をもたらしました。
When providing VoIP service, a VoIP carrier that wants to integrate various protocols typically uses a softswitch. However, such a system is still inefficient for interconnection, number portability, and sharing protocol support information among carriers, because each softswitch does not have complete end-to-end routing information for all carriers. This information can be stored in DNS, using ENUM. Therefore, carriers can expect to gain many advantages if they use ENUM within the call routing functions of their softswitches.
サービスをVoIPに供給するとき、様々なプロトコルを統合したがっているVoIPキャリヤーはsoftswitchを通常使用します。 しかしながら、インタコネクト、ナンバーポータビリティ、および共有プロトコルサポート情報には、そのようなシステムはキャリヤーの中でまだ効率が悪いです、各softswitchに終わりから終わりへのルーティングすべてのキャリヤーへの完全な情報がないので。 ENUMを使用して、DNSにこの情報を格納できます。 したがって、それらのsoftswitchesの呼び出し経路選択機能の中でENUMを使用するなら、キャリヤーは、多くの利点を獲得すると予想できます。
To confirm these benefits and to verify the performance of ENUM- enabled softswitches, NIDA cooperated with two Korean VoIP service providers for an Infrastructure ENUM trial in 2006. NIDA is a non- profit organization with a mandate to manage 2.8.e164.arpa. (representing the +82 country code of Korea). NIDA promotes and facilitates technical cooperation on a national scale between partners, and this includes ENUM. During the trial, NIDA provided a centralized ENUM DNS to each VoIP service provider for call routing. The data used in this Infrastructure trial was also accessible to the public (i.e., it was an Internet-based system, rather than a closed scheme).
これらの利益を確認して、ENUMの性能について確かめるのはsoftswitchesを有効にして、ナイダは2006年にInfrastructure ENUMトライアルのために2つの韓国のVoIPサービスプロバイダーと協力しました。 2.8.e164.arpaを管理する命令でナイダは非営利団体です。 (韓国の+82国名略号を表します。) ナイダは、パートナーの間の国家のスケールで技術協力を促進して、容易にします、そして、これはENUMを含んでいます。 トライアルの間、ナイダは呼び出しルーティングのためにそれぞれのVoIPサービスプロバイダーに集結されたENUM DNSを提供しました。 また、公衆にとって、このInfrastructureトライアルに使用されるデータもアクセス可能でした(すなわち、それは閉じている計画よりむしろインターネットを利用するシステムでした)。
2. Call Routing on Softswitch
2. Softswitchでルート設定に電話をしてください。
In the PSTN (Public Switched Telephone Network), hardware-based switches predominate. A softswitch provides similar functionality, but is implemented on a computer system by software. It typically has to support various signalling protocols (such as SIP [RFC3261], H.323 [H323], Media Gateway Control Protocol (MGCP) [RFC3435], and others) to make call connections for VoIP service, often on the boundary point between the circuit and packet network.
PSTN(公共のSwitched Telephone Network)では、ハードウェアベースのスイッチは勝っています。 softswitchは同様の機能性を提供しますが、コンピュータ・システムの上でソフトウェアによって実行されます。 それは、呼び出し接続を作るために、VoIPサービスと、しばしばサーキットとパケット網の間の境界ポイントの上で様々な合図プロトコル(SIP[RFC3261]や、H.323[H323]や、メディアゲートウェイControlプロトコル(MGCP)[RFC3435]や、他のものなどの)を通常サポートしなければなりません。
Lim, et al. Informational [Page 2] RFC 5346 Enum-Based Softswitch Use October 2008
リム、他 情報[2ページ]のRFC5346のEnumベースのSoftswitchは2008年10月を使用します。
To make a call, first of all a softswitch must discover routing information. It has to process the E.164 number that comes from a caller through its own routing table. The goal is to determine how the call can be routed towards the callee, so that either the call can be processed through the softswitch or the caller can connect to the callee directly.
まず、電話をかけるために、softswitchはルーティング情報を発見しなければなりません。 それは訪問者からそれ自身の経路指定テーブルまで来るE.164番号を処理しなければなりません。 目標はどうしたら訪問される人に向かって呼び出しを発送できるかを決定することです、softswitchを通して呼び出しを処理できるか、または訪問者が直接訪問される人に接続できるように。
Today, call routing is often based on a prefix of the dialled number. This is used very widely not only for legacy PSTN switches, but also for softswitches. So, if a softswitch exclusively uses ENUM DNS for call routing, then, in the beginning most of the calls queried to ENUM DNS would fail if there are only a small group of carriers provisioning data into ENUM. However, a softswitch will have a higher success rate with ENUM DNS as the number of carriers grows, and so the overall percentage of numbers provisioned in ENUM increases. In short, ENUM as a long-term solution has obvious benefits, but the problem lies in migrating from today's prefix-based routing towards that long-term ENUM-based solution.
今日、呼び出しルーティングはしばしばダイヤルされた数の接頭語に基づいています。 これは遺産PSTNスイッチに使用されるだけではなく、softswitchesにも非常に広く使用されます。 それで、softswitchが呼び出しルーティングに排他的にENUM DNSを使用するなら、そして初めに、ENUMにデータに食糧を供給するキャリヤーの小さいグループしかなければ、ENUM DNSに質問された呼び出しの大部分は失敗するでしょう。 しかしながら、キャリヤーの数が成長するときsoftswitchにはENUM DNSがある、より高い成功率があるので、ENUMで食糧を供給された総合的な割合の数が増加します。 要するに、長期的な解決法としてのENUMには、明白な利益がありますが、今日の接頭語ベースのルーティングからその長期のENUMベースの解決策に向かってわたるのにおいて問題があります。
3. Infrastructure ENUM Trial in Korea
3. 韓国でのインフラストラクチャENUMトライアル
As described in Section 1, NIDA and two VoIP service providers built ENUM-processing modules into their softswitches, interconnected these via the IP network, and provisioned their trial users' numbers into a centralized ENUM DNS system operated by NIDA. The carriers provisioned their E.164 numbers using Extensible Provisioning Protocol (EPP) [RFC4114] to a centralized Registration Server (also operated by NIDA). Changes to the ENUM data were implemented and updated to the ENUM DNS instantly, using DNS Dynamic Update [RFC2136].
セクション1で説明されるように、ナイダと2つのVoIPサービスプロバイダーが、ナイダによって操作された集結されたENUM DNSシステムに、ENUM-処理モジュールをそれらのsoftswitchesに組み込んで、IPネットワークを通してこれらとインタコネクトして、彼らの公判ユーザの番号に食糧を供給しました。 Extensible Provisioningプロトコル(EPP)[RFC4114]を集結されたRegistration Server(また、ナイダで、作動する)に使用することでキャリヤーは彼らのE.164番号に食糧を供給しました。 DNSダイナミック・アップデート[RFC2136]を使用して、即座にENUMデータへの変化をENUM DNSに実行して、アップデートしました。
In the trial, the EPP-based provisioning sub-system was developed and operated separately from the carriers' main customer provisioning systems and protocols. It was not integrated, as the carriers already operated their own customer provisioning systems that were totally different from the EPP-based model, and (as mission-critical components) those were not open to modification.
トライアルでは、EPPベースの食糧を供給するサブシステムは、開発されて、別々にシステムとプロトコルに食糧を供給するキャリヤーの主要取引先を中心に活動しました。 それは統合されませんでした、キャリヤーが既にEPPベースのモデルと完全に異なったシステムに食糧を供給するそれら自身の顧客を手術して、(ミッションクリティカルなコンポーネントとしての)それらが変更に開かれていなかったとき。
Lim, et al. Informational [Page 3] RFC 5346 Enum-Based Softswitch Use October 2008
リム、他 情報[3ページ]のRFC5346のEnumベースのSoftswitchは2008年10月を使用します。
Call routing
+---------------------------------------------+
| |
| |
+-----+------+ +-----------------+ +------+-----+
|Softswitch A|------| ENUM DNS(+82) |------|Softswitch B|
+-----+------+ | (Tier1,2) | +------+-----+
| +--------+--------+ |
+-----+------+ | +------+-----+
| IP Phone A | |Dynamic Update | IP Phone B |
+------------+ |(RFC 2136) +------------+
|
+------------+ +--------+--------+ +------------+
| EPP Client | | Registration | | EPP Client |
| |------| Server |------| |
+------------+ +-----------------+ +------------+
Provisioning E.164 Numbers(RFC 4114)
+にルーティングに電話をしてください。---------------------------------------------+ | | | | +-----+------+ +-----------------+ +------+-----+ |Softswitch A|------| ENUM DNS(+82)|------|Softswitch B| +-----+------+ | (Tier1、2) | +------+-----+ | +--------+--------+ | +-----+------+ | +------+-----+ | IP電話A| |ダイナミック・アップデート| IP電話B| +------------+ |(RFC2136) +------------+ | +------------+ +--------+--------+ +------------+ | EPPクライアント| | 登録| | EPPクライアント| | |------| サーバ|------| | +------------+ +-----------------+ +------------+ E.164番号に食糧を供給すること。(RFC4114)
Carrier A NIDA Carrier B
キャリヤーはナイダキャリヤーBです。
Figure 1: Infrastructure ENUM Trial System Topology
図1: インフラストラクチャENUMトライアルシステムトポロジー
4. Operational Requirements for ENUM-Based Softswitches
4. ENUMベースのSoftswitchesのための操作上の要件
4.1. Call Routing Cases for DNS Response Codes
4.1. DNS応答コードのためにケースにルート設定に電話をしてください。
To use ENUM DNS, each softswitch needs to have an ENUM module that converts from an E.164 number to the ENUM domain name (as defined in RFC 3761) and processes a query to ENUM DNS. This ENUM module uses the algorithm specified in RFC 3761.
ENUM DNSを使用するために、各softswitchはE.164番号からENUMドメイン名(RFC3761で定義されるように)と過程まで質問をENUM DNSに変換するENUMモジュールを必要とします。 このENUMモジュールはRFC3761で指定されたアルゴリズムを使用します。
However, in the initial stage of ENUM DNS roll-out, ENUM shares call routing information from a limited number of carriers. There is the problem that a softswitch can't find all of the call routing information it needs just using ENUM. To solve this problem, ENUM- based softswitches have to follow a consistent set of rules.
しかしながら、ENUM DNS初公開の初期で、ENUMは限られた数のキャリヤーからの呼び出しルーティング情報を共有します。 softswitchがそれが必要とする呼び出しルーティング情報のすべてを見つけることができないというただENUMを使用することにおける問題があります。 この問題を解決するために、ENUMのベースのsoftswitchesは一貫したセットの規則に従わなければなりません。
4.1.1. Trial Policies
4.1.1. トライアル方針
As a matter of policy in this trial, all telephone numbers in use within an "ENUM only" number range (i.e., ones in which an endpoint could only be reached via a URI found during an ENUM lookup of a telephone number in this range, and for which there was no PSTN Point of Interconnect) were arranged to return a NAPTR response. For ranges in which there was a PSTN Point of Interconnect, this was not required.
政策の問題としてこのトライアルでは、「ENUM専用」数の範囲(すなわち、電話番号のENUMルックアップの間にこの範囲で見つけられたURIで終点に達することができるだけであって、InterconnectのPSTN Pointが全くなかったもの)の中で使用中のすべての電話番号が、NAPTR応答を返すためにアレンジされました。 InterconnectのPSTN Pointがあった範囲において、これは必要ではありませんでした。
Lim, et al. Informational [Page 4] RFC 5346 Enum-Based Softswitch Use October 2008
リム、他 情報[4ページ]のRFC5346のEnumベースのSoftswitchは2008年10月を使用します。
Thus, no data (at all) needed to be provisioned into an associated ENUM domain for such a number if it were possible to "reach" that number via the PSTN, unless there were also an IP-based Point of Interconnect serving that number and the serving carrier chose to make this option available.
したがって、それがPSTNを通してその数に「達すること」において可能であるなら、どんなデータ(全く)も、そのような数のために関連ENUMドメインに食糧を供給される必要がないでしょうに、また、その数に役立つInterconnectのIPベースのPointがあって、給仕キャリヤーが、このオプションを利用可能にするのを選ばなかったなら。
In those domains in which NAPTRs for ENUM processing were provisioned, these NAPTRs were always 'terminal' rules -- non- terminal NAPTRs were not used. If non-terminal NAPTRs were to be provisioned, then the standard operation of ENUM processing might have required extra DNS lookups before the set of NAPTRs for a telephone number could be evaluated. The delay and indeterminacy this would introduce was not considered acceptable.
ENUM処理のためのNAPTRsが食糧を供給されたそれらのドメインでは、これらのNAPTRsはいつも'端末'の規則でした--非端末のNAPTRsは使用されませんでした。 非端末NAPTRsが食糧を供給されるつもりであったなら、電話番号のためのNAPTRsのセットを評価できる前にENUM処理の標準の操作は余分なDNSルックアップを必要としたかもしれません。 これが導入する遅れと不確定は許容できると考えられませんでした。
The case where a valid URI was present is covered in Section 4.1.2 (rule 2 A, second point). The case where an ENUM entry was not provisioned for a number that had an active PSTN Point of Interconnect is covered in Section 4.1.2 (rule 2 B).
有効なURIが出席していたケースがセクション4.1.2でカバーされている、(規則、2、A、2番目のポイント) ENUMエントリーがInterconnectのアクティブなPSTN Pointを持っていた数のために食糧を供給されなかったケースがセクション4.1.2でカバーされている、(規則、2、B、)
For "ENUM only" ranges, where a given number in that range was in service (i.e., there was an IP-based Point of Interconnect to a carrier), a valid SIP or H.323 URI was always provisioned into the associated ENUM domain. This is covered in Section 4.1.2 (rule 2 A, second point).
「ENUM専用」範囲において、有効なSIPかH.323 URIが関連ENUMドメインにいつも食糧を供給されました。そこでは、その範囲の与えられた数が使用中でした(すなわち、キャリヤーへのInterconnectのIPベースのPointがありました)。 これはセクション4.1.2で覆われています(規則2A、2番目に、指してください)。
In such an "ENUM only" range, if the number was not in service, a TXT record was provisioned but no valid NAPTRs would be present. This ensured that a query for NAPTRs in a given (out of service, "ENUM only" range) domain would succeed (i.e., return a RCODE of 0), but that the number of answers would also be zero. This is covered in Section 4.1.2 (rule 2 A, first point). Note that this point also covers the case where only NAPTRs that cannot be used to initiate a call exist in such a zone.
そのような「ENUM専用」範囲では、数が使用中でなかったなら、TXT記録が食糧を供給されましたが、どんな有効なNAPTRsも存在していないでしょう。 これは、与えられた(使われなくなっています、「ENUM専用」は及ぶ)ドメインのNAPTRsのための質問が成功するでしょうが(すなわち、0のRCODEを返してください)、また、答えの数がゼロであることを確実にしました。 これはセクション4.1.2で覆われています(規則2A、最初に、指してください)。 また、このポイントが呼び出しを開始するのに使用できないNAPTRsだけがそのようなゾーンに存在するケースをカバーすることに注意してください。
Where a valid URI was provisioned, the ENUM lookup would complete by returning that value for further processing. This further processing is covered in Section 4.2.
有効なURIが食糧を供給されたところでは、ENUMルックアップはさらなる処理のために戻るのによるその値を完成するでしょう。 このさらなる処理はセクション4.2でカバーされています。
For "ENUM only" ranges, there was a further policy requirement that an IP-based Point of Interconnect specified inside a NAPTR (as the domainpart of a valid URI) must be accessible for all potential carriers. The server could reject a subsequent SIP Invitation, but its machine address had to resolve. This was intended to avoid the condition where the domain name did not resolve, the softswitch logic would attempt to place the call via the PSTN, and this would fail and/or loop.
「ENUM専用」範囲には、すべての潜在的キャリヤーに、NAPTR(有効なURIのdomainpartとしての)の中で指定されたInterconnectのIPベースのPointがアクセスしやすいに違いないというさらなる方針要件がありました。 機械語アドレスだけが、サーバがその後のSIP Invitationを拒絶できたと決議しなければなりませんでした。 これがドメイン名がsoftswitch論理が、PSTNを通して電話をするのを試みて、これが失敗する、そして/または、輪にされると決議しなかった状態を避けることを意図しました。
Lim, et al. Informational [Page 5] RFC 5346 Enum-Based Softswitch Use October 2008
リム、他 情報[5ページ]のRFC5346のEnumベースのSoftswitchは2008年10月を使用します。
This "must resolve" requirement was not needed for numbers that had an active PSTN Point of Interconnect (i.e., the vast majority of assigned numbers). If the domain name did not resolve, the call would "drop back" to PSTN processing.
これが「決議しなければならない」という要件はInterconnect(すなわち、規定番号のかなりの大部分)のアクティブなPSTN Pointを持っていた数に必要ではありませんでした。 ドメイン名が、呼び出しがPSTN処理に「落ちる」と決議しなかったなら。
4.1.2. Trial ENUM Lookup Rules
4.1.2. トライアルENUMルックアップ規則
In the Korean trial, the rules were:
韓国のトライアルでは、規則は以下の通りでした。
1. The ENUM module of the softswitch converts an E.164 number coming
from the VoIP subscriber to an ENUM domain name (as defined in
RFC 3761).
1. softswitchのENUMモジュールはVoIP加入者からENUMドメイン名に来るE.164番号を変換します(RFC3761で定義されるように)。
2. The ENUM module, acting as a DNS stub resolver, sends a query to
a recursive name server.
2. DNSスタッブレゾルバとして機能して、ENUMモジュールは再帰的なネームサーバに質問を送ります。
3. If the ENUM module receives a DNS answer, the call routing
process may branch off in several ways, depending on the Rcode
value in the DNS response message, as shown below.
3. ENUMモジュールがDNS答えを受けるなら、呼び出しルーティングの過程はいくつかの方法で分岐するかもしれません、DNS応答メッセージにおけるRcode値によって、以下に示すように。
A. Rcode=0 (No error condition)
There is, potentially, an answer to the corresponding query.
The normal call routing process needs to differentiate
between the following conditions:
そこのA.Rcode=0(エラー条件がない)は潜在的に対応する質問の答えです。 正常な呼び出しルーティングの過程は、以下の条件を区別する必要があります:
+ The response includes no URI (such as SIP or H.323) that
can be used to initiate a call --
The call fails immediately.
Note: In the trial, the condition in which a telephone
number:
+ 応答は呼び出しを開始するのに使用できないURI(SIPかH.323などの)を全く含んでいます--呼び出しはすぐに、失敗します。 以下に注意してください。 トライアル、中の状態、どのa電話番号:
- is valid,
- 有効
- can only be reached via the Internet, but
- しかし、インターネットを通して達することができるだけです。
- is not currently in service
- 現在、使用中ではありません。
is indicated by an ENUM domain that DOES exist but DOES
NOT include any supported (routable) NAPTRs. A softswitch
receiving this response interprets it as indicating that
the call can be dropped immediately -- it would fail if
passed to the PSTN.
ENUMドメインによって示されて、そのDOESは存在していますが、DOES NOTはどんな支持された(発送可能)NAPTRsも含んでいます。 すぐに呼び出しを落とすことができるのを示すとこの応答を受けるsoftswitchはそれを解釈します--PSTNに通過されるなら、それは失敗するでしょう。
+ There is at least one usable URI (such as SIP and/or H.323
URIs) --
The softswitch picks one based on the preference and order
field values in the NAPTR Resource Record Set, and routes
the call using the method described in Section 4.2.
そこの+は少なくとも1つの使用可能なURI(SIP、そして/または、H.323URIなどの)です--好みに基づくものと注文にNAPTR Resource Record Setの分野値を選んで、softswitchはセクション4.2で説明された方法を使用する呼び出しをルートに選びます。
Lim, et al. Informational [Page 6] RFC 5346 Enum-Based Softswitch Use October 2008
リム、他 情報[6ページ]のRFC5346のEnumベースのSoftswitchは2008年10月を使用します。
B. Rcode=3 (Name error), 1 (Format Error), 2 (Server Failure), 4
(Not Implemented), or 5 (Refused)
There is no valid answer for the query.
The softswitch has no choice but to route the call using the
E.164 number with its vendor-specific method (such as a
prefix-based method). In this case, it means that the call
has to be delivered through the PSTN for onward call routing.
B.Rcode=3(名前誤り)、1(形式Error)、2(サーバFailure)、4(Implementedでない)、またはそこの5(拒否される)が質問のための有効な答えではありません。 softswitchは、業者特有の方法(接頭語ベースの方法などの)があるE.164番号を使用することで呼び出しを発送せざるを得ません。 この場合、それは、呼び出しが前方の呼び出しルーティングのためにPSTNを通して提供されなければならないことを意味します。
It is also important to stress that the ENUM DNS servers must
respond to all queries they receive from the softswitches.
If the ENUM module in a softswitch does not receive a
response, it will eventually time out, and the ENUM module
will treat this as a DNS error. However, the delay involved
is long in terms of the normal call setup time, and should be
avoided.
It would have been possible to modify the DNS code in each
softswitch to have shorter time-outs than normal to cover
misconfiguration of a DNS server, but this choice was not
considered in the trial. The softswitch DNS stack was used
for several purposes other than "pure" ENUM lookups.
Configuring it in a non-complaint manner was considered
unacceptable, due to the need to analyze the impact of that
choice on other DNS operations thoroughly before it could be
implemented safely.
また、圧力に、ENUM DNSサーバがそれらがsoftswitchesから受けるすべての質問に反応しなければならないのも、重要です。 softswitchのENUMモジュールが応答を受けないなら、結局タイムアウトを望んでいます、そして、ENUMモジュールはDNS誤りとしてこれを扱うでしょう。 しかしながら、かかわった遅れは、正常な呼び出し準備時間で長く、避けられるべきです。 それはDNSサーバのmisconfigurationを覆うために標準より短いタイムアウトを持つように各softswitchのDNSコードを変更するのにおいて可能だったでしょうが、この選択はトライアルでは考えられませんでした。 softswitch DNSスタックは「純粋な」ENUMルックアップ以外のいくつかの目的に使用されました。 非苦情方法でそれを構成するのは容認できないと考えられました、安全にそれを実行できる前に他のDNS操作のときにその選択の影響を徹底的に分析する必要性のため。
4.2. Call Routing Cases for Domainparts
4.2. Domainpartsのためにケースにルート設定に電話をしてください。
If the DNS response has a valid URI, such as SIP or H.323, the softswitch can resolve the domain name part of that URI to route a call by searching two different sources. One is a recursive nameserver, and the other is a fixed routing table held in the softswitch, mapping from the domain name to the corresponding gateway's host name and IP address.
DNS応答にSIPかH.323などの有効なURIがあるなら、softswitchは、2人のさまざまな原因を身体検査することによって呼び出しを発送するためにそのURIのドメイン名部分を決議できます。 1つは再帰的なネームサーバです、そして、対応するゲートウェイのドメイン名からホスト名とIPアドレスまでもう片方がsoftswitchで持たれていた、固定経路指定テーブル、マッピングです。
If there are many points of interconnection, using a recursive nameserver is useful for resolving a domain name, but if there are just a few known carriers and they do not change this interconnection information frequently, a fixed (internal) routing table mapping from domain name to the corresponding gateway hostname and IP address is more efficient (rather than querying the recursive nameserver every time). In addition, carriers would like to charge an interconnection fee for all received calls, so they tend to make interconnection only with trusted carriers based on some sort of bilateral agreement between these carriers. They may agree on a specific gateway for this purpose, so the interconnection information is often private to the parties of this particular agreement.
多くのポイントのインタコネクトがあれば、再帰的なネームサーバを使用するのはドメイン名を決議することの役に立ちますが、わずかいくつかの知られているキャリヤーがあって、彼らが頻繁にこのインタコネクト情報を変えないなら、ドメイン名から対応するゲートウェイホスト名とIPアドレスまでの固定された(内部の)経路指定テーブルマッピングは、より効率的です(毎回再帰的なネームサーバについて質問するよりむしろ)。 さらに、キャリヤーは、すべてのための接続料が呼び出しを受けたのでこれらのキャリヤーの間で単にある種の二国間条約に基づく信じられたキャリヤーでインタコネクトを作る傾向があると宣言したがっています。 彼らがこのために特定のゲートウェイに同意するかもしれないので、この特定の協定のパーティーに、インタコネクト情報はしばしば個人的です。
Lim, et al. Informational [Page 7] RFC 5346 Enum-Based Softswitch Use October 2008
リム、他 情報[7ページ]のRFC5346のEnumベースのSoftswitchは2008年10月を使用します。
In principle, these two approaches could be used in parallel, but in practice, if the DNS-based approach could be used, there would be no point in retaining the expensive and elaborate "offline" infrastructure to exchange and install the tables for domain routing. In this trial, uncertainty over the performance and reliability of ENUM-based processing meant that the softswtitches were configured so that they could be switched between the two approaches immediately. This was a temporary expedient only, and would not be a reasonable approach in the long term.
原則として、平行でこれらの2つのアプローチを使用できましたが、DNSベースのアプローチを使用できるなら、実際には、ドメインルーティングのためにテーブルを交換して、インストールするために高価で入念な「オフライン」のインフラストラクチャを保有する意味が全くないでしょうに。 このトライアルでは、ENUMベースの処理の性能と信頼性の上の不確実性は、softswtitchesがすぐに2つのアプローチの間にそれらを切り換えることができるように構成されたことを意味しました。 これは、臨時措置専用であり、長期で合理的なアプローチでないでしょう。
These two types of domain routing are also affected by the Rcode=0 case described in Section 4.1.
また、ドメインルーティングのこれらの2つのタイプがセクション4.1で説明されたRcode=0ケースで影響を受けます。
There are two choices for routing. These are described and compared here:
ルーティングのための2つの選択があります。 これらは、ここと説明されて、比較されます:
1. Case when using a fixed routing table:
1. 固定経路指定テーブルを使用するときのケース:
A. If the domain name part of the URI is found in the internal
fixed routing table, the softswitch can use it.
A. URIのドメイン名部分が内部の固定経路指定テーブルで見つけられるなら、softswitchはそれを使用できます。
B. If the domain name part of the URI does not exist in the
fixed routing table, the call is forwarded to the PSTN.
B. URIのドメイン名部分が固定経路指定テーブルに存在していないなら、呼び出しをPSTNに送ります。
2. Case when using a recursive nameserver:
2. 再帰的なネームサーバを使用するときのケース:
A. If the domain name part of the URI can be resolved via the
recursive nameserver, the softswitch can use it.
A. 再帰的なネームサーバでURIのドメイン名部分を決議できるなら、softswitchはそれを使用できます。
B. If the domain name part of the URI cannot be resolved on the
recursive nameserver for any reason (such as a response with
no usable resource records according to [RFC3263] and
[RFC3261], or with Rcode=1, 2, 3, 4, or 5), the call must be
forwarded to the PSTN.
B. どんな理由([RFC3263]と[RFC3261]、Rcode=1、2、3、4、または5がある使用可能なリソース記録のない応答などの)による再帰的なネームサーバでもURIのドメイン名部分を決議できないなら、呼び出しをPSTNに送らなければなりません。
Case (1) seems inefficient because the administrator maintains two management points for numbers: the ENUM DNS and the softswitch itself. However, this configuration can minimize the call routing failure ratio during the transition period of ENUM (when there are relatively few provisioned ENUM entries and so few IP-based Points Of Interconnection). Thus, case (1) could reasonably be implemented on the softswitches during the trial phase, and thereafter, as ENUM entries are populated, case (2) would be a reasonable choice.
管理者が数のために2管理ポイントを維持するので、ケース(1)は効率が悪く見えます: ENUM DNSとsoftswitch自身。 しかしながら、この構成はENUMの過渡期の間、呼び出しルーティング失敗比を最小にすることができます(比較的わずかな食糧を供給されたENUMエントリーととてもわずかIPベースのPoints Of Interconnectionがあるとき)。 したがって、トライアル段階の間、softswitchesで合理的にケース(1)を実行できました、そして、その後、ENUMエントリーが居住されるとき、ケース(2)は正当な選択でしょう。
With these choices, the two carriers could use ENUM DNS for call routing without any impact on their ongoing commercial VoIP service.
これらの選択で、2個のキャリヤーが呼び出しルーティングに彼らの進行中の商業VoIPサービスへの少しも影響なしでENUM DNSを使用できました。
Lim, et al. Informational [Page 8] RFC 5346 Enum-Based Softswitch Use October 2008
リム、他 情報[8ページ]のRFC5346のEnumベースのSoftswitchは2008年10月を使用します。
5. Trial Results
5. トライアル結果
To provide a stable commercial service, an ENUM-based softswitch must
have a defined performance, in the same way as must any non-ENUM-
based softswitch. The only difference between these two types of
softswitches is the searching mechanism for call routing information,
which can be stored in the softswitch itself or in the DNS.
Therefore, a similar delay time for call routing is important to
guarantee quality of service. During the trial, each carrier
measured this delay time when using the SIP protocol. This was based
on the "Answer Delay time", defined as the elapsed time between
requesting a call ('INVITE' message) and receiving a response ('200
OK' message) [RFC3261].
ENUMベースのsoftswitchには、安定した商業サービスを提供するために、定義された性能がなければなりません、同様にどんなでなければならないことのようにも非、-ベースのENUMはsoftswitchします。 softswitchesのこれらの2つのタイプの唯一の違いが呼び出しルーティング情報のための探すメカニズムです。(softswitch自身かDNSにそれを格納できます)。 したがって、呼び出しルーティングのための同様の遅延時間は、サービスの質を保証するために重要です。 この遅延時間にSIPプロトコルを使用するとき、トライアルの間、各キャリヤーは測定しました。 これは「答えDelay時間」に基づきました、要求('INVITE'メッセージ)を要求することの間の経過時間と定義されて、応答('200OK'メッセージ)[RFC3261]を受けて。
+------------------------+------+----------+
| Call Type | ENUM | Non-ENUM |
+------------------------+------+----------+
| Carrier A->A | 2.33 | 2.28 |
| Carrier A->B | 2.23 | 2.25 |
| Carrier A->other(PSTN) | 4.11 | 3.79 |
| Carrier B->B | 2.18 | 2.05 |
| Carrier B->A | 2.19 | 2.19 |
| Carrier B->other(PSTN) | 3.95 | 3.41 |
+------------------------+------+----------+
+------------------------+------+----------+ | タイプに電話をしてください。| ENUM| 非ENUM| +------------------------+------+----------+ | キャリヤーA>A| 2.33 | 2.28 | | キャリヤーの1>のB| 2.23 | 2.25 | | キャリヤー1>のもう一方(PSTN)| 4.11 | 3.79 | | キャリヤーB>B| 2.18 | 2.05 | | キャリヤーB>A| 2.19 | 2.19 | | キャリヤー、B->他、(PSTN)| 3.95 | 3.41 | +------------------------+------+----------+
Table 1: Average Answer Delay Time (Sec)
テーブル1: 平均した答え遅延時間(秒)
As shown in Table 1, there is little difference in time (under a second) between the ENUM and non-ENUM cases. Therefore, it is difficult for a caller with either carrier to detect the choice (ENUM or non-ENUM) as an aspect of quality when a call initiates. This means that ENUM definitely works well with softswitches on a commercial basis.
Table1に示されるように、ENUMと非ENUMケースの間には、少しの違いが時間内に(1秒の下で)あります。 したがって、どちらかのキャリヤーをもっている訪問者が呼び出しであることの品質の局面としての選択(ENUMか非ENUM)開始を検出するのは、難しいです。 これは、ENUMが確実にsoftswitchesで商業ベースでうまくいくことを意味します。
To make the trial more realistic, the resolver that was used by these ENUM-based softswitches was a recursive nameserver that could be accessed publicly. This was done as it was felt that a tough condition would be better to verify the fact that an ENUM-based softswitch works as well as a non-ENUM-based softswitch in providing a commercial VoIP service.
トライアルをより現実的にするように、これらのENUMベースのsoftswitchesによって使用されたレゾルバは公的にアクセスできた再帰的なネームサーバでした。 厳しい状態が事実について確かめるために、より良いとENUMベースのsoftswitchが商業VoIPサービスを提供することにおける非ENUMベースのsoftswitchと同様に働いているのを感じたとき、これをしました。
6. 'e164.arpa' Considerations
6. 'e164.arpa'問題
During the trial, the Infrastructure ENUM deployed in the 2.8.e164.arpa zone could be accessed via the (public) Internet. In this situation, each carrier questioned whether or not the centralized number management under the ENUM DNS was realistic.
トライアルの間、(公共)のインターネットを通して2.8.e164.arpaゾーンで配備されたInfrastructure ENUMにアクセスできました。 この状況で、各キャリヤーは、ENUM DNSの下の集結された数の管理が現実的であるかどうかと疑いました。
Lim, et al. Informational [Page 9] RFC 5346 Enum-Based Softswitch Use October 2008
リム、他 情報[9ページ]のRFC5346のEnumベースのSoftswitchは2008年10月を使用します。
Another issue concerned responsibility for routing errors. All carriers can use the shared ENUM data to route their calls. However, if there are routing errors (due to the data being provisioned incorrectly), it is not always clear who has responsibility for these errors and who can correct the data. The errors occur in the networks of the carriers placing the calls. Unless the identity of the carrier responsible for delivering service to this telephone number is known, it is not obvious (to the carrier handling the error) who should be informed of these problems. This is a particular issue when number portability is introduced.
別の問題はルーティング誤りへの責任に関係がありました。 すべてのキャリヤーが、彼らの呼び出しを発送するのに共有されたENUMデータを使用できます。 しかしながら、ルーティング誤り(不当に食糧を供給されるデータによる)があれば、だれにこれらの誤りへの責任があるか、そして、だれがデータを修正できるかは、いつも明確であるというわけではありません。 誤りは電話をしているキャリヤーのネットワークで発生します。 だれがこれらの問題において知識があるべきですか?この電話番号に対するサービスを提供するのに責任があるキャリヤーのアイデンティティが知られていない場合、ナンバーポータビリティを導入するとき、これが特定の問題であることは明白ではありません(誤りを扱っているキャリヤーへの)。
In addition, the carriers also question whether or not Infrastructure ENUM needs to be accessible publicly. To prevent disclosure of telephone numbers, they would prefer to access the ENUM DNS privately. Therefore, any ENUM module embedded in a softswitch needs to be flexible to adopt these considerations during the interim period of ENUM, before common policies and agreements have been forged.
また、さらに、キャリヤーは、Infrastructure ENUMが、公的にアクセスしやすい必要であるかどうかと疑います。 電話番号の公開を防ぐために、それらは、ENUM DNSに個人的にアクセスするのを好むでしょう。 したがって、softswitchに埋め込まれたどんなENUMモジュールも、ENUMの暫時の間、これらの問題を採用するのにおいてフレキシブルである必要があります、共通政策と協定が作り出される前に。
7. Security Considerations
7. セキュリティ問題
This document inherits the security considerations described in RFC 3761 and [RFC5067], as the ENUM DNS used with softswitches in this trial could be accessed publicly.
このドキュメントはRFC3761と[RFC5067]で説明されたセキュリティ問題を引き継ぎます、公的にsoftswitchesと共にこのトライアルに使用されるENUM DNSにアクセスできたとき。
In addition, if the recursive resolvers handling ENUM queries coming from a softswitch were to be compromised by an attacker, that attacker would be able to force calls to fail or cause delay to calls. Therefore, the DNS resolvers used should allow access from the local network to which the softswitch is connected, whilst restricting access from outside, using a proper access-list policy.
さらに、softswitchから来るENUM質問を扱っている再帰的なレゾルバが攻撃者によって妥協されることになっているなら、その攻撃者は失敗するという要求か原因遅れを呼び出しに強制できるでしょうに。 したがって、レゾルバが使用したDNSはsoftswitchが外部からアクセスを制限している間に関連している企業内情報通信網からアクセスを許すはずです、適切なアクセスリスト方針を使用して。
8. Acknowledgements
8. 承認
Thanks to Richard Shockey, Jason Livingood, Karsten Fleischhauer, Jim Reid, and Otmar Lendl who helped guide the direction of this document, and to Suresh Krishnan, whose GEN-ART review was very helpful.
このドキュメントの指示を誘導するのを助けたリチャード・ショッキー、ジェイソンLivingood、カルステンFleischhauer、ジム・リード、およびOtmarレンドルおかげ、およびSureshクリシュナンにとって、GEN-ARTがだれのものを見直すかは、非常に役立っていました。
Lim, et al. Informational [Page 10] RFC 5346 Enum-Based Softswitch Use October 2008
リム、他 情報[10ページ]のRFC5346のEnumベースのSoftswitchは2008年10月を使用します。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[E164] ITU-T, "The International Public Telecommunication
Number Plan", Recommendation E.164, February 2005.
[164E]ITU-T、「国際公共の電気通信数のプラン」、推薦E.164、2005年2月。
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System
(DDDS) Part Three: The Domain Name System (DNS)
Database", RFC 3403, October 2002.
[RFC3403]食事、M.、「ダイナミックな代表団発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761,
April 2004.
[RFC3761]FaltstromとP.とM.食事、「Uniform Resource Identifier(URI)ダイナミックな代表団発見システム(DDDS)アプリケーション(ENUM)へのE.164」、RFC3761、2004年4月。
9.2. Informative References
9.2. 有益な参照
[ENUMSERVICE-GUIDE]
Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
Registration of Enumservices: Guide, Template, and IANA
Considerations", Work in Progress, September 2008.
[ENUMSERVICE-ガイド]Hoeneisen、B.、マイルホーファー、A.、およびJ.Livingood、「EnumservicesのIANA登録:」 「ガイド、テンプレート、およびIANA問題」は進歩、2008年9月に働いています。
[H323] ITU-T, "Packet-based multimedia communications
systems", Recommendation H.323, 2003.
[H323]ITU-T、「パケットベースのマルチメディア通信システム」、Recommendation H.323、2003。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS
UPDATE)", RFC 2136, April 1997.
Vixie、P.、トムソン、S.、Rekhter、Y.、およびJ.が縛った[RFC2136]、「ドメインネームシステムにおけるダイナミックなアップデート(DNSアップデート)」、RFC2136(1997年4月)。
[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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC3263] Rosenberg, J., "Session Initiation Protocol (SIP):
Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] ローゼンバーグ、J.、「セッション開始は(一口)について議定書の中で述べます」。 「一口サーバの場所を見つけます」、RFC3263、2002年6月。
[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control
Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[RFC3435] Andreasen、F.、およびB.フォスター、「メディアゲートウェイコントロールは2003年1月にバージョン1インチ、(MGCP)RFC3435について議定書の中で述べます」。
Lim, et al. Informational [Page 11] RFC 5346 Enum-Based Softswitch Use October 2008
リム、他 情報[11ページ]のRFC5346のEnumベースのSoftswitchは2008年10月を使用します。
[RFC3761bis] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)", Work
in Progress, February 2008.
「Uniform Resource Identifier(URI)ダイナミックな代表団発見システム(DDDS)アプリケーション(ENUM)へのE.164」という[RFC3761bis]ブラドナー、S.、コンロイ、L.、およびK.フジワラは進行中(2008年2月)で働いています。
[RFC4114] Hollenbeck, S., "E.164 Number Mapping for the
Extensible Provisioning Protocol (EPP)", RFC 4114,
June 2005.
[RFC4114] Hollenbeck、S.、「広げることができる食糧を供給するプロトコルのために(EPP)を写像するE.164番号」、RFC4114、2005年6月。
[RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM
Requirements", RFC 5067, November 2007.
[RFC5067] リンドとS.とP.Pfautz、「インフラストラクチャENUM要件」、RFC5067、2007年11月。
Lim, et al. Informational [Page 12] RFC 5346 Enum-Based Softswitch Use October 2008
リム、他 情報[12ページ]のRFC5346のEnumベースのSoftswitchは2008年10月を使用します。
Authors' Addresses
作者のアドレス
JoonHyung Lim National Internet Development Agency of Korea(NIDA) 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu Seoul Korea
韓国代理店(ナイダ)3JoonHyungリムNationalのインターネット開発F。 KTF B/D1321-11、Seocho-ドング、Seocho-guソウル韓国
Phone: +82-2-2186-4548 EMail: jhlim@nida.or.kr URI: http://www.nida.or.kr
以下に電話をしてください。 +82-2-2186-4548 メールしてください: jhlim@nida.or.kr ユリ: http://www.nida.or.kr
Weon Kim National Internet Development Agency of Korea(NIDA) 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu Seoul Korea
韓国代理店(ナイダ)3WeonキムNationalのインターネット開発F。 KTF B/D1321-11、Seocho-ドング、Seocho-guソウル韓国
Phone: +82-2-2186-4502 EMail: wkim@nida.or.kr URI: http://www.nida.or.kr
以下に電話をしてください。 +82-2-2186-4502 メールしてください: wkim@nida.or.kr ユリ: http://www.nida.or.kr
ChanKi Park National Internet Development Agency of Korea(NIDA) 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu Seoul Korea
ChanKiは韓国代理店(ナイダ)3国家のインターネット開発F駐車します。 KTF B/D1321-11、Seocho-ドング、Seocho-guソウル韓国
Phone: +82-2-2186-4504 EMail: ckp@nida.or.kr URI: http://www.nida.or.kr
以下に電話をしてください。 +82-2-2186-4504 メールしてください: ckp@nida.or.kr ユリ: http://www.nida.or.kr
Lawrence Conroy Roke Manor Research Roke Manor Old Salisbury Lane Romsey United Kingdom
ローレンスコンロイRoke荘園研究Roke Manorの古いソールズベリーレーンロムジーイギリス
Phone: +44-1794-833666 EMail: lconroy@insensate.co.uk URI: http://www.sienum.co.uk
以下に電話をしてください。 +44-1794-833666はメールされます: lconroy@insensate.co.uk ユリ: http://www.sienum.co.uk
Lim, et al. Informational [Page 13] RFC 5346 Enum-Based Softswitch Use October 2008
リム、他 情報[13ページ]のRFC5346のEnumベースのSoftswitchは2008年10月を使用します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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に情報を記述してください。
Lim, et al. Informational [Page 14]
リム、他 情報[14ページ]
一覧
スポンサーリンク
