[要約] RFC 3311は、SIPのUPDATEメソッドに関する仕様を定義しています。このRFCの目的は、SIPセッションの更新と再利用を可能にするためのメカニズムを提供することです。
Network Working Group J. Rosenberg
Request for Comments: 3311 dynamicsoft
Category: Standards Track September 2002
The Session Initiation Protocol (SIP) UPDATE Method
セッション開始プロトコル（SIP）更新方法
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状況については、「Internet Official Protocol Standards」（STD 1）の現在の版を参照してください。このメモの分布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（c）インターネット社会（2002）。全著作権所有。
Abstract
概要
This specification defines the new UPDATE method for the Session Initiation Protocol (SIP). UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but unlike re-INVITE, it can be sent before the initial INVITE has been completed. This makes it very useful for updating session parameters within early dialogs.
この仕様は、セッション開始プロトコル（SIP）の新しい更新方法を定義します。更新により、クライアントはセッションのパラメータ（メディアストリームとそのコーデックなど）を更新できますが、ダイアログの状態に影響を与えません。その意味では、それは再招待状のようなものですが、再招待とは異なり、最初のINVITEが完了する前に送信できます。これにより、初期のダイアログ内のセッションパラメータを更新するのに非常に便利です。
Table of Contents
目次
1 Introduction .............................................. 2
2 Terminology ............................................... 3
3 Overview of Operation ..................................... 3
4 Determining Support for this Extension .................... 3
5 UPDATE Handling ........................................... 4
5.1 Sending an UPDATE ......................................... 4
5.2 Receiving an UPDATE ....................................... 5
5.3 Processing the UPDATE Response ............................ 6
6 Proxy Behavior ............................................ 7
7 Definition of the UPDATE method ........................... 7
8 Example Call Flow ......................................... 7
9 Security Considerations ................................... 11
10 IANA Considerations ....................................... 11
11 Notice Regarding Intellectual Property Rights ............. 11
12 Normative References ...................................... 11
13 Acknowledgements .......................................... 12
14 Author's Address .......................................... 12
15 Full Copyright Statement .................................. 13
1 Introduction
1はじめに
The Session Initiation Protocol (SIP) [1] defines the INVITE method for the initiation and modification of sessions. However, this method actually affects two important pieces of state. It impacts the session (the media streams SIP sets up) and also the dialog (the state that SIP itself defines). While this is reasonable in many cases, there are important scenarios in which this coupling causes complications.
セッション開始プロトコル（SIP）[1]は、セッションの開始と変更のためのINVITEメソッドを定義します。しかしながら、この方法は実際には2つの重要な状態に影響を与える。セッション（メディアストリームSIPセットアップ）とダイアログ（SIP自体が定義する状態）に影響します。これが合理的な場合、このカップリングが合併症を引き起こす重要なシナリオがあります。
The primary difficulty is when aspects of the session need to be modified before the initial INVITE has been answered. An example of this situation is "early media", a condition where the session is established, for the purpose of conveying progress of the call, but before the INVITE itself is accepted. It is important that either caller or callee be able to modify the characteristics of that session (putting the early media on hold, for example), before the call is answered. However, a re-INVITE cannot be used for this purpose, because the re-INVITE has an impact on the state of the dialog, in addition to the session.
一次の難しさは、最初のINVITEが回答される前にセッションの側面を変更する必要がある場合です。この状況の一例は「初期メディア」で、呼の進行状況を伝えることを目的として、セッションが確立された状態で、招待自体が受け入れられる前に。呼び出し元の答えが回答される前に、発信者またはCalleEがそのセッションの特性を変更できるようにすることが重要です。ただし、再招待はこの目的のために使用できません.Re-INVITEは、セッションに加えてダイアログの状態に影響を与えます。
As a result, a solution is needed that allows the caller or callee to provide updated session information before a final response to the initial INVITE request is generated. The UPDATE method, defined here, fulfills that need. It can be sent by a UA within a dialog (early or confirmed) to update session parameters without impacting the dialog state itself.
その結果、最初のINVITE要求に対する最終的な応答が生成される前に、発信者またはCalleEが更新されたセッション情報を提供することを可能にする解決策が必要とされる。ここで定義された更新方法は、その必要性を満たします。ダイアログ状態に影響を与えずにセッションパラメータを更新するために、ダイアログ内のUA（早期または確認済み）から送信できます。
2 Terminology
2用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.
この文書では、「必須」、「必須」、「SEQUR」、「しない」、「推奨する」、「推奨」、「5月」、「オプション」、「オプション」BCP 14、RFC 2119 [2]に記載されているように解釈され、準拠SIP実装のための要件レベルを示します。
3 Overview of Operation
3運営の概要
Operation of this extension is straightforward. The caller begins with an INVITE transaction, which proceeds normally. Once a dialog is established, either early or confirmed, the caller can generate an UPDATE method that contains an SDP offer [3] for the purposes of updating the session. The response to the UPDATE method contains the answer. Similarly, once a dialog is established, the callee can send an UPDATE with an offer, and the caller places its answer in the 2xx to the UPDATE. The Allow header field is used to indicate support for the UPDATE method. There are additional constraints on when UPDATE can be used, based on the restrictions of the offer/answer model.
この拡張の動作は簡単です。発信者は招待トランザクションから始まります。これは正常に進行します。ダイアログが確立されると、早くまたは確認された場合、発信者はセッションを更新する目的でSDPオファー[3]を含む更新方法を生成できます。更新方法への応答には答えが含まれています。同様に、ダイアログが確立されると、Calleeはオファーで更新を送信でき、発信者はその回答を2xxに更新にします。Allow Headerフィールドは、更新方法のサポートを示すために使用されます。オファー/アンサーモデルの制限に基づいて、更新を使用できる場合に追加の制約があります。
4 Determining Support for this Extension
4この拡張機能のサポートを決定する
The initiation of a session operates as specified in RFC 3261 [1]. However, a UAC compliant to this specification SHOULD also include an Allow header field in the INVITE request, listing the method UPDATE, to indicate its ability to receive an UPDATE request.
セッションの開始はRFC 3261 [1]で指定されているとおりに動作します。ただし、この仕様に準拠したUACには、Invite RequestのHeaderフィールドも含まれており、メソッドの更新をリストして、更新要求を受信する機能を示します。
When a UAS compliant to this specification receives an INVITE request for a new dialog, and generates a reliable provisional response containing SDP, that response SHOULD contain an Allow header field that lists the UPDATE method. This informs the caller that the callee is capable of receiving an UPDATE request at any time. An unreliable provisional response MAY contain an Allow header field listing the UPDATE method, and a 2xx response SHOULD contain an Allow header field listing the UPDATE method.
この仕様に準拠したUASが新しいダイアログのINVITE要求を受信し、SDPを含む信頼性のある暫定応答を生成し、その応答に更新方法をリストする許可ヘッダーフィールドを含める必要があります。これにより、呼び出し側に、着信者がいつでも更新要求を受信することができることを通知します。信頼性の低い暫定応答には、更新メソッドを一覧表示するAllow Headerフィールドを含めることができ、2xX応答には更新方法をリストアップするAllow Headerフィールドを含める必要があります。
Responses are processed normally as per RFC 3261 [1], and in the case of reliable provisional responses, according to [4]. It is important to note that a reliable provisional response will always create an early dialog at the UAC. Creation of this dialog is necessary in order to receive UPDATE requests from the callee.
応答は、RFC 3261 [1]、および信頼できる暫定的な応答の場合、[4]に従って通常処理されます。信頼できる暫定的な応答は常にUACで早期のダイアログを作成することに注意することが重要です。このダイアログの作成は、Calleeからの更新要求を受信するために必要です。
If the response contains an Allow header field containing the value "UPDATE", the UAC knows that the callee supports UPDATE, and the UAC is allowed to follow the procedures of Section 5.1.
応答に値 "Update"を含む許可ヘッダーフィールドが含まれている場合、UACはCalleeが更新をサポートしており、UACはセクション5.1の手順に従うことができます。
5 UPDATE Handling
5更新処理
The UPDATE request is constructed as would any other request within an existing dialog, as described in Section 12.2.1 of RFC 3261. It MAY be sent for both early and confirmed dialogs, and MAY be sent by either caller or callee. Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead. This is because an UPDATE needs to be answered immediately, ruling out the possibility of user approval. Such approval will frequently be needed, and is possible with a re-INVITE.
RFC 3261のセクション12.2.1で説明されているように、更新要求は既存のダイアログ内の他の要求として構築されます。早期のダイアログと確認されたダイアログの両方で送信される場合があります。更新プログラムは確認されたダイアログで使用できますが、代わりにRe-Inviteを使用することをお勧めします。これは、アップデートがすぐに回答する必要があるため、ユーザーの承認の可能性を判断する必要があるためです。このような承認は頻繁に必要とされ、再招待されています。
The UAC MAY add optional headers for the UPDATE request, as defined in Tables 1 and 2.
UACは、表1および2で定義されているように、更新要求のためのオプションのヘッダを追加することができる。
UPDATE is a target refresh request. As specified in RFC 3261 [1], this means that it can update the remote target of a dialog. If a UA uses an UPDATE request or response to modify the remote target while an INVITE transaction is in progress, and it is a UAS for that INVITE transaction, it MUST place the same value into the Contact header field of the 2xx to the INVITE that it placed into the UPDATE request or response.
更新はターゲットの更新要求です。RFC 3261 [1]で指定されているように、これはダイアログのリモートターゲットを更新できることを意味します。UAがINVITEトランザクションが進行中の間にリモートターゲットを変更するために更新要求または応答を使用し、そのINVITEトランザクションのUASである場合は、同じ値を2xxのContactヘッダーフィールドにINVITEに入れる必要があります。それは更新要求または応答に入ります。
The rules for inclusion of offers and answers in SIP messages as defined in Section 13.2.1 of RFC 3261 still apply. These rules exist to guarantee a consistent view of the session state. This means that, for the caller:
RFC 3261のセクション13.2.1で定義されているSIPメッセージでオファーや回答を含めるための規則はまだ適用されます。これらの規則は、セッション状態の一貫したビューを保証するために存在します。これは、呼び出し元の場合、
o If the UPDATE is being sent before completion of the initial INVITE transaction, and the initial INVITE contained an offer, the UPDATE can contain an offer if the callee generated an answer in a reliable provisional response, and the caller has received answers to any other offers it sent in either PRACK or UPDATE, and has generated answers for any offers it received in an UPDATE from the callee.
o 最初のINVITEトランザクションが完了する前に更新が送信され、最初のINVITEがオファーを含んでいる場合、CalleEが信頼できる暫定的な応答で回答を生成した場合、そのアップデートにオファーを含めることができ、発信者は他のオファーに回答を受け取りました。それはPrackまたはUpdateのいずれかで送信され、Calleeからの更新で受信されたオファーの回答を生成しました。
o If the UPDATE is being sent before completion of the initial INVITE transaction, and the initial INVITE did not contain an offer, the UPDATE can contain an offer if the callee generated an offer in a reliable provisional response, and the UAC generated an answer in the corresponding PRACK. Of course, it can't send an UPDATE if it has not received answers to any other offers it sent in either PRACK or UPDATE, or has not generated answers for any other offers it received in an UPDATE from the callee.
o 最初のINVITEトランザクションが完了する前に更新が送信されていて、最初のINVITEがオファーを含まなかった場合、CalleEが信頼できる暫定的な応答にオファーを生成した場合はオファーを含めることができ、UACは中に答えを生成できます。対応するPrack。もちろん、PrackまたはUpdateのいずれかで送信された他のオファーに対する回答を受け取っていない場合は、アップデートを送信できません。または、Calleeからの更新で受信された他のオファーに対して答えを生成していない。
o If the UPDATE is being sent after the completion of the initial INVITE transaction, it cannot contain an offer if the caller has generated or received offers in a re-INVITE or UPDATE which have not been answered.
o 初期のINVITEトランザクションが完了した後にアップデートが送信されている場合、呼び出し元が答えられていない再侵入または更新でオファーを生成または受信した場合は、オファーを含めることはできません。
and for the callee:
そして着刺しのために：
o If the UPDATE is being sent before the completion of the INVITE transaction, and the initial INVITE contained an offer, the UPDATE cannot be sent with an offer unless the callee has generated an answer in a reliable provisional response, has received a PRACK for that reliable provisional response, has not received any requests (PRACK or UPDATE) with offers that it has not answered, and has not sent any UPDATE requests containing offers that have not been answered.
o 招待トランザクションが完了する前に更新が送信されている場合、最初のINVITEがオファーを含んでいた場合、Calleeが信頼できる暫定的な応答で回答を生成していない限り、アップデートをオファーで送信することはできません。暫定的な応答は、答えられていないオファーで要求（PRACKまたはUPDATE）を受信し、答えられていないオファーを含む更新要求を送信していません。
o If the UPDATE is being sent before completion of the INVITE transaction, and the initial INVITE did not contain an offer, the UPDATE cannot be sent with an offer unless the callee has sent an offer in a reliable provisional response, received an answer in a PRACK, and has not received any UPDATE requests with offers that it has not answered, and has not sent any UPDATE requests containing offers that have not been answered.
o INVITEトランザクションが完了する前に更新が送信されており、最初のINVITEにオファーが含まれていなかった場合、Calleeが信頼できる暫定的な対応でオファーを送信していない限り、オファーとともに更新を送信できません。それが答えていないオファーで更新要求を受け取っていない、そして答えられていないオファーを含む更新要求を送信していない。
o If the UPDATE is being sent after the completion of the initial INVITE transaction, it cannot be sent with an offer if the callee has generated or received offers in a re-INVITE or UPDATE which have not been answered.
o 初期のINVITEトランザクションが完了した後に更新が送信されている場合は、CalleEが答えられていない再侵入または更新で提供されているオファーを生成または受信した場合は、オファーで送信することはできません。
The UPDATE is processed as any other mid-dialog target refresh request, as described in Section 12.2.2 of RFC 3261 [1]. If the request is generally acceptable, processing continues as described below. This processing is nearly identical to that of Section 14.2 of RFC 3261 [1], but generalized for the case of UPDATE.
RFC 3261 [1]のセクション12.2.2で説明されているように、アップデートは他のMIDダイアログターゲットリフレッシュ要求として処理されます。要求が一般的に許容可能である場合、処理は以下のように続行される。この処理は、RFC 3261 [1]のセクション14.2の項とほぼ同じであるが、更新の場合に一般化されている。
A UAS that receives an UPDATE before it has generated a final response to a previous UPDATE on the same dialog MUST return a 500 response to the new UPDATE, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds.
同じダイアログ上の前の更新に対する最終的な応答を生成する前に更新を受け取るUASは、新しいアップデートに対する500の応答を返す必要があり、0から10秒の間のランダムに選択された値を持つ再試行後のヘッダーフィールドを含める必要があります。。
If an UPDATE is received that contains an offer, and the UAS has generated an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an answer, the UAS MUST reject the UPDATE with a 491 response. Similarly, if an UPDATE is received that contains an offer, and the UAS has received an offer (in an UPDATE, PRACK, or INVITE) to which it has not yet generated an answer, the UAS MUST reject the UPDATE with a 500 response, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds.
オファーを含む更新が受信され、UASがまだ回答を受け取っていないオファーを（更新、PRACKまたはINVITEで）生成した場合、UASは491の応答を使用して更新を拒否しなければなりません。同様に、オファーを含む更新が受信され、UASがまだ回答を生成していないオファーを（更新、PRACK、またはINVITE）を受信した場合、UASは500の応答を使用して更新を拒否しなければなりません。そして、0から10秒の間でランダムに選択された値を持つリトライアフターヘッダーフィールドを含める必要があります。
If a UA receives an UPDATE for an existing dialog, it MUST check any version identifiers in the session description or, if there are no version identifiers, the content of the session description to see if it has changed. If the session description has changed, the UAS MUST adjust the session parameters accordingly and generate an answer in the 2xx response. However, unlike a re-INVITE, the UPDATE MUST be responded to promptly, and therefore the user cannot generally be prompted to approve the session changes. If the UAS cannot change the session parameters without prompting the user, it SHOULD reject the request with a 504 response. If the new session description is not acceptable, the UAS can reject it by returning a 488 (Not Acceptable Here) response for the UPDATE. This response SHOULD include a Warning header field.
UAが既存のダイアログの更新を受け取る場合は、セッションの説明で任意のバージョン識別子をチェックする必要があります。また、バージョン識別子がない場合は、セッション記述の内容が変更されたかどうかを確認します。セッション記述が変更された場合、UASはそれに応じてセッションパラメータを調整し、2xx応答で回答を生成する必要があります。ただし、RE-INVITEとは異なり、更新は迅速に応答する必要があります。したがって、ユーザーは一般にセッションの変更を承認するように求められません。ユーザーがユーザーに促されずにUASがセッションパラメータを変更できない場合は、504回答で要求を拒否する必要があります。新しいセッションの説明が受け入れられない場合、UASはアップデートのために488（ここでは受け入れられない）応答を返すことによってそれを拒否することができます。この応答には警告ヘッダーフィールドを含める必要があります。
Processing of the UPDATE response at the UAC follows the rules in Section 12.2.1.2 of RFC 3261 [1] for a target refresh request. Once that processing is complete, it continues as specified below. This processing is nearly identical to the processing of Section 14.1 of RFC 3261 [1], but generalized for UPDATE.
UACでの更新応答の処理は、ターゲットリフレッシュ要求については、RFC 3261 [1]のセクション12.2.1.2の規則に従います。その処理が完了したら、以下に指定されています。この処理は、RFC 3261 [1]のセクション14.1の処理とほぼ同じであるが、更新に一般化されている。
If a UA receives a non-2xx final response to a UPDATE, the session parameters MUST remain unchanged, as if no UPDATE had been issued. Note that, as stated in Section 12.2.1 of RFC 3261 [1], if the non-2xx final response is a 481 (Call/Transaction Does Not Exist), or a 408 (Request Timeout), or no response at all is received for the UPDATE (that is, a timeout is returned by the UPDATE client transaction), the UAC will terminate the dialog.
UAがアップデートに対して非2xxの最終応答を受信した場合、更新が発行されていないかのように、セッションパラメータは変更されないままにする必要があります。RFC 3261のセクション12.2.1で述べているように、非2xxの最終応答が481（呼/トランザクションは存在しない）、または408（リクエストタイムアウト）、または全く応答がない場合更新のために受信された（つまり、アップデートクライアントトランザクションによってタイムアウトが返されます）、UACはダイアログを終了します。
If a UAC receives a 491 response to a UPDATE, it SHOULD start a timer with a value T chosen as follows:
UACがアップデートに対する491の応答を受信した場合、次のように選択された値Tを持つタイマーを起動する必要があります。
1. If the UAC is the owner of the Call-ID of the dialog ID (meaning it generated the value), T has a randomly chosen value between 2.1 and 4 seconds in units of 10 ms.
1. UACがダイアログIDの呼び出しIDの所有者である場合（その値が生成されたことを意味します）、Tは10ミリ秒単位で2.1から4秒の間でランダムに選択された値を持ちます。
2. If the UAC is not the owner of the Call-ID of the dialog ID, T has a randomly chosen value between 0 and 2 seconds in units of 10 ms.
2. UACがダイアログIDの呼び出しIDの所有者ではない場合、Tは10ミリ秒単位で0から2秒の間のランダムに選択された値を持ちます。
When the timer fires, the UAC SHOULD attempt the UPDATE once more, if it still desires for that session modification to take place. For example, if the call was already hung up with a BYE, the UPDATE would not take place.
タイマーが発生すると、そのセッションの変更が行われている場合は、UACはもう一度アップデートを試みる必要があります。たとえば、コールがすでにBYEにハングアップされていた場合、更新は行われません。
6 Proxy Behavior
6プロキシの動作
Proxy processing of the UPDATE request is identical to any other non-INVITE request.
更新要求のプロキシ処理は、他の非招待要求と同じです。
7 Definition of the UPDATE method
7更新方法の定義
The semantics of the UPDATE method are described in detail above. This extension adds another value to the Method BNF described in RFC 3261:
更新方法の意味論は、上で詳細に説明される。この拡張子は、RFC 3261に記載されている方法BNFに別の値を追加します。
UPDATEm = %x55.50.44.41.54.45 ; UPDATE in caps
Method = INVITEm / ACKm / OPTIONSm / BYEm
/ CANCELm / REGISTERm / UPDATEm
/ extension-method
Table 1 extends Table 2 of RFC 3261 for the UPDATE method.
表1は、更新方法のためにRFC 3261の表2を拡張する。
Table 2 updates Table 3 of RFC 3261 for the UPDATE method.
更新方法については、RFC 3261の表3を更新する。
8 Example Call Flow
8コールフローの例
This section presents an example call flow using the UPDATE method. The flow is shown in Figure 1. The caller sends an initial INVITE (1) which contains an offer. The callee generates a 180 response (2) with an answer to that offer. With the completion of an offer/answer exchange, the session is established, although the dialog is still in the early state. The caller generates a PRACK (3) to acknowledge the 180, and the PRACK is answered with a 200 OK (4). The caller decides to update some aspect of the session - to put it on hold, for example. So, they generate an UPDATE request (5) with a new offer. This offer is answered in the 200 response to the UPDATE (6). Shortly thereafter, the callee decides to update some aspect of the session, so it generates an UPDATE request (7) with an offer, and the answer is sent in the 200 response (8). Finally, the callee answers the call, resulting in a 200 OK response to the INVITE (9), and then an ACK (10). Neither the 200 OK to the INVITE, nor the ACK, will contain SDP.
このセクションでは、更新方法を使用したコールフローの例を示します。フローを図1に示します。発信者はオファーを含む最初のINVITE（1）を送信します。着信者は、そのオファーに対する答えで180回答（2）を生成します。オファー/アンサー交換の完了により、ダイアログはまだ初期状態にあるがセッションは確立されます。発信者は、180を確認するためのPRACK（3）を生成し、PRACKは200 OK（4）で回答される。発信者は、例えば保留にするためにセッションのいくつかの側面を更新することを決定します。したがって、それらは新しいオファーを備えた更新要求（5）を生成します。このオファーは、更新への200回の応答に答えられます（6）。その後、その後、Calleeはセッションのいくつかの局面を更新することを決定するので、オファーを用いて更新要求（7）を生成し、その回答は200回答（8）で送信される。最後に、Calleeは呼び出しに回答し、その結果、INVITE（9）、次にACK（10）に対する200 OK応答が発生します。招待またはACKに200 OKも、SDPを含みません。
Header field where proxy UPDATE
____________________________________________
Accept R o
Accept 2xx o
Accept 415 c
Accept-Encoding R o
Accept-Encoding 2xx o
Accept-Encoding 415 c
Accept-Language R o
Accept-Language 2xx o
Accept-Language 415 c
Alert-Info -
Allow R o
Allow 2xx o
Allow r o
Allow 405 m
Allow-Events (1) -
Authentication-Info 2xx o
Authorization R o
Call-ID c r m
Call-Info ar o
Contact R m
Contact 1xx o
Contact 2xx m
Contact 3xx d o
Contact 485 o
Content-Disposition o
Content-Encoding o
Content-Language o
Content-Length ar t
Content-Type *
CSeq c r m
Date a o
Error-Info 300-699 a o
Event (1) -
Expires -
From c r m
In-Reply-To -
Max-Forwards R amr m
Min-Expires -
MIME-Version o
Organization ar o
Table 1: Summary of header fields, A--O ; (1) defined in [5].
表1：ヘッダーフィールドの概要、A - O。（1）[5]で定義されています。
Header field where proxy UPDATE
____________________________________________________
Priority -
Proxy-Authenticate 407 ar m
Proxy-Authenticate 401 ar o
Proxy-Authorization R dr o
Proxy-Require R ar o
RAck R -
Record-Route R ar o
Record-Route 2xx,18x mr o
Reply-To -
Require ar c
Retry-After 404,413,480,486 o
500,503 o
600,603 o
Route R adr c
RSeq - -
Server r o
Subject - -
Subscription-State (1) -
Supported R o
Supported 2xx o
Timestamp o
To c r m
Unsupported 420 m
User-Agent o
Via R amr m
Via rc dr m
Warning r o
WWW-Authenticate 401 ar m
WWW-Authenticate 407 ar o
Table 2: Summary of header fields, P--Z.
表2：ヘッダーフィールドの概要P - Z。
Caller Callee
| |
| |
|(1) INVITE with offer 1 |
|---------------------------->|
| |
| |
|(2) 180 with answer 1 |
|<----------------------------|
| |
| |
|(3) PRACK |
|---------------------------->|
| |
| |
|(4) 200 PRACK |
|<----------------------------|
| |
| |
|(5) UPDATE with offer 2 |
|---------------------------->|
| |
| |
|(6) 200 UPDATE with answer 2 |
|<----------------------------|
| |
| |
|(7) UPDATE with offer 3 |
|<----------------------------|
| |
| |
|(8) 200 UPDATE with answer 3 |
|---------------------------->|
| |
| |
|(9) 200 INVITE |
|<----------------------------|
| |
| |
|(10) ACK |
|---------------------------->|
| |
| |
| |
| |
Figure 1: UPDATE Call Flow
図1：コールフローを更新します
9 Security Considerations
9セキュリティに関する考慮事項
The security considerations for UPDATE are identical to those for re-INVITE. It is important that the UPDATE be integrity protected and authenticated as coming from the same source as the entity on the other end of the dialog. RFC 3261 [1] discusses security mechanisms for achieving these functions.
更新のためのセキュリティ上の考慮事項は、Re-Inviteのためのものと同じです。更新が、ダイアログのもう一方の終わりのエンティティと同じ送信元からの積分保護され、認証されることが重要です。RFC 3261 [1]はこれらの機能を達成するためのセキュリティメカニズムについて説明します。
10 IANA Considerations
10 IANAの考慮事項
As per Section 27.4 of RFC 3261 [1], this specification serves as a registration for the SIP UPDATE request method. The information to be added to the registry is:
RFC 3261のセクション27.4と同様に、本明細書はSIP更新要求方法の登録として機能します。レジストリに追加される情報は次のとおりです。
RFC 3311: This specification serves as the RFC for registering the UPDATE request method.
RFC 3311：この仕様は、更新要求方法を登録するためのRFCとして機能します。
Method Name: UPDATE
メソッド名：更新
Reason Phrase: Not applicable.
理由句：該当なし。
11 Notice Regarding Intellectual Property Rights
11知的財産権に関するお知らせ
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は、この文書に含まれる仕様の一部または全部に関して主張されている知的財産権の通知を受けています。詳細については、請求先の権利のオンラインリストを参照してください。
12 Normative References
12規範的な参考文献
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.およびE. Schooler、 "SIP：セッション開始プロトコル"、RFC 3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S.、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] Rosenberg、J.およびH.Schulzrinne、「セッション記述プロトコル（SDP）」、RFC 3264、2002年6月のオファー/アンサーモデル。
[4] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[4] Rosenberg、J.およびH.Schulzrinne、「セッション開始プロトコル（SIP）」、RFC 3262、2002年6月の「暫定反応の信頼性」。
[5] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5] ROCH、A.B.「セッション開始プロトコル（SIP） - 特殊イベント通知」、RFC 3265、2002年6月。
13 Acknowledgements
13承認
The author would like to thank Jo Hornsby, Markus Isomaki, Rohan Mahy, and Bob Penfield for their comments.
著者は、Jo Hornsby、Markus Isomaki、Rohan Mahy、およびBob Penfieldにコメントをお寄せいただきありがとうございます。
14 Author's Address
14著者の住所
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
Jonathan Rosenberg Dynamicsoft 72 Eagle Rock Avenue 1階East Hanover、NJ 07936
EMail: jdrosen@dynamicsoft.com
15 Full Copyright Statement
15完全著作権宣言
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（c）インターネット社会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書と翻訳はコピーされている可能性があり、他の文書にはコピーされ、その実装を説明するか、またはその実装を説明するか、またはその実装を支援することができます。上記の著作権通知とこの段落がそのようなすべてのコピーや派生的な作品に含まれているとしました。ただし、この文書自体は、インターネット規格を開発するために必要な場合を除き、インターネット社会や他のインターネット組織への参照を削除するなど、著作権社会やその他のインターネット組織への参照を除去することはできません。インターネット標準プロセスに従う必要があるか、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた権限は永続的であり、インターネット社会やその後継者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本明細書に含まれる情報は、「現状」ベースで提供されており、インターネット社会とインターネットエンジニアリングのタスクフォースは、本明細書の情報の使用が含まれないことを含むが、これに限定されない、またはこれに限定されないすべての保証を損なう。特定の目的のための商品性または適合性の権利または黙示的な保証を侵害する。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディタ機能のための資金は、現在インターネット社会によって提供されています。