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)
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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登録を介して拡張可能である前提条件、のための一般的なフレームワークを定義します。この文書では、サービスのネットワーク品質がセッション開始プロトコル（SIP）によって開始されたセッションの確立のための前提条件とすることができる方法について説明します。これらの前提条件は、セッションを続行する前に、参加者の予備ネットワークリソースする必要があります。私たちは、サービス予約メカニズムの新しい品質を定義しません。これらの前提条件は、単純にセッションを開始する前に、既存のリソース予約メカニズムを使用するように参加者を必要としています。
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
1 Introduction
1はじめに
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.
いくつかのアーキテクチャは、着呼側が警告された後、セッション確立時に、セッション確立の失敗の可能性が最小であることを必要としています。失敗の一つの原因は、セッションのためのネットワークリソースを予約することができないことです。 「ゴーストリング」を最小限にするためには、呼び出し先が警告される前に、セッションのためのネットワークリソースを確保する必要があります。しかし、ネットワークリソースの予約は、頻繁に呼び出し先からの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.
この文書では、シグナリングプロトコルとして[1] SIPを使用して、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.
我々は、前提条件がストリーム特異的であるので、SDP記述ではなく、SIPヘッダ内のサービスの前提条件の質を含めることを選択しました。
2 Terminology
2用語
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[3]。
3 Overview
3概要
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つの特定のメディア・ストリームに影響を与えるさまざまな状態変数を区別します。このドキュメントでは、サービスの状態の品質を定義します。
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つの状態変数は、メディアの状態の特定のピースが方向属性または使用中のコーデックは、状態の他の部分を定義するのと同じ方法をストリーミング定義します。彼らが持っているために、申し出と答えを使って2つのユーザーエージェント間で交換されています。そのため、我々は他のSDPメディア属性がSIPで使用されるオファー/アンサーモデルに扱われるのと同じ方法で、これら二つの新しい変数が[4]治療しますセッションの状態の見解を共有しました。
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は、初期のSDPにおけるサービスの前提条件の質がINVITEを含んでいます。両方向（SENDRECV）エンド・ツー・エンドで予約したネットワークリソースがあるまで、AがBに警告することを望んでいません。 Bは、呼び出し先を警告する前に、このセッションのためのネットワークリソースを予約することに同意します。 BはB->方向にリソース予約を扱うが、A-> Bの方向を処理するために必要であろう。これを示すには、Bは、リソース予約を開始するとすぐA-> B方向がセッションのための準備ができているとしてBに確認を求めに183（セッションの進捗状況）応答を返します。 AとBは両方のリソース予約を開始します。 BはB->方向にリソースを予約終了したが、両方向のネットワークリソースが必要とされているので、まだユーザーに警告しません。 Aは、A-> B方向にリソースを予約終了したとき、それが更新を送信し[5] B. Bへのセッションのすべての前提条件が満たされていることを示す、UPDATE 200（OK）レスポンスを返します。この時点で、Bは、ユーザに警告を開始し、セッション確立が正常に完了します。
4 SDP parameters
4つのSDPパラメータ
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")
現在ステータス=「A = CURR：」前提条件タイプSPステータス型SP方向タグ所望のステータス=「A = DES：」前提条件タイプSP強度タグSPステータス型SP方向タグ確認ステータス= 「A = CONF：」前提条件型SPステータス型SP方向タグ前提型=「QoSの」|トークン強度タグ=（「必須」|「オプション」|「なし」= |「失敗」|「未知」）状態タイプ=（「E2E」|「ローカル」|「リモート」）方向タグ=（」なし」| "送信" | "のrecv" | "のsendrecv"）
Current status: The current status attribute carries the current status of network resources for a particular media stream.
現状：現在のステータス属性は、特定のメディアストリームのためのネットワークリソースの現在の状態を運びます。
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.
理想のステータス：希望ステータス属性特定のメディアストリームのための前提条件を運びます。特定のストリームのために与えられた前提条件タイプ/ステータスタイプの現在の状態属性の方向タグは、に等しい（又はより良い）と同じ前提条件タイプ/状態で所望の状態属性の方向タグである場合型、そのストリームのために、その後、前提条件は、そのストリームのために満たされると考えられています。
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.
確認ステータスは：確認のステータス属性は、メディアストリームのためのしきい値条件を運びます。ネットワークリソースの状態は、これらの条件に到達すると、ピア・ユーザエージェントは、この特定のメディアストリームのための更新された現在のステータス属性を含むセッション記述の更新を送信します。
Precondition type: This document defines quality of service preconditions. Extensions may define other types of preconditions.
前提条件タイプ：この文書では、サービスの前提条件の品質を定義します。拡張機能は、前提条件の他のタイプを定義することができます。
Strength tag: The strength-tag indicates whether or not the callee can be alerted, in case the network fails to meet the preconditions.
強タグ：ネットワークが前提条件を満たしていない場合には強度・タグは、呼び出し先が警告を受けることができるかどうかを示します。
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.
ステータスタイプ：エンド・エンド・ツーとセグメント化：我々は状況の二つのタイプを定義します。エンドツーエンドのステータスは、リソースのエンド・ツー・エンドの予約の状況を反映しています。セグメント化された状態では、両方のユーザエージェントのアクセスネットワークの予約の状況を反映しています。エンドツーエンドのステータスは、上記で定義されたタグ「E2E」、および「ローカル」と「リモート」タグにセグメント化された状態に相当します。エンド・ツー・エンドのリソース予約メカニズムが用意されていたときにエンドツーエンドのステータスが便利です。一方または両方のUAは、それぞれのアクセスネットワーク上のリソース予約を行う際にセグメント化された状態が便利です。
A B
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.
方向タグ：方向タグは、特定の属性（現在、所望のまたは確認状態が）にも適用可能である方向を示しています。
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.
タグの値は、「送信」、「RECV」、「ローカル」と「リモート」はSDP記述を生成するエンティティの視点を表します。プランでは、「送信」方向offerer->アンサーと「ローカル」は、オファーのアクセスネットワークです。その答えは、「送信」方向answerer->オファー側と「ローカル」である回答者のアクセス・ネットワークです。
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
M =オーディオ20000 RTP / AVP 0 A = CURR：のQoS E2Eは= DES送信：のQoSオプションE2Eが送信= DES：QOS必須E2EのRECVのM =オーディオ20002 RTP / AVP 0 A = CURR：ローカルのsendrecv A = CURRをQOS： QOS遠隔なしA = DESは：必須リモートSENDRECVをQOS：オプションのローカルのsendrecv A = DESは、QoS
5 Usage of preconditions with offer/answer
オファー/アンサーとの前提条件の5使い方
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.
両方のユーザエージェントは、「ローカルステータステーブル」と呼ばれるローカル前提条件状態を維持しなければなりません。表1および表2は、エンドツーエンドおよびセグメント化されたステータスタイプの両方のためのこれらのテーブルのフォーマットを示します。エンドツーエンドのステータスタイプのために、テーブルは2つの行を含んでいます。各方向に対して1つ（すなわち、送信及びRECV）。 「現在」フィールドで「はい」の値は、対応する方向でそのリソースの予約が成功を示しています。 「いいえ」のリソースがまだ予約されていないことを示しています。 「所望の強度」フィールドは、対応する方向における前提条件の強さを示しています。ローカルアクセスネットワーク内およびピアのアクセスネットワークにおける双方向：セグメント化された状態タイプのテーブルには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:
プランを生成する前に、オファー側は各メディアストリームのために、現在、目的のステータスでトランザクション状態テーブルを構築する必要があります。希望の状態のための強度タグの異なる値は以下の意味を持っている属性：
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オプション：ユーザー・エージェントは、リソース予約を提供しようとする必要がありますが、セッションは関係なく、この規定が可能であるかどうかの継続することができます。
o Mandatory: the user agents MUST provide resource reservation. Otherwise, session establishment MUST NOT continue.
必須O：ユーザエージェントは、リソース予約を提供しなければなりません。それ以外の場合は、セッション確立を続行してはなりません。
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に示すように、ユーザエージェントは、独立して、（送信及び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に示されるように、ユーザエージェントは、独立して、所望の状態および各方向のための現在のステータスを持つレコード（送信及びRECV）及び（ローカル及びリモート）各セグメントを生成します。
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で後述規則に従って、現在のステータスと、所望のステータスラインを生成しなければなりません。
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」と一つの電流ステータス行を生成しなければなりません。両方向のための強度タグは、トランザクション・ステータス・テーブルにおける（例えば、両方とも「必須」）等しい場合、ユーザエージェントは、タグ「のsendrecv」とつの所望のステータス行を追加しなければなりません。両方のタグが異なる場合、ユーザエージェントは、所望の2本のステータスライン、タグ「送信」とタグ「RECV」を有する他のものを含まなければなりません。
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.
同じ強度タグ、「RECV」タグと「送信」タグおよびその他を有するものと二行のセマンティクスは、一つの「SENDRECV」行と同じです。しかし、よりコンパクトな符号化を達成するために、我々は後者のフォーマットが必須にすることを選択しました。
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".
タグ「ローカル」と他のタグと「リモート」のいずれかのセグメント化の状態タイプに対して、ユーザエージェントは、二つの現在のステータスラインを生成しなければなりません。ユーザエージェント（すなわち、ローカルおよびリモートの）セグメントごとに1つのまたは2つの所望のステータス行を追加しなければなりません。 、（ローカルまたはリモート）特定のセグメントに対して、トランザクション・ステータス・テーブルにおける両方向のタグ（例えば、両方とも「必須」）等しい場合、ユーザエージェントは、タグ「のsendrecv」とつの所望のステータス行を追加しなければなりません。両方のタグが異なる場合、ユーザエージェントは、所望の2本のステータスライン、タグ「送信」とタグ「RECV」を有する他のものを含まなければなりません。
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.
上記のルールは同様に所望の強度タグ「なし」に適用されることに留意されたいです。こうすることで、サービスの品質をサポートしていますが、それらを使用する予定はありませんユーザーエージェントは、強度 - タグ「なし」との希望ステータス行を追加します。 5.2節で説明したように、このタグは、答えにアップグレードすることができますので、回答は別のオファー/アンサー交換を必要とせずにサービス予約の品質を要求することができます。
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
M =オーディオ20000 RTP / AVP 0 A = CURR：QoSのE2EなしA = DESは：QOSローカルなしA = CURR：QOS遠隔なしA = DES：QoSの必須のE2Eのsendrecv M =オーディオ20002 RTP / AVP 0 A = CURRをQOS QoSなしリモートのrecv A =デ：：のQoSなしローカルのsendrecvオプションは、リモート= DESを送信します
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.
所望の強度：私たちは、強度、タグの絶対的な順序付けを定義していない：「なし」、「オプション」および「必須」。 「必須」最高グレードと「なし」の最低グレードとタグが付けられたタグです。回答は、トランザクション状態テーブルの任意のエントリで所望の強度をアップグレードするかもしれないが、それはそれをダウングレードしてはなりません。したがって、「なし」から、「オプション」から「なし」から行をアップグレードの周りに、またはそれに「必須」、「オプション」から「必須」ではなく、他の方法には、[OK]です。
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".
現状は：すべての行については、トランザクション状態テーブルで、と回答のローカルステータステーブルで「現在」フィールドの値は、比較する必要があります。表3は、4つの可能な組み合わせを示しています。両方のフィールドが同じ値（表3の2最初の行）を持っている場合は、何も更新する必要がありません。トランザクション状態テーブルの「現在」フィールドが「Yes」、およびローカルステータステーブルのフィールドが「No」（表3の第3行）である場合、後者は「はい」に設定しなければなりません。 （トランザクション状態テーブルの「現在」フィールドが「No」である、と地元のステータステーブルのフィールドが「はい」（第4表3の行）は、アンサーは、それが地元の情報を持っているかどうかを確認する必要がある場合には例えば、リソース予約の確認は、その特定の現在のステータスに関する）受信されています。それがない場合は、トランザクション状態テーブルの「現在」フィールドが「はい」に設定されています。回答は、その現在の状態についてのローカルな情報を持っていない場合は、ローカルステータステーブルの「現在」フィールドが「いいえ」に設定しなければなりません。
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：「現在」フィールドの可能な値
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.
両方のテーブルが更新されたら、答えは、「RECV」を「送る」ことを考慮に入れて、セクション5.1.1で説明した規則に従って生成されなければならない、「ローカル」と「リモート」のタグが答えに反転させる必要があり、表4に示すように。
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.
答えが送信された時点で、トランザクション状態テーブルと回答のローカルステータステーブルには、同じ値が含まれています。したがって、この答えは、現在のステータス属性にメディア行と、所望のステータス属性で交渉さ強さと方向タグのステータスの共有ビューを含みます。
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.
使用されるリソース予約メカニズムは、両方のユーザエージェントの参加を必要とする場合、回答は解答を送信した後にリソース予約を開始すべきであり、オファー側はすぐに答えが受信されるリソース予約を開始する必要があります。ピア・ユーザエージェントの参加は（例えば、セグメント化ステータスタイプ）が必要されていない場合は、オファー側は申し出を送信する前に、リソースの予約を開始することと回答は解答を送信する前にそれを起動することがあります。
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つの連続するオファー/アンサー交換の間で変更することができます。したがって、両方のユーザエージェントは、セッションの期間を通じて現地の情報を使用して、最新の地元状態テーブルを保持する必要があります。
6 Suspending and Resuming Session Establishment
6中断と再開セッションの確立
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.)
すべての必須の前提条件が満たされるまで、前提条件との申し出を受けたユーザエージェントサーバは、ユーザに警告するべきではありません。セッション確立がその瞬間まで中断される（例えば、PSTNへシグナリングを送信せずに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.
ユーザエージェントサーバは、その中にオファーなしでINVITEリクエストを受け取ることができます。 [1]で定義された通常の手順に従って、この場合と、[5]、ユーザエージェントサーバは、信頼性の1xx応答してオファーを提供します。ユーザエージェントクライアントは、別のSIPリクエストに答えを送信する（すなわち、1xxのためのPRACK）。申し出と答えが前提条件が含まれている場合の答えでは、すべての必須の前提条件が満たされるまで、ユーザエージェントサーバは、ユーザーに警告すべきではありません。
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.
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.
一方的にそれが送信するSDP（募集または回答）で確認-status属性を含まなければならない必須の前提条件のすべてを満たすことはできないUASは（セクション7を参照します）。さらに、この確認ステータス属性を含むSDP（提供または回答）は、すぐにSIPのオファー/アンサールールで許可されたとして送らなければなりません。
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.
セッション確立が中断されている間、ユーザーエージェントは、任意のメディアストリーム上で任意のデータを送るべきではありません。 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.
ユーザエージェントサーバは、そのローカルステータステーブルが強タグ「必須」であるすべての行で「はい」の値を持つときに、すべての前提条件がメディア行のために満たされていることを知っています。セッションのすべてのメディアラインの前提条件が満たされた場合には、セッション確立が再開すべきです。
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のために、セッション確立を中断し、再開することは非常に直感的です。すべての必須の前提条件が満たされるまで、呼び出し先が警告されません。しかし、進行中のセッションの途中で送信された前提条件を含む申し出はさらなる説明を必要とします。すべての必須の前提条件が満たされるまで、両方のユーザエージェントは、古いセッションパラメータを使用し続けるべきです。その瞬間、ユーザエージェントは、新たなセッションパラメータを使用して始めることができます。第13節は、このような状況の例が含まれています。
7 Status Confirmation
7つのステータス確認
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.
確認ステータス属性は、オファーとアンサーの両方で使用されるかもしれません。この属性は、リソース予約のためのしきい値を表します。このしきい値に達するか上回っている場合には、ユーザーエージェントはすぐにSIPのオファー/アンサールールで許可されているように、メディアラインの新しい現在の状態を反映し、ピア・ユーザエージェントに提供を送らなければなりません。このしきい値は、（例えば、ネットワークは、メディアストリームのためのリソースを提供停止）再び交差されている場合は、ユーザエージェントは、すぐにSIPのオファー/アンサールールで許可されているように、同様の新しい申し出を送らなければなりません。
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.
ピアが特定のストリームに確認を要求した場合、エージェントは、ローカルステータステーブル内のフラグでそのストリームをマークしなければなりません。このフラグを持つすべての行が「YES」の「現在」値を持っている場合、ユーザーエージェントは、ピアに新しい申し出を送らなければなりません。このオファーは、現在のステータス属性にリソース予約の現在の状態が含まれます。その後、「いいえ」に、このフラグ遷移を持つ行のいずれかの場合には、新しいオファーが同様に送らなければなりません。
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.
確認属性が交渉されていません。回答は提供で確認-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).
それは、すぐにそれが両方向（SENDRECV）のためにそのアクセスネットワーク（受信したメッセージで「リモート」タグ）内のリソースを留保としてのオファーを送信します。
8 Refusing an offer
8のオファーを拒否
We define a new SIP status code:
私たちは、新しいSIPステータスコードを定義します。
Server-Error = "580" ;Precondition Failure
サーバーエラー=「580」;前提条件の失敗
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（前提条件-失敗）応答を返すことで申し出を拒否すべきです。
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（前提条件の失敗）ステータスコードを使用すると便利です。しかし、SIPは、INVITEに対する応答（1xxのかの2xx）に到着オファーを拒否するための手段を提供していません。 UACは、初期には提供せずにINVITEを生成し、許容されないの1xxまたは2xxの応答でのオファーを受け取った場合、それが正しく形成答えをこのオファーに応え、すぐにCANCELまたはBYE送るべきです。
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."
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（前提条件障害）応答とBYEとステータスが障害を引き起こし、所望のかを示す、SDP記述を含むべきである、特定の前提条件を満たすために失敗したことを示す、リクエストをキャンセルします。それはセッションの確立につながるものではないことから、このSDP記述が申し出か答えではないことに注意してください。そのような記述の形式は、SDP（オファーまたはアンサー）は、遠隔UAから受信した最後に基づいています。
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 =」行が存在しなければなりません。このSDP記述は、正確な説明は、受信された最後のSDPとして「M =」行の同じ数を含まなければなりません。すべての「M =」行のポート番号をゼロに設定しなければなりませんが、接続アドレスは任意です。
The desired status line corresponding to the precondition that triggered the failure MUST use the "failure" strength-tag, as shown in the example below:
以下の例に示すように故障を引き起こし前提条件に対応する所望のステータス行は、「失敗」強度タグを使用する必要があります。
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.
回答は、メディアストリームを拒否したい場合のオファー/アンサーモデルでは、それはゼロにそのポートを設定します。前提条件の存在は、この動作を変更しません。ストリームはまだゼロにそのポートを設定することによって拒否されます。
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.
オファー側とアンサーの両方がゼロに設定されたポートを使用してストリームに影響を与えるすべての前提条件を無視しなければなりません。彼らは、セッション確立が再開できるかどうかを決定するために考慮されていません。
9 Unknown Precondition Type
9不明な前提条件タイプ
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の」タグを定義します。将来的に定義された新しい前提条件-種類が新しい、関連するタグを持つことになります。唯一の未知の必須の前提条件は、「ローカル」タグを持っていない限り、未知の前提条件タイプを受け取るUAは、提供中の「必須」強タグで、申し出を断るしなければなりません。この場合、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に記載の規則に従うが、代わりに、タグの「失敗」：
m=audio 20000 RTP/AVP 0
a=des:foo unknown e2e send
10 Multiple Preconditions per Media Stream
メディアストリームあたり10話の複数の前提条件
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).
メディアストリームは、複数の前提条件を含むかもしれません。異なる前提条件が同じ前提型と異なるステータス・タイプ（エンドおよびサービスの前提条件のセグメント化された品質にするなど、エンド）または異なる前提条件・タイプを持っているかもしれません（この文書は唯一の「QoSの」前提条件タイプを定義していますが、拡張子は、多くの前提条件を定義することができ将来的に-types）。
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.
メディアストリームのためのすべての前提条件は、セッション確立を再開するために満たさなければなりません。次の例では、メディアストリームのエンドツーエンドの両方を使用して、セッション記述とセグメント化されたステータス・タイプを示しています。
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
11 Option Tag for Preconditions
前提条件のための11オプションタグ
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.
私たちは、必要とSupportedヘッダーフィールドで使用するためのオプションタグ「前提条件」を定義します。オファーは1つ以上の「必須」強タグが含まれている場合、オファー側はRequireヘッダーフィールドにこのタグを含まなければなりません。明細書中の全ての強度タグは「任意」または「なし」である場合、提供者は、いずれかのサポートされているヘッダーフィールドまたはRequireヘッダーフィールドにこのタグを含まなければなりません。しかしながら、Supportedヘッダフィールドは、この場合に使用することが推奨されます。答えにおける前提条件の欠如は、回答がこの拡張をサポートしていませんでしたことを示すことになります。
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メソッドをサポートしなければなりません。これにより、サポートされているヘッダフィールドの「100rel」[7]タグを含まなければなりませんし、「UPDATE」タグで許可ヘッダフィールドを含むべきである[5]。
12 Indicating Capabilities
12のインジケート機能
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。これらのラインは、以下の例に示すように、「なし」強度タグを持つ必要があります。
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ヘッダーフィールドに「前提条件」のタグを追加する必要があります。
13 Examples
13例
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は最初のオファーでのサービスの前提条件のエンド・ツー・エンドの品質を含んでいます。
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メッセージを受信しますので、それは、知ることができます。しかし、それは他の方向での予約の状況を把握していません。その答えにおけるピアユーザエージェントAへの「RECV」方向のリソース予約のためのB要求確認。
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）、それは同様にリソース予約の実行を開始します。 AがBに向けてPATHメッセージを送信しますので、どちらのUAは、RSVPを使用し、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メッセージを受信すると、それがBに更新のオファー（5）を送信します。
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がリソース予約（即ち、SENDRECV）の現在のステータスを含む応答（6）で応答します。
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
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は、再INVITE（1）でオファーを含みます。 Aは、古いIPアドレス（192.0.2.1）にメディアの受信を継続するが、同様に新しいもの（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メッセージを受信すると、それはBに更新のオファー（5）を送信します。
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は、前提条件が（現在の状態「のsendrecv）が満たされていることを示し、その答え（6）で応答それは今ではBは、新しいリモートIPアドレス（192.0.2.2）にメディアの送信を開始しています。
A B
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
mは= IP4 INオーディオ30000 RTP / AVP 0のC =は= CURRを192.0.2.4：QoSのE2E SENDRECV A = DES：必須のE2EのsendrecvをQOS
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:
図4のコールフローは、セグメント化された状態タイプを使用して、基本的なセッション確立を示します。この例のSDP記述を以下に示します。
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:
SDP1：Aは最初のオファーで、ローカルおよびリモートのQoS前提条件が含まれています。そのアクセスネットワーク内の最初のオファー、A埋蔵資源を送信する前に。これは、以下SDPのローカル現状で示されます。
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（リンギング）応答で回答を返す（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:
のは、PCMのU-lawおよび-法則（ペイロード8）の両方とは対照的に、この応答を受け取った後、Aは、（ペイロード0）、それが唯一のPCMのu-法則を使用したいと判断したと仮定しよう。これはおそらく、INVITE（5）、200（OK）を受信する前に、Bの更新を送信することになります。 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）応答が生成された後にサポートされるコーデックの数を減らすために、この最後のオファー/アンサーは、ユーザエージェントサーバに届くことがあります。これは、Aは、サポートされるコーデックの数を減らした前にセッションが確立されていることを意味します。この状況を回避するには、ユーザエージェントクライアントは、「SENDRECV」にそのローカルの現在のステータスを設定する前に、ユーザエージェントからの最初の答えを待つことができます。
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.
第（1）セッション記述を含まないINVITE。したがって、最初のオファーは、信頼性の高い183（セッションプログレス）応答にBによって送信されます。
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は最初のオファーでのサービス前提条件のエンド・ツー・エンドの品質を含んでいます。 Bは、RSVPを使用していますので、その「送信」方向のリソースが利用可能な場合には、ネットワークからRESVメッセージを受信しますので、それは、知ることができます。しかし、それは他の方向での予約の状況を把握していません。その答えにおけるピアユーザエージェントAへの「RECV」方向のリソース予約のためのB要求の確認、、。
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（セッションの進捗状況）の応答を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
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
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）は、この回答を受信すると、それは同様にリソース予約を実行開始します。 AがBに向けてPATHメッセージを送信しますので、どちらのUAは、RSVPを使用し、BはAの方にPATHメッセージを送信します
SDP3: When A receives RESV messages, it sends an updated offer (5) to B:
SDP3：AがRESVメッセージを受信すると、それがBに更新のオファー（5）を送信します。
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がリソース予約（即ち、RECV）の現在のステータスを含む応答（6）で応答します。
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（リンギング）応答を返す（7）。
14 Security Considerations
14のセキュリティの考慮事項
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つのユーザエージェントの中央のエンティティは、所望のステータスは、セッション確立が不可能に属性を追加することができます。セッションが前提条件を満たしせずに確立されるように、また、現在のステータスパラメータの内容を変更することができます。完全性保護は、これらの攻撃を回避するために使用することができます。
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.
前提条件を運んで認証されていない要求を受信すると、リソース予約を実行するエンティティは、サービス拒否攻撃のための容易なターゲットになることができます。前提条件と要求は認証されるべきです。
15 IANA Considerations
15のIANAの考慮事項
This document defines three media level SDP attributes: desired-status, current-status and conf-status. Their format is defined in Section 4.
所望のステータス、現在のステータスとCONF-ステータス：この文書では、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との前提条件を使用するためのフレームワークを定義します。それらは標準トラックRFCで公開されている場合に、このフレームワークで使用する前提条件-タイプはIANAによって登録されています。 RFCのIANA Considerations部は、出版の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前提条件タイプの名前。名前は、任意の長さであり得るが、これ以上10文字以下に長くなければなりません。
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）を定義します。 （前提条件の失敗）デフォルトの理由フレーズはセクション8で定義されています。
This document defines a SIP option tag (precondition) in section 11.
このドキュメントは、セクション11でSIPオプションタグ（前提条件）を定義します。
16 Notice Regarding Intellectual Property Rights
知的財産権に関する16お知らせ
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は、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
17 References
17の参考文献
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 2002年6月。
[5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method," RFC 3311, September 2002.
[5]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法、" RFC 3311、2002年9月。
[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.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[7]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[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.マーシャル、P.ミシュラ、D. Nortz、およびKKラマクリシュナン、 "DOSA：強力なIP電話サービスを提供するためのアーキテクチャ、" コンピュータ通信会議（IEEEインフォコム）の議事録で（テルアビブ、イスラエル）、2000年3月。
18 Contributors
18人の貢献者
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).
KKラマクリシュナン（TeraOpticネットワーク）、エド・ミラー（Terayon）、グレン・ラッセル（CableLabsに）、Burcak Beser（パシフィック・ブロードバンド・コミュニケーションズ）、マイク・Mannette（3Com社）、クルト・スタインブレナー（3Com社）、デイヴ・オラン（シスコ）、フレミングAndreasenの（シスコ） 、マイケル・Ramalho（シスコ）、ジョン・ピケンズ（COM21）、Poornima Lalwaney（ノキア）、ジョン・フェロー（カッパーマウンテンネットワーク）、ドック・エバンス（DRエバンスコンサルティング）、キース・ケリー（NetSpeak）、アダム・ローチ（dynamicsoft）、ディーン・ウィリス（ dynamicsoft）、スティーブ・ドノバン（dynamicsoft）、ヘニングSchulzrinneと（コロンビア大学）。
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年間の集大成です。特別な注意はフレミングAndreasenの、Burcak Beser、デイブ・ボードマン、ビル・Guckel、チャックKalmanek、キース・ケリー、Poornima Lalwaney、ジョンLawser、ビル・マーシャル、マイク・Mannette、デイブ・オラン、K.K.によるものですサービス前提条件の最初の「単一INVITE」品質の先頭に立っためラマクリシュナン、マイケルRamalho、アダムローチ、ジョナサン・ローゼンバーグ、およびヘニングSchulzrinneとは以前、非SIP互換で仕事、提案を「二段階招待します」。これらの「二段INVITE」の提案は、[8]今度は、AT＆Tの分散型オープンシステム・アーキテクチャ（DOSA）からの建築の要素が動作していた、PacketCableの中に分散型コールシグナリング仕事、からその起源を持っていました。
19 Acknowledgments
19の謝辞
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のプロジェクトにおける分散型コールシグナリングの仕事は、多くの異なる企業を代表する多数の人々の仕事です。著者は認識し、彼らの支援のために次のことを感謝したいと思います：ジョン・ホイーラー、モトローラ。デビッド・ボードマン、ダニエル・ポール、ARRISインタラクティブ。ビル・ブラム、ジェイストラター、ジェフOllis、クライヴHolborow、一般的な楽器。ダグNewlin、グイド・シュスター、Ikhlaqシドゥ、3Com社。ジリ・マトゥーセック、ベイネットワーク。 Farzi Khazai、ノーテル。ジョン・チャップマン、ビルGuckel、シスコ;チャックKalmanek、ダグNortz、ジョンLawser、ジェームズ・チェン、桐-ハイシャオ、Parthoミシュラ、AT＆T; Telcordia Technologies社;そしてルーセントケーブルコミュニケーションズ。
Miguel Angel Garcia-Martin, Rohan Mahy and Mark Watson provided helpful comments and suggestions.
ミゲル・アンヘル・ガルシア・マーティン、ローハンマーイとマーク・ワトソンは有益なコメントや提案を提供しました。
20 Authors' Addresses
20本の著者のアドレス
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
ゴンサロ・カマリロエリクソン高度なシグナリング研究所。 FIN-02420 Jorvasフィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Bill Marshall AT&T Florham Park, NJ 07932 USA
ビル・マーシャルAT＆Tフローラムパーク、NJ 07932 USA
EMail: wtm@research.att.com
メールアドレス：wtm@research.att.com
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA
ジョナサン・ローゼンバーグdynamicsoft 72イーグルロックアベニューイーストハノーバー、NJ 07936 USA
EMail: jdrosen@dynamicsoft.com
メールアドレス：jdrosen@dynamicsoft.com
21 Full Copyright Statement
21完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。