RFC4032 日本語訳

Network Working Group                                       G. Camarillo
Request for Comments: 4032                                      Ericsson
Updates: 3312                                                 P. Kyzivat
Category: Standards Track                                  Cisco Systems
                                                              March 2005

コメントを求めるワーキンググループG.キャマリロの要求をネットワークでつないでください: 4032のエリクソンアップデート: 3312年のP.Kyzivatカテゴリ: 2005年の標準化過程シスコシステムズの行進

            Update to the Session Initiation Protocol (SIP)
                        Preconditions Framework

セッション開始プロトコル(一口)へのアップデートは枠組みをあらかじめ調整します。

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   This document updates RFC 3312, which defines the framework for
   preconditions in SIP.  We provide guidelines for authors of new
   precondition types and describe how to use SIP preconditions in
   situations that involve session mobility.

このドキュメントはRFC3312をアップデートします。(RFCはSIPの前提条件のために枠組みを定義します)。 私たちは、新しい前提条件タイプの作者にガイドラインを前提として、セッションの移動性にかかわる状況でSIP前提条件を使用する方法を説明します。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.  Defining New Precondition Types  . . . . . . . . . . . . . . .  3
       3.1.  Precondition Type Tag  . . . . . . . . . . . . . . . . .  3
       3.2.  Status Type  . . . . . . . . . . . . . . . . . . . . . .  3
       3.3.  Precondition Strength  . . . . . . . . . . . . . . . . .  3
       3.4.  Suspending and Resuming Session Establishment  . . . . .  3
   4.  Issues Related to Session Mobility . . . . . . . . . . . . . .  4
       4.1.  Update to RFC 3312 . . . . . . . . . . . . . . . . . . .  5
       4.2.  Desired Status . . . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
       8.1.  Normative References . . . . . . . . . . . . . . . . . .  8

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 新しい前提条件を定義すると、.33.1はタイプされます。 タイプタグ. . . . . . . . . . . . . . . . . 3 3.2をあらかじめ調整してください。 状態タイプ. . . . . . . . . . . . . . . . . . . . . . 3 3.3。 強さ. . . . . . . . . . . . . . . . . 3 3.4をあらかじめ調整してください。 セッション設立. . . . . 3 4を中断して、再開します。 問題はセッションの移動性. . . . . . . . . . . . . . 4 4.1に関連しました。 RFC3312.54.2に、アップデートします。 必要な状態. . . . . . . . . . . . . . . . . . . . . 7 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 7 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 7 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 8 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1。 引用規格. . . . . . . . . . . . . . . . . . 8

Camarillo & Kyzivat         Standards Track                     [Page 1]

RFC 4032              SIP Preconditions Framework             March 2005

キャマリロとKyzivat標準化過程[1ページ]RFC4032一口は2005年の枠組みの行進のときにあらかじめ調整されます。

       8.2.  Informational References . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 10

8.2. 情報の参照. . . . . . . . . . . . . . . . 8作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 9の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 10

1.  Introduction

1. 序論

   RFC 3312 [3] defines the framework for SIP [2] preconditions, which
   is a generic framework that allows SIP UAs (User Agents) to suspend
   the establishment of a session until a set of preconditions are met.
   Although only Quality of Service (QoS) preconditions have been
   defined so far, this framework supports different types of
   preconditions.  (QoS preconditions are defined by RFC 3312 as well).

RFC3312[3]はSIP[2]前提条件のための枠組みを定義します。(それは、1セットの前提条件が満たされるまでSIP UAs(ユーザエージェント)がセッションの設立を中断させることができる一般的な枠組みです)。 Service(QoS)前提条件の唯一のQualityが今までのところ定義されましたが、この枠組みは異なったタイプの前提条件を支持します。 (QoS前提条件はまた、RFC3312によって定義されます。)

   This document updates RFC 3312,  provides guidelines for authors of
   new precondition types and explains which topics they need to discuss
   when defining them.  In addition, it updates some of the procedures
   in RFC 3312 for using SIP preconditions in situations that involve
   session mobility as described below.

このドキュメントで、RFC3312をアップデートして、新しい前提条件タイプの作者にガイドラインを前提として、それらが、それらを定義するとき、どの話題について議論する必要であるかがわかります。 さらに、それは、以下で説明されるようにセッションの移動性にかかわる状況でSIP前提条件を使用するためにRFC3312の手順のいくつかをアップデートします。

   RFC 3312 focuses on media sessions that do not move around.  That is,
   media is sent between the same end-points throughout the duration of
   the session.  Nevertheless, media sessions established by SIP are not
   always static.

RFC3312は動き回らないメディアセッションのときに集中します。 セッションの持続時間中で同じエンドポイントの間にすなわち、メディアを送ります。 それにもかかわらず、SIPによって確立されたメディアセッションはいつも静的であるというわけではありません。

   SIP offers mechanisms to provide session mobility, namely re-INVITEs
   and UPDATEs [5].  While existing implementations of RFC 3312 can
   probably handle session mobility, there is a need to explicitly point
   out the issues involved and make a slight update on some of the
   procedures defined there in.  With the updated procedures defined in
   this document, messages carrying precondition information become more
   explicit about the current status of the preconditions.

SIPはセッションの移動性、すなわち、再INVITEsを提供するメカニズムとUPDATEs[5]を提供します。 RFC3312の既存の実現はたぶんセッションの移動性を扱うことができますが、問題がそこで定義された手順のいくつかに関するわずかな最新情報にかかわって、作ると明らかに指摘する必要があります。 アップデートされた手順が本書では定義されている状態で、前提条件情報を運ぶメッセージが前提条件の現在の状態に関して、より明白になります。

   Specifically, we now allow answers to downgrade current status values
   (this was disallowed by RFC 3312).  We consider moving an existing
   stream to a new location as equivalent to establishing a new stream.
   Therefore, answers moving streams to new locations set all the
   current status values in their answers to "No" and start a new
   precondition negotiation from scratch.

明確に、私たちは答えに現在、現在の状態値を格下げさせます(これはRFC3312によって禁じられました)。 私たちは、既存の流れを新しい流れを確立するのに同じくらい同等な新しい位置に動かすと考えます。 したがって、流れを新しい位置に動かす答えが、彼らの「いいえ」の答えにすべての現在の状態値をはめ込んで、最初から、新しい前提条件交渉を始めます。

2.  Terminology

2. 用語

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [1] and indicate requirement levels for
   compliant implementations.

本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[1]ということであり、対応する実現のために要件レベルを示すべきであるかをさせましょう。

Camarillo & Kyzivat         Standards Track                     [Page 2]

RFC 4032              SIP Preconditions Framework             March 2005

キャマリロとKyzivat標準化過程[2ページ]RFC4032一口は2005年の枠組みの行進のときにあらかじめ調整されます。

3.  Defining New Precondition Types

3. 新しい前提条件タイプを定義します。

   Specifications defining new precondition types need to discuss the
   topics described in this section.  Having clear definitions of new
   precondition types is essential to ensure interoperability among
   different implementations.

新しい前提条件タイプを定義する仕様は、このセクションで説明された話題について議論する必要があります。 新しい前提条件タイプの明確な定義を持っているのは、異なった実現の中で相互運用性を確実にするのに不可欠です。

3.1.  Precondition Type Tag

3.1. 前提条件タイプタグ

   New precondition types MUST have an associated precondition type tag
   (e.g., "qos" is the tag for QoS preconditions).  Authors of new
   preconditions MUST register new precondition types and their tags
   with the IANA by following the instructions in Section 15 of RFC
   3312.

新しい前提条件タイプは関連前提条件タイプタグを持たなければなりません(例えば、"qos"はQoS前提条件のためのタグです)。 新しい前提条件の作者は、RFC3312のセクション15での指示に従うことで新しい前提条件タイプと彼らのタグをIANAに示さなければなりません。

3.2.  Status Type

3.2. 状態タイプ

   RFC 3312 defines two status types: end-to-end and segmented.
   Specifications defining new precondition types MUST indicate which
   status applies to the new precondition.  New preconditions can use
   only one status type or both.  For example, the QoS preconditions
   defined in RFC 3312 can use both.

RFC3312は2つの状態タイプを定義します: 終わるために終わって区分されています。 新しい前提条件タイプを定義する仕様は、どの状態が新しい前提条件に適用されるかを示さなければなりません。 新しい前提条件は1つの状態タイプか両方しか使用できません。 例えば、RFC3312で定義されたQoS前提条件は両方を使用できます。

3.3.  Precondition Strength

3.3. 前提条件の強さ

   RFC 3312 defines optional and mandatory preconditions.
   Specifications defining new precondition types MUST describe whether
   or not optional preconditions are applicable, and in case they are,
   what is the expected behavior of a UA on reception of optional
   preconditions.

RFC3312は任意の、そして、義務的な前提条件を定義します。 新しい前提条件タイプを定義する仕様は、任意の前提条件が適切であるかどうか説明しなければなりません、そして、場合では、それらは説明します、任意の前提条件のレセプションにおけるUAの予想された動きであること。

3.4.  Suspending and Resuming Session Establishment

3.4. セッション設立を中断して、再開します。

   Section 6 of RFC 3312 describes the behavior of UAs from the moment
   session establishment is suspended, due to a set of preconditions,
   until it is resumed when these preconditions are met.  In general,
   the called user is not alerted until the preconditions are met.

RFC3312のセクション6は中断した瞬間のセッション設立からUAsの動きについて説明します、1セットの前提条件のため、これらの前提条件が満たされるとき、それが再開されるまで。 一般に、前提条件が満たされるまで、呼ばれたユーザは警告されません。

   In addition to not alerting the user, each precondition type MUST
   define any extra actions UAs should perform or refrain from
   performing when session establishment is suspended.  The behavior of
   media streams during session suspension is therefore part of the
   definition of a particular precondition type.  Some precondition

ユーザを警告しないことに加えて、それぞれの前提条件タイプはUAsが実行するはずであるか、または控えるはずであるセッション設立が吊しているとき働くどんな余分な動きも定義しなければなりません。 したがって、セッションサスペンションの間のメディアの流れの働きは特定の前提条件タイプの定義の一部です。 何らかの前提条件

Camarillo & Kyzivat         Standards Track                     [Page 3]

RFC 4032              SIP Preconditions Framework             March 2005

キャマリロとKyzivat標準化過程[3ページ]RFC4032一口は2005年の枠組みの行進のときにあらかじめ調整されます。

   types may allow media streams to send and receive packets during
   session suspension; others may not.  Consequently, the following
   paragraph from RFC 3312 only applies to QoS preconditions:

タイプは、メディアの流れにセッションサスペンションの間、パケットを送って、受けさせるかもしれません。 他のものはそうしないかもしれません。 その結果、RFC3312からの以下のパラグラフはQoS前提条件に適用されるだけです:

      While session establishment is suspended, user agents SHOULD not
      send any data over any media stream.  In the case of RTP, neither
      RTP nor RTCP packets are sent.

セッション設立が吊している間、ユーザエージェントSHOULDはどんなメディアの流れでも少しのデータも送りません。 RTPの場合では、RTPもRTCPパケットも送られません。

   To clarify the previous paragraph, the control messages used to
   establish connections in connection-oriented transport protocols
   (e.g., TCP SYNs) are not affected by the previous rule.  So, user
   agents follow standard rules (e.g., the SDP 'setup' attribute [7]) to
   decide when to establish the connection, regardless of QoS
   preconditions.

前のパラグラフをはっきりさせるために、接続指向のトランスポート・プロトコル(例えば、TCP SYNs)で関係を樹立するのに使用されるコントロールメッセージは前の規則で影響を受けません。 したがって、ユーザエージェントは標準の規則に従います。(例えば、SDP'セットアップ'はいつ接続を確立するかを決めるために[7])を結果と考えます、QoS前提条件にかかわらず。

   New precondition types MUST also describe the behaviour of UAs on
   reception of a re-INVITE or an UPDATE with preconditions for an
   ongoing session.

また、新しい前提条件タイプは進行中のセッションのために前提条件で再INVITEかUPDATEのレセプションにおけるUAsのふるまいについて説明しなければなりません。

4.  Issues Related to Session Mobility

4. セッションの移動性に関連する問題

   Section 5 of RFC 3312 describes how to use SIP [2] preconditions with
   the offer/answer model [4].  RFC 3312 gives a set of rules that allow
   a user agent to communicate changes in the current status of the
   preconditions to the remote user agent.

RFC3312のセクション5は申し出/答えモデル[4]と共にSIP[2]前提条件を使用する方法を説明します。 RFC3312はユーザエージェントが前提条件の現在の状態の変化をリモート・ユーザーエージェントに伝えることができる1セットの規則を与えます。

   The idea is that a given user agent knows about the current status of
   some part of the preconditions (e.g., send direction of the QoS
   precondition) through local information (e.g., an RSVP RESV is
   received indicating that resource reservation was successful).  The
   UAC (User Agent Client) informs the UAS (User Agent Server) about
   changes in the current status by sending an offer to the UAS.  The
   UAS, in turn, could (if needed) send an offer to the UAC informing it
   about the status of the part of the preconditions the UAS has local
   information about.

考えは与えられたユーザエージェントがローカルの情報を通して前提条件(例えば、QoS前提条件の指示を送る)の何らかの部分の現在の状態に関して知っているという(資源予約がうまくいったのを示すのにおいて例えば、RSVP RESVは受け取られています)ことです。 UAC(ユーザエージェントClient)は、現在の状態の変化に関して申し出をUASに送ることによって、UAS(ユーザエージェントServer)に知らせます。 UASは順番にUASにはローカルの情報がある前提条件の部分の状態に関してそれを知らせるUACに申し出を送るかもしれません(必要であるなら)。

      Note, however, that UASs do not usually send updates about the
      current status to the UAC because UASs are the ones resuming
      session establishment when all the preconditions are met.
      Therefore, rather than performing an offer/answer exchange to
      inform the UAC that all the preconditions are met, they simply
      send a 180 (Ringing) response indicating that session
      establishment has been resumed.

しかしながら、すべての前提条件が満たされるとき、UASsがもの再開の設立であるので通常、UASsが現在の状態に関してアップデートをUACに送らないことに注意してください。 すべての前提条件が満たされることをUACに知らせるために申し出/答え交換を実行するよりしたがって、むしろ、それらは180(鳴る)応答にセッション設立が再開されたのを単に示させます。

Camarillo & Kyzivat         Standards Track                     [Page 4]

RFC 4032              SIP Preconditions Framework             March 2005

キャマリロとKyzivat標準化過程[4ページ]RFC4032一口は2005年の枠組みの行進のときにあらかじめ調整されます。

   While RFC 3312 allows updating current status information using the
   methods described above, it does not allow downgrading current status
   values in answers, as shown in the third row of Table 3 of RFC 3312.
   Figure 1 shows how performing such a downgrade in an answer would
   sometimes be needed.

RFC3312が上で説明された方法を使用することで現在の状態情報をアップデートさせる間、それで答えにおける現在の状態値を格下げしません、RFC3312のTable3の3番目の列に示されるように。 図1は答えにおけるそのようなダウングレードを実行するのがどう時々必要であるだろうかを示しています。

                            3pcc
                 A       Controller        B        C

3pccはコントローラB Cです。

                 |            |            |        |
                 |<-dialog 1->|<-dialog 2->|        |
                 |            |            |        |
                 | *********************** |        |
                 |*         MEDIA         *|        |
                 | *********************** |        |
                 |            |            |        |
                 |            |            |        |
                 |<-dialog 1->|<------dialog 3----->|
                 |            |            |        |
                 | ******************************** |
                 |*             MEDIA              *|
                 | ******************************** |
                 |            |            |        |
                 |            |            |        |

| | | | | <、-対話1>| <、-対話2>|、|、|、|、|、|、| *********************** | | |* メディア*| | | *********************** | | | | | | | | | | | <、-対話1>| <、-、-、-、-、--対話3----->|、|、|、|、|、| ******************************** | |* メディア*| | ******************************** | | | | | | | | |

                 Figure 1: Session mobility using 3pcc

図1: 3pccを使用するセッションの移動性

   The 3pcc (Third Party Call Control) [6] controller in Figure 1 has
   established a session between A and B using dialog 1 towards A and
   dialog 2 towards B.  At that point, the controller wants A to have a
   session with C instead of B.  To transfer A to C (configuration shown
   at the bottom of Figure 1), the controller sends an empty (no offer)
   re-INVITE to A.  Since A does not know that the session will be
   moved, its offer in the 200 OK states that the current status of the
   media stream in the send direction is "Yes".  After contacting C
   establishing dialog 3, the controller sends back an answer to A.
   This answer contains a new destination for the media (C) and should
   have downgraded the current status of the media stream to "No", since
   there is no reservation of resources between A and C.

図1の3pcc(第3パーティCall Control)6コントローラはAとBとの間にAに向かったとの対話1と指すB.Atに向かったとの対話2を使用することでセッションを確立して、コントローラは、CがBの代わりにある状態でAが会合を開く必要があります; 発信してください。C(図1の下部に示された構成)にAを移すために、コントローラがAが知らないA.Sinceへのセッションが動きます、200OKにおける申し出がメディアの現在の状態が流れると述べるということであるために望んでいる空(ノー・オファー)の再INVITEを送る、指示は「はい」ということです。 対話3を確立しながらCに連絡した後に、コントローラは、メディア(C)のためにA.This答えの答えが含む後部に新しい目的地を送って、メディアの流れの現在の状態を「いいえ」に格下げするはずでした、AとCの間には、リソースの予約が全くないので。

4.1.  Update to RFC 3312

4.1. RFC3312へのアップデート

   Below is a set of new rules that update RFC 3312 to address the
   issues above.

以下に、問題を記述するためにRFC3312をアップデートする1セットの新しい規則が上にあります。

Camarillo & Kyzivat         Standards Track                     [Page 5]

RFC 4032              SIP Preconditions Framework             March 2005

キャマリロとKyzivat標準化過程[5ページ]RFC4032一口は2005年の枠組みの行進のときにあらかじめ調整されます。

   The rule below applies to offerers moving a media stream to a new
   address:

以下の規則は新しい住所にメディアの流れを動かしている申出人に適用されます:

   When a stream is being moved to a new transport address, the offerer
   MUST set all current status values about which it does not have local
   information about to "No".

小川が新しい輸送アドレスに動かされているとき、申出人がそれがローカルの情報を持っていないすべての現在の状態値を設定しなければならない、「いいえ。」になろうとしています

   Note that for streams using segmented status (as opposed to end-to-
   end status), the fact that the address for the media stream at the
   local segment changes may or may not affect the status of
   preconditions at the remote segment.  However, moving an existing
   stream to a new location, from the preconditions point of view, is
   like establishing a new stream.  Therefore, it is appropriate to set
   all the current status values to "No" and start a new precondition
   negotiation from scratch.

区分された状態(終わりから完了状態と対照的に)(地方のセグメント変化におけるメディアの流れのためのアドレスがリモートセグメントで前提条件の状態に影響するかもしれないという事実)を使用する流れのためにそれに注意してください。 しかしながら、既存の流れを新しい位置に動かして、前提条件から、観点は新しい流れを確立するように動きます。 したがって、「いいえ」にすべての現在の状態値を設定して、最初から新しい前提条件交渉を始めるのは適切です。

   The updated table and rules below apply to an answerer that is moving
   a media stream.  The offerer was not aware of the move when it
   generated the offer.

以下のアップデートされたテーブルと規則はメディアの流れを動かしているanswererに適用されます。 申し出を発生させたとき、申出人は移動を意識していませんでした。

   Table 3 of RFC 3312 needs to be updated to allow answerers to
   downgrade current status values.  The following table shows the
   result.

RFC3312のテーブル3は、answerersが現在の状態値を格下げするのを許容するためにアップデートする必要があります。 以下のテーブルは結果を示しています。

   Transac status table  Local status table  New values transac./local
   ____________________________________________________________________
            no                    no                    no/no
           yes                   yes                   yes/yes
           yes                    no            depends on local info
            no                   yes            depends on local info

Transac状態テーブルLocal状態テーブルNewは地方でtransac/を評価します。____________________________________________________________________ いいえ/いいえ、はいはいはい/はいのはいノー、が全く少しもはいがよらないローカルのインフォメーションによらない、ローカルのインフォメーション

   An answerer MUST downgrade the current status values received in the
   offer if it has local information about them or if the media stream
   is being moved to a new transport address.

answererはそれらに関してそれでローカルの情報があるか、またはメディア小川が新しい輸送アドレスに動かされているなら申し出で受け取られた現在の状態値を格下げしなければなりません。

   Note that for streams using segmented status, the address change at
   the answerer may or may not affect the status of the preconditions at
   the offerer's segment.  However, as stated above, moving an existing
   stream to a new location, from the preconditions point of view, is
   like establishing a new stream.  Therefore, it is appropriate to set
   all the current status values to "No" and start a new precondition
   negotiation from scratch.

区分された状態を使用する流れのためにanswererのアドレス変化が申出人のセグメントで前提条件の状態に影響するかもしれないことに注意してください。 しかしながら、上で述べられるとして既存の流れを新しい位置に動かして、前提条件から、観点は新しい流れを確立するように動きます。 したがって、「いいえ」にすべての現在の状態値を設定して、最初から新しい前提条件交渉を始めるのは適切です。

   The new table below applies to an offerer that receives an answer
   that updates or downgrades its local status tables.

以下の新しいテーブルは地方の状態テーブルをアップデートするか、または格下げする答えを受ける申出人に適用されます。

Camarillo & Kyzivat         Standards Track                     [Page 6]

RFC 4032              SIP Preconditions Framework             March 2005

キャマリロとKyzivat標準化過程[6ページ]RFC4032一口は2005年の枠組みの行進のときにあらかじめ調整されます。

   Offerers should update their local status tables when they receive an
   answer as shown in the following table.

以下のテーブルに示されるように答えを受けるとき、申出人は地元の状態テーブルをアップデートするべきです。

   Transac. status table  Local status table  New value Local Status
   _________________________________________________________________
            no                    no                    no
           yes                   yes                   yes
           yes                    no                   yes
            no                   yes                    no

Transac状態テーブルLocal状態テーブルNew値のLocal Status_________________________________________________________________ いいえ、いいえ、いいえ、はい、はい、はい、はい、いいえ、はい、いいえ、はい、いいえ

4.2.  Desired Status

4.2. 必要な状態

   The desired status that a UA wants for a media stream after the
   stream is moved to a new transport address may be different than the
   desired status negotiated for the stream originally.  A UA, for
   instance, may require mandatory QoS over a low bandwidth link but be
   satisfied with optional QoS when the stream is moved to a high
   bandwidth link.

小川が新しい輸送アドレスに動かされた後にUAがメディアの流れのために欲しい必要な状態は必要な状態が元々流れを交渉したより異なっているかもしれません。 例えば、UAは低い帯域幅リンクの上に義務的なQoSを必要とするかもしれませんが、小川が高帯域リンクに動かされたら任意のQoSに満足してください。

   If the new desired status is higher than the previous one (e.g.,
   optional to mandatory), the UA, following RFC 3312 procedures, may
   upgrade its desired status in an offer or in an answer.  If the new
   desired status is lower that the previous one (i.e., mandatory to
   optional), the UA, following RFC 3312 procedures as well, may
   downgrade its desired status only in an offer (i.e., not in an
   answer.)

新しい必要な状態が前のものより高い、(例えば、義務的に任意である、)、UA(次のRFC3312手順)は申し出か答えにおける必要な状態をアップグレードさせるかもしれません。 新しい必要な状態が低い、1(すなわち、任意に義務的な)、また、RFC3312手順に従うUAがそうする前は申し出だけにおける必要な状態を格下げします。(すなわち、答えでないのにおける。)

5.  Security Considerations

5. セキュリティ問題

   An attacker adding preconditions to a session description or
   modifying existing preconditions could prevent establishment of
   sessions.  An attacker removing preconditions from a session
   description could force sessions to be established without meeting
   mandatory preconditions.

セッション記述に前提条件を加えるか、または既存の前提条件を変更する攻撃者はセッションの設立を防ぐことができました。 義務的な前提条件を満たさないで、セッション記述から前提条件を取り除いている攻撃者はセッションを強制的に確立させることができました。

   Thus, it is strongly RECOMMENDED that integrity protection be applied
   to the SDP session descriptions.  S/MIME is the natural choice to
   provide such end-to-end integrity protection, as described in RFC
   3261 [2].

強く、保全保護をあるRECOMMENDEDは、申し込みました。その結果、それがそうである、SDPセッション記述。 S/MIMEはRFC3261[2]で説明されるように終わりから終わりへの保全そのような保護を提供する自然な選択です。

6.  IANA Considerations

6. IANA問題

   The IANA registration requirements for the preconditions framework
   are defined in RFC 3312.  Any new preconditions are governed by the
   IANA Considerations there.

前提条件枠組みのためのIANA登録要件はRFC3312で定義されます。 どんな新しい前提条件もそこでIANA Considerationsによって支配されます。

Camarillo & Kyzivat         Standards Track                     [Page 7]

RFC 4032              SIP Preconditions Framework             March 2005

キャマリロとKyzivat標準化過程[7ページ]RFC4032一口は2005年の枠組みの行進のときにあらかじめ調整されます。

7.  Acknowledgement

7. 承認

   Dave Oran and Allison Mankin provided useful comments on this
   document.

デーヴ・オランとアリソン・マンキンはこのドキュメントの役に立つコメントを提供しました。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [2]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

[2] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

   [3]  Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
        Resource Management and Session Initiation Protocol (SIP)", RFC
        3312, October 2002.

[3] キャマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、「資源管理とセッション開始プロトコル(一口)の統合」、RFC3312(2002年10月)。

8.2.  Informational References

8.2. 情報の参照

   [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, October 2002.

[5] ローゼンバーグ、J.、「セッション開始プロトコル(一口)アップデート方法」、RFC3311、2002年10月。

   [6]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
        "Best Current Practices for Third Party Call Control (3pcc) in
        the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
        2004.

[6] ローゼンバーグ、J.、ピーターソン、J.、Schulzrinne、H.、およびG.キャマリロ、「セッション開始という第三者呼び出しコントロール(3pcc)のための最も良い現在の実務は(一口)について議定書の中で述べます」、BCP85、RFC3725、2004年4月。

   [7]  Yon, D. and Camarillo, G., "TCP-Based Media Transport in the
        Session Description Protocol (SDP)", Work In Progress, November
        2004.

[7] G.、「セッション記述プロトコル(SDP)におけるTCPベースのメディア輸送」というあそこのもの、D.、およびキャマリロは進歩、2004年11月に働いています。

Camarillo & Kyzivat         Standards Track                     [Page 8]

RFC 4032              SIP Preconditions Framework             March 2005

キャマリロとKyzivat標準化過程[8ページ]RFC4032一口は2005年の枠組みの行進のときにあらかじめ調整されます。

Authors' Addresses

作者のアドレス

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

ゴンサロキャマリロエリクソンHirsalantie11Jorvas02420フィンランド

   EMail: Gonzalo.Camarillo@ericsson.com

メール: Gonzalo.Camarillo@ericsson.com

   Paul Kyzivat
   Cisco Systems
   1414 Massachusetts Avenue, BXB500 C2-2
   Boxborough, MA  01719
   USA

ポールKyzivatシスコシステムズ1414BXB500 C2-2 Boxborough、MA01719マサチューセッツ通り(米国)

   EMail: pkyzivat@cisco.com

メール: pkyzivat@cisco.com

Camarillo & Kyzivat         Standards Track                     [Page 9]

RFC 4032              SIP Preconditions Framework             March 2005

キャマリロとKyzivat標準化過程[9ページ]RFC4032一口は2005年の枠組みの行進のときにあらかじめ調整されます。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Camarillo & Kyzivat         Standards Track                    [Page 10]

キャマリロとKyzivat標準化過程[10ページ]