Network Working Group J. Rosenberg
Request for Comments: 3311 dynamicsoft
Category: Standards Track September 2002
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（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）的新更新方法。更新允许客户端更新会话的参数（例如媒体流集及其编解码器），但不会影响对话框的状态。从这个意义上讲，它类似于重新邀请，但与重新邀请不同，它可以在初始邀请完成之前发送。这对于在早期对话框中更新会话参数非常有用。
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 .............................................. 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方法。然而，这种方法实际上会影响两个重要的状态。它影响会话（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.
主要的困难是在初始邀请得到响应之前需要修改会话的某些方面。这种情况的一个例子是“早期媒体”，这是一种建立会话的条件，目的是传递呼叫的进度，但在接受邀请之前。呼叫方或被呼叫方在应答呼叫之前必须能够修改该会话的特征（例如，将早期媒体置于等待状态），这一点很重要。但是，重新邀请不能用于此目的，因为除了会话之外，重新邀请还会影响对话框的状态。
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请求的最终响应之前提供更新的会话信息。这里定义的UPDATE方法满足了这一需求。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.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”将按照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.
此扩展的操作非常简单。调用方以INVITE事务开始，该事务正常进行。一旦建立了一个对话框，无论是早期的还是确认的，调用方都可以生成一个更新方法，该方法包含SDP提供[3]，用于更新会话。对UPDATE方法的响应包含答案。类似地，一旦建立了一个对话框，被调用方就可以发送一个带有要约的更新，并且调用方将其答案放在更新的2xx中。“允许标头”字段用于指示对更新方法的支持。根据提供/应答模型的限制，何时可以使用更新还有其他限制。
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请求中包含一个Allow 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响应应该包含列出更新方法的允许标头字段。
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上创建早期对话。要接收被叫方的更新请求，必须创建此对话框。
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”的Allow header字段，则UAC知道被叫方支持UPDATE，并且允许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节所述，更新请求与现有对话框中的任何其他请求一样构造。它可以发送给提前对话和确认对话，也可以由呼叫者或被呼叫者发送。虽然可以在已确认的对话框上使用更新，但建议改用重新邀请。这是因为需要立即回复更新，排除了用户批准的可能性。通常需要此类批准，并且可以通过重新邀请获得批准。
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 to INVITE的Contact header字段中，并将其放入更新请求或响应中。
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 如果更新是在初始邀请交易完成之前发送的，并且初始邀请包含要约，则如果被叫方在可靠的临时响应中生成了答复，并且主叫方已收到其在PRACK或UPDATE中发送的任何其他要约的答复，则更新可以包含要约，并为其在被呼叫方的更新中收到的任何报价生成了答案。
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不包含要约，则如果被叫方在可靠的临时响应中生成要约，并且UAC在相应的PRACK中生成应答，则更新可以包含要约。当然，如果它没有收到PRACK或UPDATE中发送的任何其他报价的答复，或者没有生成从被叫方在更新中收到的任何其他报价的答复，则它无法发送更新。
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事务完成之前发送的，并且初始INVITE包含要约，则更新不能与要约一起发送，除非被叫方已在可靠的临时响应中生成应答，已收到该可靠的临时响应的PRACK，且未收到任何请求（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未包含要约，则除非被叫方已在可靠的临时响应中发送要约、在恶作剧中收到答复，并且未收到任何包含其未答复的要约的更新请求，否则无法随要约一起发送更新，并且未发送任何包含尚未答复的报价的更新请求。
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事务完成后发送的，则如果被叫方在重新邀请或更新中生成或接收到未应答的要约，则无法将其与要约一起发送。
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秒之间随机选择值的Retry After标头字段。
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
如果收到包含报价的更新，并且UAS生成了一个报价（在更新、PRACK或INVITE中），但尚未收到答复，则UAS必须以491响应拒绝更新。类似地，如果收到包含报价的更新，并且UAS收到了尚未生成答复的报价（在更新、PRACK或INVITE中），则UAS必须
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.
以500响应拒绝更新，并且必须包含一个在0到10秒之间随机选择值的Retry After标头字段。
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响应中生成答案。但是，与重新邀请不同，更新必须及时响应，因此通常不会提示用户批准会话更改。如果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[1]第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仍希望修改会话，则应再次尝试更新。例如，如果电话已挂断，则不会进行更新。
6 Proxy Behavior
6代理行为
Proxy processing of the UPDATE request is identical to any other non-INVITE request.
更新请求的代理处理与任何其他非INVITE请求相同。
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
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.
表2更新了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.
本节介绍使用UPDATE方法的示例调用流。流程如图1所示。调用者发送一个包含要约的初始邀请（1）。被呼叫者生成180响应（2），其中包含对该提议的回答。在提供/应答交换完成后，会话将建立，尽管对话框仍处于早期状态。调用者生成一个PRACK（3）来确认180，并用200 OK（4）回答该PRACK。调用者决定更新会话的某些方面，例如，将其挂起。因此，它们生成一个更新请求（5）和一个新的报价。这一提议在对更新的200条回复中得到了回应（6）。此后不久，被叫方决定更新会话的某些方面，因此它生成带有要约的更新请求（7），并在200响应（8）中发送应答。最后，被叫方应答呼叫，从而对INVITE（9）做出200 OK响应，然后是ACK（10）。INVITE的200 OK和ACK都不包含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
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
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 |
|---------------------------->|
| |
| |
| |
| |
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.
更新的安全注意事项与重新邀请的安全注意事项相同。更新必须受到完整性保护并进行身份验证，因为它与对话框另一端的实体来自同一来源。RFC 3261[1]讨论了实现这些功能的安全机制。
10 IANA Considerations
10国际航空航天协会的考虑事项
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[1]第27.4节，本规范作为SIP更新请求方法的注册。要添加到注册表的信息为：
RFC 3311: This specification serves as the RFC for registering the UPDATE request method.
RFC3311：此规范用作注册更新请求方法的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] Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，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大道一楼东汉诺威，NJ 07936
EMail: jdrosen@dynamicsoft.com
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编辑功能的资金目前由互联网协会提供。