RFC4240 日本語訳
4240 Basic Network Media Services with SIP. E. Burger, Ed., J. VanDyke, A. Spitzer. December 2005. (Format: TXT=54976 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Burger, Ed.
Request for Comments: 4240 J. Van Dyke
Category: Informational A. Spitzer
Brooktrout Technology, Inc.
December 2005
エド、ワーキンググループE.バーガーをネットワークでつないでください。コメントのために以下を要求してください。 4240年のJ.ヴァンダイクカテゴリ: 情報のA.スピッツァーBrooktrout技術Inc.2005年12月
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).
Copyright(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つはそのブロックからおもしろいアプリケーションを構成できます)。 これらのブロック(また、メディアServersとして、知られている)とアプリケーション開発者を提供しながらサーバの間に相互運用性を持つために、人は、よく定義された方法でそのようなサービスを場所を見つけて、呼び出すことができる必要があります。
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.
このドキュメントは、Application ServersとメディアServersとの共同利用できるインタフェースを提供するためにメカニズムについて説明します。Application ServersはSIPを拠点とするネットワークへのアプリケーション・サービスを提供します。Serversは処理ブロックを基本的なメディアに提供します。
Burger, et al. Informational [Page 1] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[1ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
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
1. 概要…2 1.1. このドキュメントで中古のコンベンション…3 2. メカニズム…3 3. 発表サービス…5 3.1. 操作…8 3.2. ダイヤグラムについて議定書の中で述べてください…9 3.3. 正式な構文…9 4. サービスをうながして、集めてください…11 4.1. 迅速で料金先方払いのサービスのための正式な構文…12 5. コンファレンスサービス…13 5.1. ダイヤグラムについて議定書の中で述べてください…14 5.2. 正式な構文…16 6. IANA問題…17 7. ユーザ部分…17 8. セキュリティ問題…20 9. 貢献者…20 10. 承認…20 11. 参照…21 11.1. 標準の参照…21 11.2. 有益な参照…22
1. Overview
1. 概要
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を拠点とするマスメディア網、(RFC3261[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 Request URIのSIPプロトコル、意味、または定義を変更もしませんし、またしないことに注意するために、どんな制限も置いたのは、批判的に重要です、何らかの方法で、このコンベンションを実装しないデバイスで。
Burger, et al. Informational [Page 2] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[2ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
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.
メディア混合はRFC3550[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]が指定されたより複雑な相互作用であるかもしれません。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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.
キーワード“MUST"のための「必須NOT」という解釈が「必要だった」RFC2119[6]、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが中にこのドキュメントを設立するべきであるかをさせましょう。
2. Mechanism
2. メカニズム
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 Request 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 Onlyデバイスはそれを実装しなければなりません。Thisが記録する○は多機能のSIPによって制御されたメディアサーバに適用されるだけです。Thisが記録する○は非多機能のSIPによって制御されたメディアサーバに影響力を全く持っていません。○ 本書では説明されたメカニズムはメディアサーバ以外のSIPデバイスで影響力を全く絶対に持っていません。
Burger, et al. Informational [Page 3] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[3ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
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.
サービスのセットが小さく、よく定義されて、よく含まれていることに注意してください。 User Part(セクション7)が固定セットのユーザ宇宙名を使用することで問題に取り組むセクション。
For per-service security, the media server SHOULD use the security protocols described in RFC 3261 [10].
1サービスあたりのセキュリティのために、メディアサーバSHOULDはRFC3261[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の挑戦を発行するかもしれません。 メディアサーバSHOULDは一口をサポートします: 発表サービスを計画してください。 メディアサーバは一口をサポートしなければなりません: 対話と会議サービスを計画してください。 各サービスのために必要とする認証のレベルはローカルの方針の問題です。
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).
サービスインディケータはRFC3261[10]単位で大文字と小文字を区別しないです。 サービス名を、セット英数字から来ていて、突進されなければなりません(米国-ASCII%2C)。 サービス名は等号(米国-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.
あるサービスには、メディアサーバに関するユニークなサービスインスタンスとの協会があるかもしれません。例えば、与えられたメディアサーバは複数の、そして、別々の会議の話し合いを主催できます。 ユニークなサービスインスタンスを特定するために、ユニークな識別子はサービス名を変更します。
Burger, et al. Informational [Page 4] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[4ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
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の法的なユーザ部分を規則を満たさなければなりません。 米国-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.
メディアサーバが要求されたサービスを実行できませんし、サービスインディケータを認識もしないなら、それは応答コードで488NOT ACCEPTABLE HEREを反応させなければなりません。 488がURIのユーザ部分に関する問題を示すとき、これは適切です。 そのうえ、ある他のメディアサーバが要望に応じることができるかもしれないように606は適切ではありません。 RFC3261[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に作成します。 しかしながら、サービスが既存のサービスインスタンスを必要として、何かそのようなサービスインスタンスがメディアサーバに存在していないなら、メディアサーバは応答コードで404NOT FOUNDを反応させなければなりません。 サービス自体がメディアサーバに存在するとき、これは適切ですが、特定のサービスインスタンスは適切であるというわけではありません。 まるでユーザが家にいないようでした。
3. Announcement Service
3. 発表サービス
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対話を完全にセットアップするかどうかということです。 Public Switched Telephone Network(PSTN)のアナログは答え指揮を供給するかどうかという(すなわち、発表を提供する前に、発表サーバは電話口に出ますか?)ことです。
Burger, et al. Informational [Page 5] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[5ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
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を交渉して、200OKで反応します。 要求デバイスから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応答コードで応じなければなりません、そして、SHOULDは「内容が見つけなかった発表」を理由句に送ります。
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で応じなければなりません、そして、SHOULDは「義務的なプレーパラメタの取り逃がすこと」を理由句に送ります。
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応答コードで反応しなければなりません、そして、SHOULDは「発表内容を検索できなかったこと」を理由句に送ります。 さらに、メディアサーバSHOULDは失敗したことがわかる適切な説明しているテキストでのWarningヘッダーを含んでいます。
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.
Request URIはアドレスと追加URIパラメタのユーザ部分の使用で発表サービスについて完全に説明します。 アドレスのユーザ部分"annc"はメディアサーバで発表サービスを指定します。サービスには、発表の内容と配送を制御するいくつかの関連URIパラメタがあります。
These parameters are described below:
これらのパラメタは以下で説明されます:
play
Specifies the resource or announcement sequence to be played.
リソースか発表がプレーされるために配列するSpecifiesと対戦してください。
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.
メディアサーバが何回、発表を繰り返すべきであるか、そして、系列が「プレー=」パラメタで命名したSpecifiesを繰り返してください。 値は、「いつまでも、」事実上、反復が限りないはずであることを意味します。 この場合、それはメディアサーバがいくつかのローカルの政策を実施するRECOMMENDEDです、「いつまでも」誤ったクライアントを確実にするために、サービス不能攻撃を作成しないように意味することを制限するのなどように。
delay
Specifies a delay interval between announcement repetitions. The
delay is measured in milliseconds.
発表反復のSpecifies a遅れ間隔を遅らせてください。 遅れはミリセカンドで測定されます。
duration
Specifies the maximum duration of the announcement. The media
server will discontinue the announcement and end the call if the
持続時間Specifies、発表の最大の持続時間。 メディアサーバは、発表を中止して、呼び出しを終わらせるでしょう。
Burger, et al. Informational [Page 6] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[6ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
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.
そして、現場Specifies、言語、任意に、発表系列の国の異形は「プレー=」でパラメタを命名しました。 RFC3066[9]は現場タグを指定します。 通常、ISO639-1[11]あたり、現場タグは、2か3レター・コードです。 しばしばもISO3166-1[12]あたり国の異形は2レター・コードです。 これらの要素は「アン_カリフォルニア」などのバー(%x5F)キャラクタの下におけるシングルで連結されます。 言語だけが現場=アンなどのように指定されるなら、国の異形の選択は実装問題です。 実装SHOULDは正確に要求された現場の間の可能なマッチを最も良く提供して、イベントにおけるメディアサーバが光栄に思うことができない利用可能な言語に現場要求を提供します。 例えば、要求が現場がca_FRとの等しさにしますが、メディアサーバに利用可能なfr_FRがあるだけであるなら、メディアサーバはfr_FR異形を使用するべきです。 どんな言語異形も利用可能でないなら、実装SHOULDは使用するデフォルト現場を提供します。
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つのパラメタ(「param9=」を通した「param1=」)が指定されるかもしれません。 発表系列の整備士はこのドキュメントの範囲を超えています。
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.
パラメタを広げるためのメカニズムが設定する拡大Provides。 メディアサーバが拡大を受けるなら、分からないで、静かに拡大パラメタと値を無視しなければなりません。
The "play=" parameter is mandatory and MUST be present. All other parameters are OPTIONAL.
「プレー=」パラメタは、義務的であり、存在していなければなりません。 他のすべてのパラメタがOPTIONALです。
NOTE: Some encodings are not self-describing. Thus, the implementation relies on filename extension conventions for determining the media type.
以下に注意してください。 いくつかのencodingsは自己に説明していません。 したがって、実装は、メディアがタイプされることを決定するためにファイル名拡大コンベンションを当てにします。
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.
プロキシが変わりのないことでRFC3261[10]がパラメタを通過するつもりであるべきであることに注意してください。 しかしながら、非従っているプロキシがRequest-URIパラメタを剥取るかもしれないのを意識してください。 本書では提示されたメカニズムのためのありそうなシナリオを考えて、それは言って、これは問題であるべきではありません。 たぶん、パラメタを挿入するプロキシはメディアサーバの前の最後のプロキシです。サービスプロバイダーがロードバランシングかサービス位置の目的のためにプロキシを配布するなら、サービスプロバイダーは、プロキシの選択がパラメタを保存するのを確実にするべきです。
Burger, et al. Informational [Page 7] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[7ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
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 Request URIのフォームは以下の通りです。 例の「プレー=」の前のバックスラッシュ、CRLF、およびスペースが読み易さ目的だけのためのものである注意。
sip:annc@ms2.example.net; \
play=http://audio.example.net/allcircuitsbusy.g711
一口: annc@ms2.example.net; \プレー= http://audio.example.net/allcircuitsbusy.g711
sip:annc@ms2.example.net; \
play=file://fileserver.example.net//geminii/yourHoroscope.wav
一口: annc@ms2.example.net; \プレー=ファイル://fileserver.example.net//geminii/yourHoroscope.wav
3.1. Operation
3.1. 操作
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 Proxy、アプリケーション・サーバー、またはメディアゲートウェイコントローラがあると仮定します。しかしながら、発表サービスは訪問者が直接サービスを呼び出しても以下で説明されるように働いています。 それが最も一般的なケースになるように私たちは、プロキシ事件について議論するのを選びました。
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 ProxyにINVITEを発行します。 SIP Proxyは、どんなオーディオプロンプトを訪問者にプレーしたらよいかを決定します。 プロキシは100TRYINGと共に訪問者に応じます。
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を発行します。 メディアサーバは200OKで反応します。 プロキシは200OKを訪問者にリレーします。 そして、訪問者は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を発行します。
Burger, et al. Informational [Page 8] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[8ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
3.2. Protocol Diagram
3.2. プロトコルダイヤグラム
Caller Proxy Media Server
| INVITE | |
|----------------------->| INVITE |
| 100 TRYING |----------------------->|
|<-----------------------| 200 OK |
| 200 OK |<-----------------------|
|<-----------------------| |
| ACK | |
|----------------------->| ACK |
| |----------------------->|
| | |
| Play Announcement (RTP) |
|<================================================|
| | |
| | BYE |
| BYE |<-----------------------|
|<-----------------------| |
| 200 OK | |
|----------------------->| 200 OK |
| |----------------------->|
| | |
訪問者プロキシメディアサーバ| 招待| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 招待| | 100 トライ|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 200 OK| | 200 OK| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| ACK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| ACK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 発表(RTP)をプレーしてください。| |<========================| | | | | | さようなら| | さようなら| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 200 OK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 200 OK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|
3.3. Formal Syntax
3.3. 正式な構文
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 4234 [7].
以下の構文仕様はRFC4234[7]で説明されるように増大しているBN記法(BNF)を使用します。
ANNC-URL = sip-ind annc-ind "@" hostport
annc-parameters uri-parameters
ANNC-URL=一口ind annc-ind"@"hostport annc-パラメタuri-パラメタ
sip-ind = "sip:" / "sips:" annc-ind = "annc"
一口ind=は「以下をちびちび飲みます」。 /は「以下をちびちび飲みます」。 annc-indは"annc"と等しいです。
annc-parameters = ";" play-param [ ";" content-param ]
[ ";" delay-param]
[ ";" duration-param ]
[ ";" repeat-param ]
[ ";" locale-param ]
[ ";" variable-params ]
[ ";" extension-params ]
「annc-パラメタ=」;、」 play-param [ ";" content-param ] [ ";" delay-param] [ ";" duration-param ] [ ";" repeat-param ] [ ";" locale-param ] [ ";" variable-params ] [「」、;、拡大-params]
play-param = "play=" prompt-url
プレー-paramは「プレー=」迅速なurlと等しいです。
content-param = "content-type=" MIME-type
内容-paramは「content type=」MIMEの種類と等しいです。
delay-param = "delay=" delay-value
遅れ-paramは「遅れ=」遅れ価値と等しいです。
Burger, et al. Informational [Page 9] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[9ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
delay-value = 1*DIGIT
遅れ値は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。 例えば、アン、アン_米国、アン_イギリスなど
variable-params = param-name "=" variable-value
可変paramsの=param-名前「=」可変値
param-name = "param" DIGIT ; e.g., "param1"
param-名前は"param"DIGITと等しいです。 例えば、"param1""
variable-value = 1*(ALPHA / DIGIT)
可変値の=1*(アルファー/ケタ)
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-パラメタ」はRFC3261[10]で説明されるようにSIP Request-URIパラメータ・リストです。 Request 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の種類は、発表のためのMIME[1][2][3][4][5]content type、オーディオ的か基本的であるとしてのそのようなもの、オーディオ/G729、オーディオ/mpeg、ビデオ/mpegなどです。
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
一口: annc@ms.example.net; \プレーがファイル://fs.example.net//クリップ/と等しい、私、-イントロはdviされます。 \content type=ビデオ/mpeg%3bencode%d3314M-25/625-50
The locale-value consists of a tag as specified in RFC 3066 [9].
現場値はRFC3066[9]の指定されるとしてのタグから成ります。
The definition of hostport is as specified by RFC 3261 [10].
hostportの定義がRFC3261[10]によって指定されるようにあります。
Burger, et al. Informational [Page 10] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[10ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
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.
迅速なurlの構文は指定されるとしてのRFC3986[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(RFC3530[16])オブジェクト)o nfs(RFC2224[14])
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は"/provisioned/"発表イドと等しいです。
announcement-id = 1*(ALPHA / DIGIT)
発表イド=1*(アルファー/ケタ)
Note that the scheme "/provisioned/" was chosen because of a hesitation to register a "provisioned:" URI scheme.
体系"/provisioned/"がためらいのために選ばれたことに注意して、aを登録してください、「食糧を供給される:、」 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リストを含んでいて。 詳しい情報については、この話題に関してPromptとCollect Service(セクション4)部を見てください。
4. Prompt and Collect Service
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
一口: 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.
メディア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スクリプトはaのユーザのパスコードなどの機密情報を含むかもしれません。
Burger, et al. Informational [Page 11] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[11ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
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が結果の任命であるとサポートしなければなりません。
4.1. Formal Syntax for Prompt and Collect Service
4.1. 迅速で料金先方払いのサービスのための正式な構文
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 4234 [7].
以下の構文仕様はRFC4234[7]で説明されるように増大しているBN記法(BNF)を使用します。
DIALOG-URL = sip-ind dialog-ind "@" hostport
dialog-parameters
DIALOG-URL=一口ind対話-ind"@"hostport対話パラメタ
sip-ind = "sip:" / "sips:" dialog-ind = "dialog"
一口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-キーワードとのVoiceXMLインタプリタセッションまで通過されるなら、vxml-値は対にされます。 すべての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-値なしであれば、メディアサーバは400BAD REQUEST応答コードで要求を拒絶しなければなりません。 さらに、メディアサーバは理由句に「なくなった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木に現れます。
Burger, et al. Informational [Page 12] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[12ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
If the Media Server does not support the passing of keyword-value pairs to the VoiceXML interpreter session, it MUST ignore the parameters.
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-パラメタ」はRFC3261[10]で説明されるようにSIP Request-URIパラメータ・リストです。 それらがuri-パラメタかvxml-keyworksから来るか否かに関係なく、パラメータ・リストのすべてのパラメタがURIの合っているアルゴリズムの一部です。
5. Conference Service
5. コンファレンスサービス
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:
1つはそれらのSIP要求URIを通した混合セッションを特定します。 混合セッションを作成するために、1つはセッションを表す要求URIにINVITEを送ります。 URIがメディアサーバに既に存在していなくて、要求されたリソースが利用可能であるなら、メディアサーバは新しい混合セッションを作成します。 既存のURIがセッションの間、あれば、メディアサーバは新しいセッションが既存のセッションに参加するという要求としてそれを解釈します。 会議のためのSIP要求URIのフォームは以下の通りです。
sip:conf=uniqueIdentifier@mediaserver.example.net
一口: 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コンベンションは、アプリケーション・サーバーが、Focusとして機能するようそれに要求しているとメディアサーバに言います。 conf-イド値は特定の焦点インスタンスを特定します。
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.
「会議フレームワークにおけるa焦点として、メディアサーバがサポートしなければならない、」 ; 」 Request 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.
アプリケーションとメディアサーバの間で共有された会議URIが警備の強化を提供することに注意する価値があります、SIPコントロールインタフェースが関係者に暴露される必要はないとき。 また、それで、特定のメディアサーバの課題はできるだけ長い間、遅れます、その結果、資源管理を簡素化します。
Burger, et al. Informational [Page 13] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[13ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
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.
人は追加脚をINVITEingによる会議に追加できます。上記の要求URIへのそれら。 RFC3261[10]の合っている規則あたり、conf-イドパラメタは合っているストリングの一部です。
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に関連している少なくとも1つのSIP対話がある限り、混合セッション、およびその結果会議特有の要求URIはアクティブなままで残っています。
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.
分けますが、ユーザがconf-イドパラメタを持っていないときRequest-URIに"conf"があるなら、メディアサーバは404NOT FOUNDと共に反応しなければなりません。
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-イドもなければ、メディアサーバは、UserエージェントClinet(UAC)にユニークな会議インスタンスを作成して、conf-イドストリングを返すかもしれません。 しかしながら、そのような操作には、許容や支払いなどの他の操作上の問題があるかもしれません。 したがって、アプリケーション・サーバーかプロキシがそのような操作をするのにおいて、よりふさわしい場所です。 そのうえ、そのような動作は会議フレームワーク[22]の用語でコンファレンスFactoryにメディアサーバを作りかえるでしょう。 それはメディアサーバのための適切な行動ではありません。
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:.
ビジネス会議などのケースに、何らかの会議使用以来、支払い意味があって、メディアサーバSHOULDはアプリケーション・サーバーかプロキシを認証します。 最小限、サーバが実装しなければならないメディアでは、ちびちび飲みます:。
5.1. Protocol Diagram
5.1. プロトコルダイヤグラム
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.
このダイヤグラムは3者間の会議の設立を示しています。 このセクションは有益です。 それは会議を設立する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.
会議フレームワーク[22]はApplication Serverの追加パラメタと振舞いについて説明します。「例えば、最初のP1からApplication ServerまでのINVITEが含んでいるだろう、」 ; 」 パラメタをisfocusします。 Application ServerはコンファレンスFactoryとして機能するでしょう。 など。 しかしながら、そのプロトコル機械のいずれもメディアServerインタフェースへのApplication Serverの操作に影響を与えません。(Application Serverはこのプロトコルドキュメントの焦点です)。
Burger, et al. Informational [Page 14] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[14ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
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 |
|<=====================================================>|
P1 P2 P3アプリケーション・サーバーメディアサーバ| | | | | | INVITE一口: public-conf@as.example.net | |---------------------------------->| | | | | INVITE一口: confは 123@ms.example.net と等しいです。| | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 200 OK| | 200 OK| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |<----------------------------------| | | ACK| | | | |---------------------------------->| ACK| | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| P1とRTP| | |<===========================>|、|、|、|、|、|、| INVITE一口: public-conf@as.example.net | | |-------------------------->| | | | | INVITE一口: confは 123@ms.example.net と等しいです。| | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 200 OK| | | 200 OK| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| ACK| | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| ACK| | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、|、|、| P1+P2-P2とRTP| | | |<=======================>|、|、|、| P1+P2-P1とRTP| | |<===========================>|、|、|、|、|、|、| INVITE一口: public-conf@as.example.net | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| INVITE一口: confは 123@ms.example.net と等しいです。| | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 200 OK| | | | 200 OK| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| ACK| | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| ACK| | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、|、|、| P1+P2+P3-P3とRTP| | | |<==================>|、|、|、| P1+P2+P3-P2とRTP| | |<=======================>|、|、|、| P1+P2+P3-P1とRTP| |<===========================>|
Burger, et al. Informational [Page 15] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[15ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
| | | | |
| | | | |
| | | | | | | | | |
Using the terminology of conference-framework [22], the Application Server is the Conference Factory, and the Media Server is the Conference Focus.
会議フレームワーク[22]の用語を使用して、Application ServerはコンファレンスFactoryです、そして、メディアServerはコンファレンスFocusです。
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.
上の呼び出し流動が通常Application ServerからUACsまで流れるどんな100のTRYINGメッセージも示さないことに注意してください。 また、それはUACsからApplication ServerまでApplication ServerからメディアServerまでACKsを見せません。
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.
各脚はBYEを送るUACによるUACの監督下かApplication Serverの監督下で落ちることができます、BYEを発行するApplication Server。 どちらの場合ではも、Application ServerはUACを代表してBYEを発行するか、または直接Serverの、そして、それぞれの分離ケースに対応するメディアにそれを発行するでしょう。
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が関係者(UACs)へのサーバであることに注意してください。 しかしながら、Application ServerはメディアServerに対する混合サービスのためのクライアントです。
5.2. Formal Syntax
5.2. 正式な構文
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 4234 [7].
以下の構文仕様はRFC4234[7]で説明されるように増大しているBN記法(BNF)を使用します。
CONF-URL = sip-ind conf-ind "=" instance-id "@" hostport
[ uri-parameters ]
CONF-URL=一口ind conf-indはインスタンスイド"@"hostportと「等しいです」。[uri-パラメタ]
sip-ind = "sip:" / "sips:"
一口ind=は「以下をちびちび飲みます」。 /は「以下をちびちび飲みます」。
conf-ind = "conf"
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-パラメタ」はRFC3261[10]で説明されるようにSIP Request-URIパラメータ・リストです。 パラメータ・リストのすべてのパラメタがURIの合っているアルゴリズムの一部です。
Burger, et al. Informational [Page 16] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[16ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
6. IANA Considerations
6. IANA問題
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/SIPS URI Parameters登録に以下のパラメタを示しました、RFC3969[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
事前に定義されたパラメタ名は参照を評価します。-------------- ----------------- --------- プレーノーRFC4240、は拡大のparam[n]の現場の持続時間のいいえRFC4240、遅れノーRFC4240ノーRFC4240ノーRFC4240ノーRFC4240ノーRFC4240、を繰り返します。
7. The User Part
7. ユーザ部分
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.
私たちは最初に、後者の問題を扱います。 一般的な例はRFC2821[15]によって定義されたPostmasterアドレスです。 異論は何か特別なものにPostmasterトークンを使用することによって、1つがそのトークンをだれにも移すということです。 したがって、例えば、合衆国郵政長官は郵便の宛先 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ユーザエージェントで説明されたユーザ名の1つを使用したいと思うなら、何も中断していません、そして、彼らのユーザエージェントは予想されるように働くでしょう。
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
要所があって、1つは組織のためにメディアServerの名前空間を名前空間に間違えることができません。 例えば、ネットワークが「アン・チャールズ」のためにサービスを提供するケースを取りましょう。 彼女は、"annc"という名前を使用するのが好きです、そして、その結果、「一口: annc@example.net 」を使用したがっています。 そこでの申し出はABSOLUTELY NO NAME COLLISION WHATSOEVERです。私たち、これはなぜそうですか? 一口: annc@example.net が特有にユーザを決議するので、これは詳細でそうです。
Burger, et al. Informational [Page 17] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[17ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
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.
アンのためのデバイス。 例として、example.netのSIP Proxyサーバは一口を決議します: annc@anns-phone.example.net への annc@example.net 。 逆に、人は直接メディアServerへのメディアサービスannc、例えば、一口を求める要求を指示します: annc@ms21.ap.example.net 。 そのうえ、定義上、直接アン・チャールズを求める要求、または発表サービス以外の何かをメディアServerに決して送らないでしょう。それが本当でないなら、世界でどんな電話もユーザ部分"eburger"を使用できないでしょうに、eburgerがBrooktroutドメインの予約されたユーザ部分であるので。 明確に、これはそうではありません。
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.
人がそれらのメディアサーバを世界的なインターネットにアクセスしやすくしますが、Server特有のユーザがそのドメインで命名するメディアの1つを保有したいなら、SIP Proxyは容易にServerメディアに特有のユーザ名を選ぶどんな不明瞭な名前1も翻訳できます。 例えば、ドメインが一口: annc@example.com の上記のアン・チャールズのためにサービスを提供したいなら、一口で発表サービスを提供できます: my-special-announcement-service@example.com 。 前のアドレス一口: ( annc@example.com )は、どこanncが住んでいるかと実際のデバイスに決議するでしょう。 後者は、メディアサーバ発表サーバアドレスまで、ちびちび飲んでください: 例としての 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 "を持っています)。そこでは、「特定のマシン」がマシンの特定のインスタンスに関する完全修飾ドメイン名(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"、および「対話」は皆メディアServerのユーザです、ちょうど「根」、「容器」、および「一人も」ユーザが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仕事グループからの入力で、私たちは、prependingすることによってユーザ名を困惑させると考えた」__一口、-、」 ユーザ名に。 しかしながら、上で説明されるように、この困惑は必要ではありません。 基本的な違いがMX記録(SMTP)か記録のAddress(SIP)にデバイスのユーザ名とユーザ名の間にあります。 一方、デバイスの上の名前がSIPルーティングネットワークに「漏れるかもしれない」可能性が全くありません。
Burger, et al. Informational [Page 18] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[18ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
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の左側がネットワークに不明瞭であるということです。 コンベンションに関して知る必要がある唯一のネットワーク要素が、メディアServerとクライアントです。 公示サービスにおける、上記の例のようにマッピング解決をしているプロキシさえコンベンションを意識している必要はありません。 コンベンションは純粋に食糧を供給することの問題です。
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 RFC3087[17]の論文はあなたが要求URIを使用することでサービスを扱うことができるということです。 しかしながら、或るものはドキュメントの例を極端に取りました。 すなわち、唯一の道にアドレスサービスへのそれは任意の、そして、不透明で、長いユーザ部分でいます。 明確に、それは名前を修理するよりむしろサービスが命名する支給に可能です。 Application ServersとメディアServersが同じ管理ドメインにある閉じているネットワークで働くことができる間、これはドメインの向こう側に働いていません、インターネットなどのように。 これはメディアサービスのクライアントがそれぞれのサービス/ドメイン組で地方名を知らなければならないからです。 状況には、これはアプリケーションとメディアサービスとの臨時の関係があるところで特に煩わしいです。 サービスとサービスアドレスとのよく知られる関係がなければ、クライアントはサービスのどのように場所を見つけますか?
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機械のすべてを使用できるということです、変更なしで。 例えば、メディアServers、ユーザとしての異なった能力缶のSIP Registerによる彼らの能力。 例えば、VoiceXMLだけデバイスは「対話」ユーザを登録するでしょう、多目的のメディアServerはユーザのすべてを登録するでしょうが。 これがプレーするURIがパラメタである理由であることに注意してください。 別の方法でするのは普通のSIPプロキシか再直接のサーバに負担をかけるでしょう。逆に、会議IDがユーザ部分の一部であることを持っているのが要求が同様(ルーティングを同じデバイスに制限するだろうGlobally Routable Userエージェント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メディアServersがanncユーザのためにSIPの再直接のサーバとともに記名することができます。 メディアServersの1つが失敗すると、登録は期限が切れるでしょう、そして、発表サービス(「anncユーザに呼びかける」)を求めるすべての要求を生き残っているメディアServerに送るでしょう。
Burger, et al. Informational [Page 19] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[19ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
8. Security Considerations
8. セキュリティ問題
Exposing network services with well-known addresses may not be desirable. The Media Server SHOULD authenticate and authorize requesting endpoints per local policy.
よく知られるアドレスでネットワーク・サービスを暴露するのは望ましくないかもしれません。 Server SHOULDがローカルの方針あたりの終点に要求するのを認証して、認可するメディア。
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.
いくつかの相互作用が本書では秘密情報の転送をもたらします。 そのうえ、相互作用の多くが保全保護を必要とします。 その結果、Serverが一口を実装しなければならないメディア: 計画してください。 さらに、アプリケーション開発者は確実にするサービスがメディアでServerを彼らのユーザのデータの保全と秘密性を申し出であったセキュリティを使用するRECOMMENDEDです、適宜。
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.
いつまでも発表を反復などなどのサービスはサービス不能攻撃のための可能性を作成します。 メディアサーバSHOULDには、「いつまでも」、複数の要求が来るところで分析して、そのようなサービスなどのためのホワイトリストを実装するのが長い間どうあるかは時間制限などのこれを取扱うローカルの方針があります。
9. Contributors
9. 貢献者
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のすべてをしました、多くのアプリケーション開発者、メディアサーバメーカー、およびサービスプロバイダーに関連して。その或るものはAcknowledgements部で記載されています。 私がしたのは、理論をして、それを詳しく書くことです。 また、それは、誤りのすべてがまた、私のものであることを意味します。
10. Acknowledgements
10. 承認
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のケビン・サマーズとラビンドラKabreに感謝申し上げます、Dynamicsoftのジョナサン・ローゼンバーグと彼らの奨励のためのConvediaのティムMelanchukと同様に。 さらに、要求URIの左側を囲む問題を解決するには、2002年のラスベガスInterim Workgroup Meetingでの議論は非常に貴重でした。 Christer Holmbergは、マルチメディア発表サービスの言語を調整するのを助けました。 RadvisionからのOritレヴィンはドキュメントの最新のバージョンで読まれた閉鎖を与えました。 LucentからのピートDanielsenは一貫してこのドキュメントの多くの異なった見解の優れた論評を提供しました。
Burger, et al. Informational [Page 20] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[20ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
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.
私は、特に彼のこのドキュメントのレビューにアラン・ジョンストンの世話になってSIP会議コントロール仕事がIETFにある状態で、順応を保証します。
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.
この書くこと時点で、7つの23の知られているクライアント実装で共同利用できる知られている独立しているサーバ実装があることに注意してください。 私たちの謝罪は私たちであるならあなたの実装を数えませんでした。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、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を分けます」。 「メディアタイプ」、RFC2046、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.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、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を分けます」。 「登録手順」、BCP13、RFC2048、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を分けます」。 「順応評価基準と例」、RFC2049、11月1996日
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[7] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
Burger, et al. Informational [Page 21] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[21ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
[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、「Uniform Resource Identifier(URI):」 「一般的な構文」、STD66、RFC3986、2005年1月。
[9] Alvestrand, H., "Tags for the Identification of Languages",
BCP 47, RFC 3066, January 2001.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[9]、BCP47、RFC3066、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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 Standard639-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 Standard3166-1、1997年10月。
11.2. Informative References
11.2. 有益な参照
[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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[14] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.
[14] キャラハン、B.、「NFS URL計画」、RFC2224、1997年10月。
[15] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[15]Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、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.、サーロウ、R.、Beame、C.、アイスラー、M.、およびD.Noveck)は「File System(NFS)バージョン4プロトコルをネットワークでつなぎます」、RFC3530、2003年4月。
[17] Campbell, B. and R. Sparks, "Control of Service Context using
SIP Request-URI", RFC 3087, April 2001.
[17] キャンベルとB.とR.スパークス、「一口要求URIを使用するサービス文脈のコントロール」、RFC3087、2001年4月。
[18] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[18] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、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] キャマリロ、G.、「セッション開始プロトコル(一口)のためのISOCの機関の一つで(IANA)Uniform Resource Identifier(URI)パラメタ登録」、BCP99、RFC3969(2004年12月)。
Burger, et al. Informational [Page 22] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[22ページ]のRFC4240はサービス2005年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]バーネット、D.、狩り、A.、マックグラシャン、S.、ポーター、B.、ルーカス、B.、Ferrans、J.、Rehor、K.、カーター、J.、Danielsen、P.、およびS.Tryphonas、「拡張マークアップ言語(VoiceXML)バージョン2インチを声に出してください、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
エリックバーガーBrooktrout技術Inc.18Keewaydin礼拝堂ニューハンプシャー03079博士(米国)
EMail: eburger@brooktrout.com
メール: eburger@brooktrout.com
Jeff Van Dyke Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
ジェフヴァンダイクBrooktrout技術Inc.18Keewaydin礼拝堂ニューハンプシャー03079博士(米国)
EMail: jvandyke@brooktrout.com
メール: jvandyke@brooktrout.com
Andy Spitzer Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
アンディスピッツァーBrooktrout技術Inc.18Keewaydin礼拝堂ニューハンプシャー03079博士(米国)
EMail: woof@brooktrout.com
メール: woof@brooktrout.com
Burger, et al. Informational [Page 23] RFC 4240 SIP Media Services December 2005
バーガー、他 情報[23ページ]のRFC4240はサービス2005年12月にメディアをちびちび飲みます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Burger, et al. Informational [Page 24]
バーガー、他 情報[24ページ]
一覧
スポンサーリンク
