[要約] RFC 3312は、リソース管理とセッション開始プロトコル（SIP）の統合に関する標準化文書です。その目的は、SIPセッションのリソース管理を効果的に行うためのガイドラインを提供することです。
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)
リソース管理とセッション開始プロトコルの統合（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.
Copyright（c）The Internet Society（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.
一部のアーキテクチャでは、セッションの確立時に、Calleeが警告されると、セッションの確立の失敗の可能性が最小になることが必要です。障害の原因の1つは、セッションのネットワークリソースを予約できないことです。「ゴーストリング」を最小限に抑えるには、Calleeが警告される前にセッションのネットワークリソースを予約する必要があります。ただし、ネットワークリソースの予約には、Calleeから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.
前提条件はストリーム固有であるため、SIPヘッダーではなく、SDP説明にサービス品質の前提条件を含めることを選択しました。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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つの状態変数は、使用中の方向属性またはコーデックが他の状態を定義するのと同じように、メディアストリームの特定の状態を定義します。その結果、他のSDPメディア属性がSIP [4]で使用されるオファー/回答モデルで扱われるのと同じ方法で、これら2つの新しい変数を扱います。セッションのステータスの共有ビュー。
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におけるサービス品質の前提条件が含まれます。Aは、エンドツーエンドの両方向（SendRecv）の両方の方向（SendRecv）に予約されているネットワークリソースがあるまで、Bを警告することを望まない。Bは、Calleeを警告する前に、このセッションのネットワークリソースを予約することに同意します。bはb-> a方向のリソース予約を処理しますが、a-> b方向を処理するにはaが必要です。SOを示すために、BはA AにAにリソースの予約を開始するように依頼し、A-> Bの方向がセッションの準備ができたらすぐにBに確認するようにasに返信します。AとBは両方ともリソースの予約を開始します。Bは、B-> A方向でリソースを予約しますが、両方向のネットワークリソースが必要であるため、まだユーザーに警告しません。A-> b方向のリソースを予約すると、更新[5]をBに送信すると、更新の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")
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.
目的のステータス：目的のステータス属性には、特定のメディアストリームの前提条件が含まれます。現在のステータス属性の方向タグが、特定のストリームの特定のPrecondition-Type/Status-Typeを使用して、同じ前提条件タイプ/ステータスの目的のステータス属性の方向タグに等しい（またはそれ以上）場合-Type、そのストリームについては、そのストリームの前提条件が満たされていると見なされます。
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.
強度タグ：筋力タグは、ネットワークが前提条件を満たしていない場合に備えて、Calleeに警告できるかどうかを示します。
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」に対応し、「ローカル」と「リモート」タグにセグメント化されたステータスに対応します。エンドツーエンドのステータスは、エンドツーエンドのリソース予約メカニズムが利用可能な場合に役立ちます。セグメント化されたステータスは、片方または両方がそれぞれのアクセスネットワークでリソース予約を実行する場合に役立ちます。
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説明を生成するエンティティの視点を表します。オファーでは、「送信」は指示のオファー - >> nessurer、「ローカル」はオファーのアクセスネットワークです。回答では、「送信」はandresser-> offererの方向であり、「ローカル」はanderserのアクセスネットワークです。
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
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つのテーブルで構成されるモデルを定義します。両方のユーザーエージェントがローカルステータステーブルを実装し、各オファー/アンサーエクスチェンジにはそれに関連付けられたトランザクションステータステーブルがあります。オファーは、ローカルステータステーブルと同じトランザクションステータステーブルを生成し、オファーの回答者に送信します。Answererは、このトランザクションステータステーブルの情報を使用して、ローカルステータステーブルを更新します。また、Answererは、時代遅れのトランザクションステータステーブルフィールドを更新し、このテーブルを回答の提供者に返します。オファーは、回答で受け取った情報を使用して、ローカルステータステーブルを更新できます。このオファー/回答交換の後、両方のユーザーエージェントのローカルステータステーブルが同期されます。彼らは今、メディアストリームのステータスについて共通の見解を持っています。いくつかのメディアストリームを含むセッションは、メディアストリームごとにこれらのテーブルを実装しています。ただし、これはソフトウェアではなく、ユーザーエージェントの動作のモデルであることに注意してください。実装は、このモデルが定義する外部動作を再現するアプローチを自由に取ることができます。
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）の現在のステータス（送信および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」を使用して1つの現在のステータスラインを生成する必要があります。トランザクションステータステーブルで、両方方向の筋力タグが等しい場合（たとえば、両方の「必須」）、ユーザーエージェントはタグ「SendRecv」に1つの目的のステータスラインを追加する必要があります。両方のタグが異なる場合、ユーザーエージェントには2つの目的のステータスラインが含まれている必要があります。1つは「送信」とタグ「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.
同じ強度タグを持つ2行のセマンティクス、1つは「送信」タグを持つ「recv」タグを持つもう1つのセマンティクスは、1つの「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".
セグメント化されたステータスタイプの場合、ユーザーエージェントは2つの現在のステータスラインを生成する必要があります。1つはタグ「ローカル」、もう1つは「リモート」です。ユーザーエージェントは、1つまたは2つの目的のステータスラインごとのセグメント（つまり、ローカルおよびリモート）を追加する必要があります。特定のセグメント（ローカルまたはリモート）の場合、トランザクションステータステーブルの両方方向のタグが等しい場合（たとえば、両方の「必須」）、ユーザーエージェントはタグ「SendRecv」に1つの目的のステータスラインを追加する必要があります。両方のタグが異なる場合、ユーザーエージェントには2つの目的のステータスラインが含まれている必要があります。1つは「送信」とタグ「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
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属性を使用してトランザクションステータステーブルを再現します。Answererは、以下のルールに従って、ローカルステータスとトランザクションステータステーブルの両方を更新します。
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.
望ましい強度：筋力タグの絶対的な順序を定義します：「なし」、「オプション」、「必須」。「必須」は、最高グレードのタグ、「none」が最も低いグレードのタグです。回答者は、トランザクションステータステーブルのエントリで目的の強度をアップグレードする場合がありますが、ダウングレードしてはなりません。したがって、行を「なし」から「オプション」から「なし」から「必須」から「オプション」から「必須」から「必須」にアップグレードしても構いませんが、その逆ではありません。
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".
現在のステータス：すべての行について、トランザクションステータステーブルの「現在の」フィールドの値、およびanderserのローカルステータステーブルを比較する必要があります。表3は、4つの可能な組み合わせを示しています。両方のフィールドに同じ値（表3の最初の行）がある場合、更新する必要はありません。トランザクションステータステーブルの「現在」フィールドが「はい」であり、ローカルステータステーブルのフィールドが「いいえ」（表3の3行目）の場合、後者は「はい」に設定する必要があります。トランザクションステータステーブルの「現在の」フィールドが「いいえ」であり、ローカルステータステーブルのフィールドが「はい」（表3の4行目）の場合、回答者はローカル情報があるかどうかを確認する必要があります（例：その特定の現在のステータスについて、リソース予約の確認が受け取られました。もしそうなら、トランザクションステータステーブルの「現在」フィールドが「はい」に設定されます。回答者が現在のステータスに関するローカル情報を持っていない場合、ローカルステータステーブルの「現在の」フィールドを「いいえ」に設定する必要があります。
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.
両方のテーブルが更新されたら、セクション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.) 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.
前提条件でオファーを受け取るユーザーエージェントサーバーは、すべての必須の前提条件が満たされるまでユーザーに警告してはなりません。セッションの確立は、その瞬間まで停止されます（たとえば、PSTNゲートウェイは、PSTNに信号を送信せずにリソースを留保します。）ユーザーエージェントサーバーは、オファーなしで招待リクエストを受信する場合があります。この場合、[1]および[5]で定義された通常の手順に続いて、ユーザーエージェントサーバーは信頼できる1XX応答でオファーを提供します。ユーザーエージェントクライアントは、別のSIPリクエスト（つまり、1XXのプラック）で回答を送信します。オファーと回答に前提条件が含まれている場合、ユーザーエージェントサーバーは、回答のすべての必須の前提条件が満たされるまでユーザーに警告してはなりません。
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.
この場合、ユーザーエージェントサーバーはすべての前提条件が満たされるまでユーザーに警告できないため、前提条件を備えた初期オファーを提供するユーザーエージェントサーバーでは、前提条件を備えた180（リンギング）応答が送信されません。
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（オファーまたは回答）に確認状態属性を含める必要があります（セクション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.
最初の招待では、セッションの確立を一時停止して再開することは非常に直感的です。すべての必須の前提条件が満たされるまで、カリーは警告されません。ただし、進行中のセッションの途中に送信された前提条件を含むオファーには、さらなる説明が必要です。両方のユーザーエージェントは、すべての必須の前提条件が満たされるまで、古いセッションパラメーターを使用し続ける必要があります。その瞬間、ユーザーエージェントは新しいセッションパラメーターの使用を開始できます。セクション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.
ピアが特定のストリームで確認を要求した場合、エージェントはそのストリームをローカルステータステーブルにフラグでマークする必要があります。このフラグのあるすべての行に「はい」の「現在」の値がある場合、ユーザーエージェントはピアに新しいオファーを送信する必要があります。このオファーには、現在のステータス属性のリソース予約の現在のステータスが含まれます。後で、このフラグが「いいえ」に移行する行のいずれかの行がある場合、新しいオファーも送信する必要があります。
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.
確認属性は交渉されません。Answererは、オファーで確認ステータス属性の値を使用し、提供者はこの属性の値を回答で使用します。
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
server-error = "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.
580（前提条件の失敗）ステータスコードを使用してオファーを拒否することは、オファーが招待状または更新リクエストで提供される場合に役立ちます。ただし、SIPは、招待への応答（1xxまたは2xx）に到着するオファーを拒否する手段を提供しません。UACがオファーなしで最初の招待を生成し、受け入れられない1xxまたは2xxの応答でオファーを受け取った場合、正しく形成された回答でこのオファーに応答し、すぐにキャンセルまたは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:
オファーが再インバイトに対する1xxまたは2xxの応答である場合、同時にセッションを終了せずにそれを拒否する方法はありません。[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は、セッションの説明が、メディア形式、トランスポート、ピアからのサポートを必要とする他のパラメーターでの以前のセッションの説明と重複することを保証する必要があります。これは、ピアがセッションの説明を拒否する必要性を避けるためです。Aには受け入れられない場合、Aは有効なセッションの説明で回答を生成し、次にセッションを終了するためにさようならを送信する必要があります。」
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（前提条件の障害）応答と別々のリクエストとキャンセルは、特定の前提条件を満たしていないことを示し、SDPの説明を含める必要があり、どの希望のステータスが障害を引き起こしたかを示す必要があります。この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 =」行が必要です。この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
M =オーディオ20000 RTP/AVP 0 A = DES：QOS障害E2E送信
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
M =オーディオ20000 RTP/AVP 0 a = des：foo unknowne2e send
10 Multiple Preconditions per Media Stream
メディアストリームごとの複数の前提条件
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」前処理タイプのみを定義しますが、拡張はより前提条件を定義する場合があります。 - 将来のタイプ）。
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.
要求およびサポートされているヘッダーフィールドで使用するためのオプションタグ「Precondition」を定義します。オファーに1つ以上の「必須の」筋力タグが含まれている場合、オファーはこのタグを要求ヘッダーフィールドに含める必要があります。説明内のすべての筋力タグが「オプション」または「なし」である場合、提供者はこのタグをサポートされているヘッダーフィールドまたは要求ヘッダーフィールドのいずれかに含める必要があります。ただし、この場合、サポートされているヘッダーフィールドを使用することをお勧めします。答えに前提条件が不足しているため、回答者がこの拡張機能をサポートしていないことを示しています。
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の前提条件を含むユーザーエージェントは、プラックと更新方法をサポートする必要があります。したがって、サポートされているヘッダーフィールドに「100Rel」[7]タグを含める必要があり、「更新」タグ[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]は、機能を示すセッション説明の形式を説明しています。この形式は、オプションリクエストへの応答で使用されます。前提条件をサポートする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は、オプションリクエストに対する応答のサポートされているヘッダーフィールドに「前処理」タグを追加する必要があります。
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メッセージを受信するため、「送信」方向のリソースがいつ利用できるかを知ることができます。ただし、他の方向の予約のステータスはわかりません。b回答では、ピアユーザーエージェントAへの「Recv」方向にリソース予約の確認を要求します。
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はメディアストリームのネットワークリソースの予約を開始します。この回答（2）を受け取ると、リソースの予約も開始します。両方のUASがRSVPを使用するため、AはBに向かってパスメッセージを送信し、BはAにパスメッセージを送信します。
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：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は、リソース予約の現在のステータス（つまり、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.
セッションの途中で、メディアを受信している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）でメディアを受け取り続けていますが、新しいメディア（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：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
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には、初期オファーにローカルおよびリモートQoSの前提条件が含まれます。最初のオファーを送信する前に、アクセスネットワークにリソースを予約します。これは、以下の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とA-Law（ペイロード8）の両方ではなく、PCM U-Law（ペイロード0）のみを使用したいと判断したと仮定します。おそらく招待（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はこのオファーの回答を生成し、更新のために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）にはセッションの説明が含まれていません。したがって、最初のオファーはBによって信頼できる183（セッションの進行状況）応答で送信されます。
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メッセージを受信するため、「送信」方向のリソースがいつ利用できるかを知ることができます。ただし、他の方向の予約のステータスはわかりません。b回答では、ピアユーザーエージェントAに「Recv」方向のリソース予約の確認を要求します。
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（セッションの進行状況）応答のプラックにその答えを含めます。
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.
回答を送信した後、メディアストリームのネットワークリソースの予約を開始します。Bがこの回答（3）を受け取ると、リソースの予約も開始します。両方のUASがRSVPを使用するため、AはBに向かってパスメッセージを送信し、BはAにパスメッセージを送信します。
SDP3: When A receives RESV messages, it sends an updated offer (5) to B:
SDP3：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は、リソース予約の現在のステータス（つまり、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.
このドキュメントは、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で前提条件を使用するためのフレームワークを定義します。このフレームワークで使用される前処理タイプは、標準トラックRFCSで公開されている場合、IANAによって登録されます。RFCのIANAに関する考慮事項セクションには、IANAレジストリに表示されるRFC番号とともに、次の情報を含める必要があります。
o Name of the precondition-type. The name MAY be of any length, but SHOULD be no more than ten characters long.
o Precondition-Typeの名前。名前は任意の長さかもしれませんが、長さ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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Handley、M。and 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method," RFC 3311, September 2002.
[5] Rosenberg、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.、Frederick、R。and 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] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[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、およびK. K. Ramakrishnan、「Dosa：堅牢なIPテレフォニーサービスを提供するためのアーキテクチャ」、コンピューターコミュニケーションに関する会議（IEEE Infocom）の議事録（Tel Aviv、イスラエル）、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).
K. K.ラマクリシュナン（テラオプティックネットワーク）、エドミラー（テラヨン）、グレンラッセル（ケイブルラブ）、ブルカックベザー（パシフィックブロードバンドコミュニケーションズ）、マイクマンネット（3COM）、カートスタインブレンナー（3COM）、デイブオラン（Cisco）、flemmis andreasen（cisco）、マイケル・ラマルホ（シスコ）、ジョン・ピケンズ（COM21）、ポルニマ・ラルワニー（ノキア）、ジョン・フェロー（コッパーマウンテンネットワーク）、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].
この「多くの人々」文書は、多くの個人による2年以上の仕事の集大成であり、ほとんどはここにリストされ、次の謝辞セクションに記載されています。特別なメモは、フレミング・アンドレアセン、ブルカック・ベザー、デイブ・ボードマン、ビル・ガッケル、チャック・カルマネク、キース・ケリー、ポルニマ・ラルワニー、ジョン・ローサー、ビル・マーシャル、マイク・マネット、デイブ・オラン、K.K。Ramakrishnan、Michael Ramalho、Adam Roach、Jonathan Rosenberg、およびHenning Schulzrinneは、以前の非SIP互換性のある「2段階の「2段階の招待」の提案からの最初の「シングル招待品質」サービスの前提条件の先頭に立っています。これらの「2段階の招待状」提案は、Packetcableの分散コールシグナリング作業からの起源を持ち、AT＆Tの分散オープンシステムアーキテクチャ（DOSA）作業からのアーキテクチャ要素がありました[8]。
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プロジェクトでの分散コールシグナリング作業は、多くの人々の仕事であり、多くの異なる企業を代表しています。著者は、以下に支援を認識し、感謝したいと思います。ジョン・ウィーラー、モトローラ。デビッドボードマン、ダニエルポール、アリスインタラクティブ。ビル・ブルム、ジェイ・ストラター、ジェフ・オリス、クライヴ・ホルボロー、一般的な楽器。Doug Newlin、Guido Schuster、Ikhlaq Sidhu、3com;Jiri Matousek、ベイネットワーク。Farzi Khazai、ノルテル;ジョン・チャップマン、ビル・ガッケル、シスコ。Chuck Kalmanek、Doug Nortz、John Lawer、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.
ミゲル・エンジェル・ガルシア・マルティン、ロハン・マヒー、マーク・ワトソンは、有益なコメントと提案を提供しました。
20 Authors' Addresses
20人の著者の住所
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
Gonzalo Camarillo Ericsson Advanced Signaling Research Lab。Fin-02420 Jorvas Finland
EMail: Gonzalo.Camarillo@ericsson.com
Bill Marshall AT&T Florham Park, NJ 07932 USA
ビルマーシャルAT＆Tフローハムパーク、ニュージャージー07932 USA
EMail: wtm@research.att.com
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA
ジョナサンローゼンバーグダイナミクスソフト72イーグルロックアベニューイーストハノーバー、ニュージャージー07936 USA
EMail: jdrosen@dynamicsoft.com
21 Full Copyright Statement
21完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。