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
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).
著作権（C）インターネット協会（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ベースのネットワークでは、基本的なネットワークメディアサービスを提供する必要があります。このようなサービスは、ネットワークの発表、ユーザーとの対話、および会議サービスが含まれます。これらのサービスは、1つの興味深いアプリケーションを構築することができ、そこから基本的なビルディングブロック、です。これらのビルディングブロックを提供するサーバ（また、メディアサーバーとして知られている）と、アプリケーション開発者の間での相互運用性を持つために、一つは明確に定義された方法で、このようなサービスを見つけて起動できるようにする必要があります。
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.
多機能メディアサーバは、多くの場合、VoiceXMLの[20]とMSCML [21]などのマークアップ言語と連携して、SIPなどのサーバ・プロトコルを使用してクライアントにネットワークメディアサービスを提供しています。この文書では、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]のキーワード "MUST" についての解釈、 "MUST NOT"、 "REQUIRED" は、、、、 "推奨"、 "すべきではない" "べきである" "ないもの" "ものとし"、 "MAY"、 「OPTIONAL」は、この文書で見つかりました。
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リクエストURIのユーザ部分の使用は、有用な特性の数を有します。
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コア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個のチャレンジを発行することができます。メディアサーバは、SIPをサポートする必要があります。発表サービスのスキームを。ダイアログのスキームと会議サービス：メディアサーバは、SIPをサポートしなければなりません。各サービスのために必要とされる認証のレベルは、ローカルポリシーの問題です。
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.
メディアサーバは、INVITEを受信すると、サービスインジケータを指摘しています。サービスインジケータによっては、メディアサーバは、いずれかの要求を尊重するか、失敗応答コードを返します。
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]あたり、サービスインジケータは大文字と小文字を区別しないです。サービス名はセットの英数字プラスダッシュ（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は、メディアサーバにINVITEを発行します。
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、NOT ACCEPTABLE HEREで応じなければなりません。 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.
一部のサービスでは、一意の識別子が必要です。ほとんどのサービスは自動的に与えられた識別子でINVITE最初の時にサービスインスタンスを作成します。サービスは、既存のサービスインスタンスを必要とし、そのようなサービスインスタンスがメディアサーバー上に存在しない場合は、メディアサーバーが見つかりません応答コード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.
コールセットアップ後に発表をプレイすることは簡単です。まず、要求側デバイスは、アナウンスサービスを要求するメディアサーバーにINVITEを発行します。メディアサーバは、SDPを交渉し、200 OKで応答します。要求側デバイスからのACKを受信した後、メディアサーバは、要求されたオブジェクトを果たし、要求側デバイスにBYEを発行します。
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".
メディアサーバーが「遊び=」パラメータなしで発表サービスのINVITEを受信した場合、それは応答コード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.
繰り返しは、メディアサーバーが「遊び=」パラメータで指定された発表やシーケンスを繰り返す必要がある回数を指定します。値は「永遠に」の繰り返しが効果的に無制限であるべきことを意味します。この場合には、そのようなサービス拒否攻撃を作成しない誤った顧客を確保するために、「永遠」の意味を限定するものとして、メディアサーバは、いくつかのローカルポリシーを実装して推奨されます。
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.
ロケールは「遊び=」パラメータで指定された発表系列の言語と、必要に応じて国バリアントを指定します。 RFC 3066 [9]ロケールタグを指定します。ロケールタグは、通常、ISO 639-1 [11]あたり2または3文字のコードです。国の変異体は、多くの場合、また、ISO 3166-1 [12]ごとに2文字のコードです。これらの要素は、「en_CA」として単一のバーの下（％x5F）文字と連結されています。言語だけが指定されている場合は、そのような= ENロケールとして、国変異体の選択は、実装の問題です。実装は、要求されたロケールとメディアサーバーが正確ロケール要求を尊重することはできませんイベントで使用可能な言語間の最良の一致を提供する必要があります。要求はロケール= 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.
「遊び=」パラメータが必須であり、存在しなければなりません。他のすべてのパラメータはオプションです。
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]注プロキシが不変を通してパラメータを渡すことになっていることを意味します。ただし、非準拠のプロキシがRequest-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の形態です。例では「遊び=」の前にバックスラッシュ、CRLF、および間隔は唯一の読みやすさの目的であることに注意してください。
sip:annc@ms2.example.net; \ play=http://audio.example.net/allcircuitsbusy.g711
SIP：annc@ms2.example.net。 \遊び=のhttp：//audio.example.net/allcircuitsbusy.g711
sip:annc@ms2.example.net; \ play=file://fileserver.example.net//geminii/yourHoroscope.wav
SIP：annc@ms2.example.net。 \遊び=ファイル：//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プロキシにINVITEを発行します。 SIPプロキシは、音声プロンプトが発信者に対して再生することを決定します。プロキシ100は、TRYINGと、発信者に応答します。
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.
プロキシは、劇=パラメータでコード化された再生するには、適切なプロンプトを要求し、メディアサーバにINVITEを発行します。メディアサーバは、200 OKで応答します。プロキシは、呼び出し元にOK 200を中継します。呼び出し側はその後、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.
コールが確立すると、メディアサーバは、要求されたプロンプトを再生します。メディアサーバは、プロンプトの再生を完了すると、プロキシにBYEを発行します。プロキシが呼び出し側にBYEを発行します。
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に記載されているように拡張バッカスナウア記法（BNF）を使用する[7]。
ANNC-URL = sip-ind annc-ind "@" hostport annc-parameters uri-parameters
ANNC-URL = SIP-IND ANNC-IND "@" のHostPort ANNCパラメータURIパラメータ
sip-ind = "sip:" / "sips:" annc-ind = "annc"
/ "一口："：= "一口" SIP-IND ANNC-IND = "ANNC"
annc-parameters = ";" play-param [ ";" content-param ] [ ";" delay-param] [ ";" duration-param ] [ ";" repeat-param ] [ ";" locale-param ] [ ";" variable-params ] [ ";" extension-params ]
ANNCパラメータ= ";"プレイのparam [ ";"コンテンツPARAM] [ ";"遅延PARAM] [ ";"期間-PARAM] [ ";"繰り返し-PARAM] [ ";"ロケールPARAM] [ ";"可変-paramsは] [ ";"延長-のparams]
play-param = "play=" prompt-url
遊ぶ-PARAM = "プレー=" プロンプト-URL
content-param = "content-type=" MIME-type
コンテンツのparam =「コンテンツタイプ=」MIMEタイプ
delay-param = "delay=" delay-value delay-value = 1*DIGIT
遅延PARAM =「遅延=」遅延値の遅延値= 1 * DIGIT
duration-param = "duration=" duration-value
期間-PARAM = "期間=" 期間値
duration-value = 1*DIGIT
デュレーション値= 1 * DIGIT
repeat-param = "repeat=" repeat-value
繰り返し-PARAM = "リピート=" リピート値
repeat-value = 1*DIGIT / "forever"
リピート値= 1 * DIGIT / "永遠"
locale-param = "locale=" token ; per RFC 3066, usually ; ISO639-1_ISO3166-1 ; e.g., en, en_US, en_UK, etc.
ロケールのparam =「ロケール=」トークン。 RFC 3066あたり、通常、 ISO639-1_ISO3166-1;例えば、EN、en_USの、en_UK、等
variable-params = param-name "=" variable-value
可変のparams =のparam-名 "=" 変数の値
param-name = "param" DIGIT ; e.g., "param1"
PARAM名=「ストップ」DIGIT。例えば、 "PARAM1"
variable-value = 1*(ALPHA / DIGIT)
変数値= 1 *（ALPHA / DIGIT）
extension-params = extension-param [ ";" extension-params ]
拡張-paramsは=伸びのparam [ ";"延長-のparams]
extension-param = token "=" token
延長-PARAM =トークン "=" トークン
"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パラメータ」RFC 3261に記載されているように、SIP要求URIパラメータリストである[10]。リクエスト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タイプは、ようにオーディオ/ベーシック、オーディオ/ G729、オーディオ/ MPEG、ビデオ/ MPEG、およびASアナウンスの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タイプのパラメータセパレータ（セミコロンは、％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
SIP：annc@ms.example.net。 \遊び=ファイル：//fs.example.net//clips/my-intro.dvi。 \コンテンツタイプ=ビデオ/ MPEG％3bencode％d3314M-25/625から50
The locale-value consists of a tag as specified in RFC 3066 [9].
[9] RFC 3066で指定されたロケール値はタグから成ります。
The definition of hostport is as specified by RFC 3261 [10].
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.
RFC 3986 [8]またはプロビジョニングアナウンス配列を示す特殊トークンによって指定されるようにプロンプト-URLの構文は、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、FTP O O NFS（RFC 2224 [14]）O（ローカルまたはNFS（RFC 3530 [16]）オブジェクトを参照）ファイル
If a provisioned announcement sequence is to be played, the value of prompt-url will have the following form:
プロビジョニング発表シーケンスを再生する場合は、プロンプト-URLの値は次の形式を持っています。
prompt-url = "/provisioned/" announcement-id
プロンプト-URL = "/プロビジョニング/" 発表-ID
announcement-id = 1*(ALPHA / DIGIT)
アナウンス-ID = 1 *（ALPHA / DIGIT）
Note that the scheme "/provisioned/" was chosen because of a hesitation to register a "provisioned:" URI scheme.
URIスキーム：スキーム「/プロビジョニング/」が原因で「プロビジョニング」を登録するにはためらいを選ばれたことに注意してください。
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.
ダイアログサービスは、告知サービスのモデルに従います。しかし、サービスインジケータは、「ダイアログ」です。ダイアログサービスが実行するのVoiceXMLスクリプトのURIを示す、=のVoiceXML、パラメータを取ります。
sip:dialog@mediaserver.example.net; \ voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml
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.
Media Serverは、追加のSIPリクエストURIパラメータを受け入れ、セッション変数としてのVoiceXMLインタプリタセッションにそれらを配信することができます。
Although not good VoiceXML programming practice, VoiceXML scripts might contain sensitive information, such as a user's pass code in a
良くないのVoiceXMLプログラミング手法が、VoiceXMLのスクリプトは、このようなユーザーのパスコードなどの機密情報を、含まれている場合があります
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.
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に記載されているように拡張バッカスナウア記法（BNF）を使用する[7]。
DIALOG-URL = sip-ind dialog-ind "@" hostport dialog-parameters
DIALOG-URL = SIP-INDダイアログ-IND "@" のHostPortダイアログパラメータ
sip-ind = "sip:" / "sips:" dialog-ind = "dialog"
/ "一口："：= "一口" SIP-INDダイアログ-IND = "ダイアログ"
dialog-parameters = ";" dialog-param [ vxml-parameters ] [ uri-parameters ]
ダイアログパラメータ=「;」ダイアログのparam [VXMLパラメータ] [URIパラメータ]
dialog-param = "voicexml=" vxml-url
ダイアログ-PARAM = "のVoiceXML =" VXML-URL
vxml-parameters = vxml-param [ vxml-parameters ]
VXMLパラメータ= VXML-PARAM [VXMLパラメータ]
vxml-param = ";" vxml-keyword "=" vxml-value
VXML-PARAM = ";" VXML-キーワード "=" VXML値
vxml-keyword = token
VXML-キーワード=トークン
vxml-value = token
VXML値=トークン
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-キーワードVXMLと値のペアを持つのVoiceXMLインタプリタセッションに渡されます。すべてVXML-キーワードが値を持たなければならないことに注意してください。
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値なしがある場合、メディアサーバ400 BAD要求応答コードで要求を拒絶しなければなりません。また、メディアサーバは、理由の句に「行方不明VXMLバリュー」を述べなければなりません。
The media server presents the parameters as environment variables in the connection object. Specifically, the parameter appears in the connection.sip tree.
メディアサーバは、接続オブジェクトでの環境変数などのパラメータを提示します。具体的には、パラメータがconnection.sipツリーに表示されます。
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はVoiceXMLのインタプリタセッションにキーワードと値のペアの受け渡しをサポートしていない場合、それはパラメータを無視しなければなりません。
"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パラメータ」RFC 3261に記載されているように、SIP要求URIパラメータリストである[10]。パラメータリストのすべてのパラメータは、彼らは、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を介してセッションを混合する1つを識別する。混合セッションを作成するためには、セッションを表すリクエストURIにINVITEを送信します。 URIが既にメディアサーバー上に存在しないと、要求されたリソースが利用可能である場合、メディアサーバは、新たなミキシングセッションを作成します。セッションの既存のURIがある場合、メディアサーバは、既存のセッションに参加するための新たなセッションの要求としてそれを解釈します。会議のためのSIPリクエストURIの形式は次のとおりです。
sip:conf=uniqueIdentifier@mediaserver.example.net
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の左側は、実際に要求URIおよびToヘッダで要求のユーザ名です。 URIのホスト部分は、特定のメディアサーバーを識別する。 「CONF」ユーザー名が、これは混合のサービスの要求であるメディアサーバーに伝えます。 UNIQUEIDENTIFIERは、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.
「; isfocus」リクエストURI中のパラメータ会議の枠組みでの焦点として、メディアサーバがサポートしなければなりません。ただし、の存在または不在こと「; 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にそれらをINVITEingことにより、会議に追加の足を追加することができます。 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.
逆に、1は、対応するダイアログでBYEを発行して、脚を削除することができます。混合セッション、したがって会議固有のリクエストURIは、限り特定の要求URIに関連付けられた少なくとも1つのSIPダイアログが存在するようにアクティブのままです。
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が存在しない場合、ユーザーエージェントClinet（UAC）にCONF-id文字列を返すことができます。しかし、このような操作は、そのような権限や請求などの他の操作上の問題を有していてもよいです。このように、アプリケーション・サーバーまたはプロキシは、このような操作を行うには良い場所です。また、そのようなアクションは、会議フレームワークの用語で会議工場[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.
この図は、三者会議の確立を示しています。このセクションは参考情報です。これは、会議を確立するための唯一の方法です。この例では、単純なバックツーバックユーザエージェントを示しています。
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.
会議フレームワーク[22]はアプリケーションサーバの追加パラメータと動作を説明します。 「; isfocus」パラメータ、例えば、最初に含まれるアプリケーションサーバにP1からINVITE。 Application 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.
会議フレームワーク[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.
上記のコールフローは、一般的に求めるUACにアプリケーションサーバからの流れであろう任意の100件のTRYINGメッセージが表示されないことに注意してください。またそれは、アプリケーションサーバーまたはアプリケーションサーバーからMedia Serverに求めるUACからの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を送信することにより、またはApplication Serverの監督の下で、アプリケーションサーバは、BYEを発行することにより、いずれかのドロップアウトすることができます。いずれの場合も、アプリケーションサーバは、UACの代わりにBYEを発行するか、またはそれぞれの切断ケースに対応し、メディアサーバーに直接発行します。
It is left as a trivial exercise to the reader for how the Application Server can mute legs, create side conferences, and so forth.
これは、Application Serverがなど、足をミュート側の会議を作成し、することができます方法については、読者への些細な課題として残されています。
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.
Application Serverは、参加者（求めるUAC）のサーバーであることに注意してください。しかし、Application ServerはMedia Serverにサービスを混合するためのクライアントです。
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 4234 [7].
以下の構文仕様はRFC 4234に記載されているように拡張バッカスナウア記法（BNF）を使用する[7]。
CONF-URL = sip-ind conf-ind "=" instance-id "@" hostport [ uri-parameters ]
CONF-URL = SIP-IND CONF-IND "=" instance-idに "@" のHostPort [URIパラメータ]
sip-ind = "sip:" / "sips:"
SIP-indが= "SIP：" / "一口："
conf-ind = "conf"
CONF-IND = "CONF"
instance-id = token
インスタンスID =トークン
"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パラメータ」RFC 3261に記載されているように、SIP要求URIパラメータリストである[10]。パラメータリスト内のすべてのパラメータは、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は、SIPに次のパラメータを登録している/ RFC 3969の仕様に必要なポリシー以下、[19] URIパラメータレジストリをSIPS。
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.
リクエストURIに固定ユーザー・パーツを使用しての知恵についてかなりの議論がありました。最も一般的な反論は、ユーザーの一部が不透明とローカルの問題であるべきことです。他の異論は、固定ユーザ部分を使用してユーザのアドレス空間からそれらの指定されたユーザのアドレスを削除することです。
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]によって定義されたポストマスタのアドレスです。異論は特別な何かのためにポストマスタートークンを使用することによって、人は誰のためにそのトークンを削除するということです。このように、米国の郵便局長一般的には、例えば、メールアドレスPostmaster@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.
キーポイントは、1つの組織の名前空間とメディアサーバーで名前空間を混同することはできません。たとえば、私たちはネットワークが「アン・チャールズ」のためのサービスを提供していますケースを見てみましょう。彼女は名前「ANNC」を使用するのが好きので、彼女は「SIP：annc@example.net」を使用したいと思います。当社は一切絶対にNO NAMEの衝突があります。なぜこれがそうですか？ annc@example.netアンのための特定のデバイスで特定のユーザーに解決されます：SIPがためです。 annc@anns-phone.example.netにannc@example.net：例として、example.netのSIPプロキシサーバは、SIPを解決します。 annc@ms21.ap.example.net：逆に、1は、例えば、SIPメディアサーバーに直接メディアサービスANNCの要求を送ります。また、定義、アン・チャールズの要求、またはアナウンスサービス以外で、直接、メディアサーバーに送信されることはありません。それが本当でなかった場合eburgerは、ブルックトラウトドメインの予約ユーザーの一部であるとして、世界の中では携帯電話は、ユーザ部「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は、グローバルなインターネットへのメディアサーバーにアクセスできるように、ドメインのMedia Server固有のユーザー名のいずれかを保持したい場合は、SIPプロキシは、簡単に1がメディアサーバー固有のユーザー名を選択した不透明な任意の名前翻訳することができます。例えば、場合ドメインがSIPで、上記のアン・チャールズのためのサービスを提供することを希望：my-special-announcement-service@example.com：annc@example.comを、彼らは一口でアナウンスサービスを提供することができます。旧アドレス、SIP：annc@example.comは、ANNCが存在する実際のデバイスに解決されます。一例として、annc@mediaserver.example.com：後者は、メディアサーバアナウンスサーバのアドレスにSIPを解決します。この規則は、このサービスをプロビジョニングすることが容易になりことに注意してください。多機能メディアサーバに固定マッピングでは、間違って取得するためのより少ないプロビジョニングデータ要素があります。
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のは、特別なユーザ「root」を留保します。ちょうど約すべてのUnixマシンは、「固有のマシンは、」特定のインスタンスの完全修飾ドメイン名（FQDN）であるアドレス「root@a-specific-machine.example.com」を、持っているユーザーのルートを持っています機械の。 「ルート」ユーザーのために非常に明確に定義された意味があります。
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機械のすべてを使用することができるということです。例えば、異なる機能を持つメディアサーバーは、ユーザーとして自分の能力を登録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.
このドキュメントのいくつかの相互作用は、機密情報の転送につながります。また、相互作用の多くは、完全性保護を必要とします。スキーム：したがって、Media ServerはSIPを実装しなければなりません。また、アプリケーション開発者は、必要に応じて、そのユーザーのデータの整合性と機密性を確保するために、メディアサーバーによって提供されるセキュリティ・サービスを使用することをお勧めします。
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の結果コードで発生します。これは、初期のメディア発表サービスのために問題となることがあります。これは、初期のメディア発表サービスが廃止されました理由の一つです。
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のアンディ・スピッツァーは、ちょうど約すべての作業のが謝辞セクションに記載されているいくつかの人の多くのアプリケーション開発者、メディアサーバーのメーカー、およびサービス・プロバイダーと連携して、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.
私たちは、Dynamicsoftのジョナサン・ローゼンバーグとその励ましのためのConvediaのティム・Melanchukとしてだけでなく、彼らの建設的なコメントのためにケビン・サマーズとソナス・ネットワークのラビンドラKabreに感謝したいと思います。また、2002年にラスベガスの中間ワークグループ会合での議論は、リクエストURIの左手側を取り巻く問題をクリアするための非常に貴重でした。クリステルHolmbergのチューニングにマルチメディア発表サービスの言語を助けました。 RADVISIONからのoriTレヴィンは、ドキュメントの最新バージョンに近い読み取りを行いました。ルーセントからのピート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.
パスカルJaletは、理論的な基盤を提供し、デビッドリオは、会議識別子がリクエスト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の会議コントロール仕事との適合性を確保アラン・ジョンストンに特にお世話になっています。
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.
著者は、初期の実装の多くを行うためのウォルター・オコナーに特別な感謝をしたいと思います。
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]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[2]フリード、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：非ASCIIテキストのためのメッセージヘッダの拡張"、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]解放され、N.、Klensin、J.、およびJ.ポステル、 "多目的インターネットメール拡張（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]フリード、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[7]クロッカー、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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003月。
[14] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.
[14]キャラハン、B.、 "NFS URLスキーム"、RFC 2224、1997年10月。
[15] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[15] Klensin、J.、 "簡易メール転送プロトコル"、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.、キャラハン、B.、ロビンソン、D.、Thurlow、R.、Beame、C.、アイスラー、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]キャンベル、B.及びR.スパークス、RFC 3087、2001年4月 "SIP要求URIを使用して、サービス・コンテキストの制御"。
[18] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[18]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[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]カマリロ、G.、BCP 99、RFC 3969、2004年12月 "セッション開始プロトコル（SIP）のための番号機関（IANA）のURI（Uniform Resource Identifier）パラメータレジストリの割り当てインターネット"。
[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]バーネット、D.、ハント、A.、McGlashan、S.、ポーター、B.、ルーカス、B.、Ferrans、J.、Rehor、K.、カーター、J.、Danielsen、P.、およびS 。Tryphonas、 "音声拡張マークアップ言語（VoiceXMLの）バージョン2.0"、W3C REC REC-voicexml20-20040316、2004年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]ヴァン・ダイク、J.、バーガー、E.、エド。、およびA.スピッツァー、 "メディアサーバ制御マークアップ言語（MSCML）とプロトコル"、進歩、2004年12月に作業。
[22] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", Work in Progress, October 2004.
[22]ローゼンバーグ、J.、「セッション開始プロトコルとの会議のための枠組み」、進歩、2004年10月での作業。
Authors' Addresses
著者のアドレス
Eric Burger Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
エリックバーガーブルックトラウト・テクノロジー社18 Keewaydin博士セーラム、NH 03079 USA
EMail: eburger@brooktrout.com
メールアドレス：eburger@brooktrout.com
Jeff Van Dyke Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
ジェフ・ヴァン・ダイクブルックトラウト・テクノロジー社18 Keewaydin博士セーラム、NH 03079 USA
EMail: jvandyke@brooktrout.com
メールアドレス：jvandyke@brooktrout.com
Andy Spitzer Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
アンディスピッツァーブルックトラウト・テクノロジー社18 Keewaydin博士セーラム、NH 03079 USA
EMail: woof@brooktrout.com
メールアドレス：woof@brooktrout.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.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 Editor機能のための基金は現在、インターネット協会によって提供されます。