[要約] RFC 3312は、SIP (Session Initiation Protocol) において、メディアセッションの開始前にネットワークリソースの予約（QoS）が完了していることを保証するためのフレームワークを定義しています。SDP（セッション記述プロトコル）を拡張し、リソース予約の状態（Preconditions）をシグナリングに含め、予約が成功するまで通話の呼び出しを待機させる手順を規定しています。ネットワークのリソース不足による通話の中断を防ぎ、確実にQoSが保証された状態でのみサービスを開始できるようにすることを目的としています。
Network Working Group G. Camarillo, Ed.
Request for Comments: 3312 Ericsson
Category: Standards Track W. Marshall, Ed.
AT&T
J. Rosenberg
dynamicsoft
October 2002
Integration of Resource Management and Session Initiation Protocol (SIP)
Session Initiation Protocol (SIP) におけるリソース予約の統合
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本書は、インターネットコミュニティ向けのインターネット標準化過程のプロトコルを規定し、改善に向けた議論や提案を求めています。このプロトコルの標準化段階と状態については、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。本書の配布に制限はありません。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
概要
This document defines a generic framework for preconditions, which are extensible through IANA registration. This document also discusses how network quality of service can be made a precondition for establishment of sessions initiated by the Session Initiation Protocol (SIP). These preconditions require that the participant reserve network resources before continuing with the session. We do not define new quality of service reservation mechanisms; these preconditions simply require a participant to use existing resource reservation mechanisms before beginning the session.
本書は、IANA登録によって拡張できる、前提条件の汎用フレームワークを定義します。また、Session Initiation Protocol（SIP）が開始するセッションの確立において、ネットワークのサービス品質（QoS）を前提条件として扱う方法を説明します。これらの前提条件では、セッションを続ける前に参加者がネットワークリソースを確保する必要があります。本書では新たなQoS予約機構を定義せず、セッション開始前に既存のリソース予約機構を使うことを前提条件として求めます。
Table of Contents
目次
1 Introduction ................................................... 2
2 Terminology .................................................... 3
3 Overview ....................................................... 3
4 SDP parameters ................................................. 4
5 Usage of preconditions with offer/answer ....................... 7
5.1 Generating an offer .......................................... 8
5.1.1 SDP encoding ............................................... 9
5.2 Generating an Answer ......................................... 10
6 Suspending and Resuming Session Establishment .................. 11
7 Status Confirmation ............................................ 12
8 Refusing an offer .............................................. 13
8.1 Rejecting a Media Stream ..................................... 14
9 Unknown Precondition Type ...................................... 15
10 Multiple Preconditions per Media Stream ....................... 15
11 Option Tag for Preconditions .................................. 16
12 Indicating Capabilities ....................................... 16
13 Examples ...................................................... 16
13.1 End-to-end Status Type ...................................... 17
13.2 Segmented Status Type ....................................... 21
13.3 Offer in a SIP response ..................................... 23
14 Security Considerations ....................................... 26
15 IANA Considerations ........................................... 26
16 Notice Regarding Intellectual Property Rights ................. 27
17 References .................................................... 27
18 Contributors .................................................. 28
19 Acknowledgments ............................................... 28
20 Authors' Addresses ............................................ 29
21 Full Copyright Statement ...................................... 30
Some architectures require that at session establishment time, once the callee has been alerted, the chances of a session establishment failure are minimum. One source of failure is the inability to reserve network resources for a session. In order to minimize "ghost rings", it is necessary to reserve network resources for the session before the callee is alerted. However, the reservation of network resources frequently requires learning the IP address, port, and session parameters from the callee. This information is obtained as a result of the initial offer/answer exchange carried in SIP. This exchange normally causes the "phone to ring", thus introducing a chicken-and-egg problem: resources cannot be reserved without performing an initial offer/answer exchange, and the initial offer/answer exchange can't be done without performing resource reservation.
一部のアーキテクチャでは、着信側に着信を通知した後にセッション確立が失敗する可能性を最小限に抑える必要があります。失敗の原因の1つは、セッション用のネットワークリソースを確保できないことです。「ゴースト呼び出し」を避けるには、着信側に通知する前にセッション用のネットワークリソースを確保する必要があります。しかし、リソースの確保には、着信側からIPアドレス、ポート、セッションパラメーターを取得しなければならない場合が多くあります。これらの情報は、SIPで運ばれる最初のオファー/アンサー交換で得られます。この交換によって通常は電話が鳴り始めるため、先にリソースを予約しなければならない一方、その予約には最初のオファー/アンサー交換が必要という、鶏と卵の問題が生じます。
The solution is to introduce the concept of a precondition. A precondition is a set of constraints about the session which are introduced in the offer. The recipient of the offer generates an answer, but does not alert the user or otherwise proceed with session establishment. That only occurs when the preconditions are met. This can be known through a local event (such as a confirmation of a resource reservation), or through a new offer sent by the caller.
この問題を解決するため、前提条件という概念を導入します。前提条件は、オファーで提示されるセッション上の制約です。オファーの受信側はアンサーを生成しますが、前提条件が満たされるまではユーザーへの着信通知など、セッション確立に向けた処理を進めません。前提条件が満たされたことは、リソース予約の確認などのローカルイベント、または発信側から送られる新しいオファーによって確認できます。
This document deals with sessions that use SIP [1] as a signalling protocol and SDP [2] to describe the parameters of the session.
このドキュメントでは、SIP [1]をシグナリングプロトコルとして使用し、SDP [2]を使用してセッションのパラメーターを説明するセッションを扱います。
We have chosen to include the quality of service preconditions in the SDP description rather than in the SIP header because preconditions are stream specific.
前提条件はメディアストリームごとに異なるため、QoSの前提条件はSIPヘッダーではなくSDP記述に含めることにしました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [3].
このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、BCP 14 で説明されているように解釈されるものとします。
In order to ensure that session establishment does not take place until certain preconditions are met, we distinguish between two different state variables that affect a particular media stream: current status and desired status. This document defines the quality of service status.
特定の前提条件が満たされるまでセッション確立を行わないようにするため、各メディアストリームに関わる2つの状態変数、現在状態と希望状態を区別します。本書ではQoS状態を定義します。
The desired status consists of a threshold for the current status. Session establishment stops until the current status reaches or surpasses this threshold. Once this threshold is reached or surpassed, session establishment resumes.
希望状態は現在状態に対するしきい値です。現在状態がこのしきい値に達するか上回るまで、セッション確立を中断します。しきい値に達するか上回ると、セッション確立を再開します。
For example, the following values for current and desired status would not allow session establishment to resume:
たとえば、現在状態と希望状態が次の値の場合、セッション確立は再開できません。
current status = resources reserved in the send direction desired status = resources reserved in both (sendrecv) directions
現在状態 = 送信方向でリソース確保済み 希望状態 = 両方向（sendrecv）でリソース確保済み
On the other hand, the values of the example below would make session establishment resume:
一方、次の例の値であれば、セッション確立を再開できます。
current status = resources reserved in both (sendrecv) directions desired status = resources reserved in the send direction
現在状態 = 両方向（sendrecv）でリソース確保済み 希望状態 = 送信方向でリソース確保済み
These two state variables define a certain piece of state of a media stream the same way the direction attribute or the codecs in use define other pieces of state. Consequently, we treat these two new variables in the same way as other SDP media attributes are treated in the offer/answer model used by SIP [4]: they are exchanged between two user agents using an offer and an answer in order to have a shared view of the status of the session.
この2つの状態変数は、方向属性や使用中のコーデックが他の状態要素を定義するのと同じように、メディアストリームの状態の一部を定義します。そのため、SIPで用いるオファー/アンサー方式[RFC3264]では、他のSDPメディア属性と同様に扱います。セッション状態について両方のユーザーエージェントが共通認識を持てるよう、これらの変数はオファーとアンサーを使って交換されます。
Figure 1 shows a typical message exchange between two SIP user agents using preconditions. A includes quality of service preconditions in the SDP of the initial INVITE. A does not want B to be alerted until there are network resources reserved in both directions (sendrecv) end-to-end. B agrees to reserve network resources for this session before alerting the callee. B will handle resource reservation in the B->A direction, but needs A to handle the A->B direction. To indicate so, B returns a 183 (Session Progress) response to A asking A to start resource reservation and to confirm to B as soon as the A->B direction is ready for the session. A and B both start resource reservation. B finishes reserving resources in the B->A direction, but does not alert the user yet, because network resources in both directions are needed. When A finishes reserving resources in the A->B direction, it sends an UPDATE [5] to B. B returns a 200 (OK) response for the UPDATE, indicating that all the preconditions for the session have been met. At this point in time, B starts alerting the user, and session establishment completes normally.
図1は、前提条件を用いる場合の、2つのSIPユーザーエージェント間の一般的なメッセージ交換を示します。Aは最初のINVITEのSDPにQoSの前提条件を含めます。Aは、両方向（sendrecv）のエンドツーエンドでネットワークリソースが確保されるまで、Bが着信側に着信を通知しないことを望みます。Bは着信側に通知する前に、このセッション用のリソースを確保することに同意します。BはB->A方向の予約を担当しますが、A->B方向はAが担当する必要があります。これを示すため、Bは183（Session Progress）応答をAに返し、Aにリソース予約を開始し、A->B方向の準備ができたらすぐにBへ通知するよう求めます。AとBは両方ともリソース予約を開始します。BはB->A方向の予約を終えますが、両方向のリソースが必要なため、まだ着信側に通知しません。AがA->B方向の予約を終えると、UPDATE [RFC3311]をBに送ります。BはUPDATEに対する200（OK）応答を返し、セッションのすべての前提条件が満たされたことを示します。ここでBは着信側への通知を開始し、通常どおりセッションが確立されます。
We define the following media level SDP attributes:
次のメディアレベルのSDP属性を定義します。
current-status = "a=curr:" precondition-type
SP status-type SP direction-tag
desired-status = "a=des:" precondition-type
SP strength-tag SP status-type
SP direction-tag
confirm-status = "a=conf:" precondition-type
SP status-type SP direction-tag
precondition-type = "qos" | token
strength-tag = ("mandatory" | "optional" | "none"
= | "failure" | "unknown")
status-type = ("e2e" | "local" | "remote")
direction-tag = ("none" | "send" | "recv" | "sendrecv")
Current status: The current status attribute carries the current status of network resources for a particular media stream.
現在状態：current-status属性は、特定のメディアストリームに対するネットワークリソースの現在状態を示します。
Desired status: The desired status attribute carries the preconditions for a particular media stream. When the direction-tag of the current status attribute, with a given precondition-type/status-type for a particular stream is equal to (or better than) the direction-tag of the desired status attribute with the same precondition-type/status-type, for that stream, then the preconditions are considered to be met for that stream.
希望状態：desired-status属性は、特定のメディアストリームに対する前提条件を示します。特定のストリームで同じprecondition-typeとstatus-typeを持つcurrent-status属性のdirection-tagが、desired-status属性のdirection-tagと等しいか、それを満たす状態であれば、そのストリームの前提条件は満たされたものとみなされます。
Confirmation status: The confirmation status attribute carries threshold conditions for a media stream. When the status of network resources reach these conditions, the peer user agent will send an update of the session description containing an updated current status attribute for this particular media stream.
確認状態：conf-status属性は、メディアストリームに対するしきい値条件を示します。ネットワークリソースの状態がこの条件に達すると、ピアのユーザーエージェントは、このメディアストリームの更新されたcurrent-status属性を含むセッション記述を送信します。
Precondition type: This document defines quality of service preconditions. Extensions may define other types of preconditions.
前提条件タイプ：本書ではQoSの前提条件を定義します。拡張によって別のタイプの前提条件を定義することもできます。
Strength tag: The strength-tag indicates whether or not the callee can be alerted, in case the network fails to meet the preconditions.
強度タグ：strength-tagは、ネットワークが前提条件を満たせない場合に着信側へ通知できるかどうかを示します。
Status type: We define two types of status: end-to-end and segmented. The end-to-end status reflects the status of the end-to-end reservation of resources. The segmented status reflects the status of the access network reservations of both user agents. The end-to-end status corresponds to the tag "e2e", defined above and the segmented status to the tags "local" and "remote". End-to-end status is useful when end-to-end resource reservation mechanisms are available. The segmented status is useful when one or both UAs perform resource reservations on their respective access networks.
状態タイプ：状態にはエンドツーエンドとセグメント化の2種類があります。エンドツーエンド状態は、リソースのエンドツーエンド予約の状態を示します。セグメント化状態は、両ユーザーエージェントのアクセスネットワークにおける予約状態を示します。エンドツーエンド状態には上記のタグ"e2e"を、セグメント化状態にはタグ"local"と"remote"を使います。エンドツーエンドのリソース予約機構が利用できる場合は、エンドツーエンド状態が有用です。一方、一方または両方のUAがそれぞれのアクセスネットワークでリソース予約を行う場合は、セグメント化状態が有用です。
A B
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| |
Figure 1: Basic session establishment using preconditions
図1：前提条件を使用した基本セッションの確立
Direction tag: The direction-tag indicates the direction in which a particular attribute (current, desired or confirmation status) is applicable to.
方向タグ：direction-tagは、current、desired、confirmationの各状態属性が適用される方向を示します。
The values of the tags "send", "recv", "local" and "remote" represent the point of view of the entity generating the SDP description. In an offer, "send" is the direction offerer->answerer and "local" is the offerer's access network. In an answer, "send" is the direction answerer->offerer and "local" is the answerer's access network.
タグ"send"、"recv"、"local"、"remote"の値は、SDP記述を生成する側から見た方向を表します。オファーでは、"send"はオファー側からアンサー側への方向、"local"はオファー側のアクセスネットワークです。アンサーでは、"send"はアンサー側からオファー側への方向、"local"はアンサー側のアクセスネットワークです。
The following example shows these new SDP attributes in two media lines of a session description:
次の例は、セッションの説明の2つのメディアラインにこれらの新しいSDP属性を示しています。
m=audio 20000 RTP/AVP 0
a=curr:qos e2e send
a=des:qos optional e2e send
a=des:qos mandatory e2e recv
m=audio 20002 RTP/AVP 0
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos optional local sendrecv
a=des:qos mandatory remote sendrecv
Parameter negotiation in SIP is carried out using the offer/answer model described in [4]. The idea behind this model is to provide a shared view of the session parameters for both user agents once the answer has been received by the offerer. This section describes which values our new SDP attributes can take in an answer, depending on their value in the offer.
SIPのパラメーター交渉には[4]で説明されているオファー/アンサー方式を使います。この方式では、オファー側がアンサーを受け取った後、両方のユーザーエージェントがセッションパラメーターについて共通認識を持てます。本節では、オファー内の値に応じて、新しいSDP属性に対するアンサーでどの値を指定できるかを説明します。
To achieve a shared view of the status of a media stream, we define a model that consists of three tables: both user agents implement a local status table, and each offer/answer exchange has a transaction status table associated to it. The offerer generates a transaction status table, identical to its local status table, and sends it to the answerer in the offer. The answerer uses the information of this transaction status table to update its local status table. The answerer also updates the transaction status table fields that were out of date and returns this table to the offerer in the answer. The offerer can then update its local status table with the information received in the answer. After this offer/answer exchange, the local status tables of both user agents are synchronised. They now have a common view of the status of the media stream. Sessions that involve several media streams implement these tables per media stream. Note, however, that this is a model of user agent behavior, not of software. An implementation is free to take any approach that replicates the external behavior this model defines.
メディアストリームの状態について共通認識を得るため、3つのテーブルから成るモデルを定義します。両方のユーザーエージェントはそれぞれローカル状態テーブルを持ち、各オファー/アンサー交換にはトランザクション状態テーブルが関連付けられます。オファー側は自身のローカル状態テーブルと同じ内容のトランザクション状態テーブルを作り、オファーに含めてアンサー側へ送ります。アンサー側はこのテーブルの情報を使ってローカル状態テーブルを更新します。また、古くなったトランザクション状態テーブルの項目を更新し、アンサーに含めてオファー側へ返します。オファー側はアンサーで受け取った情報に基づいてローカル状態テーブルを更新します。この交換後、両ユーザーエージェントのローカル状態テーブルは同期され、メディアストリームの状態について共通の見解を持ちます。複数のメディアストリームがあるセッションでは、テーブルをストリームごとに管理します。ただし、これはソフトウェア構造ではなく、ユーザーエージェントの動作モデルです。実装は、このモデルが定める外部動作を再現する限り、任意の方法を採用できます。
Both user agents MUST maintain a local precondition status, which is referred to as a "local status table". Tables 1 and 2 show the format of these tables for both the end-to-end and the segmented status types. For the end-to-end status type, the table contains two rows; one for each direction (i.e., send and recv). A value of "yes" in the "Current" field indicates the successful reservation of that resource in the corresponding direction. "No" indicates that resources have not been reserved yet. The "Desired Strength" field indicates the strength of the preconditions in the corresponding direction. The table for the segmented status type contains four rows: both directions in the local access network and in the peer's access network. The meaning of the fields is the same as in the end-to-end case.
両ユーザーエージェントは、"local status table"と呼ぶローカル前提条件状態を維持しなければなりません (MUST)。表1と表2に、エンドツーエンド状態タイプとセグメント化状態タイプそれぞれのテーブル形式を示します。エンドツーエンド状態タイプのテーブルは、各方向（send、recv）に1行ずつ、合計2行です。"Current"フィールドの"yes"は、対応する方向のリソース確保が成功したことを示し、"no"はまだ確保されていないことを示します。"Desired Strength"フィールドは、対応する方向の前提条件の強度を示します。セグメント化状態タイプのテーブルは4行で、ローカルアクセスネットワークとピアのアクセスネットワークのそれぞれについて、両方向の状態を記録します。各フィールドの意味はエンドツーエンドの場合と同じです。
Before generating an offer, the offerer MUST build a transaction status table with the current and the desired status, for each media stream. The different values of the strength-tag for the desired status attribute have the following semantics:
オファー側は、オファーを生成する前に、各メディアストリームについて現在状態と希望状態を含むトランザクション状態テーブルを作成しなければなりません (MUST)。希望状態属性のstrength-tagの値は、次の意味を持ちます。
o None: no resource reservation is needed.
o なし：リソース予約は不要です。
o Optional: the user agents SHOULD try to provide resource reservation, but the session can continue regardless of whether or not this provision is possible.
o 任意：ユーザーエージェントはリソース予約を試みるべきです (SHOULD)。ただし、予約できるかどうかにかかわらず、セッションは継続できます。
o Mandatory: the user agents MUST provide resource reservation. Otherwise, session establishment MUST NOT continue.
o 必須：ユーザーエージェントはリソースを予約しなければなりません (MUST)。予約できない場合、セッション確立を続行してはなりません (MUST NOT)。
The offerer then decides whether it is going to use the end-to-end status type or the segmented status type. If the status type of the media line will be end-to-end, the user agent generates records with the desired status and the current status for each direction (send and recv) independently, as shown in table 1:
次にオファー側は、エンドツーエンド状態タイプとセグメント化状態タイプのどちらを使うかを決めます。メディア行の状態タイプがエンドツーエンドの場合、ユーザーエージェントは表1のように、各方向（send、recv）の希望状態と現在状態を独立したレコードにします。
Direction Current Desired Strength
____________________________________
send no mandatory
recv no mandatory
Table 1: Table for the end-to-end status type
表1：エンドツーエンド状態タイプのテーブル
If the status type of the media line will be segmented, the user agent generates records with the desired status and the current status for each direction (send and recv) and each segment (local and remote) independently, as shown in table 2:
メディア行の状態タイプがセグメント化の場合、ユーザーエージェントは表2のように、各方向（send、recv）と各区間（local、remote）について、希望状態と現在状態を独立したレコードにします。
Direction Current Desired Strength
______________________________________
local send no none
local recv no none
remote send no optional
remote recv no none
Table 2: Table for the segmented status type
表2：セグメント化状態タイプのテーブル
At the time of sending the offer, the offerer's local status table and the transaction status table contain the same values.
オファーを送信する時点では、オファー側のローカル状態テーブルとトランザクション状態テーブルに同じ値が格納されています。
With the transaction status table, the user agent MUST generate the current-status and the desired status lines, following the syntax of Section 4 and the rules described below in Section 5.1.1.
ユーザーエージェントは、トランザクション状態テーブルを使い、セクション4の構文とセクション5.1.1の規則に従って、current-status行とdesired-status行を生成しなければなりません (MUST)。
For the end-to-end status type, the user agent MUST generate one current status line with the tag "e2e" for the media stream. If the strength-tags for both directions are equal (e.g., both "mandatory") in the transaction status table, the user agent MUST add one desired status line with the tag "sendrecv". If both tags are different, the user agent MUST include two desired status lines, one with the tag "send" and the other with the tag "recv".
エンドツーエンド状態タイプでは、ユーザーエージェントはメディアストリームに対し、タグ"e2e"のcurrent-status行を1つ生成しなければなりません (MUST)。トランザクション状態テーブルで両方向のstrength-tagが同じ場合（たとえば両方が"mandatory"の場合）、タグ"sendrecv"のdesired-status行を1つ追加しなければなりません (MUST)。両方向のタグが異なる場合は、タグ"send"とタグ"recv"のdesired-status行を1つずつ含めなければなりません (MUST)。
The semantics of two lines with the same strength-tag, one with a "send" tag and the other with a "recv" tag, is the same as one "sendrecv" line. However, in order to achieve a more compact encoding, we have chosen to make the latter format mandatory.
strength-tagが同じ2行を使い、一方をタグ"send"、もう一方をタグ"recv"とした場合の意味は、タグ"sendrecv"を使う1行と同じです。ただし、符号化を簡潔にするため、後者の形式（"sendrecv"の1行）を必須としています。
For the segmented status type, the user agent MUST generate two current status lines: one with the tag "local" and the other with the tag "remote". The user agent MUST add one or two desired status lines per segment (i.e., local and remote). If, for a particular segment (local or remote), the tags for both directions in the transaction status table are equal (e.g., both "mandatory"), the user agent MUST add one desired status line with the tag "sendrecv". If both tags are different, the user agent MUST include two desired status lines, one with the tag "send" and the other with the tag "recv".
セグメント化状態タイプでは、ユーザーエージェントはcurrent-status行を2つ生成しなければなりません (MUST)。一方のタグは"local"、もう一方は"remote"です。ユーザーエージェントは、各区間（local、remote）についてdesired-status行を1つまたは2つ追加しなければなりません (MUST)。特定の区間でトランザクション状態テーブルの両方向のタグが同じ場合（たとえば両方が"mandatory"の場合）、タグ"sendrecv"のdesired-status行を1つ追加しなければなりません (MUST)。両方向のタグが異なる場合は、タグ"send"とタグ"recv"のdesired-status行を1つずつ含めなければなりません (MUST)。
Note that the rules above apply to the desired strength-tag "none" as well. This way, a user agent that supports quality of service but does not intend to use them, adds desired status lines with the strength-tag "none". Since this tag can be upgraded in the answer, as described in Section 5.2, the answerer can request quality of service reservation without a need of another offer/answer exchange.
上記の規則は、希望状態のstrength-tagが"none"の場合にも適用されます。そのため、QoSをサポートしているものの使用しないユーザーエージェントも、strength-tagを"none"としたdesired-status行を追加します。セクション5.2で説明するとおり、アンサー側はアンサーでこのタグを上位の強度に変更できるため、別のオファー/アンサー交換を行わずにQoS予約を要求できます。
The example below shows the SDP corresponding to tables 1 and 2.
以下の例は、表1および2に対応するSDPを示しています。
m=audio 20000 RTP/AVP 0
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
m=audio 20002 RTP/AVP 0
a=curr:qos local none
a=curr:qos remote none
a=des:qos optional remote send
a=des:qos none remote recv
a=des:qos none local sendrecv
When the answerer receives the offer, it recreates the transaction status table using the SDP attributes contained in the offer. The answerer updates both its local status and the transaction status table following the rules below:
アンサー側はオファーを受け取ると、そこに含まれるSDP属性を使ってトランザクション状態テーブルを再構成します。次の規則に従って、自身のローカル状態テーブルとトランザクション状態テーブルを更新します。
Desired Strength: We define an absolute ordering for the strength-tags: "none", "optional" and "mandatory". "Mandatory" is the tag with the highest grade and "none" the tag with the lowest grade. An answerer MAY upgrade the desired strength in any entry of the transaction status table, but it MUST NOT downgrade it. Therefore, it is OK to upgrade a row from "none" to "optional", from "none" to "mandatory", or from "optional" to "mandatory", but not the other way around.
希望強度：strength-tagには"none"、"optional"、"mandatory"の順で絶対的な順序があります。"mandatory"が最も高く、"none"が最も低い強度です。アンサー側はトランザクション状態テーブルの任意の項目で希望強度を上げてもかまいません (MAY) が、下げてはなりません (MUST NOT)。したがって、"none"から"optional"、"none"から"mandatory"、または"optional"から"mandatory"への変更はできますが、逆方向の変更はできません。
Current Status: For every row, the value of the "Current" field in the transaction status table, and in the local status table of the answerer, have to be compared. Table 3 shows the four possible combinations. If both fields have the same value (two first rows of table 3), nothing needs to be updated. If the "Current" field of the transaction status table is "Yes", and the field of the local status table is "No" (third row of table 3), the latter MUST be set to "Yes". If the "Current" field of the transaction status table is "No", and the field of the local status table is "Yes" (forth row of table 3), the answerer needs to check if it has local information (e.g., a confirmation of a resource reservation has been received) about that particular current status. If it does, the "Current" field of the transaction status table is set to "Yes". If the answerer does not have local information about that current status, the "Current" field of the local status table MUST be set to "No".
現在状態：各行について、トランザクション状態テーブルの"Current"フィールドとアンサー側のローカル状態テーブルの同フィールドを比較します。表3に4通りの組み合わせを示します。両フィールドの値が同じ（表3の最初の2行）であれば、更新は不要です。トランザクション状態テーブルの値が"Yes"で、ローカル状態テーブルの値が"No"の場合（表3の3行目）、ローカル状態テーブルの値を"Yes"に設定しなければなりません (MUST)。逆に、トランザクション状態テーブルが"No"でローカル状態テーブルが"Yes"の場合（表3の4行目）、アンサー側は、その状態に関するローカル情報（たとえば、リソース予約の確認を受信したかどうか）を調べる必要があります。該当する情報があれば、トランザクション状態テーブルの"Current"を"Yes"に設定します。情報がなければ、ローカル状態テーブルの"Current"を"No"に設定しなければなりません (MUST)。
Transac. status table Local status table New values transac./local
____________________________________________________________________
no no no/no
yes yes yes/yes
yes no yes/yes
no yes depends on local info
Table 3: Possible values for the "Current" fields
表3："Current"フィールドに設定できる値
Once both tables have been updated, an answer MUST be generated following the rules described in Section 5.1.1, taking into account that "send", "recv", "local" and "remote" tags have to be inverted in the answer, as shown in table 4.
両方のテーブルを更新したら、セクション5.1.1の規則に従ってアンサーを生成しなければなりません (MUST)。その際、表4のとおり、アンサーではタグ"send"と"recv"、および"local"と"remote"をそれぞれ反転させます。
Offer Answer
______________
send recv
recv send
local remote
remote local
Table 4: Values of tags in offers and answers
表4：オファーとアンサーにおけるタグの値
At the time the answer is sent, the transaction status table and the answerer's local status table contain the same values. Therefore, this answer contains the shared view of the status of the media line in the current-status attribute and the negotiated strength and direction-tags in the desired-status attribute.
アンサー送信時には、トランザクション状態テーブルとアンサー側のローカル状態テーブルに同じ値が格納されています。そのため、このアンサーのcurrent-status属性にはメディア行の状態についての共通認識が示され、desired-status属性には交渉した強度と方向タグが示されます。
If the resource reservation mechanism used requires participation of both user agents, the answerer SHOULD start resource reservation after having sent the answer and the offerer SHOULD start resource reservation as soon as the answer is received. If participation of the peer user agent is not needed (e.g., segmented status type), the offerer MAY start resource reservation before sending the offer and the answerer MAY start it before sending the answer.
使用するリソース予約機構で両方のユーザーエージェントの参加が必要な場合、アンサー側はアンサー送信後に予約を開始すべきです (SHOULD)。オファー側もアンサーを受け取ったらすぐに予約を開始すべきです (SHOULD)。ピアのユーザーエージェントが参加する必要のない場合（たとえばセグメント化状態タイプの場合）、オファー側はオファー送信前に予約を開始してもかまいません (MAY)。アンサー側もアンサー送信前に開始してもかまいません (MAY)。
The status of the resource reservation of a media line can change between two consecutive offer/answer exchanges. Therefore, both user agents MUST keep their local status tables up to date, using local information throughout the duration of the session.
メディア行のリソース予約状態は、連続する2回のオファー/アンサー交換の間に変化することがあります。そのため、両方のユーザーエージェントは、セッション中、ローカル情報を使って自身のローカル状態テーブルを最新に保たなければなりません (MUST)。
A user agent server that receives an offer with preconditions SHOULD NOT alert the user until all the mandatory preconditions are met; session establishment is suspended until that moment (e.g., a PSTN gateway reserves resources without sending signalling to the PSTN.) A user agent server may receive an INVITE request with no offer in it. In this case, following normal procedures defined in [1] and [5], the user agent server will provide an offer in a reliable 1xx response. The user agent client will send the answer in another SIP request (i.e., the PRACK for the 1xx). If the offer and the answer contain preconditions, the user agent server SHOULD NOT alert the user until all the mandatory preconditions in the answer are met.
前提条件を含むオファーを受け取ったUASは、必須の前提条件がすべて満たされるまで着信側に通知すべきではありません (SHOULD NOT)。それまではセッション確立を中断します（たとえば、PSTNゲートウェイはPSTNに信号を送らずにリソースを予約します）。オファーを含まないINVITEをUASが受信する場合もあります。この場合、[1]と[5]で定められた通常の手順に従い、UASは信頼性のある1xx応答でオファーを送ります。UACは別のSIP要求、すなわち1xxへのPRACKでアンサーを返します。オファーとアンサーに前提条件が含まれる場合、アンサー内の必須の前提条件がすべて満たされるまで、UASは着信側に通知すべきではありません (SHOULD NOT)。
Note that in this case, a user agent server providing an initial offer with preconditions, a 180 (Ringing) response with preconditions will never be sent, since the user agent server cannot alert the user until all the preconditions are met.
この場合、前提条件を含む初期オファーを送るUASは、前提条件を含む180（Ringing）応答を送信しません。すべての前提条件が満たされるまで、UASは着信側に通知できないためです。
A UAS that is not capable of unilaterally meeting all of the mandatory preconditions MUST include a confirm-status attribute in the SDP (offer or answer) that it sends (see Section 7). Further, the SDP (offer or answer) that contains this confirm-status attribute MUST be sent as soon as allowed by the SIP offer/answer rules.
必須の前提条件をすべて単独では満たせないUASは、自身が送信するSDP（オファーまたはアンサー）にconf-status属性を含めなければなりません (MUST)（セクション7を参照）。また、このconf-status属性を含むSDPは、SIPのオファー/アンサー規則で許される限り速やかに送信しなければなりません (MUST)。
While session establishment is suspended, user agents SHOULD not send any data over any media stream. In the case of RTP [6], neither RTP nor RTCP packets are sent.
セッション確立が中断されている間、ユーザーエージェントはメディアストリーム上でデータを送信すべきではありません (SHOULD NOT)。RTP [6]の場合、RTPパケットもRTCPパケットも送信しません。
A user agent server knows that all the preconditions are met for a media line when its local status table has a value of "yes" in all the rows whose strength-tag is "mandatory". When the preconditions of all the media lines of the session are met, session establishment SHOULD resume.
UASのローカル状態テーブルでstrength-tagが"mandatory"のすべての行が"yes"であれば、そのメディア行の前提条件はすべて満たされています。セッション内のすべてのメディア行の前提条件が満たされたら、セッション確立を再開すべきです (SHOULD)。
For an initial INVITE, suspending and resuming session establishment is very intuitive. The callee will not be alerted until all the mandatory preconditions are met. However, offers containing preconditions sent in the middle of an ongoing session need further explanation. Both user agents SHOULD continue using the old session parameters until all the mandatory preconditions are met. At that moment, the user agents can begin using the new session parameters. Section 13 contains an example of this situation.
最初のINVITEでは、セッション確立の一時停止と再開は直感的です。必須の前提条件がすべて満たされるまで、着信側への通知を保留します。一方、進行中のセッション中に前提条件を含むオファーを送る場合は、追加の説明が必要です。両方のユーザーエージェントは、必須の前提条件がすべて満たされるまで古いセッションパラメーターを使い続けるべきです (SHOULD)。その時点で新しいセッションパラメーターを使い始められます。この状況の例はセクション13にあります。
The confirm-status attribute MAY be used in both offers and answers. This attribute represents a threshold for the resource reservation. When this threshold is reached or surpassed, the user agent MUST send an offer to the peer user agent, reflecting the new current status of the media line as soon as allowed by the SIP offer/answer rules. If this threshold is crossed again (e.g., the network stops providing resources for the media stream), the user agent MUST send a new offer as well, as soon as allowed by the SIP offer/answer rules.
confirm-status属性はオファーとアンサーの両方で使用してもかまいません (MAY)。この属性はリソース予約のしきい値を表します。このしきい値に達するか上回った場合、ユーザーエージェントは、SIPのオファー/アンサー規則で許される限り速やかに、メディア行の新しい現在状態を反映したオファーをピアのユーザーエージェントへ送信しなければなりません (MUST)。たとえばネットワークがメディアストリームへのリソース提供を停止するなど、しきい値を再度下回った場合にも、新しいオファーを同じく速やかに送信しなければなりません (MUST)。
If a peer has requested confirmation on a particular stream, an agent MUST mark that stream with a flag in its local status table. When all the rows with this flag have a "Current" value of "yes", the user agent MUST send a new offer to the peer. This offer will contain the current status of resource reservation in the current-status attributes. Later, if any of the rows with this flag transition to "No", a new offer MUST be sent as well.
ピアが特定のストリームについて確認を要求した場合、ユーザーエージェントはそのストリームをローカル状態テーブルでフラグ付けしなければなりません (MUST)。このフラグが付いたすべての行の"Current"が"yes"になったら、ユーザーエージェントはピアに新しいオファーを送信しなければなりません (MUST)。このオファーのcurrent-status属性には、リソース予約の現在状態が含まれます。その後、フラグ付きの行のいずれかが"No"に変わった場合も、新しいオファーを送信しなければなりません (MUST)。
Confirmation attributes are not negotiated. The answerer uses the value of the confirm-status attribute in the offer, and the offerer uses the value of this attribute in the answer.
確認属性は交渉しません。アンサー側はオファー内のconf-status属性の値を使い、オファー側はアンサー内の同属性の値を使います。
For example, if a user agent receives an SDP description with the following attributes:
たとえば、ユーザーエージェントが次の属性を使用してSDP説明を受信した場合：
m=audio 20002 RTP/AVP 0
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=conf:qos remote sendrecv
It will send an offer as soon as it reserves resources in its access network ("remote" tag in the received message) for both directions (sendrecv).
受信したメッセージのタグ"remote"が示すアクセスネットワークで、両方向（sendrecv）のリソースが確保されると、ユーザーエージェントはすぐにオファーを送信します。
We define a new SIP status code:
新しいSIPステータスコードを定義します。
Server-Error = "580" ;Precondition Failure
Server-Error = "580" ;Precondition Failure
When a UAS, acting as an answerer, cannot or is not willing to meet the preconditions in the offer, it SHOULD reject the offer by returning a 580 (Precondition-Failure) response.
アンサー側のUASがオファー内の前提条件を満たせない、または満たす意思がない場合、580（Precondition Failure）応答を返してオファーを拒否すべきです (SHOULD)。
Using the 580 (Precondition Failure) status code to refuse an offer is useful when the offer comes in an INVITE or in an UPDATE request. However, SIP does not provide a means to refuse offers that arrive in a response (1xx or 2xx) to an INVITE. If a UAC generates an initial INVITE without an offer and receives an offer in a 1xx or 2xx response which is not acceptable, it SHOULD respond to this offer with a correctly formed answer and immediately send a CANCEL or a BYE.
INVITEまたはUPDATE要求に含まれるオファーを拒否する場合、580（Precondition Failure）ステータスコードが役立ちます。ただし、SIPではINVITEに対する応答（1xxまたは2xx）に含まれるオファーを拒否する方法がありません。UACがオファーなしで最初のINVITEを送り、受け入れられないオファーを含む1xxまたは2xx応答を受信した場合、正しく形式化したアンサーを返し、直ちにCANCELまたはBYEを送るべきです (SHOULD)。
If the offer comes in a 1xx or 2xx response to a re-INVITE, A would not have a way to reject it without terminating the session at the same time. The same recommendation given in Section 15.2 of [1] applies here:
再INVITEに対する1xxまたは2xx応答にオファーが含まれている場合、Aはセッションを同時に終了させずにそのオファーを拒否する方法がありません。[1]のセクション15.2で示されている推奨事項をここでも適用します。
"The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, other parameters that require support from the peer. This is to avoid the need for the peer to reject the session description. If, however, it is unacceptable to A, A SHOULD generate an answer with a valid session description, and then send a BYE to terminate the session."
「UASは、メディア形式、トランスポート、その他ピアの対応が必要なパラメーターについて、セッション記述が直前のセッション記述と重なるようにしなければなりません (MUST)。これは、ピアがセッション記述を拒否する必要をなくすためです。ただし、Aがその記述を受け入れられない場合、Aは有効なセッション記述を含むアンサーを生成し、その後BYEを送ってセッションを終了すべきです (SHOULD)。
580 (Precondition Failure) responses and BYE and CANCEL requests, indicating failure to meet certain preconditions, SHOULD contain an SDP description, indicating which desired status triggered the failure. Note that this SDP description is not an offer or an answer, since it does not lead to the establishment of a session. The format of such a description is based on the last SDP (an offer or an answer) received from the remote UA.
特定の前提条件を満たせないことを示す580（Precondition Failure）応答、BYE要求、CANCEL要求には、どの希望状態が失敗の原因となったかを示すSDP記述を含めるべきです (SHOULD)。このSDP記述はセッション確立につながらないため、オファーでもアンサーでもありません。記述の形式は、リモートUAから最後に受信したSDP（オファーまたはアンサー）に基づきます。
For each "m=" line in the last SDP description received, there MUST be a corresponding "m=" line in the SDP description indicating failure. This SDP description MUST contain exactly the same number of "m=" lines as the last SDP description received. The port number of every "m=" line MUST be set to zero, but the connection address is arbitrary.
最後に受信したSDP記述の各"m="行に対し、失敗を示すSDP記述にも対応する"m="行を含めなければなりません (MUST)。このSDP記述には、最後に受信したSDP記述とまったく同じ数の"m="行を含めなければなりません (MUST)。すべての"m="行のポート番号を0に設定しなければなりません (MUST)。接続アドレスは任意です。
The desired status line corresponding to the precondition that triggered the failure MUST use the "failure" strength-tag, as shown in the example below:
失敗の原因となった前提条件に対応するdesired-status行では、以下の例のようにstrength-tagを"failure"にしなければなりません (MUST)。
m=audio 20000 RTP/AVP 0 a=des:qos failure e2e send
m=audio 20000 RTP/AVP 0 a=des:qos failure e2e send
In the offer/answer model, when an answerer wishes to reject a media stream, it sets its port to zero. The presence of preconditions does not change this behaviour; streams are still rejected by setting their port to zero.
オファー/アンサー方式では、アンサー側がメディアストリームを拒否する場合、そのポート番号を0に設定します。前提条件があってもこの動作は変わらず、ポート番号を0にしてストリームを拒否します。
Both the offerer and the answerer MUST ignore all the preconditions that affect a stream with its port set to zero. They are not taken into consideration to decide whether or not session establishment can resume.
オファー側とアンサー側は、ポート番号が0に設定されたストリームに関わる前提条件をすべて無視しなければなりません (MUST)。セッション確立を再開できるかどうかの判断にも、これらの前提条件を考慮しません。
This document defines the "qos" tag for quality of service preconditions. New precondition-types defined in the future will have new associated tags. A UA that receives an unknown precondition-type, with a "mandatory" strength-tag in an offer, MUST refuse the offer unless the only unknown mandatory preconditions have the "local" tag. In this case, the UA does not need to be involved in order to meet the preconditions. The UA will ask for confirmation of the preconditions and, when the confirmation arrives, it will resume session establishment.
本書は、QoSの前提条件を示す"qos"タグを定義します。将来定義される前提条件タイプには、それぞれ新しいタグが割り当てられます。オファー内でstrength-tagが"mandatory"の未知の前提条件タイプを受信したUAは、未知の必須前提条件がすべてタグ"local"である場合を除き、オファーを拒否しなければなりません (MUST)。この場合、前提条件を満たすためにUAが関与する必要はありません。UAは前提条件の確認を要求し、その確認が届いたらセッション確立を再開します。
A UA refusing an offer follows the rules described in section 8, but instead of the tag "failure", it uses the tag "unknown", as shown in the example below:
オファーを拒否するUAはセクション8の規則に従いますが、以下の例のように、タグ"failure"の代わりにタグ"unknown"を使います。
m=audio 20000 RTP/AVP 0 a=des:foo unknown e2e send
m=audio 20000 RTP/AVP 0 a=des:foo unknown e2e send
A media stream MAY contain multiple preconditions. Different preconditions MAY have the same precondition-type and different status-types (e.g., end to end and segmented quality of service preconditions) or different precondition-types (this document only defines the "qos" precondition type, but extensions may define more precondition-types in the future).
メディアストリームには複数の前提条件を含めてもかまいません (MAY)。異なる前提条件でも、同じprecondition-typeと異なるstatus-type（たとえばエンドツーエンドQoSとセグメント化QoS）を使う場合があります (MAY)。または、異なるprecondition-typeを使う場合があります（本書では"qos"タイプだけを定義しますが、将来の拡張で別のタイプを定義できます）。
All the preconditions for a media stream MUST be met in order to resume session establishment. The following example shows a session description that uses both end-to-end and segmented status-types for a media stream.
セッション確立を再開するには、メディアストリームの前提条件をすべて満たさなければなりません (MUST)。次の例は、1つのメディアストリームにエンドツーエンドとセグメント化の両方の状態タイプを使うセッション記述を示します。
m=audio 20000 RTP/AVP 0
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=curr:qos e2e none
a=des:qos optional e2e sendrecv
We define the option tag "precondition" for use in the Require and Supported header fields. An offerer MUST include this tag in the Require header field if the offer contains one or more "mandatory" strength-tags. If all the strength-tags in the description are "optional" or "none", the offerer MUST include this tag in either a Supported header field or in a Require header field. It is, however, RECOMMENDED that the Supported header field be used in this case. The lack of preconditions in the answer would indicate that the answerer did not support this extension.
RequireヘッダーフィールドとSupportedヘッダーフィールドで使うオプションタグ"precondition"を定義します。オファーにstrength-tagが"mandatory"の項目が1つ以上含まれる場合、オファー側はこのタグをRequireヘッダーフィールドに含めなければなりません (MUST)。記述内のstrength-tagがすべて"optional"または"none"の場合、オファー側はこのタグをSupportedまたはRequireヘッダーフィールドのいずれかに含めなければなりません (MUST)。この場合はSupportedヘッダーフィールドを使うことが推奨されます (SHOULD)。アンサーに前提条件がない場合、アンサー側がこの拡張に対応していないことを示します。
The mapping of offers and answers to SIP requests and responses is performed following the rules given in [5]. Therefore, a user agent including preconditions in the SDP MUST support the PRACK and UPDATE methods. Consequently, it MUST include the "100rel" [7] tag in the Supported header field and SHOULD include an Allow header field with the "UPDATE" tag [5].
SIP要求と応答に対するオファーとアンサーの対応付けは[5]の規則に従います。そのため、SDPに前提条件を含めるユーザーエージェントはPRACKとUPDATEの各メソッドに対応しなければなりません (MUST)。したがって、Supportedヘッダーフィールドにタグ"100rel" [7]を含めなければなりません (MUST)。さらに、タグ"UPDATE" [5]を含むAllowヘッダーフィールドを含めるべきです (SHOULD)。
The offer/answer model [4] describes the format of a session description to indicate capabilities. This format is used in responses to OPTIONS requests. A UA that supports preconditions SHOULD add desired status lines indicating the precondition-types supported for each media stream. These lines MUST have the "none" strength-tag, as shown in the example below:
オファー/アンサー方式[4]では、機能を示すセッション記述の形式を定めています。この形式はOPTIONS要求への応答で使われます。前提条件に対応するUAは、各メディアストリームで対応する前提条件タイプを示すdesired-status行を追加すべきです (SHOULD)。以下の例のように、これらの行のstrength-tagは"none"でなければなりません (MUST)。
m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=des:foo none e2e sendrecv
a=des:qos none local sendrecv
Note that when this document was published, the precondition-type "foo" has not been registered. It is used here in the session description above to provide an example with multiple precondition-types.
本書の発行時点では、前提条件タイプ"foo"は登録されていません。複数の前提条件タイプの例を示すため、上記のセッション記述ではこのタイプを使っています。
A UA that supports this framework SHOULD add a "precondition" tag to the Supported header field of its responses to OPTIONS requests.
このフレームワークに対応するUAは、OPTIONS要求への応答のSupportedヘッダーフィールドに"precondition"タグを追加すべきです (SHOULD)。
The following examples cover both status types; end-to-end and segmented.
以下の例では、エンドツーエンドとセグメント化の両方の状態タイプを扱います。
The call flow of Figure 2 shows a basic session establishment using the end-to-end status type. The SDP descriptions of this example are shown below:
図2の呼び出しフローは、エンドツーエンド状態タイプを使う基本的なセッション確立を示します。この例のSDP記述を以下に示します。
SDP1: A includes end-to-end quality of service preconditions in the initial offer.
SDP1：Aは最初のオファーにエンドツーエンドQoSの前提条件を含めます。
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
SDP2: Since B uses RSVP, it can know when resources in its "send" direction are available, because it will receive RESV messages from the network. However, it does not know the status of the reservations in the other direction. B requests confirmation for resource reservations in its "recv" direction to the peer user agent A in its answer.
SDP2：BはRSVPを使うため、ネットワークからRESVメッセージを受信し、自身の"send"方向でリソースが利用可能になったことを確認できます。しかし、反対方向の予約状態は分かりません。そこでBはアンサー内で、"recv"方向のリソース予約についてピアのユーザーエージェントAに確認を求めます。
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
After having sent the answer, B starts reserving network resources for the media stream. When A receives this answer (2), it starts performing resource reservation as well. Both UAs use RSVP, so A sends PATH messages towards B and B sends PATH messages towards A.
アンサーを送信すると、Bはメディアストリームのネットワークリソース予約を開始します。Aはこのアンサー（2）を受信すると、同様にリソース予約を開始します。両方のUAがRSVPを使うため、AはBへPATHメッセージを送り、BはAへPATHメッセージを送ります。
As time passes, B receives RESV messages confirming the reservation. However, B waits until resources in the other direction are reserved as well, since it did not receive any confirmation and the preconditions still have not been met.
時間が経つにつれて、Bは予約を確認するRESVメッセージを受信します。しかし、反対方向の予約については確認を受け取っておらず、前提条件がまだ満たされていないため、Bはその方向のリソースが確保されるまで待ちます。
SDP3: When A receives RESV messages, it sends an updated offer (5) to B:
SDP3：AはRESVメッセージを受信すると、更新したオファー（5）をBに送ります。
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
SDP4: B responds with an answer (6) which contains the current status of the resource reservation (i.e., sendrecv):
SDP4：Bはアンサー（6）を返し、リソース予約の現在状態が"sendrecv"であることを示します。
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
At this point in time, session establishment resumes and B returns a 180 (Ringing) response (7).
この時点で、セッションの確立が再開され、Bは180（リンギング）応答（7）を返します。
A B
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| |
Figure 2: Example using the end-to-end status type
図2：エンドツーエンドステータスタイプを使用した例
Let's assume, that in the middle of the session, A wishes to change the IP address where it is receiving media. Figure 3 shows this scenario.
セッションの途中で、Aがメディア受信先のIPアドレスを変更したいとします。図3にこの状況を示します。
SDP1: A includes an offer in a re-INVITE (1). A continues to receive media on the old IP address (192.0.2.1), but is ready to receive media on the new one as well (192.0.2.2):
SDP1：Aはre-INVITE（1）にオファーを含めます。Aは古いIPアドレス（192.0.2.1）でのメディア受信を続けながら、新しいIPアドレス（192.0.2.2）でも受信できる状態にします。
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
SDP2: B includes a "conf" attribute in its answer. B continues sending media to the old remote IP address (192.0.2.1)
SDP2：Bはアンサーに"conf"属性を含めます。Bは古いリモートIPアドレス（192.0.2.1）へのメディア送信を続けます。
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
SDP3: When A receives RESV messages it sends an updated offer (5) to B:
SDP3：AはRESVメッセージを受信すると、更新したオファー（5）をBに送ります。
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
SDP4: B responds with an answer (6), indicating that the preconditions have been met (current status "sendrecv). It is now that B begins sending media to the new remote IP address (192.0.2.2).
SDP4：Bはアンサー（6）を返し、前提条件が満たされたこと（現在状態"sendrecv"）を示します。この時点でBは新しいリモートIPアドレス（192.0.2.2）へのメディア送信を開始します。
A B
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-----------(7) 200 OK (INVITE)-------------|
| |
|------------------(8) ACK------------------>|
| |
| |
Figure 3: Session modification with preconditions
図3：前提条件を用いたセッション変更
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
The call flow of Figure 4 shows a basic session establishment using the segmented status type. The SDP descriptions of this example are shown below: SDP1: A includes local and remote QoS preconditions in the initial offer. Before sending the initial offer, A reserves resources in its access network. This is indicated in the local current status of the SDP below:
図4の呼び出しフローは、セグメント化状態タイプを使う基本的なセッション確立を示します。この例のSDP記述を以下に示します。SDP1：Aは最初のオファーにlocalとremoteのQoS前提条件を含めます。初期オファーを送る前に、Aは自身のアクセスネットワークでリソースを確保します。これは以下のSDPのlocal current-statusに示されています。
m=audio 20000 RTP/AVP 0 8
c=IN IP4 192.0.2.1
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
SDP2: B reserves resources in its access network and, since all the preconditions are met, returns an answer in a 180 (Ringing) response (3).
SDP2：Bは自身のアクセスネットワークでリソースを確保します。すべての前提条件が満たされたため、180（Ringing）応答（3）にアンサーを含めて返します。
m=audio 30000 RTP/AVP 0 8
c=IN IP4 192.0.2.4
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
Let's assume that after receiving this response, A decides that it wants to use only PCM u-law (payload 0), as opposed to both PCM u-law and A-law (payload 8). It would send an UPDATE to B, possibly before receiving the 200 (OK) for the INVITE (5). The SDP would look like:
この応答を受け取った後、AはPCM u-law（ペイロード0）だけを使い、PCM u-lawとA-law（ペイロード8）の両方は使わないことにしたとします。INVITEに対する200（OK）（5）を受け取る前に、AはBへUPDATEを送る場合があります。SDPは次のようになります。
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
B would generate an answer for this offer and place it in the 200 (OK) for the UPDATE.
Bはこのオファーに対するアンサーを生成し、UPDATEに対する200（OK）応答に含めます。
Note that this last offer/answer to reduce the number of supported codecs may arrive to the user agent server after the 200 (OK) response has been generated. This would mean that the session is established before A has reduced the number of supported codecs. To avoid this situation, the user agent client could wait for the first answer from the user agent before setting its local current status to "sendrecv".
対応するコーデック数を減らすための最後のオファー/アンサーは、200（OK）応答が生成された後にUASへ届く場合があります。その場合、Aが対応コーデック数を減らす前にセッションが確立されてしまいます。これを避けるため、UACはローカルのcurrent-statusを"sendrecv"に設定する前に、UASから最初のアンサーを受け取るまで待つことができます。
The call flow of Figure 5 shows a basic session establishment where the initial offer appears in a reliable 1xx response. This example uses the end-to-end status type. The SDP descriptions of this example are shown below:
図5の呼び出しフローは、信頼性のある1xx応答内に初期オファーを含める基本的なセッション確立を示します。この例ではエンドツーエンド状態タイプを使います。SDP記述を以下に示します。
The first INVITE (1) does not contain a session description. Therefore, the initial offer is sent by B in a reliable 183 (Session Progress) response.
最初のINVITE（1）にはセッション記述がありません。そのため、Bは信頼性のある183（Session Progress）応答に初期オファーを含めて送信します。
SDP1: B includes end-to-end quality of service preconditions in the initial offer. Since B uses RSVP, it can know when resources in its "send" direction are available, because it will receive RESV messages from the network. However, it does not know the status of the reservations in the other direction. B requests confirmation for resource reservations in its "recv" direction, to the peer user agent A, in its answer.
SDP1：Bは最初のオファーにエンドツーエンドQoSの前提条件を含めます。BはRSVPを使うため、ネットワークからRESVメッセージを受信し、自身の"send"方向でリソースが利用可能になったことを確認できます。しかし、反対方向の予約状態は分かりません。そこでBはアンサー内で、"recv"方向のリソース予約についてピアのユーザーエージェントAに確認を求めます。
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
SDP2: A includes its answer in the PRACK for the 183 (Session Progress) response.
SDP2：Aは183（Session Progress）応答へのPRACKにアンサーを含めます。
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
A B
A B
| *** |
| *R* |
| *E* |
| *S* |
| *E* |
| *R* |
| *V* |
| *A* |
| *T* |
| *I* |
| *O* |
| *N* |
| *** |
|-------------(1) INVITE SDP1--------------->|
| *** |
| *R* |
| *E* |
| *S* |
| *E* |
| *R* |
| *V* |
| *A* |
| *T* |
| *I* |
| *O* |
| *N* |
| *** |
|<----------(2) 180 Ringing SDP2-------------|
| |
|----------------(3) PRACK------------------>|
| |
|<-----------(4) 200 OK (PRACK)--------------|
| |
| |
|<-----------(5) 200 OK (INVITE)-------------|
| |
|------------------(6) ACK------------------>|
| |
| |
Figure 4: Example using the segmented status type
図4：セグメント化されたステータスタイプを使用した例
A B
A B
| |
|----------------(1) INVITE----------------->|
| |
|<------(2) 183 Session Progress SDP1--------|
| |
|---------------(3) PRACK SDP2-------------->|
| *** *** |
|<-*R*--------(4) 200 OK (PRACK)-------*R*---|
| *E* *E* |
| *S* *S* |
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
|-------------(5) UPDATE SDP3----------***-->|
| *** |
|<--------(6) 200 OK (UPDATE) SDP4-----***---|
| *** |
| *** |
| *** |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
Figure 5: Example of an initial offer in a 1xx response
図5：1xx応答内の初期オファーの例
After having sent the answer, A starts reserving network resources for the media stream. When B receives this answer (3), it starts performing resource reservation as well. Both UAs use RSVP, so A sends PATH messages towards B and B sends PATH messages towards A.
アンサーを送信すると、Aはメディアストリームのネットワークリソース予約を開始します。Bはこのアンサー（3）を受信すると、同様に予約を開始します。両方のUAがRSVPを使うため、AはBへPATHメッセージを送り、BはAへPATHメッセージを送ります。
SDP3: When A receives RESV messages, it sends an updated offer (5) to B:
SDP3：AはRESVメッセージを受信すると、更新したオファー（5）をBに送ります。
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
SDP4: B responds with an answer (6) which contains the current status of the resource reservation (i.e., recv):
SDP4：Bはアンサー（6）を返し、リソース予約の現在状態が"recv"であることを示します。
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e recv
a=des:qos mandatory e2e sendrecv
As time passes, B receives RESV messages confirming the reservation. At this point in time, session establishment resumes and B returns a 180 (Ringing) response (7).
時間が経つにつれて、Bは予約を確認するRESVメッセージを受信します。ここでセッション確立が再開され、Bは180（Ringing）応答（7）を返します。
An entity in the middle of two user agents establishing a session may add desired-status attributes making session establishment impossible. It could also modify the content of the current-status parameters so that the session is established without meeting the preconditions. Integrity protection can be used to avoid these attacks.
セッションを確立する2つのユーザーエージェント間にいる第三者は、セッション確立を不可能にするdesired-status属性を追加する可能性があります。また、current-statusパラメーターを書き換え、前提条件が満たされていないのにセッションを確立させる可能性もあります。完全性保護によって、こうした攻撃を防止できます。
An entity performing resource reservations upon reception of unauthenticated requests carrying preconditions can be an easy target for a denial of service attack. Requests with preconditions SHOULD be authenticated.
前提条件を含む未認証要求を受け取ってリソース予約を行うエンティティは、サービス拒否攻撃の格好の標的になり得ます。前提条件を含む要求は認証すべきです (SHOULD)。
This document defines three media level SDP attributes: desired-status, current-status and conf-status. Their format is defined in Section 4.
本書は、desired-status、current-status、conf-statusという3つのメディアレベルSDP属性を定義します。それらの形式はセクション4で定義しています。
This document defines a framework for using preconditions with SIP. Precondition-types to be used with this framework are registered by the IANA when they are published in standards track RFCs. The IANA Considerations section of the RFC MUST include the following information, which appears in the IANA registry along with the RFC number of the publication.
本書は、SIPで前提条件を使うためのフレームワークを定義します。このフレームワークで使う前提条件タイプは、Standards Track RFCとして公開される際にIANAが登録します。RFCのIANAに関する考慮事項には、以下の情報を含めなければなりません (MUST)。この情報は、登録対象RFCの番号とともにIANAレジストリに掲載されます。
o Name of the precondition-type. The name MAY be of any length, but SHOULD be no more than ten characters long.
o 前提条件タイプの名前。名前の長さは任意でもよい (MAY)ですが、10文字以下にすべきです (SHOULD)。
o Descriptive text that describes the extension.
o 拡張を説明する記述
The only entry in the registry for the time being is:
現時点でのレジストリ項目は次のとおりです。
Pecondition-Type Reference Description
---------------- --------- -----------
qos RFC 3312 Quality of Service preconditions
This document also defines a new SIP status code (580). Its default reason phrase (Precondition Failure) is defined in section 8.
本書は新しいSIPステータスコード（580）も定義します。既定の理由句（Precondition Failure）はセクション8で定義します。
This document defines a SIP option tag (precondition) in section 11.
本書はセクション11でSIPオプションタグ"precondition"を定義します。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
本書に含まれる仕様の一部または全部について、主張された知的財産権がある旨をIETFは通知されています。詳細については、主張された権利のオンライン一覧を参照してください。
[1] 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.
[1] 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.
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method," RFC 3311, September 2002.
[5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method," RFC 3311, September 2002.
[6] Schulzrinne, S., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[6] Schulzrinne, S., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[8] C. Kalmanek, W. Marshall, P. Mishra, D. Nortz, and K. K. Ramakrishnan, "DOSA: an architecture for providing robust IP telephony service," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (Tel Aviv, Israel), Mar. 2000.
[8] C. Kalmanek, W. Marshall, P. Mishra, D. Nortz, and K. K. Ramakrishnan, "DOSA: an architecture for providing robust IP telephony service," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (Tel Aviv, Israel), Mar. 2000.
The following persons contributed and were co-authors on earlier versions of this spec:
以下の方々は本仕様の以前の版に貢献し、共著者でもありました。
K. K. Ramakrishnan (TeraOptic Networks), Ed Miller (Terayon), Glenn Russell (CableLabs), Burcak Beser (Pacific Broadband Communications), Mike Mannette (3Com), Kurt Steinbrenner (3Com), Dave Oran (Cisco), Flemming Andreasen (Cisco), Michael Ramalho (Cisco), John Pickens (Com21), Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain Networks), Doc Evans (D. R. Evans Consulting), Keith Kelly (NetSpeak), Adam Roach (dynamicsoft), Dean Willis (dynamicsoft), Steve Donovan (dynamicsoft), Henning Schulzrinne (Columbia University).
K. K. Ramakrishnan (TeraOptic Networks), Ed Miller (Terayon), Glenn Russell (CableLabs), Burcak Beser (Pacific Broadband Communications), Mike Mannette (3Com), Kurt Steinbrenner (3Com), Dave Oran (Cisco), Flemming Andreasen (Cisco), Michael Ramalho (Cisco), John Pickens (Com21), Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain Networks), Doc Evans (D. R. Evans Consulting), Keith Kelly (NetSpeak), Adam Roach (dynamicsoft), Dean Willis (dynamicsoft), Steve Donovan (dynamicsoft), Henning Schulzrinne (Columbia University).
This "manyfolks" document is the culmination of over two years of work by many individuals, most are listed here and in the following acknowledgements section. A special note is due to Flemming Andreasen, Burcak Beser, Dave Boardman, Bill Guckel, Chuck Kalmanek, Keith Kelly, Poornima Lalwaney, John Lawser, Bill Marshall, Mike Mannette, Dave Oran, K.K. Ramakrishnan, Michael Ramalho, Adam Roach, Jonathan Rosenberg, and Henning Schulzrinne for spearheading the initial "single INVITE" quality of service preconditions work from previous, non-SIP compatible, "two-stage Invite" proposals. These "two-stage INVITE" proposals had their origins from Distributed Call Signaling work in PacketCable, which, in turn, had architectural elements from AT&T's Distributed Open Systems Architecture (DOSA) work [8].
この"manyfolks"文書は、多くの方々が2年以上にわたり取り組んだ成果であり、その多くは本節および次の謝辞節に記載されています。特に、以前のSIP非互換な"two-stage Invite"提案から、初期の"single INVITE" QoS前提条件の取り組みを主導したFlemming Andreasen、Burcak Beser、Dave Boardman、Bill Guckel、Chuck Kalmanek、Keith Kelly、Poornima Lalwaney、John Lawser、Bill Marshall、Mike Mannette、Dave Oran、K. K. Ramakrishnan、Michael Ramalho、Adam Roach、Jonathan Rosenberg、Henning Schulzrinneに謝意を表します。これらの"two-stage INVITE"提案はPacketCableのDistributed Call Signalingの作業に由来し、同作業にはAT&TのDistributed Open Systems Architecture（DOSA）[8]の設計要素が取り入れられていました。
The Distributed Call Signaling work in the PacketCable project is the work of a large number of people, representing many different companies. The authors would like to recognize and thank the following for their assistance: John Wheeler, Motorola; David Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jay Strater, Jeff Ollis, Clive Holborow, General Instruments; Doug Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckel, Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent Cable Communications.
PacketCableプロジェクトのDistributed Call Signalingは、多数の企業からの多くの人々が取り組んだ作業です。著者は、支援してくださった以下の方々と組織に感謝します：John Wheeler (Motorola); David Boardman, Daniel Paul (Arris Interactive); Bill Blum, Jay Strater, Jeff Ollis, Clive Holborow (General Instruments); Doug Newlin, Guido Schuster, Ikhlaq Sidhu (3Com); Jiri Matousek (Bay Networks); Farzi Khazai (Nortel); John Chapman, Bill Guckel (Cisco); Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra (AT&T); Telcordia Technologies; Lucent Cable Communications.
Miguel Angel Garcia-Martin, Rohan Mahy and Mark Watson provided helpful comments and suggestions.
Miguel Angel Garcia-Martin、Rohan Mahy、Mark Watsonから有益なコメントと提案をいただきました。
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
EMail: Gonzalo.Camarillo@ericsson.com
Bill Marshall AT&T Florham Park, NJ 07932 USA
Bill Marshall AT&T Florham Park, NJ 07932 USA
EMail: wtm@research.att.com
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA
EMail: jdrosen@dynamicsoft.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本書およびその翻訳は、他者に複製・提供できます。また、本書について論評または説明する派生著作物や、本書の実装を支援する著作物を、全部または一部、いかなる制限もなく作成、複製、公開、配布できます。ただし、そのすべての複製物および派生著作物に、上記の著作権表示と本段落を含める必要があります。本書自体は、著作権表示やInternet Societyその他のインターネット関連組織への言及を削除するなど、いかなる方法でも変更してはなりません。ただし、インターネット標準の策定に必要な変更で、Internet Standards Processに定められた著作権手順に従う場合、または英語以外の言語への翻訳に必要な変更は例外です。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限定的な許可は恒久的であり、Internet Society、その後継者または譲受人によって取り消されません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本書および本書に含まれる情報は「現状有姿」で提供されます。INTERNET SOCIETYおよびINTERNET ENGINEERING TASK FORCEは、明示または黙示を問わず、すべての保証を否認します。これには、本書の情報の使用が権利を侵害しないという保証、ならびに商品性または特定目的への適合性に関する黙示の保証が含まれますが、これらに限定されません。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyが行っています。