RFC3312 日本語訳
3312 Integration of Resource Management and Session InitiationProtocol (SIP). G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg. October 2002. (Format: TXT=65757, PS=655218, PDF=130391 bytes) (Updated by RFC4032, RFC5027) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Camarillo, Ed.
Request for Comments: 3312 Ericsson
Category: Standards Track W. Marshall, Ed.
AT&T
J. Rosenberg
dynamicsoft
October 2002
ワーキンググループG.キャマリロ、エドをネットワークでつないでください。コメントのために以下を要求してください。 3312年のエリクソンカテゴリ: エド規格Track W.マーシャル、AT&T J.ローゼンバーグdynamicsoft2002年10月
Integration of Resource Management
and Session Initiation Protocol (SIP)
資源管理とセッション開始プロトコルの統合(一口)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document defines a generic framework for preconditions, which are extensible through IANA registration. This document also discusses how network quality of service can be made a precondition for establishment of sessions initiated by the Session Initiation Protocol (SIP). These preconditions require that the participant reserve network resources before continuing with the session. We do not define new quality of service reservation mechanisms; these preconditions simply require a participant to use existing resource reservation mechanisms before beginning the session.
このドキュメントは前提条件のためにジェネリックフレームワークを定義します。(前提条件はIANA登録で広げることができます)。 また、このドキュメントはネットワークサービスの質がどう作られていて、セッションの設立のための前提条件がSession Initiationで、プロトコル(SIP)を開始したということであるかもしれないかについて議論します。 これらの前提条件は、セッションを続行する前に関係者がネットワーク資源を予約するのを必要とします。 私たちは新しいサービスの質予約メカニズムを定義しません。 これらの前提条件は、セッションを始める前に関係者が既存の資源予約メカニズムを使用するのを単に必要とします。
Camarillo, et. al. Standards Track [Page 1] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[1ページ]。
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つの序論… 2 2用語… 3 3概要… 3 4のSDPパラメタ… 申し出/答えがある前提条件の4 5用法… 7 5.1 申し出を生成します… 8 5.1 .1 SDPコード化… 9 5.2 答えを生成します… 10 6 セッション設立を中断して、再開します… 11 7 状態確認… 12 8 申し出を断ります… 13 8.1 メディアストリームを拒絶します… 14 9 未知の前提条件タイプ… 15 10倍数はメディアストリーム単位であらかじめ調整されます… 前提条件のための15 11オプションタグ… 16 12の表示能力… 16 13の例… 16 13.1 終わりから完了状態へのタイプ… 17 13.2は状態タイプを区分しました… 21 13.3 SIP応答では、提供します。 23 14のセキュリティ問題… 26 15のIANA問題… 26 16に知的所有権に関して気付きます… 27 17の参照箇所… 27 18人の貢献者… 28 19の承認… 28 20人の作者のアドレス… 29 21の完全な著作権宣言文… 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.
いくつかのアーキテクチャが、セッション設立時間に訪問される人がいったん警告されるとセッション設立失敗の機会が最小であることを必要とします。 失敗の1つの源はセッションのためのネットワーク資源を予約できないことです。 「幽霊リング」を最小にするために、訪問される人が警告される前のセッションのためのネットワーク資源を予約するのが必要です。 しかしながら、ネットワーク資源の予約は、頻繁に訪問される人からIPアドレス、ポート、およびセッションパラメタを学ぶのを必要とします。 SIPで運ばれた初期の申し出/答え交換の結果、この情報を得ます。 通常、この交換は「リングへの電話」を引き起こして、その結果、因果関係の分からない問題を紹介します: 初期の申し出/答え交換を実行しないで、リソースを予約できません、そして、資源予約を実行しないで、初期の申し出/答え交換ができません。
Camarillo, et. al. Standards Track [Page 2] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[2ページ]。
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.
ソリューションは前提条件の概念を紹介することです。 前提条件は申し出で導入される1セットのセッションに関する規制です。 申し出の受取人は、答えを生成しますが、ユーザを警告もしませんし、そうでなければ、セッション設立を続けもしません。 前提条件が満たされるときだけ、それは起こります。 ローカルイベント(資源予約の確認などの)を通して、または、訪問者によって送られた新しい申し出を通してこれを知ることができます。
This document deals with sessions that use SIP [1] as a signalling protocol and SDP [2] to describe the parameters of the session.
このドキュメントはセッションのパラメタについて説明するのに合図プロトコルとSDP[2]としてSIP[1]を使用するセッションに対処します。
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[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)で必要な状態=リソースが中で予約した方向を予約した、方向を送ってください。
Camarillo, et. al. Standards Track [Page 3] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[3ページ]。
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つの新しい変数を扱います: 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は初期のINVITEのSDPのサービスの質前提条件を含んでいます。 終わるために(sendrecvに)終わっている両方の方向への予約されたネットワーク資源があるまで、AはBを警告して欲しくはありません。 Bは、訪問される人を警告する前にこのセッションのためのネットワーク資源を予約するのに同意します。 Bは、B>A方向に資源予約を扱いますが、A>B方向を扱うためにAを必要とします。 したがって、Bがセッションのために資源予約を始めて、方向が準備ができているとA>Bの次第Bに確認するようにAに頼むAへの183(セッションProgress)応答を返すのを示すために。 AとBはともに資源予約を始めます。 Bは、B>A方向によるリソースを予約し終えますが、まだユーザを警告していません、両方の方向へのネットワーク資源が必要であるので。 Aが、A>B方向によるリソースを予約し終えると、BがUPDATEのために200(OK)応答を返すB.にUPDATE[5]を送ります、セッションのためのすべての前提条件を満たしてあるのを示して。 この時点で、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.
現在の状態: 現在の状態属性は特定のメディアストリームのためにネットワーク資源の現在の状態を運びます。
Camarillo, et. al. Standards Track [Page 4] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[4ページ]。
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.
状態タイプ: 私たちは2つのタイプの状態を定義します: 終わるために終わって区分されています。 終わりから完了状態は終わりから終わりへのリソースの予約の状態を反映します。 区分された状態は両方のユーザエージェントのアクセスネットワークの予約の状態を反映します。 終わりから完了状態は上で定義されたタグ"e2e"とタグへの区分された状態に「地方」で「リモートな」状態で対応しています。 終わりから終わりへの資源予約メカニズムが利用可能であるときに、終わりから完了状態は役に立ちます。 1かUAsの両方がそれらのそれぞれのアクセスネットワークの資源予約を実行するとき、区分された状態は役に立ちます。
Camarillo, et. al. Standards Track [Page 5] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[5ページ]。
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----------------->|
| |
| |
| | |-------------(1) SDP1を招待してください。--------------->|、|、| | <、-、-、-、-、--(2) 183 セッション進歩SDP2--------| | *** *** | |--*R*-----------(3) PRACK-------------*R*-->|、| *E**E*| | <、-*S*-------(4) 200OK(PRACK)--------*S*---| | *E**E*| | *R**R*| | *V**V*| | ***は*です。| | *T**T*| | *I**I*| | *○ **O*| | *N**N*| | *** *** | | *** | | *** | |-------------(5) アップデートSDP3--------------->|、|、| | <、-、-、-、-、-、-、--(6) 200 OK(アップデート)SDP4-----------| | | | <、-、-、-、-、-、-、-、-、-、-、-、--(7) 180 鳴ること---------------| | | |-----------------(8) PRACK----------------->|、|、| | <、-、-、-、-、-、-、-、-、-、-、--(9) 200OK(PRACK)-------------| | | | | | | | <、-、-、-、-、-、-、-、-、-、--(10) 200OK(招待します)------------| | | |------------------(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.
方向タグ: 方向タグは適切な状態で特定の属性(電流、必要であるか確認状態)がある方向を示します。
Camarillo, et. al. Standards Track [Page 6] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[6ページ]。
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記述を生成する実体の観点を表します。 「発信してください」による方向申出人>answererで「地方」が申出人のアクセスネットワークであるという申し出では、ことです。 答えでは、「発信してください」は方向の、よりanswererな>の申出人です、そして、「ローカル」は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
RTP/AVP0a=curr: qos e2eがa=des: qosの任意のe2eを送るオーディオのm=20000は0a=curr: qosの地方のsendrecv a=curr: a=desのqosのリモートでないどれか: qosの任意の地方のsendrecv a=des: qosの義務的なリモートsendrecvをオーディオの20002a=des: qos義務的なe2e recv m=RTP/AVPに送ります。
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は、地方の状態テーブルをアップデートするのにこのトランザクション状態テーブルの情報を使用します。 answererはまた、時代遅れであったトランザクション状態テーブル分野をアップデートして、答えでこのテーブルを申出人に返します。 そして、申出人は答えで情報を受け取っていて地方の状態テーブルをアップデートできます。 この後、申し出/答え交換、両方のユーザエージェントの地方の状態テーブルはそうです。連動しました。 彼らには、現在、メディアストリームの状態の共通認識があります。 いくつかのメディアストリームにかかわるセッションがこれらのメディアストリームあたりのテーブルを実装します。 しかしながら、これがソフトウェアではなく、ユーザエージェントの振舞いのモデルであることに注意してください。 実装は自由にこのモデルが定義する外部の振舞いを模写するどんなアプローチも取ることができます。
Camarillo, et. al. Standards Track [Page 7] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[7ページ]。
5.1 Generating an offer
5.1 申し出を生成すること。
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つの行を含んでいます。 各方向(すなわち、発信して、recvする)あたり1つ。 「現在」の分野の「はい」の値は対応する方向へのそのリソースのうまくいっている予約について簡単に述べます。 「いいえ」は、リソースがまだ予約されていないのを示します。 「必要な強さ」分野は対応する方向への前提条件の強さを示します。 区分された状態タイプのためのテーブルは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 任意: ユーザエージェントSHOULDは資源予約を提供しようとしますが、この支給が可能であるかどうかにかかわらずセッションは続くことができます。
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:
そして、申出人は、それが終わりから完了状態へのタイプか区分された状態タイプを使用するだろうかどうか決めます。 メディア系列の状態タイプが終わらせる終わりになるなら、ユーザエージェントは必要な状態と現在の状態で独自に各方向(送って、recvする)に記録を生成します、テーブル1に示されるように:
Direction Current Desired Strength
____________________________________
send no mandatory
recv no mandatory
方向の現在の必要な強さ____________________________________ 義務的でなくどんな義務的なrecvも送らないでください。
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:
メディア系列の状態タイプが区分されるなら、ユーザエージェントは各方向(送って、recvする)と各セグメント(地方の、そして、リモートな)のために必要な状態と現在の状態で独自に記録を生成します、テーブル2に示されるように:
Camarillo, et. al. Standards Track [Page 8] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[8ページ]。
Direction Current Desired Strength
______________________________________
local send no none
local recv no none
remote send no optional
remote recv no none
方向の現在の必要な強さ______________________________________ ローカルはいいえをなにもにどんな任意のリモートrecvノーもリモートであるなにも送らないいいえに地方であることのなにもrecvしない送ります。
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で説明された規則に従って。
5.1.1 SDP encoding
5.1.1 SDPコード化
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"に従った、ある必要な状況表示行を加えなければなりません。 両方のタグが異なるなら、ユーザエージェントが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つの"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か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で説明されるように答えでアップグレードできるので、answererは別の申し出/答え交換の必要性なしでサービスの質の予約を要求できます。
Camarillo, et. al. Standards Track [Page 9] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[9ページ]。
The example below shows the SDP corresponding to tables 1 and 2.
ショーテーブル1に対応するSDPと2の下における例
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=オーディオの20000RTP/AVP0a=curr: qos e2e、=オーディオの20002RTP/AVP0a=curr: a=currのqosの地方でないどれか: a=desのqosのリモートでないどれか: a=desのいずれも:でない qos義務的なe2e sendrecv m qos、任意である、リモートである、recv a=des:地方であることのqosなにもsendrecvしないリモートであるなにもa=des: qosに送らないでください。
5.2 Generating an Answer
5.2 答えを生成すること。
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:
answererが申し出を受けるとき、それは、申し出に含まれた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.
必要な強さ: 私たちは強さタグのための絶対注文を定義します: 「なにも」、「任意で」「義務的」。 「義務的」は最上級があるタグであり、「なにも」は最も低いグレードがあるタグです。 answererはトランザクション状態テーブルのどんなエントリーでも必要な強さをアップグレードさせるかもしれませんが、それはそれを格下げしてはいけません。 したがって、行を「なにも」から「任意になる」までアップグレードさせるのは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".
現在の状態: 比べて、あらゆる行、トランザクション状態テーブル、およびanswererの地方の状態テーブルの「現在」の分野の値がそうしなければならないので。 テーブル3は4つの可能な組み合わせを示しています。 両方の分野に同じ値(2つのファースト・ローのテーブル3)があるなら、何も、アップデートする必要がありません。 トランザクション状態テーブルの「現在」の分野が「はい」であり、地方の状態テーブルの分野が「いいえ」(テーブル3の3番目の行)であるなら、「はい」に後者を設定しなければなりません。 トランザクション状態テーブルの「現在」の分野が「いいえ」であり、地方の状態テーブルの分野が「はい」(先へ、テーブル3は船をこぐ)であるなら、answererは、その特定の現在の状態の周りでそれでローカルの情報があるかどうか(例えば資源予約の確認を受け取りました)チェックする必要があります。 それがそうするなら、トランザクション状態テーブルの「現在」の分野は「はい」に設定されます。 answererにその現在の状態のローカルの情報がないなら、地方の状態テーブルの「現在」の分野を「いいえ」に設定しなければなりません。
Camarillo, et. al. Standards Track [Page 10] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[10ページ]。
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
Transac状態テーブルLocal状態テーブルNewは地方でtransac/を評価します。____________________________________________________________________ いいえ/いいえ、はいはいはい/はいのはいノーない、はい/、はい、はいは全くローカルのインフォメーションによりません。
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で説明される約束を守るのを答えに生成しなければなりません、「発信してください」、「地方」の、そして、「リモートな」タグがそうしなければならない"recv"が答えで逆にされるのを考慮に入れて、テーブル4に示されるように。
Offer Answer
______________
send recv
recv send
local remote
remote local
申し出答え______________ 発信、recv recvは地元のリモートリモートローカルを送ります。
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.
答えを送るとき、トランザクション状態テーブルとanswererの地方の状態テーブルは同じ値を含んでいます。 したがって、この答えは必要な状態属性に交渉された現在の状態属性におけるメディア系列の状態の共有された視点、強さ、および方向タグを含んでいます。
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.
使用される資源予約メカニズムが両方のユーザエージェントの参加を必要とするなら、答えを送った後にanswerer SHOULDは資源予約を始めます、そして、答えが受け取られているとすぐに、申出人SHOULDは資源予約を始めます。 同輩ユーザエージェントの参加は必要でないなら(例えば、状態タイプを区分します)、申し出とanswererを送ると答えを送る前に始まるかもしれない前に申出人は資源予約を始めるかもしれません。
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.)
すべての義務的な前提条件が満たされるまでSHOULD NOTがユーザに警告する前提条件で申し出を受けるユーザエージェントサーバ。 セッション設立はそれまで中断します。(PSTNに合図しながら発信しないで、例えば、PSTNゲートウェイはリソースを予約します。)
Camarillo, et. al. Standards Track [Page 11] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[11ページ]。
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)における答えを送るでしょう。 申し出と答えが前提条件を含んでいるなら、答えにおけるすべての義務的な前提条件が満たされるまで、ユーザエージェントサーバSHOULD NOTはユーザを警告します。
Note that in this case, a user agent server providing an
initial offer with preconditions, a 180 (Ringing) response with
preconditions will never be sent, since the user agent server
cannot alert the user until all the preconditions are met.
この場合前提条件、前提条件がある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を見てください)。 さらに、できるだけ早くSIP申し出/答え規則でこの状態を確認している属性を含むSDP(提供するか、または答える)を送らなければなりません。
While session establishment is suspended, user agents SHOULD not send any data over any media stream. In the case of RTP [6], neither RTP nor RTCP packets are sent.
セッション設立が吊している間、ユーザエージェントSHOULDはどんなメディアストリームの上にも少しのデータも送りません。 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.
ユーザエージェントサーバは、地方の状態テーブルに強さタグが「義務的である」すべての行の「はい」の値があるとすべての前提条件がメディア系列のために満たされるのを知っています。 セッションのすべてのメディア系列の前提条件が満たされるとき、セッション設立SHOULDは再開します。
For an initial INVITE, suspending and resuming session establishment is very intuitive. The callee will not be alerted until all the mandatory preconditions are met. However, offers containing preconditions sent in the middle of an ongoing session need further explanation. Both user agents SHOULD continue using the old session parameters until all the mandatory preconditions are met. At that moment, the user agents can begin using the new session parameters. Section 13 contains an example of this situation.
初期のINVITEに関しては、セッション設立を中断して、再開するのは非常に直感的です。 すべての義務的な前提条件が満たされるまで、訪問される人は警告されないでしょう。 しかしながら、進行中のセッションの途中で送られた前提条件を含む申し出が詳細な説明を必要とします。 ユーザエージェントSHOULDは、すべての義務的な前提条件が満たされるまでともに、古いセッションパラメタを使用し続けています。 その瞬間に、ユーザエージェントは、新しいセッションパラメタを使用し始めることができます。 セクション13はこの状況に関する例を含みます。
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申し出/答え規則で。
Camarillo, et. al. Standards Track [Page 12] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[12ページ]。
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
m=オーディオの20002RTP/AVP0a=curr: a=currのqosの地方でないどれか: a=desのqosのリモートでないどれか: qosの義務的な地方のsendrecv a=des: qosの義務的なリモートsendrecv a=conf: qosのリモート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、answererとしての芝居がそうすることができない、望んでいない、SHOULDは、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(前提条件Failure)ステータスコードを使用するのは役に立ちます。 しかしながら、SIPは応答に到達する申し出(1xxか2xx)をINVITEに拒否する手段を提供しません。 UACは申し出なしで初期のINVITEを生成して、1xxの申し出か許容できない2xx応答を受けます、それ。SHOULDは正しく形成された答えでこの申し出に応じて、すぐに、キャンセルかBYEを送ります。
Camarillo, et. al. Standards Track [Page 13] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[13ページ]。
If the offer comes in a 1xx or 2xx response to a re-INVITE, A would not have a way to reject it without terminating the session at the same time. The same recommendation given in Section 15.2 of [1] applies here:
申し出が再INVITEへの1xxか2xx応答に入るなら、Aには、同時にセッションを終えないでそれを拒絶する方法がないでしょう。 [1]のセクション15.2で与えられた同じ推薦はここに適用されます:
"The UAS MUST ensure that the session description overlaps with
its previous session description in media formats, transports,
other parameters that require support from the peer. This is
to avoid the need for the peer to reject the session
description. If, however, it is unacceptable to A, A SHOULD
generate an answer with a valid session description, and then
send a BYE to terminate the session."
「UAS MUSTは、セッション記述がメディア形式、輸送、同輩から支持を要する他のパラメタにおける前のセッション記述に重なるのを確実にします。」 これは、同輩がセッション記述を拒絶する必要性を避けるためのものです。 「しかしながら、それがAに容認できないなら、A SHOULDは有効なセッション記述で答えを生成して、次に、セッションを終えるためにBYEを送ります。」
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 (前提条件Failure)の応答、BYE、およびキャンセル要求、ある前提条件を満たさないことを示して、SHOULDは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はオーディオの20000RTP/AVP0a=desと等しいです: qosの故障e2eは発信します。
8.1 Rejecting a Media Stream
8.1 メディアストリームを拒絶すること。
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.
answererがメディアストリームを拒絶したがっているとき、申し出/答えモデルでは、それはゼロにポートを設定します。 前提条件の存在はこのふるまいを変えません。 ストリームは、それらのポートをゼロに設定することによって、まだ拒絶されています。
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.
申出人とanswererの両方がポートセットでストリームに影響するすべての前提条件をゼロまで無視しなければなりません。 それらは、セッション設立が再開できるかどうか決めるために考慮に入れられません。
Camarillo, et. al. Standards Track [Page 14] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[14ページ]。
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はオーディオの20000RTP/AVP0a=desと等しいです: fooの未知のe2eは発信します。
10 Multiple Preconditions per Media Stream
10 複数の1メディアあたりの前提条件が流れます。
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
m=オーディオの20000RTP/AVP0a=curr: a=currのqosの地方でないどれか: a=desのqosのリモートでないどれか: qosの義務的な地方のsendrecv a=des: qosの義務的なリモートsendrecv a=curr: qos e2e、a=desのいずれも:でない qosの任意のe2e sendrecv
Camarillo, et. al. Standards Track [Page 15] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[15ページ]。
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.
私たちはRequireとSupportedヘッダーフィールドにおける使用のためにオプションタグ「前提条件」を定義します。 申し出が1個以上の「義務的な」強さタグを含むなら、申出人はRequireヘッダーフィールドでこのタグを入れなければなりません。 記述におけるすべての強さタグが「任意である」か、または「なにも」、申出人が任意でなければならないなら、SupportedヘッダーフィールドかRequireヘッダーフィールドでこのタグを含めてください。 しかしながら、Supportedヘッダーフィールドがこの場合使用されるのは、RECOMMENDEDです。 答えにおける、前提条件の不足は、answererがこの拡大をサポートしなかったのを示すでしょう。
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].
[5]で与えられた規則に従って、SIP要求と応答の申し出と答えに関するマッピングは実行されます。 したがって、SDP MUSTの前提条件がPRACKとUPDATEメソッドをサポートするユーザエージェント包含。 その結果、Supportedヘッダーフィールドに"100rel"[7]タグを含まなければなりません、そして、SHOULDは「アップデート」タグ[5]があるAllowヘッダーフィールドを含んでいます。
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要求への応答に使用されます。 SHOULDが加える前提条件をサポートするUAはそれぞれのメディアストリームのためにサポートされた前提条件タイプを示す状況表示行を望んでいました。 これらの系列には、「なにも」強さタグが以下の例に示されるようになければなりません:
m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=des:foo none e2e sendrecv
a=des:qos none local sendrecv
オーディオの0RTP/AVP0m=a=rtpmap: 0PCMU/8000a=des: e2e sendrecv a=desのfooでないどれか: 地方であることのなにもsendrecvしないqos
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.
OPTIONS要求への応答のSupportedヘッダーフィールドへの「前提条件」タグをSHOULDが加えるこのフレームワークに支えるUA。
13 Examples
13の例
The following examples cover both status types; end-to-end and segmented.
以下の例は両方の状態タイプをカバーしています。 終わるために終わって区分されています。
Camarillo, et. al. Standards Track [Page 16] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[16ページ]。
13.1 End-to-end Status Type
13.1 終わりから完了状態へのタイプ
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
mがオーディオの20000RTP/AVPと等しい、0、c、=IN IP4 192.0.2.1a=curr: qos e2e、a=desのいずれも:でない qosの義務的な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
mがオーディオの30000RTP/AVPと等しい、0、c、=IN IP4 192.0.2.4a=curr: qos e2e、a=desのいずれも:でない qosの義務的な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)を受けるとき、それはまた、資源予約を実行し始めます。 両方のUAsはRSVPを使用します、そして、したがって、AはBに向かったメッセージをPATHに送ります、そして、BはAに向かったメッセージをPATHに送ります。
As time passes, B receives RESV messages confirming the reservation. However, B waits until resources in the other direction are reserved as well, since it did not receive any confirmation and the preconditions still have not been met.
時間が経過するとき、Bは、予約を確認しながら、RESVメッセージを受け取ります。 しかしながら、また、もう片方の方向によるリソースが予約されるまで、Bは待っています、少しの確認も受け取らないで、また前提条件がまだ満たされていないので。
SDP3: When A receives RESV messages, it sends an updated offer (5) to B:
SDP3: AがRESVメッセージを受け取るとき、アップデートされた申し出(5)をBに送ります:
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
mがオーディオの20000RTP/AVPと等しい、0、c、.1a=curr: qos e2eがa=des: qosに義務的なe2e sendrecvを送る=IN IP4 192.0.2
Camarillo, et. al. Standards Track [Page 17] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[17ページ]。
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
m=オーディオ30000RTP/AVP0c=IN IP4 192.0.2.4のa=curr:qos e2e sendrecv a=des:qosの義務的なe2e sendrecv
At this point in time, session establishment resumes and B returns a 180 (Ringing) response (7).
この時点で、セッション設立履歴書とBは180(鳴る)応答(7)を返します。
Camarillo, et. al. Standards Track [Page 18] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[18ページ]。
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----------------->|
| |
| |
| | |-------------(1) SDP1を招待してください。--------------->|、|、| | <、-、-、-、-、--(2) 183 セッション進歩SDP2--------| | *** *** | |--*R*-----------(3) PRACK-------------*R*-->|、| *E**E*| | <、-*S*-------(4) 200OK(PRACK)--------*S*---| | *E**E*| | *R**R*| | *V**V*| | ***は*です。| | *T**T*| | *I**I*| | *○ **O*| | *N**N*| | *** *** | | *** | | *** | |-------------(5) アップデートSDP3--------------->|、|、| | <、-、-、-、-、-、-、--(6) 200 OK(アップデート)SDP4-----------| | | | <、-、-、-、-、-、-、-、-、-、-、-、--(7) 180 鳴ること---------------| | | |-----------------(8) PRACK----------------->|、|、| | <、-、-、-、-、-、-、-、-、-、-、--(9) 200OK(PRACK)-------------| | | | | | | | <、-、-、-、-、-、-、-、-、-、--(10) 200OK(招待します)------------| | | |------------------(11) ACK----------------->|、|、|、|、|
Figure 2: Example using the end-to-end status type
図2: 終わりから完了状態へのタイプを使用する例
Camarillo, et. al. Standards Track [Page 19] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[19ページ]。
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
mがオーディオの20000RTP/AVPと等しい、0、c、=IN IP4 192.0.2.2a=curr: qos e2e、a=desのいずれも:でない qosの義務的な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
mがオーディオの30000RTP/AVPと等しい、0、c、=IN IP4 192.0.2.4a=curr: qos e2e、a=desのいずれも:でない qosの義務的なe2e sendrecv a=conf: qos e2e recv
SDP3: When A receives RESV messages it sends an updated offer (5) to B:
SDP3: AがRESVメッセージを受け取るとき、アップデートされた申し出(5)をBに送ります:
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
mがオーディオの20000RTP/AVPと等しい、0、c、.2a=curr: qos e2eがa=des: qosに義務的なe2e sendrecvを送る=IN IP4 192.0.2
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)。
Camarillo, et. al. Standards Track [Page 20] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[20ページ]。
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------------------>|
| |
| |
| | |-------------(1) SDP1を招待してください。--------------->|、|、| | <、-、-、-、-、--(2) 183 セッション進歩SDP2--------| | *** *** | |--*R*-----------(3) PRACK-------------*R*-->|、| *E**E*| | <、-*S*-------(4) 200OK(PRACK)--------*S*---| | *E**E*| | *R**R*| | *V**V*| | ***は*です。| | *T**T*| | *I**I*| | *○ **O*| | *N**N*| | *** *** | | *** | | *** | |-------------(5) アップデートSDP3--------------->|、|、| | <、-、-、-、-、-、-、--(6) 200 OK(アップデート)SDP4-----------| | | | <、-、-、-、-、-、-、-、-、-、--(7) 200OK(招待します)-------------| | | |------------------(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=オーディオ30000RTP/AVP0c=IN IP4 192.0.2.4のa=curr:qos e2e sendrecv a=des:qosの義務的なe2e sendrecv
13.2 Segmented Status Type
13.2 区分された状態タイプ
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記述は以下に示されます:
Camarillo, et. al. Standards Track [Page 21] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[21ページ]。
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
mがオーディオの20000RTP/AVPと等しい、0 8、c、=IN IP4 192.0.2.1a=curr: qosの地方のsendrecv a=curr: a=desのqosのリモートでないどれか: qosの義務的な地方のsendrecv a=des: qosの義務的なリモート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
mがオーディオの30000RTP/AVPと等しい、0 8、c、=IN IP4 192.0.2.4a=curr: qosの地方のsendrecv a=curr: qosのリモートsendrecv a=des: qosの義務的な地方のsendrecv a=des: qosの義務的なリモートsendrecv
Let's assume that after receiving this response, A decides that it wants to use only PCM u-law (payload 0), as opposed to both PCM u-law and A-law (payload 8). It would send an UPDATE to B, possibly before receiving the 200 (OK) for the INVITE (5). The SDP would look like:
この応答を受けた後にAが、PCM u-法(ペイロード0)だけを使用したがっていると決めると仮定しましょう、PCM u-法とA-法(ペイロード8)の両方と対照的に。 INVITE(5)のために、200(OK)を受け取ることによると前に、それはUPDATEを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
mがオーディオの20000RTP/AVPと等しい、0、c、=IN IP4 192.0.2.1a=curr: qosの地方のsendrecv a=curr: qosのリモートsendrecv a=des: qosの義務的な地方のsendrecv a=des: qosの義務的なリモート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"までの答えを待つことができました。
Camarillo, et. al. Standards Track [Page 22] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[22ページ]。
13.3 Offer in a SIP response
13.3 SIP応答における申し出
The call flow of Figure 5 shows a basic session establishment where the initial offer appears in a reliable 1xx response. This example uses the end-to-end status type. The SDP descriptions of this example are shown below:
図5の呼び出し流動は、初期の申し出が信頼できる1xx応答でどこに見えるかを基本的なセッション設立に示します。 この例は終わりから完了状態へのタイプを使用します。 この例のSDP記述は以下に示されます:
The first INVITE (1) does not contain a session description. Therefore, the initial offer is sent by B in a reliable 183 (Session Progress) response.
最初のINVITE(1)はセッション記述を含んでいません。 したがって、信頼できる183(セッションProgress)応答における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メッセージを受け取るので。 しかしながら、それは予約の状態をもう片方の方向に知りません。 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
mがオーディオの30000RTP/AVPと等しい、0、c、=IN IP4 192.0.2.4a=curr: qos e2e、a=desのいずれも:でない qosの義務的なe2e sendrecv a=conf: qos e2e recv
SDP2: A includes its answer in the PRACK for the 183 (Session Progress) response.
SDP2: Aは183(セッションProgress)応答のためのPRACKに答えを含んでいます。
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
mがオーディオの20000RTP/AVPと等しい、0、c、=IN IP4 192.0.2.1a=curr: qos e2e、a=desのいずれも:でない qosの義務的なe2e sendrecv
Camarillo, et. al. Standards Track [Page 23] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[23ページ]。
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------------------>|
| |
| |
| *** | | *R*| | *E*| | *S*| | *E*| | *R*| | *V*| | **| | *T*| | *I*| | *○ *| | *N*| | *** | |-------------(1) SDP1を招待してください。--------------->|、| *** | | *R*| | *E*| | *S*| | *E*| | *R*| | *V*| | **| | *T*| | *I*| | *○ *| | *N*| | *** | | <、-、-、-、-、-、-、-、-、--(2) 180 SDP2を鳴らすこと。-------------| | | |----------------(3) PRACK------------------>|、|、| | <、-、-、-、-、-、-、-、-、-、--(4) 200OK(PRACK)--------------| | | | | | <、-、-、-、-、-、-、-、-、-、--(5) 200OK(招待します)-------------| | | |------------------(6) ACK------------------>|、|、|、|、|
Figure 4: Example using the segmented status type
図4: 区分された状態タイプを使用する例
Camarillo, et. al. Standards Track [Page 24] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[24ページ]。
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----------------->|
| |
| | |----------------(1) 招待----------------->|、|、| | <、-、-、-、-、--(2) 183 セッション進歩SDP1--------| | | |---------------(3) PRACK SDP2-------------->|、| *** *** | | <、-*R*--------(4) 200OK(PRACK)-------*R*---| | *E**E*| | *S**S*| | *E**E*| | *R**R*| | *V**V*| | ***は*です。| | *T**T*| | *I**I*| | *○ **O*| | *N**N*| | *** *** | |-------------(5) アップデートSDP3----------***-->|、| *** | | <、-、-、-、-、-、-、--(6) 200 OK(アップデート)SDP4-----***---| | *** | | *** | | *** | | <、-、-、-、-、-、-、-、-、-、-、-、--(7) 180 鳴ること---------------| | | |-----------------(8) PRACK----------------->|、|、| | <、-、-、-、-、-、-、-、-、-、-、--(9) 200OK(PRACK)-------------| | | | | | | | <、-、-、-、-、-、-、-、-、-、--(10) 200OK(招待します)------------| | | |------------------(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)を受けるとき、それはまた、資源予約を実行し始めます。 両方のUAsはRSVPを使用します、そして、したがって、AはBに向かったメッセージをPATHに送ります、そして、BはAに向かったメッセージをPATHに送ります。
Camarillo, et. al. Standards Track [Page 25] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[25ページ]。
SDP3: When A receives RESV messages, it sends an updated offer (5) to B:
SDP3: AがRESVメッセージを受け取るとき、アップデートされた申し出(5)をBに送ります:
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
mがオーディオの20000RTP/AVPと等しい、0、c、.1a=curr: qos e2eがa=des: qosに義務的なe2e sendrecvを送る=IN IP4 192.0.2
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
m=オーディオ30000RTP/AVP0c=IN IP4 192.0.2.4のa=curr:qos e2e recv a=des:qosの義務的な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.
前提条件を運びながら非認証された要求のレセプションの資源予約を実行する実体はサービス不能攻撃のための格好の的であるかもしれません。 前提条件で、SHOULDが認証されるよう要求します。
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属性を定義します: 必要な状態、現在の状態、およびconf-状態。 それらの書式はセクション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 MUSTのIANA Considerations部は以下の情報を含めます。(それは、公表のRFC番号に伴うIANA登録に現れます)。
Camarillo, et. al. Standards Track [Page 26] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[26ページ]。
o Name of the precondition-type. The name MAY be of any length,
but SHOULD be no more than ten characters long.
o 前提条件タイプの名前。 名前がどんな長さのそうですがも、SHOULDは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
Pecondition-タイプ参照記述---------------- --------- ----------- Service前提条件のqos RFC3312Quality
This document also defines a new SIP status code (580). Its default reason phrase (Precondition Failure) is defined in section 8.
また、このドキュメントは新しいSIPステータスコード(580)を定義します。 デフォルト理由句(前提条件Failure)はセクション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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
[2] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method," RFC 3311, September 2002.
[5] ローゼンバーグ、J.、「セッション開始プロトコル(一口)アップデート方法」、RFC3311、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.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、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、「セッション開始プロトコル(一口)の暫定的な応答の信頼性」、RFC3262、2002年6月。
Camarillo, et. al. Standards Track [Page 27] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[27ページ]。
[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.Mishra、D.Nortz、およびK.K.Ramakrishnan、「DOSA:」 2000年3月のコンピュータCommunications(IEEE Infocom)、(テルアビブ(イスラエル))のコンファレンスのProceedingsの「体力を要しているIP電話技術サービスを提供するための構造。」
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; Ramakrishnan(TeraOpticネットワーク)、エド・ミラー(Terayon)、グレン・ラッセル(CableLabs)、Burcak Beser(太平洋の広帯域通信)、マイクMannette(3Com)、カートスタインブレナー(3Com)、デーヴ・オラン(シスコ)フレミングAndreasen(シスコ)、マイケルRamalho(シスコ)、ジョン・ピケンズ(Com21); Poornima Lalwaney(ノキア)、ジョンFellows(カッパーマウンテンネットワーク)、Doc Evans(D.R.エヴァンスコンサルティング)、キース・ケリー(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年間以上の仕事の完成である、大部分はここと以下の承認部で記載されています。 特別な注意はサービスの質前提条件がコンパチブル前の、そして、非SIPの「2ステージのInvite」提案から扱う初期の「独身のINVITE」の先頭に立つためのフレミングAndreasen、Burcak Beser、デーヴBoardman、ビルGuckel、チャックKalmanek、キース・ケリー、Poornima Lalwaney、ジョンLawser、ビル・マーシャル、マイクMannette、デーヴ・オラン、K.K.Ramakrishnan、マイケルRamalho、アダム・ローチ、ジョナサン・ローゼンバーグ、およびヘニングSchulzrinneのためです。 Distributed Call Signalingからのそれらの起源はPacketCableでこれらの「2ステージのINVITE」提案で働きました。(順番に、PacketCableはAT&TのDistributedオープンSystems Architecture(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プロジェクトにおけるDistributed Call Signaling仕事は多くの人々の仕事です、多くの異なった会社を代表して。 作者がそうしたい、認識して、感謝する、: ジョン・ウィーラー、モトローラ。 デヴィッドBoardman、ダニエル・ポール、アリスInteractive。 ビル・ブルーム、ジェイStrater、ジェフ・オリス、クライヴHolborow、ゼネラルインスツルメンツ。 ダグ・ニューリン、グイド・シュスター、Ikhlaq Sidhu、3Com。 ジリマトウシェク、ベイネットワークス。 Farzi Khazai、ノーテル。 ジョン・チャップマン、ビルGuckel、シスコ。 チャックKalmanek、ダグNortz、ジョンLawser、ジェームス・チェン、タン-Haiシャオ、Partho Mishra、AT&T。 Telcordia技術。 そして、透明な有線通信。
Camarillo, et. al. Standards Track [Page 28] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[28ページ]。
Miguel Angel Garcia-Martin, Rohan Mahy and Mark Watson provided helpful comments and suggestions.
ミゲル・Angelガルシア-マーチン、Rohanマーイ、およびマーク・ワトソンは役に立つコメントと提案を提供しました。
20 Authors' Addresses
20人の作者のアドレス
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
ゴンサロキャマリロエリクソンは合図研究研究室を進めました。 フィン-02420Jorvasフィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メール: Gonzalo.Camarillo@ericsson.com
Bill Marshall AT&T Florham Park, NJ 07932 USA
ビルマーシャルAT&T Florham Park、ニュージャージー07932米国
EMail: wtm@research.att.com
メール: wtm@research.att.com
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA
ジョナサンローゼンバーグdynamicsoft72のEagle Rock Aveの東ハノーバー王家、ニュージャージー07936米国
EMail: jdrosen@dynamicsoft.com
メール: jdrosen@dynamicsoft.com
Camarillo, et. al. Standards Track [Page 29] RFC 3312 Integration of Resource Management and SIP October 2002
etキャマリロ、アル。 規格は2002年10月に資源管理と一口のRFC3312統合を追跡します[29ページ]。
21 Full Copyright Statement
21 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Camarillo, et. al. Standards Track [Page 30]
etキャマリロ、アル。 標準化過程[30ページ]
一覧
スポンサーリンク
