[要約] RFC 4240は、SIPを使用した基本的なネットワークメディアサービスに関する仕様です。このRFCの目的は、SIPを介してネットワーク上でメディアサービスを提供するための基本的なガイドラインを提供することです。
Network Working Group E. Burger, Ed.
Request for Comments: 4240 J. Van Dyke
Category: Informational A. Spitzer
Brooktrout Technology, Inc.
December 2005
Basic Network Media Services with SIP
SIPを使用した基本的なネットワークメディアサービス
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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.
SIPベースのネットワークでは、基本的なネットワークメディアサービスを提供する必要があります。このようなサービスには、ネットワークの発表、ユーザーの相互作用、および会議サービスが含まれます。これらのサービスは、興味深いアプリケーションを構築できる基本的なビルディングブロックです。これらのビルディングブロック（メディアサーバーとも呼ばれる）とアプリケーション開発者を提供するサーバー間で相互運用性を持つためには、そのようなサービスを明確に定義された方法で見つけて呼び出すことができる必要があります。
This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks.
このドキュメントでは、SIPベースのネットワークにアプリケーションサービスを提供するアプリケーションサーバー間の相互運用可能なインターフェイスを提供するメカニズムと、基本的なメディア処理ビルディングブロックを提供するメディアサーバーを提供するメカニズムについて説明します。
Table of Contents
目次
1. Overview ........................................................2
1.1. Conventions Used in This Document ..........................3
2. Mechanism .......................................................3
3. Announcement Service ............................................5
3.1. Operation ..................................................8
3.2. Protocol Diagram ...........................................9
3.3. Formal Syntax ..............................................9
4. Prompt and Collect Service .....................................11
4.1. Formal Syntax for Prompt and Collect Service ..............12
5. Conference Service .............................................13
5.1. Protocol Diagram ..........................................14
5.2. Formal Syntax .............................................16
6. IANA Considerations ............................................17
7. The User Part ..................................................17
8. Security Considerations ........................................20
9. Contributors ...................................................20
10. Acknowledgements ..............................................20
11. References ....................................................21
11.1. Normative References .....................................21
11.2. Informative References ...................................22
In SIP-based media networks (RFC 3261 [10]), there is a need to provide basic network media services. Such services include playing announcements, initiating a media mixing session (conference), and prompting and collecting information with a user.
SIPベースのメディアネットワーク（RFC 3261 [10]）では、基本的なネットワークメディアサービスを提供する必要があります。このようなサービスには、発表のプレイ、メディアミキシングセッション（会議）の開始、ユーザーとの情報のプロンプトと収集が含まれます。
These services are basic in nature, are few in number, and fundamentally have not changed in 25 years of enhanced telephony services. Moreover, given their elemental nature, one would not expect them to change in the future.
これらのサービスは本質的に基本的なものであり、数が少なく、基本的には25年の強化されたテレフォニーサービスで変更されていません。さらに、彼らの基本的な性質を考えると、彼らが将来変化するとは思わないでしょう。
Multifunction media servers provide network media services to clients using server protocols such as SIP, often in conjunction with markup languages such as VoiceXML [20] and MSCML [21]. This document describes how to identify to a multifunction media server what sort of session the client is requesting, without modifying the SIP protocol.
多機能メディアサーバーは、SIPなどのサーバープロトコルを使用して、多くの場合、VoiceXML [20]やMSCML [21]などのマークアップ言語と併用して、クライアントにネットワークメディアサービスを提供します。このドキュメントでは、SIPプロトコルを変更せずに、クライアントが要求しているセッションの種類を多機能メディアサーバーに識別する方法について説明します。
It is critically important to note that the mechanism described here in no way modifies the SIP protocol, the meaning, or definition of a SIP Request URI, or does it put any restrictions, in any way, on devices that do not implement this convention.
ここで説明されているメカニズムは、SIPプロトコル、SIPリクエストURIの意味、または定義を決して変更しないことに注意することが非常に重要です。または、この規則を実装しないデバイスに何らかの方法で制限を設けます。
Announcements are media played to the user. Announcements can be static media files, media files generated in real-time, media streams generated in real-time, multimedia objects, or combinations of the above.
発表は、ユーザーにプレイされるメディアです。発表は、静的メディアファイル、リアルタイムで生成されたメディアファイル、リアルタイムで生成されたメディアストリーム、マルチメディアオブジェクト、または上記の組み合わせなどです。
Media mixing is the act of mixing different RTP streams, as described in RFC 3550 [13]. Note that the service described here suffices for simple mixing of media for a basic conferencing service. This service does not address enhanced conferencing services, such as floor control, gain control, muting, subconferences, etc. MSCML [21] addresses enhanced conferencing. However, that is beyond the scope of this document. Interested readers should read conferencing-framework [22] for details on the IETF SIP conferencing framework.
メディアミキシングは、RFC 3550 [13]に記載されているように、さまざまなRTPストリームを混合する行為です。ここで説明するサービスは、基本的な会議サービスのためのメディアの単純な混合に十分であることに注意してください。このサービスは、フロアコントロール、ゲインコントロール、ミュート、サブ会議などの拡張された会議サービスに対処しません。MSCML[21]は、強化された会議に対処します。ただし、これはこのドキュメントの範囲を超えています。興味のある読者は、IETF SIP会議フレームワークの詳細については、会議フレームワーク[22]を読む必要があります。
Prompt and collect is where the server prompts the user for some information, as in an announcement, and then collects the user's response. This can be a one-step interaction, for example by playing an announcement, "Please enter your pass code", followed by collecting a string of digits. It can also be a more complex interaction, specified, for example, by VoiceXML [20] or MSCML [21].
プロンプトとコレクションは、発表のように、サーバーがユーザーにいくつかの情報をプロンプトし、ユーザーの応答を収集する場所です。これは、「パスコードを入力してください」と発表して、一連の数字を収集するという発表をプレイすることで、ワンステップの相互作用になる可能性があります。また、たとえばvoiceXML [20]またはMSCML [21]によって指定されている、より複雑な相互作用でもあります。
RFC 2119 [6] the interpretations for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" found in this document.
RFC 2119 [6]キーワードの解釈は、「必須」、「必須」、「必須」、「「必要」」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」をこのドキュメントにあります。
In the context of SIP control of media servers, we take advantage of the fact that the standard SIP URI has a user part. Multifunction media servers do not have users. Thus we use the user address, or the left-hand-side of the URI, as a service indicator.
メディアサーバーのSIP制御のコンテキストでは、標準的なSIP URIにユーザーの部分があるという事実を利用します。多機能メディアサーバーにはユーザーがいません。したがって、ユーザーアドレス、またはURIの左側をサービスインジケーターとして使用します。
The use of the user part of the SIP Request URI has a number of useful properties:
SIPリクエストのユーザー部分の使用には、多くの有用なプロパティがあります。
o There is no change to core SIP. o Only devices that choose to conform to this standard have to implement it. o This document only applies to multifunction SIP-controlled media servers. o This document has no impact on non-multifunction SIP-controlled media servers. o The mechanism described in this document has absolutely no impact on SIP devices other than media servers.
o Core SIPに変更はありません。oこの標準に準拠することを選択したデバイスのみが実装する必要があります。oこのドキュメントは、多機能SIP制御メディアサーバーにのみ適用されます。oこのドキュメントは、非拡張SIP制御メディアサーバーに影響を与えません。oこのドキュメントで説明されているメカニズムは、メディアサーバー以外のSIPデバイスにまったく影響を与えません。
The last bullet point is crucial. In particular, the user part convention described here places absolutely no restrictions on any SIP user agent, proxy, back-to-back user agent (B2BUA), or any future device. The user parts defined here only apply to multifunction media servers that chose to implement the convention. With the exception of a conforming media server, these user names and conventions have no impact on the user part namespace. They do not restrict the use of these user names at devices other than a multifunction media server.
最後の箇条書きは非常に重要です。特に、ここで説明されているユーザーパーツ条約では、SIPユーザーエージェント、プロキシ、連続したユーザーエージェント（B2BUA）、または将来のデバイスにまったく制限がありません。ここで定義されているユーザーパーツは、コンベンションの実装を選択した多機能メディアサーバーにのみ適用されます。適合メディアサーバーを除き、これらのユーザー名とコンベンションは、ユーザーパーツネームスペースに影響を与えません。これらのユーザー名の使用は、多機能メディアサーバー以外のデバイスでの使用を制限していません。
Note that the set of services is small, well defined, and well contained. The section The User Part (Section 7) discusses the issues with using a fixed set of user-space names.
サービスのセットは小さく、明確に定義されており、よく含まれていることに注意してください。セクションユーザーパーツ（セクション7）は、ユーザー空間名の固定セットを使用して問題について説明します。
For per-service security, the media server SHOULD use the security protocols described in RFC 3261 [10].
サービスごとのセキュリティのために、メディアサーバーはRFC 3261 [10]で説明されているセキュリティプロトコルを使用する必要があります。
The media server MAY issue 401 challenges for authentication. The media server SHOULD support the sips: scheme for the announcement service. The media server MUST support the sips: scheme for the dialog and conference services. The level of authentication to require for each service is a matter of local policy.
メディアサーバーは、認証に関する401の課題を発行する場合があります。メディアサーバーは、SIPS：Scheme for the Annection Serviceをサポートする必要があります。メディアサーバーは、SIPS：ダイアログおよび会議サービスのスキームをサポートする必要があります。各サービスに要求する認証のレベルは、ローカルポリシーの問題です。
The media server, upon receiving an INVITE, notes the service indicator. Depending on the service indicator, the media server will either honor the request or return a failure response code.
メディアサーバーは、招待状を受信すると、サービスインジケーターに注意します。サービスインジケーターに応じて、メディアサーバーはリクエストを尊重するか、失敗応答コードを返します。
The service indicator is the concatenation of the service name and an optional service instance identifier, separated by an equal sign.
サービスインジケーターは、サービス名とオプションのサービスインスタンス識別子の連結であり、等しい符号で区切られています。
Per RFC 3261 [10], the service indicator is case insensitive. The service name MUST be from the set alphanumeric characters plus dash (US-ASCII %2C). The service name MUST NOT include an equal sign (US-ASCII %3D).
RFC 3261 [10]ごとに、サービスインジケーターは症例鈍感です。サービス名は、設定された英数字とDASH（US-ASCII％2C）からのものでなければなりません。サービス名には、等号（US-ASCII％3D）を含めてはなりません。
The service name MAY have long- and short-forms, as SIP does for headers.
SIPがヘッダーに対して行うように、サービス名には長い形式と短い形式がある場合があります。
A given service indicator MAY have an associated set of parameters. Such parameters MUST follow the convention set out for SIP URI parameters. That is, a semi-colon separated list of keyword=value pairs.
特定のサービスインジケーターには、関連するパラメーターセットがある場合があります。このようなパラメーターは、SIP URIパラメーターのために設定された条約に従う必要があります。つまり、キーワードのセミコロン分離リスト=値ペア。
Certain services may have an association with a unique service instance on the media server. For example, a given media server can host multiple, separate conference sessions. To identify unique service instances, a unique identifier modifies the service name.
特定のサービスは、メディアサーバー上の一意のサービスインスタンスとの関連がある場合があります。たとえば、特定のメディアサーバーは、複数の個別の会議セッションをホストできます。一意のサービスインスタンスを識別するために、一意の識別子がサービス名を変更します。
The unique identifier MUST meet the rules for a legal user part of a SIP URI. An equal sign, US-ASCII %3D, MUST separate the service indicator from the unique identifier.
一意の識別子は、SIP URIの法律ユーザー部分のルールを満たす必要があります。等記号、US-ASCII％3Dは、サービスインジケーターを一意の識別子から分離する必要があります。
Note that since the service indicator is case insensitive, the service instance identifier is also case insensitive.
サービスインジケーターは症例鈍感であるため、サービスインスタンス識別子も症例鈍感であることに注意してください。
The requesting client issues a SIP INVITE to the media server, specifying the requested service and any appropriate parameters.
要求するクライアントは、SIPがメディアサーバーに招待され、要求されたサービスと適切なパラメーターを指定します。
If the media server can perform the requested service, it does so, following the processing steps described in the service definition document.
メディアサーバーがリクエストされたサービスを実行できる場合、サービス定義ドキュメントで説明されている処理手順に従って、そうします。
If the media server cannot perform the requested service or does not recognize the service indicator, it MUST respond with the response code 488 NOT ACCEPTABLE HERE. This is appropriate, as 488 refers to a problem with the user part of the URI. Moreover, 606 is not appropriate, as some other media server may be able to satisfy the request. RFC 3261 [10] describes the 488 and 606 response codes.
メディアサーバーが要求されたサービスを実行できない場合、またはサービスインジケーターを認識しない場合、ここでは受け入れられない応答コード488で応答する必要があります。488はURIのユーザー部分の問題を指しているため、これは適切です。さらに、他のメディアサーバーがリクエストを満たすことができるため、606は適切ではありません。RFC 3261 [10]は、488および606の応答コードについて説明しています。
Some services require a unique identifier. Most services automatically create a service instance upon the first INVITE with the given identifier. However, if a service requires an existing service instance, and no such service instance exists on the media server, the media server MUST respond with the response code 404 NOT FOUND. This is appropriate as the service itself exists on the media server, but the particular service instance does not. It is as if the user was not home.
一部のサービスには、一意の識別子が必要です。ほとんどのサービスは、指定された識別子を使用した最初の招待でサービスインスタンスを自動的に作成します。ただし、サービスに既存のサービスインスタンスが必要であり、メディアサーバーにそのようなサービスインスタンスが存在しない場合、メディアサーバーは応答コード404が見つからない場合に応答する必要があります。これは、サービス自体がメディアサーバーに存在するため適切ですが、特定のサービスインスタンスは存在しません。それはまるでユーザーが家ではなかったかのようです。
A network announcement is the delivery of a multimedia resource, such as a prompt file, to a terminal device. Note the multimedia resource may be any multimedia object that the media server supports. This service can play a single object with multiple streams, such as a video and audio prompt. However, this service cannot play multiple objects on the same SIP dialog.
ネットワークの発表は、端子デバイスにプロンプトファイルなどのマルチメディアリソースの配信です。メモマルチメディアリソースは、メディアサーバーがサポートするマルチメディアオブジェクトである場合があります。このサービスは、ビデオやオーディオプロンプトなど、複数のストリームを備えた単一のオブジェクトを再生できます。ただし、このサービスは、同じSIPダイアログで複数のオブジェクトを再生することはできません。
There are two types of network announcements. The differentiating characteristic between the two types is whether the network fully sets up the SIP dialog before playing the announcement. The analog in the Public Switched Telephone Network (PSTN) is whether answer supervision is supplied (i.e., does the announcement server answer the call prior to delivering the announcement?).
ネットワークアナウンスには2つのタイプがあります。2つのタイプ間の違いの特性は、発表を再生する前にネットワークがSIPダイアログを完全に設定するかどうかです。公開された電話ネットワーク（PSTN）のアナログは、回答監督が提供されるかどうかです（つまり、アナウンスサーバーは、発表を配信する前に電話に応答しますか？）。
Playing an announcement after call setup is straightforward. First, the requesting device issues an INVITE to the media server requesting the announcement service. The media server negotiates the SDP and responds with a 200 OK. After receiving the ACK from the requesting device, the media server plays the requested object and issues a BYE to the requesting device.
コールのセットアップ後に発表をプレイするのは簡単です。まず、要求デバイスは、アナウンスサービスを要求するメディアサーバーに招待されます。メディアサーバーはSDPを交渉し、200 OKで応答します。要求デバイスからACKを受信した後、メディアサーバーは要求されたオブジェクトを再生し、リクエストデバイスに別々の発行を行います。
If the media server supports announcements, but it cannot find the referenced URI, it MUST respond with the 404 response code and SHOULD send the reason phrase "Announcement content not found".
メディアサーバーが発表をサポートしているが、参照されているURIを見つけることができない場合、404応答コードで応答する必要があり、「発見されていないコンテンツのアナウンス」という理由を送信する必要があります。
If the media server receives an INVITE for the announcement service without a "play=" parameter, it MUST respond with the response code 400 and SHOULD send the reason phrase "Mandatory play parameter missing".
メディアサーバーが「play =」パラメーターなしでアナウンスサービスの招待を受信した場合、応答コード400で応答する必要があり、「必須の再生パラメーターが欠落」という理由のフレーズを送信する必要があります。
If there is an error retrieving the announcement, the media server MUST respond with a 400 response code and SHOULD send the reason phrase "Announcement content could not be retrieved". In addition the media server SHOULD include a Warning header with appropriate explanatory text explaining what failed.
発表を取得するエラーがある場合、メディアサーバーは400の応答コードで応答する必要があり、「アナウンスコンテンツを取得できなかった」という理由のフレーズを送信する必要があります。さらに、メディアサーバーには、失敗したものを説明する適切な説明テキストを備えた警告ヘッダーを含める必要があります。
The Request URI fully describes the announcement service through the use of the user part of the address and additional URI parameters. The user portion of the address, "annc", specifies the announcement service on the media server. The service has several associated URI parameters that control the content and delivery of the announcement.
リクエストURIは、アドレスのユーザー部分と追加のURIパラメーターを使用して、アナウンスサービスを完全に説明しています。アドレスのユーザー部分「ANNC」は、メディアサーバーでアナウンスサービスを指定します。このサービスには、発表のコンテンツと配信を制御するいくつかの関連するURIパラメーターがあります。
These parameters are described below:
これらのパラメーターを以下に説明します。
play Specifies the resource or announcement sequence to be played.
再生すると、再生されるリソースまたはアナウンスシーケンスを指定します。
repeat Specifies how many times the media server should repeat the announcement or sequence named by the "play=" parameter. The value "forever" means the repeat should be effectively unbounded. In this case, it is RECOMMENDED the media server implements some local policy, such as limiting what "forever" means, to ensure errant clients do not create a denial of service attack.
繰り返し、メディアサーバーが「play =」パラメーターで名前が付けられたアナウンスまたはシーケンスを繰り返す回数を指定します。「永遠」の値は、繰り返しが効果的に無制限であることを意味します。この場合、メディアサーバーは、「永遠」の意味を制限するなど、誤ったクライアントがサービス攻撃の拒否を作成しないようにするなど、いくつかのローカルポリシーを実装することをお勧めします。
delay Specifies a delay interval between announcement repetitions. The delay is measured in milliseconds.
遅延は、発表の繰り返し間の遅延間隔を指定します。遅延はミリ秒で測定されます。
duration Specifies the maximum duration of the announcement. The media server will discontinue the announcement and end the call if the maximum duration has been reached. The duration is measured in milliseconds.
期間は、発表の最大期間を指定します。メディアサーバーは、発表を中止し、最大期間に達した場合にコールを終了します。期間はミリ秒単位で測定されます。
locale Specifies the language and optionally country variant of the announcement sequence named in the "play=" parameter. RFC 3066 [9] specifies the locale tag. The locale tag is usually a two- or three-letter code per ISO 639-1 [11]. The country variant is also often a two-letter code per ISO 3166-1 [12]. These elements are concatenated with a single under bar (%x5F) character, such as "en_CA". If only the language is specified, such as locale=en, the choice of country variant is an implementation matter. Implementations SHOULD provide the best possible match between the requested locale and the available languages in the event the media server cannot honor the locale request precisely. For example, if the request has locale=ca_FR, but the media server only has fr_FR available, the media server should use the fr_FR variant. Implementations SHOULD provide a default locale to use if no language variants are available.
Localeは、「Play =」パラメーターで名前が付けられたアナウンスシーケンスの言語とオプションの国のバリアントを指定します。RFC 3066 [9]は、ロケールタグを指定します。ロケールタグは通常、ISO 639-1 [11]ごとに2レッターまたは3文字のコードです。国のバリアントは、多くの場合、ISO 3166-1 [12]ごとに2文字のコードです。これらの要素は、「EN_CA」などの単一の下のバー（％x5F）文字で連結されています。Locale = enなどの言語のみが指定されている場合、国のバリアントの選択は実装の問題です。実装は、メディアサーバーがロケールリクエストを正確に尊重できない場合に、要求されたロケールと利用可能な言語との間に可能な限り最高の一致を提供する必要があります。たとえば、要求にlocale = ca_frがあるが、メディアサーバーにFR_FRのみが利用可能な場合、メディアサーバーはFR_FRバリアントを使用する必要があります。実装は、言語バリエーションが利用できない場合に使用するデフォルトのロケールを提供する必要があります。
param[n] Provides a mechanism for passing values that are to be substituted into an announcement sequence. Up to 9 parameters ("param1=" through "param9=") may be specified. The mechanics of announcement sequences are beyond the scope of this document.
PARAM [n]は、アナウンスシーケンスに置き換える値を渡すメカニズムを提供します。最大9つのパラメーター（ "param1 ="から "param9 ="）を指定できます。アナウンスシーケンスのメカニズムは、このドキュメントの範囲を超えています。
extension Provides a mechanism for extending the parameter set. If the media server receives an extension it does not understand, it MUST silently ignore the extension parameter and value.
拡張機能は、パラメーターセットを拡張するためのメカニズムを提供します。メディアサーバーが理解できない拡張機能を受信した場合、拡張パラメーターと値を静かに無視する必要があります。
The "play=" parameter is mandatory and MUST be present. All other parameters are OPTIONAL.
「play =」パラメーターは必須であり、存在する必要があります。他のすべてのパラメーターはオプションです。
NOTE: Some encodings are not self-describing. Thus, the implementation relies on filename extension conventions for determining the media type.
注：一部のエンコーディングは自己説明ではありません。したがって、この実装は、メディアタイプを決定するためのファイル名拡張規則に依存しています。
Note that RFC 3261 [10] implies that proxies are supposed to pass parameters through unchanged. However, be aware that non-conforming proxies may strip Request-URI parameters. That said, given the likely scenarios for the mechanisms presented in this document, this should not be an issue. Most likely, the proxy inserting the parameters is the last proxy before the media server. If the service provider deploys a proxy for load balancing or service location purposes, the service provider should ensure that its choice of proxy preserves parameters.
RFC 3261 [10]は、プロキシが変更されていないパラメーターを渡すことになっていることを意味することに注意してください。ただし、不適合プロキシがリクエスト-URIパラメーターを削除する可能性があることに注意してください。とはいえ、このドキュメントに示されているメカニズムの可能性のあるシナリオを考えると、これは問題ではないはずです。おそらく、パラメーターを挿入するプロキシは、メディアサーバーの前の最後のプロキシです。サービスプロバイダーがロードバランシングまたはサービスの場所を目的とするプロキシを展開する場合、サービスプロバイダーはプロキシの選択がパラメーターを保持することを確認する必要があります。
The form of the SIP Request URI for announcements is as follows. Note that the backslash, CRLF, and spacing before the "play=" in the example is for readability purposes only.
発表のSIP要求URIの形式は次のとおりです。例の「Play =」の前のバックスラッシュ、CRLF、および間隔は、読みやすさのみを目的としていることに注意してください。
sip:annc@ms2.example.net; \
play=http://audio.example.net/allcircuitsbusy.g711
sip:annc@ms2.example.net; \
play=file://fileserver.example.net//geminii/yourHoroscope.wav
The scenarios below assume there is a SIP Proxy, application server, or media gateway controller between the caller and the media server. However, the announcement service works as described below even if the caller invokes the service directly. We chose to discuss the proxy case, as it will be the most common case.
以下のシナリオでは、発信者とメディアサーバーの間にSIPプロキシ、アプリケーションサーバー、またはメディアゲートウェイコントローラーがあると想定しています。ただし、発信者がサービスを直接呼び出す場合でも、アナウンスサービスは以下に説明するように機能します。最も一般的なケースになるため、プロキシケースについて議論することを選択しました。
The caller issues an INVITE to the serving SIP Proxy. The SIP Proxy determines what audio prompt to play to the caller. The proxy responds to the caller with 100 TRYING.
発信者は、サービングSIPプロキシへの招待を発行します。SIPプロキシは、発信者に再生するオーディオプロンプトを決定します。プロキシは、100人の試行で発信者に応答します。
It is important to note that the mechanism described here in no way modifies the behavior of SIP [10]. In particular, this convention does not modify SDP negotiation [18].
ここで説明されているメカニズムは、SIPの挙動を決して変更しないことに注意することが重要です[10]。特に、この条約はSDP交渉を変更しません[18]。
The proxy issues an INVITE to the media server, requesting the appropriate prompt to play coded in the play= parameter. The media server responds with 200 OK. The proxy relays the 200 OK to the caller. The caller then issues an ACK. The proxy then relays the ACK to the media server.
プロキシはメディアサーバーへの招待状を発行し、Play =パラメーターでコード化された再生を再生するための適切なプロンプトを要求します。メディアサーバーは200 OKで応答します。プロキシは、発信者に200 OKをリレーします。その後、発信者はACKを発行します。その後、プロキシはACKをメディアサーバーに中継します。
With the call established, the media server plays the requested prompt. When the media server completes the play of the prompt, it issues a BYE to the proxy. The proxy then issues a BYE to the caller.
コールが確立された状態で、メディアサーバーは要求されたプロンプトを再生します。メディアサーバーがプロンプトの再生を完了すると、プロキシにさようならを発行します。その後、プロキシは発信者にさようならを発行します。
Caller Proxy Media Server
| INVITE | |
|----------------------->| INVITE |
| 100 TRYING |----------------------->|
|<-----------------------| 200 OK |
| 200 OK |<-----------------------|
|<-----------------------| |
| ACK | |
|----------------------->| ACK |
| |----------------------->|
| | |
| Play Announcement (RTP) |
|<================================================|
| | |
| | BYE |
| BYE |<-----------------------|
|<-----------------------| |
| 200 OK | |
|----------------------->| 200 OK |
| |----------------------->|
| | |
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 4234 [7].
次の構文仕様では、RFC 4234 [7]に記載されているように、拡張されたバックスノーフォーム（BNF）を使用しています。
ANNC-URL = sip-ind annc-ind "@" hostport annc-parameters uri-parameters
annc-url = sip-ind annc-ind "@" hostport annc-parameters uri-parameters
sip-ind = "sip:" / "sips:"
annc-ind = "annc"
annc-parameters = ";" play-param [ ";" content-param ]
[ ";" delay-param]
[ ";" duration-param ]
[ ";" repeat-param ]
[ ";" locale-param ]
[ ";" variable-params ]
[ ";" extension-params ]
play-param = "play=" prompt-url
play-param = "play =" prompt-url
content-param = "content-type=" MIME-type
content-param = "content-type =" mime-type
delay-param = "delay=" delay-value
delay-value = 1*DIGIT
duration-param = "duration=" duration-value
duration-param = "duration =" duration-value
duration-value = 1*DIGIT
repeat-param = "repeat=" repeat-value
Repeat-Param = "Repeat =" Repeat-Value
repeat-value = 1*DIGIT / "forever"
locale-param = "locale=" token
; per RFC 3066, usually
; ISO639-1_ISO3166-1
; e.g., en, en_US, en_UK, etc.
variable-params = param-name "=" variable-value
variable-params = param-name "=" variable-value
param-name = "param" DIGIT ; e.g., "param1"
param-name = "param" digit;たとえば、「param1」
variable-value = 1*(ALPHA / DIGIT)
extension-params = extension-param [ ";" extension-params ]
extension-Params = Extension-Param [";"拡張パラム]
extension-param = token "=" token
拡張パラム=トークン "="トークン
"uri-parameters" is the SIP Request-URI parameter list as described in RFC 3261 [10]. All parameters of the Request URI are part of the URI matching algorithm.
「URI-Parameters」は、RFC 3261 [10]で説明されているSIPリクエスト-URIパラメーターリストです。リクエストURIのすべてのパラメーターは、URIマッチングアルゴリズムの一部です。
The MIME-type is the MIME [1] [2] [3] [4] [5] content type for the announcement, such as audio/basic, audio/G729, audio/mpeg, video/mpeg, and so on.
MIMEタイプは、Audio/Basic、Audio/G729、Audio/MPEG、Video/MPEGなど、アナウンスのMIME [1] [2] [3] [4] [5]コンテンツタイプです。
A number of MIME registrations, which could be used here, have parameters, for instance, video/DV. To accommodate this, and retain compatibility with the SIP URI structure, the MIME-type parameter separator (semicolon, %3b) and value separator (equal, %d3) MUST be escaped. For example:
ここで使用できる多くのMIME登録には、たとえばビデオ/DVなどのパラメーターがあります。これに対応し、SIP URI構造との互換性を保持するには、MIMEタイプのパラメーターセパレーター（Semicolon、％3B）および値セパレーター（等しい、％D3）を逃がす必要があります。例えば：
sip:annc@ms.example.net; \
play=file://fs.example.net//clips/my-intro.dvi; \
content-type=video/mpeg%3bencode%d3314M-25/625-50
The locale-value consists of a tag as specified in RFC 3066 [9].
ロケール値は、RFC 3066で指定されているタグで構成されています[9]。
The definition of hostport is as specified by RFC 3261 [10].
Hostportの定義は、RFC 3261 [10]で指定されているとおりです。
The syntax of prompt-url consists of a URL scheme as specified by RFC 3986 [8] or a special token indicating a provisioned announcement sequence. For example, the URL scheme MAY include any of the following.
Prompt-URLの構文は、RFC 3986 [8]で指定されているURLスキームまたはプロビジョニングされたアナウンスシーケンスを示す特別なトークンで構成されています。たとえば、URLスキームには以下のいずれかが含まれる場合があります。
o http/https o ftp o file (referencing a local or NFS (RFC 3530 [16]) object) o nfs (RFC 2224 [14])
o http/https o ftp oファイル（ローカルまたはNFS（RFC 3530 [16]）オブジェクトを参照）O NFS（RFC 2224 [14]）
If a provisioned announcement sequence is to be played, the value of prompt-url will have the following form:
プロビジョニングされたアナウンスシーケンスを再生する場合、Prompt-URLの値には次の形式があります。
prompt-url = "/provisioned/" announcement-id
PRONT-URL = "/PROVISIONED/" Annuction-ID
announcement-id = 1*(ALPHA / DIGIT)
Note that the scheme "/provisioned/" was chosen because of a hesitation to register a "provisioned:" URI scheme.
「/プロビジョニング/」というスキームは、「プロビジョニング：」の登録をためらうために選択されたことに注意してください。
This document is strictly focused on the SIP interface for the announcement service and, as such, does not detail how announcement sequences are provisioned or defined.
このドキュメントは、アナウンスサービスのSIPインターフェイスに厳密に焦点を当てているため、アナウンスシーケンスがどのようにプロビジョニングまたは定義されているかを詳述していません。
Note that the media type of the object the prompt-url refers to can be most anything, including audio file formats, text file formats, or URI lists. See the Prompt and Collect Service (Section 4) section for more on this topic.
プロンプト-URLが言及するオブジェクトのメディアタイプは、オーディオファイル形式、テキストファイル形式、またはURIリストなど、ほとんどのものである可能性があることに注意してください。このトピックの詳細については、プロンプトと収集サービス（セクション4）セクションを参照してください。
This service is also known as a voice dialog. It establishes an aural dialog with the user.
このサービスは、音声ダイアログとしても知られています。ユーザーとの聴覚的な対話を確立します。
The dialog service follows the model of the announcement service. However, the service indicator is "dialog". The dialog service takes a parameter, voicexml=, indicating the URI of the VoiceXML script to execute.
ダイアログサービスは、アナウンスサービスのモデルに従います。ただし、サービスインジケーターは「ダイアログ」です。ダイアログサービスには、パラメーターboicexml =を使用して、実行するVoiceXMLスクリプトのURIを示します。
sip:dialog@mediaserver.example.net; \
voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml
A Media Server MAY accept additional SIP request URI parameters and deliver them to the VoiceXML interpreter session as session variables.
メディアサーバーは、追加のSIP要求URIパラメーターを受け入れ、セッション変数としてVoiceXMLインタープリターセッションに配信する場合があります。
Although not good VoiceXML programming practice, VoiceXML scripts might contain sensitive information, such as a user's pass code in a DTMF grammar. Thus, the media server MUST support the https scheme for the voicexml parameter for secure fetching of scripts. Likewise, dynamic grammars often do have user-identifying information. As such, the VoiceXML browser implementation on the media server MUST support https fetching of grammars and subsequent documents.
VoiceXMLプログラミングの練習は良くありませんが、voiceXMLスクリプトには、DTMF文法のユーザーのパスコードなど、機密情報が含まれている場合があります。したがって、メディアサーバーは、スクリプトを安全にフェッチするために、VoiceXMLパラメーターのHTTPSスキームをサポートする必要があります。同様に、動的文法には多くの場合、ユーザーを特定する情報があります。そのため、メディアサーバーでのVoiceXMLブラウザの実装は、文法と後続のドキュメントのHTTPSの取得をサポートする必要があります。
Returned information often is sensitive. For example, the information could be financial information or instructions. Thus, the media server MUST support https posting of results.
返された情報はしばしば敏感です。たとえば、情報は財務情報または指示である可能性があります。したがって、メディアサーバーは、結果のHTTPSの投稿をサポートする必要があります。
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 4234 [7].
次の構文仕様では、RFC 4234 [7]に記載されているように、拡張されたバックスノーフォーム（BNF）を使用しています。
DIALOG-URL = sip-ind dialog-ind "@" hostport dialog-parameters
dialog-url = sip-indダイアログインド "@" hostport dialog-parameters
sip-ind = "sip:" / "sips:"
dialog-ind = "dialog"
dialog-parameters = ";" dialog-param [ vxml-parameters ] [ uri-parameters ]
dialog-parameters = ";"Dialog-Param [VXML-Parameters] [URI-Parameters]
dialog-param = "voicexml=" vxml-url
dialog-param = "voicexml =" vxml-url
vxml-parameters = vxml-param [ vxml-parameters ]
vxml-parameters = vxml-param [vxml-parameters]
vxml-param = ";" vxml-keyword "=" vxml-value
vxml-keyword = token
vxml-value = token
The vxml-url is the URI of the VoiceXML script. If present, other parameters get passed to the VoiceXML interpreter session with the assigned vxml-keyword vxml-value pairs. Note that all vxml-keywords MUST have values.
VXML-URLは、VoiceXMLスクリプトのURIです。存在する場合、その他のパラメーターは、割り当てられたVXML-KeyWord VXML-ValueペアでVoiceXMLインタープリターセッションに渡されます。すべてのVXML-KeyWordには値が必要であることに注意してください。
If there is a vxml-keyword without a corresponding vxml-value, the media server MUST reject the request with a 400 BAD REQUEST response code. In addition, the media server MUST state "Missing VXML Value" in the reason phrase.
対応するVXML値がないVXML-KeyWordがある場合、メディアサーバーは400の悪い要求応答コードでリクエストを拒否する必要があります。さらに、メディアサーバーは、理由フレーズに「VXML値の欠落」を述べる必要があります。
The media server presents the parameters as environment variables in the connection object. Specifically, the parameter appears in the connection.sip tree.
メディアサーバーは、接続オブジェクトの環境変数としてパラメーターを提示します。具体的には、パラメーターは接続のツリーに表示されます。
If the Media Server does not support the passing of keyword-value pairs to the VoiceXML interpreter session, it MUST ignore the parameters.
Media ServerがbeoveXMLインタープリターセッションへのキーワード値ペアの通過をサポートしていない場合、パラメーターを無視する必要があります。
"uri-parameters" is the SIP Request-URI parameter list as described in RFC 3261 [10]. All parameters in the parameter list, whether they come from uri-parameters or from vxml-keyworks, are part of the URI matching algorithm.
「URI-Parameters」は、RFC 3261 [10]で説明されているSIPリクエスト-URIパラメーターリストです。パラメーターリストのすべてのパラメーターは、URIパラメータからまたはVXML-KeyWorksからのものであろうと、URIマッチングアルゴリズムの一部です。
One identifies mixing sessions through their SIP request URIs. To create a mixing session, one sends an INVITE to a request URI that represents the session. If the URI does not already exist on the media server and the requested resources are available, the media server creates a new mixing session. If there is an existing URI for the session, then the media server interprets it as a request for the new session to join the existing session. The form of the SIP request URI for conferencing is:
SIPリクエストURIを使用して、ミキシングセッションを識別します。ミキシングセッションを作成するには、セッションを表すURIのリクエストに招待状を送信します。URIがメディアサーバーにまだ存在しておらず、要求されたリソースが利用可能な場合、メディアサーバーは新しいミキシングセッションを作成します。セッションに既存のURIがある場合、メディアサーバーは、既存のセッションに参加する新しいセッションのリクエストとして解釈されます。会議のためのSIPリクエストURIの形式は次のとおりです。
sip:conf=uniqueIdentifier@mediaserver.example.net
The left-hand side of the request URI is actually the username of the request in the request URI and the To header. The host portion of the URI identifies a particular media server. The "conf" user name conveys to the media server that this is a request for the mixing service. The uniqueIdentifier can be any value that is compliant with the SIP URI specification. It is the responsibility of the conference control application to ensure the identifier is unique within the scope of any potential conflict.
リクエストの左側は、実際にはリクエストのリクエストのユーリとヘッダーのリクエストのユーザー名です。URIのホスト部分は、特定のメディアサーバーを識別します。「conf」ユーザー名は、これがミキシングサービスのリクエストであることをメディアサーバーに伝えます。一意のidentifierは、SIP URI仕様に準拠した任意の値にすることができます。識別子が潜在的な競合の範囲内で一意であることを確認することは、会議管理アプリケーションの責任です。
In the terminology of the conferencing framework [22], this URI convention tells the media server that the application server is requesting it to act as a Focus. The conf-id value identifies the particular focus instance.
会議フレームワーク[22]の用語では、このURI条約は、アプリケーションサーバーがフォーカスとして機能するように要求していることをメディアサーバーに伝えています。conf-id値は、特定のフォーカスインスタンスを識別します。
As a focus in the conferencing framework, the media server MUST support the ";isfocus" parameter in the Request URI. Note, however, that the presence or absence of the ";isfocus" parameter has no protocol impact at the media server.
会議のフレームワークに焦点を当てているため、メディアサーバーはリクエストURIの「; isFocus」パラメーターをサポートする必要があります。ただし、「; isfocus」パラメーターの存在または不在は、メディアサーバーにプロトコルの影響がないことに注意してください。
It is worth noting that the conference URI shared between the application and media servers provides enhanced security, as the SIP control interface does not have to be exposed to participants. It also allows the assignment of a specific media server to be delayed as long as possible, thereby simplifying resource management.
SIPコントロールインターフェイスを参加者にさらす必要がないため、アプリケーションサーバーとメディアサーバーの間でURIが共有され、メディアサーバーがセキュリティが強化されることは注目に値します。また、特定のメディアサーバーの割り当てを可能な限り遅らせることができ、それによりリソース管理が簡素化されます。
One can add additional legs to the conference by INVITEing them to the above-mentioned request URI. Per the matching rules of RFC 3261 [10], the conf-id parameter is part of the matching string.
上記のリクエストURIにそれらを招待することにより、会議に追加の脚を追加できます。RFC 3261 [10]の一致するルールに従って、conf-idパラメーターは一致する文字列の一部です。
Conversely, one can remove legs by issuing a BYE in the corresponding dialog. The mixing session, and thus the conference-specific request URI, remains active so long as there is at least one SIP dialog associated with the given request URI.
逆に、対応するダイアログでさようならを発行することで脚を削除できます。ミキシングセッション、したがって会議固有のリクエストURIは、指定されたリクエストURIに関連付けられているSIPダイアログが少なくとも1つある限り、アクティブのままです。
If the Request-URI has "conf" as the user part, but does not have a conf-id parameter, the media server MUST respond with a 404 NOT FOUND.
リクエスト-URIがユーザーパーツとして「conf」を持っているが、conf-idパラメーターがない場合、メディアサーバーは404が見つかりませんでした。
NOTE: The media server could create a unique conference instance and return the conf-id string to the User Agent Clinet (UAC) if there is no conf-id present. However, such an operation may have other operational issues, such as permissions and billing. Thus an application server or proxy is a better place to do such an operation. Moreover, such action would make the media server into a Conference Factory in the terminology of conference-framework [22]. That is not the appropriate behavior for a media server.
注：メディアサーバーは、一意の会議インスタンスを作成し、conf-idが存在しない場合は、conf-id文字列をユーザーエージェントクリニット（UAC）に返すことができます。ただし、このような操作には、アクセス許可や請求など、他の運用上の問題がある場合があります。したがって、アプリケーションサーバーまたはプロキシは、そのような操作を行うのに適した場所です。さらに、このようなアクションは、メディアサーバーを会議フレームワークの用語で会議工場にするでしょう[22]。これは、メディアサーバーにとって適切な動作ではありません。
Since some conference use cases, such as business conferencing, have billing implications, the media server SHOULD authenticate the application server or proxy. At a minimum, the media server MUST implement sips:.
ビジネス会議などの一部の会議のユースケースには請求の影響があるため、メディアサーバーはアプリケーションサーバーまたはプロキシを認証する必要があります。少なくとも、メディアサーバーはSIPを実装する必要があります。
This diagram shows the establishment of a three-way conference. This section is informative. It is only one method of establishing a conference. This example shows a simple back-to-back user agent.
この図は、三者会議の設立を示しています。このセクションは有益です。会議を確立する方法の1つにすぎません。この例は、単純な連続したユーザーエージェントを示しています。
The conference-framework [22] describes additional parameters and behaviors of the Application Server. For example, the first INVITE from P1 to the Application Server would include the ";isfocus" parameter; the Application Server would act as a Conference Factory; and so on. However, none of that protocol machinery has an impact on the operation of the Application Server to Media Server interface, which is the focus of this protocol document.
Conference-Framework [22]は、アプリケーションサーバーの追加のパラメーターと動作について説明します。たとえば、P1からアプリケーションサーバーへの最初の招待には、「; isfocus」パラメーターが含まれます。アプリケーションサーバーは会議工場として機能します。等々。ただし、そのプロトコル機械は、このプロトコルドキュメントの焦点であるMedia Serverインターフェイスへのアプリケーションサーバーの操作に影響を与えるものはありません。
P1 P2 P3 Application Server Media Server
| | | | |
| INVITE sip:public-conf@as.example.net |
|---------------------------------->| |
| | | INVITE sip:conf=123@ms.example.net |
| | | |------------------>|
| | | | 200 OK |
| 200 OK | |<------------------|
|<----------------------------------| |
| ACK | | | |
|---------------------------------->| ACK |
| | | |------------------>|
| | | RTP w/ P1 | |
|<=====================================================>|
| | | | |
| INVITE sip:public-conf@as.example.net |
| |-------------------------->| |
| | | INVITE sip:conf=123@ms.example.net |
| | | |------------------>|
| | | | 200 OK |
| | 200 OK | |<------------------|
| |<--------------------------| |
| | ACK | | |
| |-------------------------->| ACK |
| | | |------------------>|
| | | | |
| | | RTP w/ P1+P2-P2 | |
| |<=============================================>|
| | | RTP w/ P1+P2-P1 | |
|<=====================================================>|
| | | | |
| INVITE sip:public-conf@as.example.net |
| | |----------------->| |
| | | INVITE sip:conf=123@ms.example.net |
| | | |------------------>|
| | | | 200 OK |
| | | 200 OK |<------------------|
| | |<-----------------| |
| | | ACK | |
| | |----------------->| ACK |
| | | |------------------>|
| | | | |
| | | RTP w/ P1+P2+P3-P3 |
| | |<====================================>|
| | | RTP w/ P1+P2+P3-P2 |
| |<=============================================>|
| | | RTP w/ P1+P2+P3-P1 |
|<=====================================================>|
| | | | |
| | | | |
Using the terminology of conference-framework [22], the Application Server is the Conference Factory, and the Media Server is the Conference Focus.
Conference-Framework [22]の用語を使用して、アプリケーションサーバーは会議工場であり、メディアサーバーは会議の焦点です。
Note that the above call flow does not show any 100 TRYING messages that would typically flow from the Application Server to the UACs; nor does it show the ACKs from the UACs to the Application Server or from the Application Server to the Media Server.
上記のコールフローには、通常、アプリケーションサーバーからUACSに流れる100の試行メッセージが表示されないことに注意してください。また、UACSからアプリケーションサーバー、またはアプリケーションサーバーからメディアサーバーにACKを表示しません。
Each leg can drop out either under the supervision of the UAC, by the UAC sending a BYE, or under the supervision of the Application Server, by the Application Server issuing a BYE. In either case, the Application Server will either issue a BYE on behalf of the UAC or issue it directly to the Media Server, corresponding to the respective disconnect case.
各レッグは、UACの監督の下、UACがさようならを送信することにより、またはアプリケーションサーバーがByeを発行するアプリケーションサーバーの監督の下で脱落することができます。どちらの場合でも、アプリケーションサーバーはUACに代わってさようならを発行するか、それぞれの切断ケースに対応するメディアサーバーに直接発行します。
It is left as a trivial exercise to the reader for how the Application Server can mute legs, create side conferences, and so forth.
アプリケーションサーバーが脚をミュートしたり、サイド会議を作成したりする方法など、読者に些細な演習として残されています。
Note that the Application Server is a server to the participants (UACs). However, the Application Server is a client for mixing services to the Media Server.
アプリケーションサーバーは、参加者（UACS）のサーバーであることに注意してください。ただし、アプリケーションサーバーは、サービスをメディアサーバーにミキシングするためのクライアントです。
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 4234 [7].
次の構文仕様では、RFC 4234 [7]に記載されているように、拡張されたバックスノーフォーム（BNF）を使用しています。
CONF-URL = sip-ind conf-ind "=" instance-id "@" hostport [ uri-parameters ]
conf-url = sip-ind conf-ind "=" instance-id "@" hostport [uri-parameters]
sip-ind = "sip:" / "sips:"
conf-ind = "conf"
instance-id = token
"uri-parameters" is the SIP Request-URI parameter list as described in RFC 3261 [10]. All parameters in the parameter list are part of the URI matching algorithm.
「URI-Parameters」は、RFC 3261 [10]で説明されているSIPリクエスト-URIパラメーターリストです。パラメーターリストのすべてのパラメーターは、URIマッチングアルゴリズムの一部です。
The IANA has registered the following parameters in the SIP/SIPS URI Parameters registry, following the specification required policy of RFC 3969 [19]:
IANAは、RFC 3969の仕様に従って、SIP/SIPS URIパラメータレジストリに次のパラメーターを登録しています[19]：
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
play no RFC 4240
repeat no RFC 4240
delay no RFC 4240
duration no RFC 4240
locale no RFC 4240
param[n] no RFC 4240
extension no RFC 4240
There has been considerable discussion about the wisdom of using fixed user parts in a request URI. The most common objection is that the user part should be opaque and a local matter. The other objection is that using a fixed user part removes those specified user addresses from the user address space.
Request URIで固定ユーザーパーツを使用するという知恵についてかなりの議論がありました。最も一般的な異議は、ユーザーの部分が不透明でローカルな問題であることです。もう1つの異議は、固定ユーザーパーツを使用すると、ユーザーアドレス空間から指定されたユーザーアドレスが削除されることです。
We address the latter issue first. The common example is the Postmaster address defined by RFC 2821 [15]. The objection is that by using the Postmaster token for something special, one removes that token for anyone. Thus, the Postmaster General of the United States, for example, cannot have the mail address Postmaster@usps.gov. However, one may debate whether this is a significant limitation.
最初に後者の問題に対処します。一般的な例は、RFC 2821 [15]で定義されたポストマスターアドレスです。異議は、ポストマスタートークンを使用して特別なものに使用することで、誰のためにそのトークンを削除するということです。したがって、たとえば、米国の郵便局長は、master@usps.govのメールアドレスを持つことはできません。ただし、これが重大な制限であるかどうかを議論する場合があります。
This document explicitly addresses this issue. The user names described in the text (namely annc, ivr, dialog, and conf) are available for whatever local use a given SIP user agent or proxy wishes for them. What this document does is give special meaning for these user names at media servers that implement this specification. If a media server chooses not to implement this specification, nothing breaks. If a user wishes to use one of the user names described in this document at their SIP user agent, nothing breaks and their user agent will work as expected.
このドキュメントは、この問題に明示的に対処しています。テキストで説明されているユーザー名（つまり、ANNC、IVR、ダイアログ、およびCONF）は、特定のSIPユーザーエージェントまたはプロキシの希望を希望するローカルで使用できます。このドキュメントが行うことは、この仕様を実装するメディアサーバーでこれらのユーザー名に特別な意味を与えることです。メディアサーバーがこの仕様を実装しないことを選択した場合、何も壊れません。ユーザーがSIPユーザーエージェントでこのドキュメントで説明されているユーザー名のいずれかを使用したい場合、何も壊れず、ユーザーエージェントは予想どおりに機能します。
The key point is, one cannot confuse the namespace at a Media Server with the namespace for an organization. For example, let us take the case where a network offers services for "Ann Charles". She likes to use the name "annc", and thus she would like to use "sip:annc@example.net". We offer there is ABSOLUTELY NO NAME COLLISION WHATSOEVER. Why is this so? This is so because sip:annc@example.net will resolve to the specific user at a specific device for Ann. As an example, example.net's SIP Proxy Server resolves sip:annc@example.net to annc@anns-phone.example.net. Conversely, one directs requests for the media service annc directly to the Media Server, e.g., sip:annc@ms21.ap.example.net. Moreover, by definition, requests for Ann Charles, or anything other than the announcement service, will NEVER be directly sent to the Media Server. If that were not true, no phone in the world could use the user part "eburger", as eburger is a reserved user part in the Brooktrout domain. Clearly, this is not the case.
重要なポイントは、メディアサーバーの名前空間を組織の名前空間と混同することができないということです。たとえば、ネットワークが「アンチャールズ」のサービスを提供するケースを見てみましょう。彼女は「ANNC」という名前を使用するのが好きなので、「sip：annc@example.net」を使用したいと思います。名前の衝突はまったくありません。なぜそうなの？これは、sip：annc@example.netがANNの特定のデバイスで特定のユーザーに解決するためです。例として、example.netのSIPプロキシサーバーは、sip：annc@example.netをannc@anns-phone.example.netに解決します。逆に、メディアサービスANNCのリクエストをメディアサーバーに直接指示します。たとえば、sip：annc@ms21.ap.example.net。さらに、定義上、アン・チャールズのリクエスト、またはアナウンスサービス以外は、メディアサーバーに直接送信されることはありません。それが真実でない場合、EburgerはBrooktroutドメインの予約されたユーザーパーツであるため、世界の電話はユーザーパーツ「Eburger」を使用できません。明らかに、そうではありません。
If one wishes to make their media server accessible to the global Internet, but retain one of the Media Server-specific user names in the domain, a SIP Proxy can easily translate whatever opaque name one chooses to the Media Server-specific user name. For example, if a domain wishes to offer services for the above mentioned Ann Charles at sip:annc@example.com, they can offer the announcement service at sip:my-special-announcement-service@example.com. The former address, sip:annc@example.com, would resolve to the actual device where annc resides. The latter would resolve to the media server announcement server address, sip:annc@mediaserver.example.com, as an example. Note that this convention makes it easier to provision this service. With a fixed mapping at the multifunction media server, there are less provisioning data elements to get wrong.
メディアサーバーをグローバルインターネットにアクセスできるようにしたいが、ドメイン内のメディアサーバー固有のユーザー名の1つを保持したい場合、SIPプロキシは、メディアサーバー固有のユーザー名に選択した不透明な名前を簡単に翻訳できます。たとえば、ドメインが上記のAnn Charles at sip：annc@example.comにサービスを提供したい場合、SIP：MySpecial-Announcement-service@example.comでアナウンスサービスを提供できます。以前のアドレス、SIP：annc@example.comは、ANNCが存在する実際のデバイスに解決します。後者は、例として、Media Serverアナウンスサーバーアドレス（SIP：annc@mediaserver.example.com）に解決します。この条約により、このサービスの提供が容易になることに注意してください。多機能メディアサーバーに固定されたマッピングを使用すると、間違えるためのデータ要素のプロビジョニングが少なくなります。
Here is another way of looking at this issue. Unix reserves the special user "root". Just about all Unix machines have a user root, who has an address "root@a-specific-machine.example.com", where "a-specific-machine" is the fully-qualified domain name (FQDN) of a particular instance of a machine. There are very well-defined semantics for the "root" user.
この問題を見る別の方法があります。UNIXは、特別なユーザー「ルート」を留保します。ほぼすべてのUnixマシンには、「root@a-specific-machine.example.com」というアドレスがあるユーザールートがあり、「a-specific-machine」はマシンの特定のインスタンスの完全に適格なドメイン名（fqdn）です。「ルート」ユーザーには非常に明確に定義されたセマンティクスがあります。
Even though most every Unix machine has a "root" user, often there is no mapping for a "root" user in a domain, such as "root@example.com". Conversely, there is no restriction on creating an MX record for "root@example.com". That choice is fully up to the administrative authority for the domain.
ほとんどすべてのUNIXマシンには「ルート」ユーザーがいますが、多くの場合、「root@example.com」などのドメインに「ルート」ユーザーのマッピングがありません。逆に、「root@example.com」のMXレコードの作成に制限はありません。その選択は、ドメインの管理当局に完全に依存しています。
The "users" proposed by this document, "annc", "conf", and "dialog" are all users at a Media Server, just as the "root", "bin", and "nobody" users are "users" at a Unix host.
このドキュメントで提案された「ユーザー」、「ANNC」、「CONF」、および「ダイアログ」はすべて、「ルート」、「ビン」、「誰も」ユーザーがUNIXホストの「ユーザー」であるように、メディアサーバーのユーザーです。
After much discussion, with input from the W3C URI work group, we considered obfuscating the user name by prepending "__sip-" to the user name. However, as explained above, this obfuscation is not necessary. There is a fundamental difference between a user name at a device and a user name at an MX record (SMTP) or Address-of-Record (SIP). Again, there is no possibility that the name on the device may "leak out" into the SIP routing network.
多くの議論の後、W3C URIワークグループからの入力を使用して、ユーザー名に「__SIP-」を準備することにより、ユーザー名を難読化することを検討しました。ただし、上で説明したように、この難読化は必要ありません。デバイスでのユーザー名と、MXレコード（SMTP）または録音アドレス（SIP）のユーザー名には根本的な違いがあります。繰り返しますが、デバイス上の名前がSIPルーティングネットワークに「漏れ」する可能性はありません。
The most important thing to note about this convention is that the left-hand side of the request URI is opaque to the network. The only network elements that need to know about the convention are the Media Server and client. Even proxies doing mapping resolution, as in the example above for public announcement services, do not need to be aware of the convention. The convention is purely a matter of provisioning.
この条約について注意すべき最も重要なことは、リクエストの左側がURIがネットワークに不透明であることです。コンベンションについて知る必要がある唯一のネットワーク要素は、メディアサーバーとクライアントです。上記の公開アナウンスサービスの例のように、マッピング解像度を行っているプロキシでさえ、条約に注意する必要はありません。条約は純粋にプロビジョニングの問題です。
Some have proposed that such naming be a pure matter of local convention. For example, the thesis of the informational RFC RFC 3087 [17] is that you can address services using a request URI. However, some have taken the examples in the document to an extreme. Namely, that the only way to address services is via arbitrary, opaque, long user parts. Clearly, it is possible to provision the service names, rather than fixed names. While this can work in a closed network, where the Application Servers and Media Servers are in the same administrative domain, this does not work across domains, such as in the Internet. This is because the client of the media service has to know the local name for each service / domain pair. This is particularly onerous for situations where there is an ad hoc relationship between the application and the media service. Without a well-known relationship between service and service address, how would the client locate the service?
このような命名は地元の慣習の純粋な問題であると提案している人もいます。たとえば、情報情報RFC RFC 3087 [17]の論文は、リクエストURIを使用してサービスに対処できることです。ただし、ドキュメントの例を極端に導いた人もいます。すなわち、サービスに対処する唯一の方法は、任意の不透明な長いユーザーパーツを介してであるということです。明らかに、固定名ではなく、サービス名をプロビジョニングすることが可能です。これは、アプリケーションサーバーとメディアサーバーが同じ管理ドメインにあるクローズドネットワークで機能する可能性がありますが、インターネットなどのドメイン間で機能しません。これは、メディアサービスのクライアントが各サービス /ドメインペアのローカル名を知る必要があるためです。これは、アプリケーションとメディアサービスの間にアドホックな関係がある状況で特に面倒です。サービスとサービスアドレスの間によく知られている関係がなければ、クライアントはどのようにサービスを見つけますか？
One very important result of using the user part as the service descriptor is that we can use all of the standard SIP machinery, without modification. For example, Media Servers with different capabilities can SIP Register their capabilities as users. For example, a VoiceXML-only device will register the "dialog" user, while a multi-purpose Media Server will register all of the users. Note that this is why the URI to play is a parameter. Doing otherwise would overburden a normal SIP proxy or redirect server. Conversely, having the conference ID be part of the user part gives an indication that requests get routed similarly (as opposed to requiring a Globally Routable User Agent URI (GRUU), which would restrict routing to the same device).
ユーザーパーツをサービス記述子として使用することの非常に重要な結果の1つは、変更なしですべての標準SIP機械を使用できることです。たとえば、さまざまな機能を備えたメディアサーバーは、ユーザーとしての機能を登録できます。たとえば、VoiceXMLのみのデバイスは「ダイアログ」ユーザーを登録し、多目的メディアサーバーはすべてのユーザーを登録します。これが、プレイするURIがパラメーターである理由であることに注意してください。それ以外の場合は、通常のSIPプロキシまたはリダイレクトサーバーに過剰に負担します。逆に、会議IDをユーザーパーツの一部にすることで、リクエストが同様にルーティングされることを示します（同じデバイスへのルーティングを制限するグローバルにルーティング可能なユーザーエージェントURI（GRUU）を要求するのではなく）。
Likewise, this scheme lets us leverage the standard SIP proxy behavior of using an intelligent redirect server or proxy server to provide high-available services. For example, two Media Servers can register with a SIP redirect server for the annc user. If one of the Media Servers fails, the registration will expire and all requests for the announcement service ("calls to the annc user") will get sent to the surviving Media Server.
同様に、このスキームでは、インテリジェントリダイレクトサーバーまたはプロキシサーバーを使用して高利用可能なサービスを提供するという標準のSIPプロキシ動作を活用できます。たとえば、2つのメディアサーバーがANNCユーザー用のSIPリダイレクトサーバーに登録できます。メディアサーバーのいずれかが失敗した場合、登録が期限切れになり、アナウンスサービス（「ANNCユーザーへの呼び出し」）のすべてのリクエストが存続しているメディアサーバーに送信されます。
Exposing network services with well-known addresses may not be desirable. The Media Server SHOULD authenticate and authorize requesting endpoints per local policy.
よく知られているアドレスでネットワークサービスを公開することは望ましくない場合があります。メディアサーバーは、ローカルポリシーごとにエンドポイントの要求を認証および承認する必要があります。
Some interactions in this document result in the transfer of confidential information. Moreover, many of the interactions require integrity protection. Thus, the Media Server MUST implement the sips: scheme. In addition, application developers are RECOMMENDED to use the security services offered by the Media Server to ensure the integrity and confidentiality of their user's data, as appropriate.
このドキュメントのいくつかの相互作用により、機密情報が転送されます。さらに、相互作用の多くは完全性保護を必要とします。したがって、メディアサーバーはSIPS：スキームを実装する必要があります。さらに、アプリケーション開発者は、メディアサーバーが提供するセキュリティサービスを使用して、必要に応じてユーザーのデータの整合性と機密性を確保することをお勧めします。
Untrusted network elements could use the convention described here for providing information services. Many extant billing arrangements are for completed calls. Successful call completion occurs with a 2xx result code. This can be an issue for the early media announcement service. This is one of the reasons why the early media announcement service is deprecated.
信頼されていないネットワーク要素は、情報サービスを提供するためにここで説明する条約を使用できます。現存する請求の多くは、完了した通話用です。2xxの結果コードでコールの完了が成功します。これは、早期のメディア発表サービスの問題になる可能性があります。これが、早期のメディアアナウンスサービスが非推奨される理由の1つです。
Services such as repeating an announcement forever create the possibility for denial of service attacks. The media server SHOULD have local policies to deal with this, such as time-limiting how long "forever" is, analyzing where multiple requests come from, implementing white-lists for such a service, and so on.
アナウンスを永遠に繰り返すなどのサービスは、サービス拒否攻撃の可能性を生み出します。メディアサーバーには、これに対処するためのローカルポリシーが必要です。たとえば、「永遠」の期間を制限する、複数のリクエストがどこから来たのか、そのようなサービスのホワイトリストの実装などがあります。
Jeff Van Dyke and Andy Spitzer of SnowShore did just about all of the work developing netann, in conjunction with many application developers, media server manufacturers, and service providers, some of whom are listed in the Acknowledgements section. All I did was do the theory and write it up. That also means all of the mistakes are mine, as well.
SnowshoreのJeff Van DykeとAndy Spitzerは、多くのアプリケーション開発者、メディアサーバーメーカー、およびサービスプロバイダーと併せて、Netannを開発している作業のほぼすべてを行いました。私がしたことは、理論をしてそれを書くことだけでした。それはまた、すべての間違いが私のものであることを意味します。
We would like to thank Kevin Summers and Ravindra Kabre of Sonus Networks for their constructive comments, as well as Jonathan Rosenberg of Dynamicsoft and Tim Melanchuk of Convedia for their encouragement. In addition, the discussion at the Las Vegas Interim Workgroup Meeting in 2002 was invaluable for clearing up the issues surrounding the left-hand-side of the request URI. Christer Holmberg helped tune the language of the multimedia announcement service. Orit Levin from Radvision gave a close read on the most recent version of the document. Pete Danielsen from Lucent has consistently provided excellent reviews of the many different versions of this document.
Sonus NetworksのKevin SummersとRavindra Kabreの建設的なコメントと、DynamicsoftのJonathan RosenbergとConvediaのTim Mancharkukに励ましてくれたことに感謝します。さらに、2002年のラスベガス暫定ワークグループ会議での議論は、リクエストURIの左側を取り巻く問題を解決するために非常に貴重でした。Christer Holmbergは、マルチメディアアナウンスサービスの言語を調整するのを手伝いました。RadvisionのOrit Levinは、ドキュメントの最新バージョンについて詳しく読んだことがあります。LucentのPete Danielsenは、このドキュメントのさまざまなバージョンの優れたレビューを一貫して提供してきました。
Pascal Jalet provided the theoretical underpinning and David Rio provided the experimental evidence for why the conference identifier belongs in the user part of the request-URI.
Pascal Jaletは理論的な基盤を提供し、David Rioは会議識別子がRequest-URIのユーザー部分に属する理由の実験的証拠を提供しました。
I am particularly indebted to Alan Johnston for his review of this document and ensuring its conformance with the SIP conference control work in the IETF.
私は、この文書のレビューとIETFでのSIP会議管理作業との適合を確保したことで、Alan Johnstonに特に感謝しています。
Mary Barnes, as usual, found the holes and showed how to fix them.
メアリー・バーンズはいつものように、穴を見つけて、それらを修正する方法を示しました。
The authors would like to give a special thanks to Walter O'Connor for doing much of the initial implementation.
著者は、最初の実装の多くを行ってくれたWalter O'Connorに特別な感謝を捧げたいと思います。
Note that at the time of this writing, there are 7 known independent server implementations that are interoperable with 23 known client implementations. Our apologies if we did not count your implementation.
この執筆時点では、23の既知のクライアント実装と相互運用可能な7つの既知の独立したサーバー実装があることに注意してください。私たちがあなたの実装をカウントしなかった場合、私たちの謝罪。
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[1] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[2] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[3] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[3] ムーア、K。、「MIME（多目的インターネットメール拡張）パート3：ASSASCII以外のテキストのメッセージヘッダー拡張機能」、RFC 2047、1996年11月。
[4] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[4] Freed、N.、Klensin、J。、およびJ. Postel、「多目的インターネットメール拡張機能（MIME）パート4：登録手順」、BCP 13、RFC 2048、1996年11月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[5] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート5：適合基準と例」、RFC 2049、1996年11月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[7] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[8] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[9] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[9] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INIATION PROTOCOL "、RFC 3261、2002年6月。
[11] International Organization for Standardization, "Codes for the representation of names of languages -- Part 1: Alpha-2 code", ISO Standard 639-1, July 2002.
[11] 国際標準化機関、「言語名の表現のためのコード - パート1：アルファ-2コード」、ISO標準639-1、2002年7月。
[12] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO Standard 3166-1, October 1997.
[12] 国際標準化機関、「国の名前とその細分化の表現のためのコード - パート1：国コード」、ISO標準3166-1、1997年10月。
[13] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[13] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[14] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.
[14] Callaghan、B。、「NFS URLスキーム」、RFC 2224、1997年10月。
[15] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[15] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[16] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[16] Shepler、S.、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、M。、およびD. Noveck、「ネットワークファイルシステム（NFS）バージョン4プロトコル」、RFC 3530、2003年4月。
[17] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001.
[17] Campbell、B。およびR. Sparks、「SIP Request-URIを使用したサービスコンテキストの制御」、RFC 3087、2001年4月。
[18] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[18] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[19] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[19] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）のための数字権権（IANA）のユニフォームリソース識別子（URI）パラメーターレジストリを割り当てました」、BCP 99、RFC 3969、2004年12月。
[20] Burnett, D., Hunt, A., McGlashan, S., Porter, B., Lucas, B., Ferrans, J., Rehor, K., Carter, J., Danielsen, P., and S. Tryphonas, "Voice Extensible Markup Language (VoiceXML) Version 2.0", W3C REC REC-voicexml20-20040316, March 2004.
[20] Burnett、D.、Hunt、A.、McGlashan、S.、Porter、B.、Lucas、B.、Ferrans、J.、Rehor、K.、Carter、J.、Danielsen、P。、およびS. Tryphonas、 "Voice Extensible Markup Language（VoiceXML）バージョン2.0"、W3C REC REC REC-VOICEXML20-20040316、3月
[21] Van Dyke, J., Burger, E., Ed., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", Work in Progress, December 2004.
[21] Van Dyke、J.、Burger、E.、ed。、およびA. Spitzer、「Media Server Control Markup Language（MSCML）およびProtocol」、2004年12月の進行中。
[22] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", Work in Progress, October 2004.
[22] Rosenberg、J。、「セッション開始プロトコルとの会議のためのフレームワーク」、2004年10月、進行中の作業。
Authors' Addresses
著者のアドレス
Eric Burger Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
Eric Burger Brooktrout Technology、Inc。18 Keewaydin Dr. Salem、NH 03079 USA
EMail: eburger@brooktrout.com
Jeff Van Dyke Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
ジェフヴァンダイクブルックトラウトテクノロジー、インク18キーウェイディンドクターセーラム、ニューハンプシャー03079 USA
EMail: jvandyke@brooktrout.com
Andy Spitzer Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
Andy Spitzer Brooktrout Technology、Inc。18 Keewaydin Dr. Salem、NH 03079 USA
EMail: woof@brooktrout.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用、またはそのような権利に基づくライセンスに基づくライセンスが利用可能である可能性がある範囲に関連すると主張される可能性のある他の権利の範囲に関してはありません。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.ietf.org/IPRでIETFオンラインIPRリポジトリから取得できます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。