RFC5278 日本語訳
5278 IANA Registration of Enumservices for Voice and Video Messaging.J. Livingood, D. Troshynski. July 2008. (Format: TXT=39745 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Livingood
Request for Comments: 5278 Comcast Cable Communications
Category: Standards Track D. Troshynski
Acme Packet
July 2008
Livingoodがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5278年のコムキャスト有線通信カテゴリ: 標準化過程D.Troshynski頂上パケット2008年7月
IANA Registration of Enumservices for Voice and Video Messaging
声とビデオメッセージングのためのEnumservicesの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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system. This vmsg Enumservice registers three Enumservice types: "voicemsg", "videomsg", and "unifmsg". Each type also registers the subtypes "sip", "sips", "http", and "https", as well as the subtype "tel" for the "voicemsg" type.
このドキュメントは声、ビデオ、および統一されたコミュニケーションのリアルタイムのルーティングをメッセージシステムに容易にするのに使用される"vmsg"というEnumserviceを登録します。 このvmsg Enumserviceレジスタthree Enumserviceはタイプします: "voicemsg"、"videomsg"、および"unifmsg"。 また、各タイプは血液型亜型「一口」を登録します、と"voicemsg"のための「一口」、"http"、"https"、および「副-タイプ」"tel"はタイプします。
Livingood & Troshynski Standards Track [Page 1] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Selected Use Cases for Illustrative Purposes ...............4
1.2. Consideration of Other Existing Enumservices ...............5
2. Distribution of Data ............................................5
3. Security Considerations .........................................5
4. ENUM Service Registration for voicemsg ..........................6
4.1. Registration for "voicemsg" with Subtype "sip" .............6
4.2. Registration for "voicemsg" with Subtype "sips" ............7
4.3. Registration for "voicemsg" with Subtype "tel" .............7
4.4. Registration for "voicemsg" with Subtype "http" ............8
4.5. Registration for "voicemsg" with Subtype "https" ...........9
5. ENUM Service Registration for videomsg .........................10
5.1. Registration for "videomsg" with Subtype "sip" ............10
5.2. Registration for "videomsg" with Subtype "sips" ...........10
5.3. Registration for "videomsg" with Subtype "http" ...........11
5.4. Registration for "videomsg" with Subtype "https" ..........12
6. ENUM Service Registration for unifmsg ..........................13
6.1. Registration for "unifmsg" with Subtype "sip" .............13
6.2. Registration for "unifmsg" with Subtype "sips" ............13
6.3. Registration for "unifmsg" with Subtype "http" ............14
6.4. Registration for "unifmsg" with Subtype "https" ...........15
7. Selected Examples for Illustrative Purposes ....................16
7.1. Example Using a 'sip' URI .................................16
7.2. Example Using a 'tel' URI .................................16
7.3. Example Using a Backreference .............................16
7.4. Example Using a 'sip' URI without a Telephone Number ......17
7.5. Example of Failover Using E2U+videomsg:sip ................17
8. Implementation Recommendations .................................17
8.1. Call Processing When Multiple Records Are Returned ........17
8.2. NAPTR Configuration Issues ................................18
9. IANA Considerations ............................................18
10. Acknowledgements ..............................................18
11. Contributors ..................................................19
12. References ....................................................19
12.1. Normative References .....................................19
12.2. Informative References ...................................20
1. 序論…3 1.1. 選択されて、説明に役立った目的にケースを使用してください…4 1.2. 他の既存のEnumservicesの考慮…5 2. データの分配…5 3. セキュリティ問題…5 4. voicemsgのためのENUM Service Registration…6 4.1. Subtype「一口」がある"voicemsg"のための登録…6 4.2. Subtypeがある"voicemsg"のための登録は「ちびちび飲まれます」…7 4.3. Subtype"tel"がある"voicemsg"のための登録…7 4.4. Subtype"http"がある"voicemsg"のための登録…8 4.5. Subtype"https"がある"voicemsg"のための登録…9 5. videomsgのためのENUM Service Registration…10 5.1. Subtype「一口」がある"videomsg"のための登録…10 5.2. Subtypeがある"videomsg"のための登録は「ちびちび飲まれます」…10 5.3. Subtype"http"がある"videomsg"のための登録…11 5.4. Subtype"https"がある"videomsg"のための登録…12 6. unifmsgのためのENUM Service Registration…13 6.1. Subtype「一口」がある"unifmsg"のための登録…13 6.2. Subtypeがある"unifmsg"のための登録は「ちびちび飲まれます」…13 6.3. Subtype"http"がある"unifmsg"のための登録…14 6.4. Subtype"https"がある"unifmsg"のための登録…15 7. 説明に役立った目的のための例を選択します…16 7.1. '一口'URIを使用する例…16 7.2. 'tel'URIを使用する例…16 7.3. Backreferenceを使用する例…16 7.4. 電話番号なしで'一口'URIを使用する例…17 7.5. E2U+videomsgを使用するフェイルオーバーに関する例: ちびちび飲んでください…17 8. 実装推薦…17 8.1. 複数の記録を返すときには処理に電話をしてください…17 8.2. NAPTR構成問題…18 9. IANA問題…18 10. 承認…18 11. 貢献者…19 12. 参照…19 12.1. 標準の参照…19 12.2. 有益な参照…20
Livingood & Troshynski Standards Track [Page 2] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[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 Naming Authority Pointer (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.
ドメインネームシステム、NS記録を通したRFC1034[3])委譲とNaming Authority Pointer(NAPTR)は記録します。ENUM、(E.164 Number Mapping、RFC3761[1])がE.164番号を変える技術である、(国際Public Telecommunication Numbering Plan、ドメイン名と次に、用途へのITU-T Recommendation E.164[2])DNS、((ダイナミックな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])階層構造。
Voice messaging systems are used widely with telephony and voice communication services. The need for a voice messaging service type has become clear in order to provide certain applications with direct access to various voice messaging services (for example, voicemail), most typically via the use of SIP.
声のメッセージシステムは電話と声の通信サービスと共に広く使用されます。 声のメッセージングサービスタイプの必要性は様々な音声メッセージングサービス(例えば、ボイスメール)への直接アクセスをあるアプリケーションに提供するために明確になりました、通常SIPの使用を通した大部分。
The authors considered the use of Voice Profile for Internet Mail (VPIM) [14] but found that VPIM was best suited to the non-real-time and non-session-based routing of a voice message once it had been deposited into a voice messaging system. Thus, VPIM was a good solution for the non-real-time and non-session-based routing of voice messages between and within domains, but it did not enable real-time interaction with a voice messaging system.
それがいったん声のメッセージシステムに預けられると、作者は、Voice Profileのインターネットメール(VPIM)[14]の使用を考えましたが、音声メールの非リアルタイムで非セッションベースのルーティングにVPIMを合わせたのが最も良いのがわかりました。 したがって、VPIMはドメインとドメインの中の音声メールの非リアルタイムで非セッションベースのルーティングのための良いソリューションでしたが、それは声のメッセージシステムとのリアルタイムの相互作用を可能にしませんでした。
Thus, a need has been identified for this voice messaging service type that would enable, for example, some of the use cases listed in this section.
したがって、必要性はケースがこのセクションで記載した例えば、何らかの使用を可能にするこの声のメッセージングサービスタイプのために特定されました。
Video messaging systems, sometimes called visual voice messaging systems, are beginning to be used with real-time communication services. The need for a video messaging service type has become clear in order to provide certain applications with direct access to various video messaging services, most typically via the use of SIP. Thus, a need has been identified for this video messaging service type that would enable, for example, some of the use cases listed in this section.
瞬時通信サービスと共に時々視覚声のメッセージシステムと呼ばれたビデオメッセージシステムは使用され始めています。 ビデオメッセージングサービスタイプの必要性は、様々なビデオメッセージングサービス(通常SIPの使用を通した大部分)への直接アクセスに、ある利用を提供するために明確になりました。 したがって、必要性はケースがこのセクションで記載した例えば、何らかの使用を可能にするこのビデオメッセージングサービスタイプのために特定されました。
Livingood & Troshynski Standards Track [Page 3] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[3ページ]。
Finally, several service providers and software developers have indicated that their system for voice messaging and video messaging either have been or soon will be unified into a single system. As such, they desired to have the option of using an Enumservice type that represents a subscriber's mailbox as being a so-called unified messaging repository. Thus, a need has been identified for this unified voice and video messaging service type that would enable, for example, some of the use cases listed in this section.
最終的に、いくつかのサービスプロバイダーと開発者が持っているソフトウェアは、彼らの声のメッセージングと通信するビデオのシステムがそうであることを示すか、またはすぐ、ただ一つのシステムに統一されるでしょう。 そういうものとして、彼らは、いわゆるユニファイド・メッセージング倉庫であるとして加入者のメールボックスを表すEnumserviceタイプを使用するオプションを持っていることを望んでいました。 したがって、必要性はケースがこのセクションで記載した例えば、何らかの使用を可能にするこの統一された声とビデオメッセージングサービスタイプのために特定されました。
1.1. Selected Use Cases for Illustrative Purposes
1.1. 選択されて、説明に役立った目的にケースを使用してください。
The following is a partial, non-exclusive list of use cases that the vmsg Enumservice could address:
以下はa部分的であり、使用の非排他的なリストはvmsg Enumserviceが扱うことができたそうです:
* A called party is busy or does not answer a call. A client or
server then determines that a messaging service should be used and
sends the calling party's session to such a service. The client or
server needs to be able to determine which server to direct this
real-time session to, whether that is within or outside of the
called party's domain.
* 被呼者は、忙しいか、または呼び出しに答えません。 クライアントかサーバが、次に、メッセージングサービスが使用されるべきであると決心して、そのようなものに対するサービスを起呼側のセッションに送ります。 クライアントかサーバが、それが被呼者のドメインの中か外にいるか否かに関係なく、そうするようこのリアルタイムのセッションに指示するためにどのサーバを決定できる必要があります。
* Similar to the above use case, a real-time session is attempted to
a messaging system, but that system is currently unavailable.
Since multiple service type records may be returned by the original
ENUM query, the client or server could then attempt to initiate a
session with one or more backup messaging servers in a manner that
is transparent to the calling party and that supports better
overall availability of a messaging service.
* 使用がケースに入れる上記で同様です、リアルタイムのセッションはメッセージシステムに試みられますが、そのシステムは現在、入手できません。 オリジナルのENUM質問で複数のサービスタイプ記録を返すかもしれないので、そして、クライアントかサーバが、起呼側にとって透明であり、メッセージングサービスの、より良い総合的な有用性をサポートする方法でサーバを通信させる1つ以上のバックアップとのセッションを開始するのを試みるかもしれません。
* Similar to the above use case, this service type could be used to
balance load across multiple messaging servers, whether those are
in the same or in different physical locations.
* 使用がケースに入れる上記で同様です、複数のメッセージングサーバの向こう側に負荷のバランスをとるのにこのサービスタイプを使用できました、それらが同じくらいか異なった物理的な位置にいるか否かに関係なく。
* A user with an account on a messaging service needs to connect to
the messaging service in order to retrieve messages. They initiate
a real-time session, and an ENUM query is performed to discover the
messaging server that holds its mailbox.
* メッセージングサービスの上にアカウントがあるユーザは、メッセージを検索するためにメッセージングサービスに接続する必要があります。 彼らはリアルタイムのセッションを開始します、そして、ENUM質問は、メールボックスを支えるメッセージングサーバを発見するために実行されます。
* In the process of invoking and supporting a real-time, automated
and interactive session with a user, whether for message deposit or
retrieval, VoiceXML files are referenced and utilized, via either
HTTP or HTTPS. Multiple VoiceXML servers could be associated with
a user and returned via ENUM query, for the purposes of load
balancing, for example.
* メッセージ預金か検索にかかわらずユーザとのリアルタイムで、自動化されて対話的なセッションを呼び出して、サポートすることの途中に、VoiceXMLファイルは、参照をつけられて、利用されます、HTTPかHTTPSのどちらかを通して。例えば、ロードバランシングの目的のために複数のVoiceXMLサーバをユーザに関連づけて、ENUM質問で返すことができるでしょう。
Livingood & Troshynski Standards Track [Page 4] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[4ページ]。
1.2. Consideration of Other Existing Enumservices
1.2. 他の既存のEnumservicesの考慮
The authors considered whether this service type could simply use the SIP Enumservice type [19], but found that it does not satisfy their voice messaging requirements, particularly given the non-SIP URI sub- types specified herein. Even with sub-types for SIP URIs, however, there are challenges to using the SIP Enumservice type. For example, a request for access to such a service could be extended to the requesting SIP client, or User Agent Client (UAC), rather than relying upon the local policy of a SIP server, or User Agent Server (UAS), which means that special routing logic within a UAS cannot be relied upon to solve this problem. More importantly, however, the authors have found that without this service type, a UAC or UAS will be presented with multiple SIP URIs, with no ability other than in non-standards-based routing rules or application logic to recognize which one is related to a voice messaging, video messaging, or unified voice and video messaging service.
作者は、このサービスタイプが単にSIP Enumserviceタイプ[19]を使用できるかどうか考えましたが、それが彼らの声のメッセージング要件を満たさないのがわかりました、ここに指定された非SIP URIサブタイプを特に考えて。 しかしながら、SIP URIのためのサブタイプがあっても、SIP Enumserviceタイプを使用することへの挑戦があります。 例えば、そのようなサービスへのアクセスがあるかもしれないので、要求はこの問題を解決するためにUASの中の特別なルーティング論理を当てにすることができないことを意味するSIPサーバ、またはUserエージェントServer(UAS)のローカルの方針を当てにするよりむしろ、要求しているSIPクライアント、またはUserエージェントClient(UAC)に達しました。 しかしながら、より重要に、作者は、このサービスタイプがなければ、複数のSIP URIがUACかUASに与えられるのがわかりました、コネ以外の能力なしで非、規格ベース、規則か認識する声のメッセージングか、ビデオメッセージングか、統一された声とビデオメッセージングサービスに関連するアプリケーション論理を発送します。
2. Distribution of Data
2. データの分配
The authors believe that it is more likely that these records will be distributed on a purely private basis, but they may also be distributed in public ENUM trees. Distribution of this NAPTR data could be either (a) on a private basis within a service provider's internal network, (b) on a private basis between one or more parties using a variety of security mechanisms to prohibit general public access, or (c) openly available.
作者は、これらの記録が純粋に個人的なベースで分配されますが、また、それらが公共のENUM木で分配されるかもしれないのが、おそらくであると信じています。 このNAPTRデータの分配は(a) (b) (c) サービスプロバイダーの内部のネットワークの中の個人的ベース、一般アクセスを禁止するのにさまざまなセキュリティー対策を使用している1回以上のパーティーの間の個人的ベース、またはオープンに利用可能であるかもしれません。
3. Security Considerations
3. セキュリティ問題
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 voicemsg 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がvoicemsg Enumserviceデータを保守するのに木としてe164.arpaか他の公的に利用可能なドメインを使用するなら、だれにとっても、この情報は匿名で目に見えるでしょう。 これはそのようなデータが戸外か少しも指示のないそのようなデータへの容易さアクセスであるのにもかかわらずの、アクセスされて、するか、またはそれがアクセスされたTelephoneディレクトリにおける公表と質的に異なっていませんが。
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 it can use to make unsolicited telemarketing phone calls, or so-called SPAM over Internet Telephony (SPIT). Many countries have do-not-call registries or other legal or regulatory mechanisms in place to deal with such abuses.
第三者に取り入れられるそのようなデータは、求められていない情報のための目標のリストを生成するのにしばしば使用されます。 したがって、第三者は、それが求められていないテレマーケティング電話、またはインターネットの上のいわゆるスパムをTelephony(SPIT)にするのに使用できるリストを生成するのにこれを使用できました。 多くの国が、そのような乱用に対処するために適所に電話勧誘辞退登録か他の法的であるか規定のメカニズムを持っています。
Livingood & Troshynski Standards Track [Page 5] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[5ページ]。
As noted earlier, carriers, service providers, and other users may simply choose not to publish such information in the public e164.arpa tree, but may instead simply publish this in their internal ENUM routing database that is only able to be queried by trusted elements of their network and/or partner networks, 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木でそのような情報を発表しないのを単に選びますが、代わりにそれらのネットワーク、そして/または、パートナーネットワークの信じられた原理で質問できるだけである彼らの内部のENUMルーティングデータベースで単にこれを発行するかもしれません、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 [16] to this is provided in RFC 3761 [1]. A thorough analysis of threats to the DNS itself is covered in RFC 3833 [17].
DNSへのENUMの依存とDNSSEC[16]のこれへの適用性に特定の脅威の分析をRFC3761[1]に提供します。 DNS自身への脅威の徹底的な分析はRFC3833[17]でカバーされています。
4. ENUM Service Registration for voicemsg
4. voicemsgのためのENUM Service Registration
4.1. Registration for "voicemsg" with Subtype "sip"
4.1. Subtype「一口」がある"voicemsg"のための登録
Enumservice Name: "voicemsg"
Enumserviceは以下を命名します。 "voicemsg"
Enumservice Type: "voicemsg"
Enumserviceはタイプします: "voicemsg"
Enumservice Subtypes: "sip"
Enumservice血液型亜型: 「一口」
URI Schemes: 'sip:'
URI体系: 'ちびちび飲んでください'
Functional Specification:
機能的な仕様:
This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a voice communication session to a voice messaging system.
このEnumserviceは、声のコミュニケーションセッションを声のメッセージシステムに開始するために関連URI体系で特定された遠隔資源は扱うことができるのを示します。
Security Considerations: See Section 3.
セキュリティ問題: セクション3を見てください。
Intended Usage: COMMON
意図している用法: 一般的
Authors:
作者:
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood( jason_livingood@cable.comcast.com )ドンTroshynski( dtroshynski@acmepacket.com )
Livingood & Troshynski Standards Track [Page 6] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[6ページ]。
Any other information the author deems interesting:
作者がおもしろいと考えるいかなる他の情報も:
Implementers should review a non-exclusive list of examples below in Section 7.
Implementersはセクション7で以下の例の非排他的なリストを再検討するはずです。
4.2. Registration for "voicemsg" with Subtype "sips"
4.2. Subtype「一口」がある"voicemsg"のための登録
Enumservice Name: "voicemsg"
Enumserviceは以下を命名します。 "voicemsg"
Enumservice Type: "voicemsg"
Enumserviceはタイプします: "voicemsg"
Enumservice Subtypes: "sips"
Enumservice血液型亜型: 「一口」
URI Schemes: 'sips:'
URI体系: '一口:'
Functional Specification:
機能的な仕様:
This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a voice communication session to a voice messaging system.
このEnumserviceは、声のコミュニケーションセッションを声のメッセージシステムに開始するために関連URI体系で特定された遠隔資源は扱うことができるのを示します。
Security Considerations: See Section 3.
セキュリティ問題: セクション3を見てください。
Intended Usage: COMMON
意図している用法: 一般的
Authors:
作者:
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood( jason_livingood@cable.comcast.com )ドンTroshynski( dtroshynski@acmepacket.com )
Any other information the author deems interesting:
作者がおもしろいと考えるいかなる他の情報も:
Implementers should review a non-exclusive list of examples below in Section 7.
Implementersはセクション7で以下の例の非排他的なリストを再検討するはずです。
4.3. Registration for "voicemsg" with Subtype "tel"
4.3. Subtype"tel"がある"voicemsg"のための登録
Enumservice Name: "voicemsg"
Enumserviceは以下を命名します。 "voicemsg"
Enumservice Type: "voicemsg"
Enumserviceはタイプします: "voicemsg"
Enumservice Subtype: "tel"
Enumservice Subtype: "tel"
URI Schemes: 'tel:'
URI体系: 'tel:'
Livingood & Troshynski Standards Track [Page 7] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[7ページ]。
Functional Specification:
機能的な仕様:
This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a voice communication session to a voice messaging system.
このEnumserviceは、声のコミュニケーションセッションを声のメッセージシステムに開始するために関連URI体系で特定された遠隔資源は扱うことができるのを示します。
Security Considerations: See Section 3.
セキュリティ問題: セクション3を見てください。
Intended Usage: COMMON
意図している用法: 一般的
Authors:
作者:
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood( jason_livingood@cable.comcast.com )ドンTroshynski( dtroshynski@acmepacket.com )
Any other information the author deems interesting:
作者がおもしろいと考えるいかなる他の情報も:
Implementers should review a non-exclusive list of examples below in Section 7.
Implementersはセクション7で以下の例の非排他的なリストを再検討するはずです。
4.4. Registration for "voicemsg" with Subtype "http"
4.4. Subtype"http"がある"voicemsg"のための登録
Enumservice Name: "voicemsg"
Enumserviceは以下を命名します。 "voicemsg"
Enumservice Type: "voicemsg"
Enumserviceはタイプします: "voicemsg"
Enumservice Subtype: "http"
Enumservice Subtype: "http"
URI Schemes: 'http:'
URI体系: 'http:'
Functional Specification:
機能的な仕様:
This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information.
このEnumserviceは、関連URI体系によって特定された遠隔資源は情報源であることができるのを示します。
Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'http:' [11] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even voice message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource.
情報の種類が検索した注意は多種多様である場合があります。 通常、'httpはリソースに連絡します: '[11]URIはドキュメントを提供します。 このドキュメントは多くの異種の情報のダウンロードの引き金となる参照を含むことができます、テキスト、オーディオ、ビデオ、実行コード、または音声メールファイルなどのようにさえ。 したがって、1つはリソースに連絡するとき予想された情報の種類に関して、より特定であるはずがありません。
Security Considerations: See Section 3.
セキュリティ問題: セクション3を見てください。
Intended Usage: COMMON
意図している用法: 一般的
Livingood & Troshynski Standards Track [Page 8] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[8ページ]。
Authors:
作者:
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood( jason_livingood@cable.comcast.com )ドンTroshynski( dtroshynski@acmepacket.com )
Any other information the author deems interesting:
作者がおもしろいと考えるいかなる他の情報も:
Implementers should review a non-exclusive list of examples below in Section 7.
Implementersはセクション7で以下の例の非排他的なリストを再検討するはずです。
4.5. Registration for "voicemsg" with Subtype "https"
4.5. Subtype"https"がある"voicemsg"のための登録
Enumservice Name: "voicemsg"
Enumserviceは以下を命名します。 "voicemsg"
Enumservice Type: "voicemsg"
Enumserviceはタイプします: "voicemsg"
Enumservice Subtype: "https"
Enumservice Subtype: "https"
URI Schemes: 'https:'
URI体系: 'https:'
Functional Specification:
機能的な仕様:
This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information, which can be contacted using TLS or the Secure Socket Layer protocol.
このEnumserviceは、関連URI体系によって特定された遠隔資源は情報源であることができるのを示します。(TLSかSecure Socket Layerプロトコルを使用することで情報源に連絡できます)。
Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'https:' [12] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even voice message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource.
情報の種類が検索した注意は多種多様である場合があります。 通常、'httpsはリソースに連絡します: '[12]URIはドキュメントを提供します。 このドキュメントは多くの異種の情報のダウンロードの引き金となる参照を含むことができます、テキスト、オーディオ、ビデオ、実行コード、または音声メールファイルなどのようにさえ。 したがって、1つはリソースに連絡するとき予想された情報の種類に関して、より特定であるはずがありません。
Security Considerations: See Section 3.
セキュリティ問題: セクション3を見てください。
Intended Usage: COMMON
意図している用法: 一般的
Authors:
作者:
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood( jason_livingood@cable.comcast.com )ドンTroshynski( dtroshynski@acmepacket.com )
Any other information the author deems interesting:
作者がおもしろいと考えるいかなる他の情報も:
Implementers should review a non-exclusive list of examples below in Section 7.
Implementersはセクション7で以下の例の非排他的なリストを再検討するはずです。
Livingood & Troshynski Standards Track [Page 9] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[9ページ]。
5. ENUM Service Registration for videomsg
5. videomsgのためのENUM Service Registration
5.1. Registration for "videomsg" with Subtype "sip"
5.1. Subtype「一口」がある"videomsg"のための登録
Enumservice Name: "videomsg"
Enumserviceは以下を命名します。 "videomsg"
Enumservice Type: "videomsg"
Enumserviceはタイプします: "videomsg"
Enumservice Subtypes: "sip"
Enumservice血液型亜型: 「一口」
URI Schemes: 'sip:'
URI体系: 'ちびちび飲んでください'
Functional Specification:
機能的な仕様:
This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a video communication session to a video messaging system.
このEnumserviceは、ビデオコミュニケーションセッションをビデオメッセージシステムに開始するために関連URI体系で特定された遠隔資源は扱うことができるのを示します。
Security Considerations: See Section 3.
セキュリティ問題: セクション3を見てください。
Intended Usage: COMMON
意図している用法: 一般的
Authors:
作者:
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood( jason_livingood@cable.comcast.com )ドンTroshynski( dtroshynski@acmepacket.com )
Any other information the author deems interesting:
作者がおもしろいと考えるいかなる他の情報も:
Implementers should review a non-exclusive list of examples below in Section 7.
Implementersはセクション7で以下の例の非排他的なリストを再検討するはずです。
5.2. Registration for "videomsg" with Subtype "sips"
5.2. Subtype「一口」がある"videomsg"のための登録
Enumservice Name: "videomsg"
Enumserviceは以下を命名します。 "videomsg"
Enumservice Type: "videomsg"
Enumserviceはタイプします: "videomsg"
Enumservice Subtypes: "sips"
Enumservice血液型亜型: 「一口」
URI Schemes: 'sips:'
URI体系: '一口:'
Functional Specification:
機能的な仕様:
This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a video communication session to a video messaging system.
このEnumserviceは、ビデオコミュニケーションセッションをビデオメッセージシステムに開始するために関連URI体系で特定された遠隔資源は扱うことができるのを示します。
Livingood & Troshynski Standards Track [Page 10] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[10ページ]。
Security Considerations: See Section 3.
セキュリティ問題: セクション3を見てください。
Intended Usage: COMMON
意図している用法: 一般的
Authors:
作者:
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood( jason_livingood@cable.comcast.com )ドンTroshynski( dtroshynski@acmepacket.com )
Any other information the author deems interesting:
作者がおもしろいと考えるいかなる他の情報も:
Implementers should review a non-exclusive list of examples below in Section 7.
Implementersはセクション7で以下の例の非排他的なリストを再検討するはずです。
5.3. Registration for "videomsg" with Subtype "http"
5.3. Subtype"http"がある"videomsg"のための登録
Enumservice Name: "videomsg"
Enumserviceは以下を命名します。 "videomsg"
Enumservice Type: "videomsg"
Enumserviceはタイプします: "videomsg"
Enumservice Subtype: "http"
Enumservice Subtype: "http"
URI Schemes: 'http:'
URI体系: 'http:'
Functional Specification:
機能的な仕様:
This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information.
このEnumserviceは、関連URI体系によって特定された遠隔資源は情報源であることができるのを示します。
Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'http:' [11] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource.
情報の種類が検索した注意は多種多様である場合があります。 通常、'httpはリソースに連絡します: '[11]URIはドキュメントを提供します。 このドキュメントは多くの異種の情報のダウンロードの引き金となる参照を含むことができます、テキスト、オーディオ、ビデオ、実行コード、またはビデオメッセージファイルなどのようにさえ。 したがって、1つはリソースに連絡するとき予想された情報の種類に関して、より特定であるはずがありません。
Security Considerations: See Section 3.
セキュリティ問題: セクション3を見てください。
Intended Usage: COMMON
意図している用法: 一般的
Authors:
作者:
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood( jason_livingood@cable.comcast.com )ドンTroshynski( dtroshynski@acmepacket.com )
Livingood & Troshynski Standards Track [Page 11] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[11ページ]。
Any other information the author deems interesting:
作者がおもしろいと考えるいかなる他の情報も:
Implementers should review a non-exclusive list of examples below in Section 7.
Implementersはセクション7で以下の例の非排他的なリストを再検討するはずです。
5.4. Registration for "videomsg" with Subtype "https"
5.4. Subtype"https"がある"videomsg"のための登録
Enumservice Name: "videomsg"
Enumserviceは以下を命名します。 "videomsg"
Enumservice Type: "videomsg"
Enumserviceはタイプします: "videomsg"
Enumservice Subtype: "https"
Enumservice Subtype: "https"
URI Schemes: 'https:'
URI体系: 'https:'
Functional Specification:
機能的な仕様:
This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information, which can be contacted using TLS or the Secure Socket Layer protocol.
このEnumserviceは、関連URI体系によって特定された遠隔資源は情報源であることができるのを示します。(TLSかSecure Socket Layerプロトコルを使用することで情報源に連絡できます)。
Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'https:' [12] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource.
情報の種類が検索した注意は多種多様である場合があります。 通常、'httpsはリソースに連絡します: '[12]URIはドキュメントを提供します。 このドキュメントは多くの異種の情報のダウンロードの引き金となる参照を含むことができます、テキスト、オーディオ、ビデオ、実行コード、またはビデオメッセージファイルなどのようにさえ。 したがって、1つはリソースに連絡するとき予想された情報の種類に関して、より特定であるはずがありません。
Security Considerations: See Section 3.
セキュリティ問題: セクション3を見てください。
Intended Usage: COMMON
意図している用法: 一般的
Authors:
作者:
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood( jason_livingood@cable.comcast.com )ドンTroshynski( dtroshynski@acmepacket.com )
Any other information the author deems interesting:
作者がおもしろいと考えるいかなる他の情報も:
Implementers should review a non-exclusive list of examples below in Section 7.
Implementersはセクション7で以下の例の非排他的なリストを再検討するはずです。
Livingood & Troshynski Standards Track [Page 12] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[12ページ]。
6. ENUM Service Registration for unifmsg
6. unifmsgのためのENUM Service Registration
6.1. Registration for "unifmsg" with Subtype "sip"
6.1. Subtype「一口」がある"unifmsg"のための登録
Enumservice Name: "unifmsg"
Enumserviceは以下を命名します。 "unifmsg"
Enumservice Type: "unifmsg"
Enumserviceはタイプします: "unifmsg"
Enumservice Subtypes: "sip"
Enumservice血液型亜型: 「一口」
URI Schemes: 'sip:'
URI体系: 'ちびちび飲んでください'
Functional Specification:
機能的な仕様:
This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a unified communication session to a unified messaging system.
このEnumserviceは、統一されたコミュニケーションセッションをユニファイド・メッセージングシステムに開始するために関連URI体系で特定された遠隔資源は扱うことができるのを示します。
Security Considerations: See Section 3.
セキュリティ問題: セクション3を見てください。
Intended Usage: COMMON
意図している用法: 一般的
Authors:
作者:
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood( jason_livingood@cable.comcast.com )ドンTroshynski( dtroshynski@acmepacket.com )
Any other information the author deems interesting:
作者がおもしろいと考えるいかなる他の情報も:
Implementers should review a non-exclusive list of examples below in Section 7.
Implementersはセクション7で以下の例の非排他的なリストを再検討するはずです。
6.2. Registration for "unifmsg" with Subtype "sips"
6.2. Subtype「一口」がある"unifmsg"のための登録
Enumservice Name: "unifmsg"
Enumserviceは以下を命名します。 "unifmsg"
Enumservice Type: "unifmsg"
Enumserviceはタイプします: "unifmsg"
Enumservice Subtypes: "sips"
Enumservice血液型亜型: 「一口」
URI Schemes: 'sips:'
URI体系: '一口:'
Functional Specification:
機能的な仕様:
This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a unified communication session to a unified messaging system.
このEnumserviceは、統一されたコミュニケーションセッションをユニファイド・メッセージングシステムに開始するために関連URI体系で特定された遠隔資源は扱うことができるのを示します。
Livingood & Troshynski Standards Track [Page 13] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[13ページ]。
Security Considerations: See Section 3.
セキュリティ問題: セクション3を見てください。
Intended Usage: COMMON
意図している用法: 一般的
Authors:
作者:
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood( jason_livingood@cable.comcast.com )ドンTroshynski( dtroshynski@acmepacket.com )
Any other information the author deems interesting:
作者がおもしろいと考えるいかなる他の情報も:
Implementers should review a non-exclusive list of examples below in Section 7.
Implementersはセクション7で以下の例の非排他的なリストを再検討するはずです。
6.3. Registration for "unifmsg" with Subtype "http"
6.3. Subtype"http"がある"unifmsg"のための登録
Enumservice Name: "unifmsg"
Enumserviceは以下を命名します。 "unifmsg"
Enumservice Type: "unifmsg"
Enumserviceはタイプします: "unifmsg"
Enumservice Subtype: "http"
Enumservice Subtype: "http"
URI Schemes: 'http:'
URI体系: 'http:'
Functional Specification:
機能的な仕様:
This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information.
このEnumserviceは、関連URI体系によって特定された遠隔資源は情報源であることができるのを示します。
Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'http:' [11] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource.
情報の種類が検索した注意は多種多様である場合があります。 通常、'httpはリソースに連絡します: '[11]URIはドキュメントを提供します。 このドキュメントは多くの異種の情報のダウンロードの引き金となる参照を含むことができます、テキスト、オーディオ、ビデオ、実行コード、またはビデオメッセージファイルなどのようにさえ。 したがって、1つはリソースに連絡するとき予想された情報の種類に関して、より特定であるはずがありません。
Security Considerations: See Section 3.
セキュリティ問題: セクション3を見てください。
Intended Usage: COMMON
意図している用法: 一般的
Authors:
作者:
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood( jason_livingood@cable.comcast.com )ドンTroshynski( dtroshynski@acmepacket.com )
Livingood & Troshynski Standards Track [Page 14] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[14ページ]。
Any other information the author deems interesting:
作者がおもしろいと考えるいかなる他の情報も:
Implementers should review a non-exclusive list of examples below in Section 7.
Implementersはセクション7で以下の例の非排他的なリストを再検討するはずです。
6.4. Registration for "unifmsg" with Subtype "https"
6.4. Subtype"https"がある"unifmsg"のための登録
Enumservice Name: "unifmsg"
Enumserviceは以下を命名します。 "unifmsg"
Enumservice Type: "unifmsg"
Enumserviceはタイプします: "unifmsg"
Enumservice Subtype: "https"
Enumservice Subtype: "https"
URI Schemes: 'https:'
URI体系: 'https:'
Functional Specification:
機能的な仕様:
This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information, which can be contacted using TLS or the Secure Socket Layer protocol.
このEnumserviceは、関連URI体系によって特定された遠隔資源は情報源であることができるのを示します。(TLSかSecure Socket Layerプロトコルを使用することで情報源に連絡できます)。
Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'https:' [12] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource.
情報の種類が検索した注意は多種多様である場合があります。 通常、'httpsはリソースに連絡します: '[12]URIはドキュメントを提供します。 このドキュメントは多くの異種の情報のダウンロードの引き金となる参照を含むことができます、テキスト、オーディオ、ビデオ、実行コード、またはビデオメッセージファイルなどのようにさえ。 したがって、1つはリソースに連絡するとき予想された情報の種類に関して、より特定であるはずがありません。
Security Considerations: See Section 3.
セキュリティ問題: セクション3を見てください。
Intended Usage: COMMON
意図している用法: 一般的
Authors:
作者:
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood( jason_livingood@cable.comcast.com )ドンTroshynski( dtroshynski@acmepacket.com )
Any other information the author deems interesting:
作者がおもしろいと考えるいかなる他の情報も:
Implementers should review a non-exclusive list of examples below in Section 7.
Implementersはセクション7で以下の例の非排他的なリストを再検討するはずです。
Livingood & Troshynski Standards Track [Page 15] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[15ページ]。
7. Selected Examples for Illustrative Purposes
7. 説明に役立った目的のための選択された例
The following sub-sections document several examples that implementers may find informative. These examples shall in no way limit the various forms that this Enumservice may take.
以下の小区分はimplementersが有益であることがわかるかもしれないいくつかの例を記録します。 これらの例はこのEnumserviceが取るかもしれない様々な形を決して、制限しないものとします。
7.1. Example Using a 'sip' URI
7.1. '一口'URIを使用する例
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+voicemsg:sip"
"!^.*$!sip:12155550123@gw.example.com!".
$発生源3.2.1.0.5.5.5.5.1.2.1.e164.arpa。 「$!一口: NAPTR10 100「u」「E2U+voicemsg: 一口」」 ^* 12155550123@gw.example.com! 。」
In this example, a calling party has attempted a session that has gone unanswered after a certain period of time. The calling party's session is sent to the appropriate voice messaging server, a personalized greeting is played to the calling party, after which it records a voice message to the called party.
この例では、起呼側はある期間の後に答えがなくなったセッションを試みました。 適切な音声メッセージングサーバに起呼側のセッションを送って、個人化された挨拶を起呼側にプレーします。(その時、それは音声メールを被呼者に記録しました後)。
7.2. Example Using a 'tel' URI
7.2. 'tel'URIを使用する例
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+voicemsg:tel"
"!^.*$!tel:1-215-555-0123!".
$発生源3.2.1.0.5.5.5.5.1.2.1.e164.arpa。 「$!NAPTR10 100「」 「E2U+はtelに以下をvoicemsgします!」u」 ^*tel:1-215-555-0123!」
In this example, a calling party has attempted a session that has gone unanswered after a certain period of time. The calling party's session is sent to the appropriate voice messaging server, a personalized greeting is played to the calling party, after which it records a voice message to the called party.
この例では、起呼側はある期間の後に答えがなくなったセッションを試みました。 適切な音声メッセージングサーバに起呼側のセッションを送って、個人化された挨拶を起呼側にプレーします。(その時、それは音声メールを被呼者に記録しました後)。
7.3. Example Using a Backreference
7.3. Backreferenceを使用する例
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+voicemsg:sip"
"!(^.*)$!sip:\1@example.net!".
$発生源3.2.1.0.5.5.5.5.1.2.1.e164.arpa。 「NAPTR10 100「u」「E2U+voicemsg: 一口」」 (^*)$!一口: \ 1@example.net! 。」
In this example, a backreference is used to reduce the size of the NAPTR record. The sip URI uses "\1", which would dynamically replace the expression with the TN, in this case +12155550123.
この例では、backreferenceは、NAPTR記録のサイズを減少させるのに使用されます。 「一口URI用途」\1インチ。(その1インチはダイナミックに式をテネシー、この場合+12155550123に取り替えるでしょう)。
Livingood & Troshynski Standards Track [Page 16] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[16ページ]。
7.4. Example Using a 'sip' URI without a Telephone Number
7.4. 電話番号なしで'一口'URIを使用する例
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+voicemsg:sip"
"!^.*$!sip:johndoe@gw.example.com!".
$発生源3.2.1.0.5.5.5.5.1.2.1.e164.arpa。 「$!一口: NAPTR10 100「u」「E2U+voicemsg: 一口」」 ^* johndoe@gw.example.com! 。」
In this example, a calling party has attempted a session that has gone unanswered after a certain period of time. The calling party's session is sent to the appropriate voice messaging server, a personalized greeting is played to the calling party, after which it records a voice message to the called party. The URI that this session is directed to does not include a telephone number, as this user has multiple service that are not particularly tied to telephone numbers whereby text, audio, video and other multimedia messages can be received and accessed.
この例では、起呼側はある期間の後に答えがなくなったセッションを試みました。 適切な音声メッセージングサーバに起呼側のセッションを送って、個人化された挨拶を起呼側にプレーします。(その時、それは音声メールを被呼者に記録しました後)。 このセッションがそうであるURIが電話番号を含めないよう指示されて、このユーザに複数のサービスがあるとき、それは、特にテキスト、オーディオ、ビデオ、および他のマルチメディアメッセージを受け取ることができる電話番号に結ばれないでアクセスされています。
7.5. Example of Failover Using E2U+videomsg:sip
7.5. E2U+videomsgを使用するフェイルオーバーに関する例: 一口
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+videomsg:sip"
"!^.*$!sip:12155550123@gw1.example.com!".
$発生源3.2.1.0.5.5.5.5.1.2.1.e164.arpa。 「$!一口: NAPTR10 100「u」「E2U+videomsg: 一口」」 ^* 12155550123@gw1.example.com! 。」
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
NAPTR 10 200 "u" "E2U+videomsg:sip"
"!^.*$!sip:12155550123@gw2.example.com!".
$発生源3.2.1.0.5.5.5.5.1.2.1.e164.arpa。 「$!一口: NAPTR10 200「u」「E2U+videomsg: 一口」」 ^* 12155550123@gw2.example.com! 。」
In this example, the preference indicates that gw1.example.com is used first (100), and if this is unreachable, then the next higher preference (200) is used and gw2.example.com is contacted. While out of scope for this document, a service provider could thus mirror or cluster a message store and fail from the primary to secondary using the DNS in an active-standby mode.
この例では、好みは、gw1.example.comが中古の最初の(100)であることを示します、そして、これが手が届かないなら、次の、より高い好み(200)は使用されています、そして、gw2.example.comは連絡されます。 サービスプロバイダーは、このドキュメントのための範囲からアクティブな待ち受け状態でDNSを使用することでその結果、メッセージ店を映すか、またはクラスタリングさせて、予備選挙からセカンダリに失敗できるでしょうが。
8. Implementation Recommendations
8. 実装推薦
8.1. Call Processing When Multiple Records Are Returned
8.1. 複数の記録を返すときには処理に電話をしてください。
It is likely that both E2U+sip and E2U+voicemsg, E2U+videomsg, and/or E2U+unifmsg Enumservice type records will be returned for a given query. In this case, this could result in what is essentially E2U+sip records for real-time communications with an end user, while, for example, the E2U+voicemsg records will be used for real-time communications with a voice messaging service, when the called party is not available or does not wish to be disturbed. Therefore, the network element that receives the results of this ENUM query will need to know enough information in order to select the voicemsg service type, rather than the sip service type.
与えられた質問のためにE2U+一口とE2U+voicemsg、E2U+videomsg、そして/または、E2U+unifmsg Enumserviceタイプ記録の両方を返しそうでしょう。 この場合、これは本質的にはエンドユーザとのリアルタイムのコミュニケーションのためのE2U+一口記録であることをもたらすかもしれません、例えば、E2U+voicemsg記録が音声メッセージングサービスとのリアルタイムのコミュニケーションに使用されるでしょうが、被呼者を利用可能でないか、または擾乱されたくないとき。 したがって、このENUM質問の結果を受けるネットワーク要素は、一口サービスタイプよりむしろvoicemsgサービスタイプを選ぶために十分な情報を知る必要があるでしょう。
Livingood & Troshynski Standards Track [Page 17] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[17ページ]。
In addition, it is likely that multiple E2U+voicemsg, E2U+videomsg, and/or E2U+unifmsg Enumservice type records will be returned for a given query. In this case, multiple records may include order and preference to allow recursion or load balancing. Order could be used to designate a primary and a backup voice, video, or unified voice and video messaging service. Preference could be used to load balance across multiple voice, video, and/or unified voice and video messaging servers by weight, for example.
さらに、与えられた質問のために複数のE2U+voicemsg、E2U+videomsg、そして/または、E2U+unifmsg Enumserviceタイプ記録を返しそうでしょう。 この場合、複数の記録が、再帰かロードバランシングを許容するために注文と好みを含むかもしれません。 予備選挙とバックアップ声か、ビデオか、統一された声とビデオメッセージングをサービスに指定するのにオーダーを使用できました。 例えば、重さに従って複数の声、ビデオ、そして/または、統一された声とビデオメッセージングサーバの向こう側にバランスをロードするのに好みを使用できました。
Finally, 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.
最終的に、e164.arpa木の典型的なENUM質問から生じる複数の記録のように、それは、どの記録を使用するか、そして、どの記録を無視したらよいかを決定するのにENUMレゾルバを使用することでアプリケーションまで達しています。 Implementersはこれを考慮に入れて、論理を適切に商用で基づく複数の記録、ネットワーク、または他の規則から選び抜くことができる彼らのアプリケーションに組み込むはずです。
8.2. NAPTR Configuration Issues
8.2. NAPTR構成問題
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.
Implementersは、個々のNAPTRsのサイズを減少させるのに正規表現を使用すると考えたがっているかもしれません。 これで、データベースの総合的なサイズへの重要な効果はかかわるでしょう。
9. IANA Considerations
9. IANA問題
This document registers the 'voicemsg' Enumservice type and the subtype "tel", "sip", "sips", "http", and "https" under the Enumservice registry described in the IANA considerations in RFC 3761. Details of this registration are provided in Section 4 of this document.
このドキュメントはEnumserviceがタイプして、Enumservice登録の下の「副-タイプ」"tel"、「一口」、「一口」、"http"、および"https"がRFC3761のIANA問題で説明した'voicemsg'を登録します。 この登録の詳細はこのドキュメントのセクション4に明らかにされます。
This document registers the 'videomsg' Enumservice type and the subtype "sip", "sips", "http", and "https" under the Enumservice registry described in the IANA considerations in RFC 3761. Details of this registration are provided in Section 5 of this document.
このドキュメントはEnumserviceがタイプして、Enumservice登録の下の「副-タイプ」「一口」、「一口」、"http"、および"https"がRFC3761のIANA問題で説明した'videomsg'を登録します。 この登録の詳細はこのドキュメントのセクション5に明らかにされます。
This document registers the 'unifmsg' Enumservice type and the subtype "sip", "sips", "http", and "https" under the Enumservice registry described in the IANA considerations in RFC 3761. Details of this registration are provided in Section 6 of this document.
このドキュメントはEnumserviceがタイプして、Enumservice登録の下の「副-タイプ」「一口」、「一口」、"http"、および"https"がRFC3761のIANA問題で説明した'unifmsg'を登録します。 この登録の詳細はこのドキュメントのセクション6に明らかにされます。
10. Acknowledgements
10. 承認
The authors thank Rich Ferrise, Chris Harvey, Tong Zhou, and Hadriel Kaplan for their detailed assistance in developing the ideas behind this document in numerous brainstorming sessions, with information gleaned from their work to solve real application architecture issues. The authors also thank Lawrence Conroy and Jean-Francois Mule for their feedback in developing this document.
作者は彼らのきめ細かい支援について頻繁なブレインストーミング・セッションにこのドキュメントの後ろで考えを開発する際にリッシュFerrise、クリス・ハーヴェイ、Tong周、およびHadrielキャプランに感謝します、情報が本当のアプリケーションアーキテクチャ問題を解決するために彼らの仕事から収集されている状態で。 また、作者は彼らのフィードバックについてこのドキュメントを開発する際にローレンス・コンロイとジャン・フランソワMuleに感謝します。
Livingood & Troshynski Standards Track [Page 18] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[18ページ]。
11. Contributors
11. 貢献者
Tong Zhou Comcast Cable Communications Email: tong_zhou@cable.comcast.com
党の周コムキャスト有線通信はメールされます: tong_zhou@cable.comcast.com
Richard Ferrise Comcast Cable Communications Email: rich_ferrise@cable.comcast.com
リチャードFerriseコムキャスト有線通信はメールされます: rich_ferrise@cable.comcast.com
Chris Harvey Comcast Cable Communications Email: chris_harvey@cable.comcast.com
クリスハーヴェイコムキャスト有線通信はメールされます: chris_harvey@cable.comcast.com
Hadriel Kaplan Acme Packet Email: hkaplan@acmepacket.com
Hadrielキャプラン頂上パケットメール: hkaplan@acmepacket.com
12. References
12. 参照
12.1. Normative References
12.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 Numbering
Plan", Recommendation E.164, May 1997.
[2] ITU-T(「国際公共の電気通信付番プラン」、推薦E.164)は1997がそうするかもしれません。
[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月。
[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月。
Livingood & Troshynski Standards Track [Page 19] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[19ページ]。
[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] 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.
[10] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[11] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[12] レスコラ(E.、「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。
12.2. Informative References
12.2. 有益な参照
[13] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164
numbers with the Session Initiation Protocol (SIP)", RFC 3824,
June 2004.
[13] ピーターソン、J.、リュウ、H.、ユー、J.、およびB.キャンベル、「Session Initiationプロトコル(SIP)があるE.164番号を使用します」、RFC3824(2004年6月)。
[14] Vaudreuil, G., "Voice Message Routing Service", RFC 4238,
October 2005.
[14] ボードルイ、G.、「音声メールルート設定サービス」、RFC4238、2005年10月。
[15] Brandner, R., Conroy, L., and R. Stastny, "IANA Registration
for Enumservices email, fax, mms, ems, and sms", RFC 4355,
January 2006.
[15]BrandnerとR.とコンロイ、L.とR.Stastny、「Enumservicesメール、ファックス、mms、ems、およびsmsのためのIANA Registration」RFC4355、2006年1月。
[16] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005.
[16] Arends(R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月。
[17] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
System (DNS)", RFC 3833, August 2004.
[17] アトキンスとD.とR.Austein、「ドメインネームシステム(DNS)の脅威分析」、RFC3833、2004年8月。
[18] Foster, M., McGarry, T., and J. Yu, "Number Portability in the
Global Switched Telephone Network (GSTN): An Overview", RFC
3482, February 2003.
[18] フォスター、M.、McGarry、T.、およびJ.ユー、「グローバルのナンバーポータビリティは電話網(GSTN)を切り換えました」。 「概要」、RFC3482、2003年2月。
[19] Peterson, J., "enumservice registration for Session Initiation
Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.
[19] ピーターソン、J.、「記録のSession Initiationプロトコル(SIP)アドレスのためのenumservice登録」、RFC3764、2004年4月。
Livingood & Troshynski Standards Track [Page 20] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[20ページ]。
Authors' Addresses
作者のアドレス
Jason Livingood Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 USA EMail: jason_livingood@cable.comcast.com
ジェイソンLivingoodコムキャスト有線通信1つのコムキャストは1701年のフィラデルフィア、PA19103米国ジョン・F.ケネディー大通りメールを中心に置きます: jason_livingood@cable.comcast.com
Donald Troshynski Acme Packet EMail: dtroshynski@acmepacket.com
ドナルドTroshynski頂上パケットメール: dtroshynski@acmepacket.com
Livingood & Troshynski Standards Track [Page 21] RFC 5278 VMSG Enumservice July 2008
Livingood&Troshynski規格はVMSG Enumservice2008年7月にRFC5278を追跡します[21ページ]。
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に情報を扱ってください。
Livingood & Troshynski Standards Track [Page 22]
Livingood&Troshynski標準化過程[22ページ]
一覧
スポンサーリンク
