RFC5167 日本語訳
5167 Media Server Control Protocol Requirements. M. Dolly, R. Even. March 2008. (Format: TXT=17147 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Dolly
Request for Comments: 5167 AT&T Labs
Category: Informational R. Even
Polycom
March 2008
コメントを求めるワーキンググループM.台車要求をネットワークでつないでください: 5167年のAT&T研究室カテゴリ: 2008年の情報のR.同等のPolycom行進
Media Server Control Protocol Requirements
メディアサーバ制御プロトコル要件
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 addresses the communication between an application server and media server. The current work in IETF working groups shows these logical entities, but it does not address the physical decomposition and the protocol between the entities.
このドキュメントはアプリケーション・サーバーとメディアサーバとのコミュニケーションを扱います。IETFワーキンググループにおける執筆中の作品はこれらの論理的な実体を示していますが、それは物理的な分解と実体の間のプロトコルを扱いません。
This document presents the requirements for a Media Server Control Protocol (MCP) that enables an application server to use a media server. It will address the aspects of announcements, Interactive Voice Response, and conferencing media services.
このドキュメントはアプリケーション・サーバーがメディアサーバを使用するのを可能にするメディアServer Controlプロトコル(MCP)のための要件を提示します。それは発表であって、Interactive Voice Responseの、そして、会議メディアサービスの局面を扱うでしょう。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Media Control Requirements . . . . . . . . . . . . . . . . 3
3.2. Media mixing Requirements . . . . . . . . . . . . . . . . . 5
3.3. IVR Requirements . . . . . . . . . . . . . . . . . . . . . 6
3.4. Operational Requirements . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Informative References . . . . . . . . . . . . . . . . . . . . 7
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 要件. . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1。 メディアは要件. . . . . . . . . . . . . . . . 3 3.2を制御します。 Requirements. . . . . . . . . . . . . . . . . 5 3.3を混ぜるメディア。 IVR要件. . . . . . . . . . . . . . . . . . . . . 6 3.4。 操作上の要件. . . . . . . . . . . . . . . . . 6 4。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 6 5。 承認. . . . . . . . . . . . . . . . . . . . . . . . 7 6。 有益な参照. . . . . . . . . . . . . . . . . . . . 7
Dolly & Even Informational [Page 1] RFC 5167 MCP Requirements March 2008
ドリーと2008年の[1ページ]情報のRFC5167MCP要件行進さえ
1. Introduction
1. 序論
The IETF conferencing framework in RFC 4353 [CARCH] presents an architecture that is built of several functional entities. RFC 4353 [CARCH] does not specify the protocols between the functional entities since it is considered out of scope.
RFC4353[CARCH]のIETF会議フレームワークはいくつかの機能的な実体で築き上げられるアーキテクチャを提示します。 それが範囲から考えられるので、RFC4353[CARCH]は機能的な実体の間のプロトコルを指定しません。
Based on RFC 4353 [CARCH], this document defines the requirements for a protocol that will enable one functional entity, known as an Application Server (AS), that includes the conference/media policy server, the notification server, and the focus, all defined in RFC 4353 [CARCH], to interact with one or more functional entities, called Media Server (MS), that serves as mixer or media server.
RFC4353[CARCH]に基づいて、このドキュメントは会議/メディア方針サーバ、通知サーバを含んでいるApplication Server(AS)として知られている1つの機能的な実体、およびミキサーかメディアサーバとして機能する1つ以上の機能的な実体と対話するためにメディアServer(MS)と呼ばれるRFC4353[CARCH]ですべて定義された焦点を可能にするプロトコルのための要件を定義します。
The media server can also be used for announcements and Interactive Voice Response (IVR) functions.
また、発表とInteractive Voice Response(IVR)機能にメディアサーバを使用できます。
Application servers host one or more instances of a communication application. Media servers provide real time media processing functions. An example of the decomposition of a media server and an application server is described in the media control framework document [MEDIACTRL-FW].
アプリケーション・サーバーはコミュニケーションアプリケーションの1つ以上のインスタンスを接待します。 メディアサーバは処理機能をリアルタイムのメディアに提供します。 メディアサーバとアプリケーション・サーバーの分解に関する例はメディアコントロールフレームワークドキュメント[MEDIACTRL-FW]で説明されます。
This document presents the requirements for a Media Server Control Protocol (MCP) that enables an application server to control a media server. It will address the aspects of announcements, IVR, and conferencing media services.
このドキュメントはアプリケーション・サーバーがメディアサーバを制御するのを可能にするメディアServer Controlプロトコル(MCP)のための要件を提示します。それは発表であって、IVRの、そして、会議メディアサービスの局面を扱うでしょう。
The requirements are for the protocol and do not address the AS or MS functionality discussed in the media control framework.
要件は、ASかMSがメディアコントロールフレームワークで議論した機能性であると、プロトコルのためにあって、扱いません。
Since the media server is a centralized component, the charter of the working group states that this work will not investigate distributed media processing algorithms or control protocols.
メディアサーバが集結されたコンポーネントであるので、ワーキンググループの特許は、この仕事がアルゴリズムか制御プロトコルを処理する分配されたメディアを調査しないと述べます。
2. Terminology
2. 用語
The media server work uses, when appropriate, and expands on the terminology introduced in the conferencing framework [CARCH] and Centralized Conferencing (XCON) framework [XCON-FRMWRK]. The following additional terms are defined:
メディアサーバ仕事は、会議フレームワーク[CARCH]とCentralized Conferencing(XCON)フレームワーク[XCON-FRMWRK]で紹介された用語について、適切であるときに、使用して、詳述します。 次の追加用語は定義されます:
Application Server (AS) - A functional entity that hosts one or more instances of a communication application. The application server may include the conference policy server, the focus, and the conference notification server, as defined in [CARCH]. Also, it may include communication applications that use IVR or announcement services.
アプリケーションServer(AS)--コミュニケーションアプリケーションの1つ以上のインスタンスを接待する機能的な実体。 アプリケーション・サーバーは[CARCH]で定義されるように会議方針サーバ、焦点、および会議通知サーバを含むかもしれません。 また、それはIVRかホームページの告知を使用するコミュニケーションアプリケーションを含むかもしれません。
Dolly & Even Informational [Page 2] RFC 5167 MCP Requirements March 2008
ドリーと2008年の[2ページ]情報のRFC5167MCP要件行進さえ
Media Server (MS) - The media server includes the mixer as defined in [CARCH]. The media server plays announcements, it processes media streams for functions like Dual Tone Multi-Frequency (DTMF) detection and transcoding. The media server may also record media streams for supporting IVR functions like announcing participants
メディアServer(MS)--メディアサーバは[CARCH]で定義されるようにミキサーを含んでいます。 メディアサーバは発表をプレーして、それはDual利根Multi-頻度(DTMF)検出とコード変換のような機能のためのメディアストリームを処理します。 また、メディアサーバは、関係者を発表するような機能をIVRにサポートするためにメディアストリームを記録するかもしれません。
Media Resource Broker (MRB) - A logical entity that is responsible for both the collection of appropriate published Media Server (MS) information and supplying of appropriate MS information to consuming entities. The MRB is an optional entity and will be discussed in a separate document.
メディアResource Broker(MRB)--適切な発行されたメディアServer(MS)情報の収集と実体を消費することへの適切なMS情報の供給の両方に原因となる論理的な実体。 MRBについて任意の実体であり、別々のドキュメントで議論するでしょう。
Notification - A notification is used when there is a need to report event-related information from the MS to the AS.
通知--イベント関連の情報をMSからASに報告する必要があるとき、通知は使用されています。
Request - A request is sent from the controlling entity, such as an application server, to another resource, such as a media server, asking that a particular type of operation be executed.
要求--制御実体から要求を送ります、アプリケーション・サーバーのように、別のリソースに、メディアサーバのように、特定のタイプの操作が実行されるように頼んで。
Response - A response is used to signal information, such as an acknowledgement or error code in reply to a previously issued request.
応答--応答は情報に合図するのに使用されます、以前に発行された要求に対する承認やエラーコードのように。
3. Requirements
3. 要件
3.1. Media Control Requirements
3.1. メディアは要件を制御します。
The following are the media control requirements:
↓これはメディアコントロール要件です:
REQ-MCP-01 - The MS Control Protocol shall enable one or more
application servers to request media services from one or more
media servers.
REQ-MCP-01--MS Controlプロトコルは、1つ以上のアプリケーション・サーバーが1つ以上のメディアサーバからメディアサービスを要求するのを可能にするものとします。
REQ-MCP-02 - The MS Control Protocol shall use a reliable transport
protocol.
REQ-MCP-02--MS Controlプロトコルは信頼できるトランスポート・プロトコルを使用するものとします。
REQ-MCP-03 - The applications supported by the protocol shall
include conferencing and Interactive Voice Response media
services.
REQ-MCP-03--プロトコルで後押しされているアプリケーションは会議とInteractive Voice Responseメディアサービスを含んでいるものとします。
Note: Though the protocol enables these services, the functionality is invoked through other mechanisms.
以下に注意してください。 プロトコルはこれらのサービスを可能にしますが、機能性は他のメカニズムを通して呼び出されます。
REQ-MCP-04 - Media types supported in the context of the
applications shall include audio, tones, text, and video. Tones
media include in-band audio or RFC 4733 payload.
REQ-MCP-04--アプリケーションの文脈でサポートされたメディアタイプはオーディオ、トーン、テキスト、およびビデオを入れるものとします。 トーンメディアはバンドにおけるオーディオか4733年のRFCペイロードを含んでいます。
Dolly & Even Informational [Page 3] RFC 5167 MCP Requirements March 2008
ドリーと2008年の[3ページ]情報のRFC5167MCP要件行進さえ
REQ-MCP-05 - The MS control protocol should allow, but must not
require, a media resource broker (MRB) or intermediate proxy to
exist with the application server and media server.
REQ-MCP-05--許容するべきですが、制御プロトコルが必要としてはいけないMS、メディアリソースはアプリケーション・サーバーとメディアサーバで存在するように(MRB)か中間的プロキシを仲介します。
REQ-MCP-06 - On the MS control channel, there shall be requests to
the MS, responses from the MS, and notifications to the AS.
REQ-MCP-06--MS制御チャンネルの上に、MS(MS、および通知からASまでの応答)への要求があるでしょう。
REQ-MCP-07 - SIP/SDP (Session Initiation Protocol / Session
Description Protocol) shall be used to establish and modify media
connections to a media server.
REQ-MCP-07--SIP/SDP(セッションInitiationプロトコル/セッション記述プロトコル)は、メディア接続をメディアサーバに確立して、変更するのに使用されるものとします。
REQ-MCP-08 - It should be possible to support a single conference
spanning multiple media servers.
REQ-MCP-08--マルチメディアサーバにかかるただ一つの会議をサポートするのは可能であるべきです。
Note: It is probable that spanning multiple MSs can be
accomplished by the AS and does not require anything in the
protocol for the scenarios we have in mind. However, the concern
is that if this requirement is treated too lightly, one may end up
with a protocol that precludes its support.
以下に注意してください。 複数のMSsにかかるのがASが達成できて、私たちが考えているシナリオのためにプロトコルの何も必要としないのは、ありえそうです。 しかしながら、関心はこの要件があまりに軽く扱われるなら、サポートを排除するプロトコルで終わるかもしれないということです。
REQ-MCP-09 - It must be possible to split call legs individually, or
in groups, away from a main conference on a given media server,
without performing re-establishment of the call legs to the MS
(e.g., for purposes such as performing IVR with a single call leg
or creating sub-conferences, not for creating entirely new
conferences).
REQ-MCP-09--個別、またはグループで呼び出し脚を分けるのは可能であるに違いありません、与えられたメディアサーバの主な会議によって離れています、MS(例えば、完全に新しい会議を創設するのではなく、ただ一つの呼び出し脚でIVRを実行するか、またはサブ会議を創設などなどの目的のための)に呼び出し脚の再建を実行しないで。
REQ-MCP-10 - The MS control protocol should be extendable,
facilitating forward and backward compatibility.
REQ-MCP-10--前進の、そして、後方の互換性を容易にして、MS制御プロトコルは「広げ-可能」であるはずです。
REQ-MCP-11 - The MS control protocol shall include an authentication
component to ensure that only an authorized AS can communicate
with the MS, and vice versa.
REQ-MCP-11--MS制御プロトコルは認可されたASだけがMSとコミュニケートできるのを保証するために認証コンポーネントを含んでいるものとします、逆もまた同様に。
REQ-MCP-12 - The MS control protocol shall use some form of
transport protection to ensure the confidentiality and integrity
of the data between the AS and MS.
REQ-MCP-12--MS制御プロトコルは、ASとMSの間のデータの秘密性と保全を確実にするのに何らかの輸送形態保護を使用するものとします。
REQ-MCP-13 - Different application servers may have different
privileges for using an MS. The protocol should prevent the AS
from doing unauthorized operations on a MS.
異なったアプリケーション・サーバーには、MSを使用するための異なった特権があるかもしれません。REQ-MCP-13--プロトコルは、ASがMSで権限のない操作をするのを防ぐべきです。
REQ-MCP-14 - The MS control protocol requires mechanisms to protect
the MS resources used by one AS from another AS since the solution
needs to support multiple ASs controlling one MS.
REQ-MCP-14--MS制御プロトコルは、ソリューションが、複数のASs制御に1MSをサポートする必要があるので1ASで別のASからMS運用資金を保護するためにメカニズムを必要とします。
Dolly & Even Informational [Page 4] RFC 5167 MCP Requirements March 2008
ドリーと2008年の[4ページ]情報のRFC5167MCP要件行進さえ
REQ-MCP-15 - During session establishment, there shall be a
capability to negotiate parameters that are associated with media
streams. This requirement should also enable an AS managing
conference to specify the media streams allowed in the conference.
セッション設立の間、メディアストリームに関連しているパラメタを交渉する能力があるでしょう。REQ-MCP-15--また、この要件は、AS管理会議がストリームが会議で許容したメディアを指定するのを可能にするべきです。
REQ-MCP-16 - The AS shall be able to instruct the MS to perform
stream operations like mute and gain control.
REQ-MCP-16--ASは、無言と利得制御のようなストリーム操作を実行するようMSに命令できるでしょう。
REQ-MCP-17 - The AS shall be able to instruct the MS to play a
specific announcement.
REQ-MCP-17--ASは、特定の発表をプレーするようMSに命令できるでしょう。
REQ-MCP-18 - The AS shall be able to request the MS to create,
delete, and manipulate a mixing, IVR, or announcement session.
REQ-MCP-18--ASは混合、IVR、または発表セッションを作成して、削除して、操作するようMSに要求できるでしょう。
REQ-MCP-19 - The AS shall be able to instruct the MS to play
announcements to a single user or to a conference mix.
REQ-MCP-19--ASは、シングルユーザー、または、会議ミックスに発表をプレーするようMSに命令できるでしょう。
REQ-MCP-20 - The MS control protocol should enable the AS to ask the
MS for a session summary report. The report may include resource
usage and quality metrics.
REQ-MCP-20--MS制御プロトコルは、ASがセッション概略報告をMSに求めるのを可能にするべきです。 レポートはリソース用法と上質の測定基準を含むかもしれません。
REQ-MCP-21 - The MS shall be able to notify the AS of events
received in the media stream if requested by the AS. (Examples -
STUN request, Flow Control, etc.)
REQ-MCP-21--MSはASによって要求されるならメディアストリームで受け取られたイベントについてASに通知できるでしょう。 (例--STUN要求、Flow Controlなど)
3.2. Media mixing Requirements
3.2. メディア混合Requirements
REQ-MCP-22 - The AS shall be able to define a conference mix; the MS
may offer different mixing topologies. The conference mix may be
defined on a conference or user level.
REQ-MCP-22--ASは会議ミックスを定義できるでしょう。 MSは異なった混合topologiesを提供するかもしれません。 会議ミックスは会議かユーザレベルで定義されるかもしれません。
REQ-MCP-23 - The AS may be able to define a custom video layout
built of rectangular sub-windows.
REQ-MCP-23--ASは長方形のサブの窓で組み込まれたカスタムビデオレイアウトを定義できるかもしれません。
REQ-MCP-24 - For video, the AS shall be able to map a stream to a
specific sub-window or to define to the MS how to decide which
stream will go to each sub-window.
REQ-MCP-24--ビデオに関しては、ASは特定のサブの窓にストリームを写像するか、またはどの小川がそれぞれのサブの窓に行くかを決める方法をMSと定義できるでしょう。
REQ-MCP-25 - The MS shall be able to notify the ASs of who the
active sources of the media are; for example, who the active
speaker is or who is being viewed in a conference. The speaker
and the video source may be different, for example, a person
describing a video stream from a remote camera managed by a
different user.
REQ-MCP-25--MSはメディアの活発な源がだれであるかについてASsに通知できるでしょう。 例えば、アクティブスピーカーはだれであるか、そして、だれが会議で見られていますか? スピーカーとビデオソースが異なるかもしれない、例えば、遠隔カメラからビデオストリームについて説明する人は異なったユーザで管理しました。
Dolly & Even Informational [Page 5] RFC 5167 MCP Requirements March 2008
ドリーと2008年の[5ページ]情報のRFC5167MCP要件行進さえ
REQ-MCP-26 - The MS shall be able to inform the AS which layouts it
supports.
REQ-MCP-26--MSは、それがどのレイアウトをサポートするかをASに知らせることができるでしょう。
REQ-MCP-27 - The MS control protocol should enable the AS to
instruct the MS to record a specific conference mix.
REQ-MCP-27--MS制御プロトコルは、ASが、特定の会議ミックスを記録するようMSに命令するのを可能にするべきです。
3.3. IVR Requirements
3.3. IVR要件
REQ-MCP-28 - The AS shall be able to instruct the MS to perform one
or more IVR scripts and receive the results. The script may be in
a server or contained in the control message.
REQ-MCP-28--ASは1つ以上のIVRスクリプトを実行して、結果を受けるようMSに命令できるでしょう。 スクリプトは、サーバにはあるか、またはコントロールメッセージに含まれるかもしれません。
REQ-MCP-29 - The AS shall be able to manage the IVR session by
sending requests to play announcements to the MS and receiving the
response (e.g., DTMF). The IVR session flow, in this case, is
handled by the AS by starting a next phase based on the response
it receives from the MS on the current phase.
REQ-MCP-29--MSに発表をプレーするという要求を送って、応答(例えば、DTMF)を受けることによって、ASはIVRセッションに対処できるでしょう。 IVRセッション流動は、この場合それが現在のフェーズのMSから受ける応答に基づく次のフェーズを始めることによって、ASによって扱われます。
REQ-MCP-30 - The AS should be able to instruct the MS to record a
short participant stream and play it back. This is not a
recording requirement.
REQ-MCP-30--ASは短い関与しているストリームを記録して、それを再生するようMSに命令するはずであることができます。 これは録音要件ではありません。
3.4. Operational Requirements
3.4. 操作上の要件
These requirements may be applicable to the MRB, but they can be used by an AS if it has a one-to-one connection to the MS.
これらの要件はMRBに適切であるかもしれませんが、MSに一対一接続を持っているなら、ASはそれらを使用できます。
REQ-MCP-31 - The MS control protocol must allow the AS to audit the
MS state during an active session.
REQ-MCP-31--MS制御プロトコルで、ASは活発なセッションの間、MS州を監査できなければなりません。
REQ-MCP-32 - The MS shall be able to inform the AS about its status
during an active session.
REQ-MCP-32--MSは活発なセッションの間、状態に関してASに知らせることができるでしょう。
4. Security Considerations
4. セキュリティ問題
This document discusses high-level requirements for MCP. The MCP has some specific security requirements, which will be summarized here at a very high level.
このドキュメントはMCPに、ハイレベルの要件について議論します。 MCPには、いくつかの特定のセキュリティ要件があります。(要件はここ、非常に高いレベルでまとめられるでしょう)。
All of the operations and functions described in this document need to be authorized by an MS or an AS. It is expected that MS resources will be governed by a set of authorization rules defined as part of the AS / MS policy. In order for the policy to be implemented, the MS needs to be able to authenticate requests. Normal SIP mechanisms, including Digest authentication and certificates, can be used as specified in RFC 3261 [RFC3261]. These MCP security requirements will be discussed in detail in the framework and protocol documents.
本書では説明された操作と機能のすべてが、MSかASによって認可される必要があります。 MSリソースがAS/MS方針の一部と定義された1セットの承認規則で支配されると予想されます。 政策が実施されるために、MSは、要求を認証できる必要があります。 RFC3261[RFC3261]で指定されるようにDigest認証と証明書を含む正常なSIPメカニズムは使用できます。 フレームワークとプロトコルドキュメントで詳細にこれらのMCPセキュリティ要件について議論するでしょう。
Dolly & Even Informational [Page 6] RFC 5167 MCP Requirements March 2008
ドリーと2008年の[6ページ]情報のRFC5167MCP要件行進さえ
5. Acknowledgments
5. 承認
This RFC represents the work from two previous personal works in progress, "Media Control Protocol Requirements" and "Requirements for a Media Server Control Protocol". The authors would like to acknowledge the work of Gary Munson from AT&T Labs, and James Rafferty from Cantata who helped write "Media Control Protocol Requirements", on which this work is based.
このRFCは前の2個の個人的な執筆中の作品から仕事を表します、そして、「メディアコントロールは要件について議定書の中で述べ」て、「メディアサーバ制御装置のための要件は議定書を作ります」。 作者はAT&T Labs、およびジェームスRaffertyからこの仕事が基づいている「メディア制御プロトコル要件」を書くのを助けたCantataからゲーリー・ムンソンの仕事を承諾したがっています。
6. Informative References
6. 有益な参照
[CARCH] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
February 2006.
[CARCH] 2006年2月のローゼンバーグ、J.、「セッション開始プロトコル(一口)がある会議のためのフレームワーク」RFC4353。
[MEDIACTRL-FW] Melanchuk, T., Ed., "An Architectural Framework for
Media Server Control", Work in Progress,
February 2008.
[MEDIACTRL-FW] Melanchuk、T.、エド、「メディアサーバ制御装置のための建築フレームワーク」、処理中の作業、2月2008
[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月。
[XCON-FRMWRK] Barnes, M., Boulton, C., and O. Levin, "A Framework
for Centralized Conferencing", Work in Progress,
November 2007.
[XCON-FRMWRK] バーンズ、M.、ボールトン、C.、およびO.レヴィン、「集結された会議のためのフレームワーク」は進歩、2007年11月に働いています。
Dolly & Even Informational [Page 7] RFC 5167 MCP Requirements March 2008
ドリーと2008年の[7ページ]情報のRFC5167MCP要件行進さえ
Authors' Addresses
作者のアドレス
Martin Dolly AT&T Labs 200 Laurel Avenue Middletown, NJ 07748 USA
マーチン台車AT&T研究室200ローレルアベニューミドルタウン、ニュージャージー07748米国
Phone: EMail: mdolly@att.com URI:
以下に電話をしてください。 メール: mdolly@att.com ユリ:
Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel
ロニ同等のPolycom94DerechイエムHamoshavot Petach Tikva49130イスラエル
EMail: roni.even@polycom.co.il
メール: roni.even@polycom.co.il
Dolly & Even Informational [Page 8] RFC 5167 MCP Requirements March 2008
ドリーと2008年の[8ページ]情報のRFC5167MCP要件行進さえ
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に情報を記述してください。
Dolly & Even Informational [Page 9]
ドリーで情報でさえあります。[9ページ]
一覧
スポンサーリンク
