Internet Engineering Task Force (IETF) G. Camarillo, Ed.
Request for Comments: 6141 C. Holmberg
Updates: 3261 Ericsson
Category: Standards Track Y. Gao
ISSN: 2070-1721 ZTE
March 2011
Internet Engineering Task Force (IETF) G. Camarillo, Ed.
Request for Comments: 6141 C. Holmberg
Updates: 3261 Ericsson
Category: Standards Track Y. Gao
ISSN: 2070-1721 ZTE
March 2011
Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP)
会话启动协议（SIP）中的重新邀请和目标刷新请求处理
Abstract
摘要
The procedures for handling SIP re-INVITEs are described in RFC 3261. Implementation and deployment experience has uncovered a number of issues with the original documentation, and this document provides additional procedures that update the original specification to address those issues. In particular, this document defines in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, this document defines further details of procedures related to target-refresh requests.
RFC 3261中描述了处理SIP重新邀请的过程。实施和部署经验揭示了原始文档中存在的一些问题，本文档提供了更新原始规范以解决这些问题的附加过程。特别是，本文档定义了在哪些情况下UAS（用户代理服务器）应生成成功响应，以及在哪些情况下UAS应生成重新邀请的错误响应。此外，本文档还定义了与目标刷新请求相关的过程的更多详细信息。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6141.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6141.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Changing the Session State during a Re-INVITE ...................5
3.1. Background on Re-INVITE Handling by UASs ...................5
3.2. Problems with Error Responses and Already Executed Changes .9
3.3. UAS Behavior ..............................................10
3.4. UAC Behavior ..............................................11
3.5. Glare Situations ..........................................11
3.6. Example of UAS Behavior ...................................12
3.7. Example of UAC Behavior ...................................14
3.8. Clarifications on Canceling Re-INVITEs ....................17
4. Refreshing a Dialog's Targets ..................................17
4.1. Background and Terminology on a Dialog's Targets ..........17
4.2. Background on Target-Refresh Requests .....................17
4.3. Clarification on the Atomicity of Target-Refresh Requests .18
4.4. UA Updating the Dialog's Local Target in a Request ........19
4.5. UA Updating the Dialog's Local Target in a Response .......19
4.6. A Request Updating the Dialog's Remote Target .............19
4.7. A Response Updating the Dialog's Remote Target ............20
4.8. Race Conditions and Target Refreshes ......................20
4.9. Early Dialogs .............................................21
5. A UA Losing Its Contact ........................................21
5.1. Background on Re-INVITE Transaction Routing ...............22
5.2. Problems with UAs Losing Their Contact ....................22
5.3. UAS Losing Its Contact: UAC Behavior ......................22
5.4. UAC Losing Its Contact: UAS Behavior ......................23
5.5. UAC Losing Its Contact: UAC Behavior ......................24
6. Security Considerations ........................................24
7. Acknowledgements ...............................................24
8. References .....................................................25
8.1. Normative References ......................................25
8.2. Informative References ....................................25
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Changing the Session State during a Re-INVITE ...................5
3.1. Background on Re-INVITE Handling by UASs ...................5
3.2. Problems with Error Responses and Already Executed Changes .9
3.3. UAS Behavior ..............................................10
3.4. UAC Behavior ..............................................11
3.5. Glare Situations ..........................................11
3.6. Example of UAS Behavior ...................................12
3.7. Example of UAC Behavior ...................................14
3.8. Clarifications on Canceling Re-INVITEs ....................17
4. Refreshing a Dialog's Targets ..................................17
4.1. Background and Terminology on a Dialog's Targets ..........17
4.2. Background on Target-Refresh Requests .....................17
4.3. Clarification on the Atomicity of Target-Refresh Requests .18
4.4. UA Updating the Dialog's Local Target in a Request ........19
4.5. UA Updating the Dialog's Local Target in a Response .......19
4.6. A Request Updating the Dialog's Remote Target .............19
4.7. A Response Updating the Dialog's Remote Target ............20
4.8. Race Conditions and Target Refreshes ......................20
4.9. Early Dialogs .............................................21
5. A UA Losing Its Contact ........................................21
5.1. Background on Re-INVITE Transaction Routing ...............22
5.2. Problems with UAs Losing Their Contact ....................22
5.3. UAS Losing Its Contact: UAC Behavior ......................22
5.4. UAC Losing Its Contact: UAS Behavior ......................23
5.5. UAC Losing Its Contact: UAC Behavior ......................24
6. Security Considerations ........................................24
7. Acknowledgements ...............................................24
8. References .....................................................25
8.1. Normative References ......................................25
8.2. Informative References ....................................25
As discussed in Section 14 of RFC 3261 [RFC3261], an INVITE request sent within an existing dialog is known as a re-INVITE. A re-INVITE is used to modify session parameters, dialog parameters, or both. That is, a single re-INVITE can change both the parameters of its associated session (e.g., changing the IP address where a media stream is received) and the parameters of its associated dialog (e.g., changing the remote target of the dialog). A re-INVITE can change the remote target of a dialog because it is a target refresh request, as defined in Section 6 of RFC 3261 [RFC3261].
如RFC 3261[RFC3261]第14节所述，在现有对话框中发送的邀请请求称为重新邀请。重新邀请用于修改会话参数、对话框参数或两者。也就是说，单个重新邀请可以更改其关联会话的参数（例如，更改接收媒体流的IP地址）和其关联对话框的参数（例如，更改对话框的远程目标）。重新邀请可以更改对话框的远程目标，因为它是RFC 3261[RFC3261]第6节中定义的目标刷新请求。
A re-INVITE transaction has an offer/answer [RFC3264] exchange associated with it. The UAC (User Agent Client) generating a given re-INVITE can act as the offerer or as the answerer. A UAC willing to act as the offerer includes an offer in the re-INVITE. The UAS (User Agent Server) then provides an answer in a response to the re-INVITE. A UAC willing to act as answerer does not include an offer in the re-INVITE. The UAS then provides an offer in a response to the re-INVITE becoming, thus, the offerer.
重新邀请事务具有与其关联的要约/应答[RFC3264]交换。生成给定重新邀请的UAC（用户代理客户端）可以充当报价人或应答人。愿意担任报价人的UAC在重新邀请中包括报价。然后，UAS（用户代理服务器）在响应重新邀请时提供答案。愿意担任答复者的UAC在重新邀请中不包括报价。然后，UAS提供报价，以响应重新邀请，从而成为报价人。
Certain transactions within a re-INVITE (e.g., UPDATE [RFC3311] transactions) can also have offer/answer exchanges associated to them. A UA (User Agent) can act as the offerer or the answerer in any of these transactions regardless of whether the UA was the offerer or the answerer in the umbrella re-INVITE transaction.
重新邀请中的某些事务（例如更新[RFC3311]事务）也可以具有与之关联的报价/应答交换。UA（用户代理）可以在任何此类交易中充当报价人或应答人，无论UA是伞式再邀请交易中的报价人还是应答人。
There has been some confusion among implementors regarding how a UAS should handle re-INVITEs. In particular, implementors requested clarification on which type of response a UAS should generate in different situations. In this document, we clarify these issues.
对于UAS应该如何处理重新邀请，实现者之间存在一些困惑。具体而言，实施者要求澄清UAS在不同情况下应产生何种类型的响应。在本文件中，我们将澄清这些问题。
Additionally, there has also been some confusion among implementors regarding target refresh requests, which include but are not limited to re-INVITEs. In this document, we also clarify the process by which remote targets are refreshed.
此外，对于目标刷新请求（包括但不限于重新邀请），实现者之间也存在一些混淆。在本文档中，我们还将阐明刷新远程目标的过程。
Indented passages such as this one are used in this document to provide additional information and clarifying text. They do not contain normative protocol behavior.
本文档中使用缩进段落（如本段落）来提供附加信息和澄清文本。它们不包含规范的协议行为。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
UA: User Agent.
用户代理。
UAC: User Agent Client.
用户代理客户端。
UAS: User Agent Server.
UAS：用户代理服务器。
Note that the terms UAC and UAS are used with respect to an INVITE or re-INVITE transaction and do not necessarily reflect the role of the UA concerned with respect to any other transaction, such as an UPDATE transaction occurring within the INVITE transaction.
请注意，术语UAC和UAS用于邀请或重新邀请交易，并不一定反映相关UA在任何其他交易（如邀请交易中发生的更新交易）中的角色。
The following sub-sections discuss how to change the state of the session during a re-INVITE transaction.
以下小节讨论如何在重新邀请事务期间更改会话状态。
Eventually, a UAS receiving a re-INVITE will need to generate a response to it. Some re-INVITEs can be responded to immediately because their handling does not require user interaction (e.g., changing the IP address where a media stream is received). The handling of other re-INVITEs requires user interaction (e.g., adding a video stream to an audio-only session). Therefore, these re-INVITEs cannot be responded to immediately.
最终，收到重新邀请的UAS需要生成响应。一些重新邀请可以立即响应，因为它们的处理不需要用户交互（例如，更改接收媒体流的IP地址）。处理其他重新邀请需要用户交互（例如，向仅音频会话添加视频流）。因此，这些重新邀请无法立即响应。
An error response to a re-INVITE has the following semantics. As specified in Section 12.2.2 of RFC 3261 [RFC3261], if a re-INVITE is rejected, no state changes are performed. These state changes include state changes associated to the re-INVITE transaction and all other transactions within the re-INVITE (this section deals with changes to the session state; target refreshes are discussed in Section 4.2). That is, the session state is the same as before the re-INVITE was received. The example in Figure 1 illustrates this point.
对重新邀请的错误响应具有以下语义。按照RFC 3261[RFC3261]第12.2.2节的规定，如果重新邀请被拒绝，则不执行状态更改。这些状态更改包括与重新邀请事务相关的状态更改以及重新邀请中的所有其他事务（本节讨论会话状态的更改；第4.2节讨论了目标刷新）。也就是说，会话状态与收到重新邀请之前相同。图1中的示例说明了这一点。
UAC UAS
UAC UAS
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------------(2) 200 OK SDP2----------------|
| |
|------------------(3) ACK------------------>|
| |
| |
|-------------(4) INVITE SDP3--------------->|
| |
|<-----------------(5) 4xx-------------------|
| |
|------------------(6) ACK------------------>|
| |
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------------(2) 200 OK SDP2----------------|
| |
|------------------(3) ACK------------------>|
| |
| |
|-------------(4) INVITE SDP3--------------->|
| |
|<-----------------(5) 4xx-------------------|
| |
|------------------(6) ACK------------------>|
| |
Figure 1: Rejection of a re-INVITE
图1：拒绝重新邀请
The UAs perform an offer/answer exchange to establish an audio-only session:
UAs执行提供/应答交换以建立仅音频会话：
SDP1: m=audio 30000 RTP/AVP 0
SDP1:m=音频30000 RTP/AVP 0
SDP2: m=audio 31000 RTP/AVP 0
SDP2:m=音频31000 RTP/AVP 0
At a later point, the UAC sends a re-INVITE (4) in order to add a video stream to the session.
稍后，UAC发送重新邀请（4），以便向会话添加视频流。
SDP3:
m=audio 30000 RTP/AVP 0
m=video 30002 RTP/AVP 31
SDP3:
m=audio 30000 RTP/AVP 0
m=video 30002 RTP/AVP 31
The UAS is configured to automatically reject video streams. Consequently, the UAS returns an error response (5). At that point, the session parameters in use are still those resulting from the initial offer/answer exchange, which are described by SDP1 and SDP2. That is, the session state is the same as before the re-INVITE was received.
UAS配置为自动拒绝视频流。因此，UAS返回错误响应（5）。此时，正在使用的会话参数仍然是由初始提供/应答交换产生的会话参数，这些参数由SDP1和SDP2描述。也就是说，会话状态与收到重新邀请之前相同。
In the previous example, the UAS rejected all the changes requested in the re-INVITE by returning an error response. However, there are situations where a UAS wants to accept some but not all the changes requested in a re-INVITE. In these cases, the UAS generates a 200 (OK) response with a Session Description Protocol (SDP) indicating which changes were accepted and which were not. The example in Figure 2 illustrates this point.
在前面的示例中，UAS通过返回错误响应拒绝了重新邀请中请求的所有更改。但是，在某些情况下，UAS希望接受重新邀请中请求的部分更改，而不是全部更改。在这些情况下，UAS生成一个200（OK）响应，该响应带有会话描述协议（SDP），指示哪些更改被接受，哪些更改未被接受。图2中的示例说明了这一点。
UAC UAS
UAC UAS
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------------(2) 200 OK SDP2----------------|
| |
|------------------(3) ACK------------------>|
| |
| |
|-------------(4) INVITE SDP3--------------->|
| |
|<------------(5) 200 OK SDP4----------------|
| |
|------------------(6) ACK------------------>|
| |
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------------(2) 200 OK SDP2----------------|
| |
|------------------(3) ACK------------------>|
| |
| |
|-------------(4) INVITE SDP3--------------->|
| |
|<------------(5) 200 OK SDP4----------------|
| |
|------------------(6) ACK------------------>|
| |
Figure 2: Automatic rejection of a video stream
图2：自动拒绝视频流
The UAs perform an offer/answer exchange to establish an audio-only session:
UAs执行提供/应答交换以建立仅音频会话：
SDP1: m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.1
SDP1:m=音频30000 RTP/AVP 0 c=在IP4 192.0.2.1中
SDP2: m=audio 31000 RTP/AVP 0 c=IN IP4 192.0.2.5
SDP2:m=音频31000 RTP/AVP 0 c=在IP4 192.0.2.5中
At a later point, the UAC moves to an access that provides a higher bandwidth. Therefore, the UAC sends a re-INVITE (4) in order to change the IP address where it receives the audio stream to its new IP address and add a video stream to the session.
稍后，UAC转向提供更高带宽的接入。因此，UAC发送重新邀请（4），以便将接收音频流的IP地址更改为其新的IP地址，并向会话添加视频流。
SDP3:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.2
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.2
SDP3:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.2
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.2
The UAS is automatically configured to reject video streams. However, the UAS needs to accept the change of the audio stream's remote IP address. Consequently, the UAS returns a 200 (OK) response and sets the port of the video stream to zero in its SDP.
UAS自动配置为拒绝视频流。但是，UAS需要接受音频流远程IP地址的更改。因此，UAS返回200（OK）响应，并在其SDP中将视频流的端口设置为零。
SDP4:
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 0 RTP/AVP 31
SDP4:
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 0 RTP/AVP 31
In the previous example, the UAS was configured to automatically reject the addition of video streams. The example in Figure 3 assumes that the UAS requires its user's input in order to accept or reject the addition of a video stream and uses reliable provisional responses [RFC3262] (PRACK transactions are not shown for clarity).
在前面的示例中，UAS被配置为自动拒绝添加视频流。图3中的示例假设UAS需要其用户的输入以接受或拒绝视频流的添加，并使用可靠的临时响应[RFC3262]（为了清晰起见，未显示PRACK事务）。
UAC UAS
UAC UAS
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------------(2) 200 OK SDP2----------------|
| |
|------------------(3) ACK------------------>|
| |
| |
|-------------(4) INVITE SDP3--------------->|
| |
|<----(5) 183 Session Progress SDP4----------|
| |
| |
|<------------(6) UPDATE SDP5----------------|
| |
|-------------(7) 200 OK SDP6--------------->|
| |
|<---------------(8) 200 OK------------------|
| |
|------------------(9) ACK------------------>|
| |
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------------(2) 200 OK SDP2----------------|
| |
|------------------(3) ACK------------------>|
| |
| |
|-------------(4) INVITE SDP3--------------->|
| |
|<----(5) 183 Session Progress SDP4----------|
| |
| |
|<------------(6) UPDATE SDP5----------------|
| |
|-------------(7) 200 OK SDP6--------------->|
| |
|<---------------(8) 200 OK------------------|
| |
|------------------(9) ACK------------------>|
| |
Figure 3: Manual rejection of a video stream by the user
图3：用户手动拒绝视频流
Everything up to (4) is identical to the previous example. In (5), the UAS accepts the change of the audio stream's remote IP address but does not accept the video stream yet (it provides a null IP address instead of setting the stream to 'inactive' because inactive streams still need to exchange RTP Control Protocol (RTCP) traffic).
（4）之前的所有内容都与前面的示例相同。在（5）中，UAS接受音频流远程IP地址的更改，但不接受视频流（它提供一个空IP地址，而不是将流设置为“非活动”，因为非活动流仍然需要交换RTP控制协议（RTCP）流量）。
SDP4:
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 31002 RTP/AVP 31
c=IN IP4 0.0.0.0
SDP4:
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 31002 RTP/AVP 31
c=IN IP4 0.0.0.0
At a later point, the UAS's user rejects the addition of the video stream. Consequently, the UAS sends an UPDATE request (6) setting the port of the video stream to zero in its offer.
稍后，UAS的用户拒绝添加视频流。因此，UAS发送更新请求（6），在其提供中将视频流的端口设置为零。
SDP5:
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 0 RTP/AVP 31
c=IN IP4 0.0.0.0
SDP5:
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 0 RTP/AVP 31
c=IN IP4 0.0.0.0
The UAC returns a 200 (OK) response (7) to the UPDATE with the following answer:
UAC向更新返回200（OK）响应（7），并给出以下答案：
SDP6:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.2
m=video 0 RTP/AVP 31
SDP6:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.2
m=video 0 RTP/AVP 31
The UAS now returns a 200 (OK) response (8) to the re-INVITE.
UAS现在向重新邀请返回200（确定）响应（8）。
In all the previous examples, the UAC of the re-INVITE transaction was the offerer. Examples with UACs acting as the answerers would be similar.
在前面的所有示例中，重新邀请交易的UAC是报价人。UAC作为回答者的例子类似。
Section 3.1 contains examples on how a UAS rejects all the changes requested in a re-INVITE without executing any of them by returning an error response (Figure 1), and how a UAS executes some of the changes requested in a re-INVITE and rejects some of them by returning a 2xx response (Figures 2 and 3). A UAS can accept and reject different sets of changes simultaneously (Figure 2) or at different times (Figure 3).
第3.1节包含UAS如何通过返回错误响应（图1）拒绝重新邀请中请求的所有更改而不执行任何更改，以及UAS如何执行重新邀请中请求的一些更改并通过返回2xx响应拒绝其中一些更改的示例（图2和图3）。UAS可以同时（图2）或在不同时间（图3）接受和拒绝不同的变更集。
The scenario that created confusion among implementors consists of a UAS that receives a re-INVITE, executes some of the changes requested in it, and then wants to reject all those already executed changes and revert to the pre-re-INVITE state. Such a UAS may consider returning an error response to the re-INVITE (the message flow would be similar to the one in Figure 1), or using an UPDATE request to revert to the pre-re-INVITE state and then returning a 2xx response to the re-INVITE (the message flow would be similar to the one in Figure 3). This section explains the problems associated with returning an error response in these circumstances. In order to avoid these problems, the UAS should use the latter option (UPDATE request plus a 2xx response). Sections 3.3 and 3.4 contain the normative statements needed to avoid these problems.
在实现者之间造成混乱的场景包括一个UAS，它接收重新邀请，执行其中请求的一些更改，然后想要拒绝所有已经执行的更改并恢复到重新邀请前的状态。这样的UAS可以考虑向Read邀请返回错误响应（消息流将类似于图1中的一个），或者使用更新请求恢复到Real-Read邀请状态，然后向Read邀请返回2XX响应（消息流将类似于图3中的消息流）。本节解释了在这些情况下与返回错误响应相关的问题。为了避免这些问题，UAS应该使用后一个选项（更新请求加上2xx响应）。第3.3节和第3.4节包含了避免这些问题所需的规范性声明。
The reason for not using an error response to undo already executed changes is that an error response to a re-INVITE for which changes have already been executed (e.g., as a result of UPDATE transactions or reliable provisional responses) is effectively requesting a change in the session state. However, the UAC has no means to reject that change if it is unable to execute them. That is, if the UAC is unable to revert to the pre-re-INVITE state, it will not be able to communicate this fact to the UAS.
不使用错误响应撤消已执行的更改的原因是，对已执行更改（例如，由于更新事务或可靠的临时响应）的重新邀请的错误响应实际上是请求更改会话状态。然而，如果UAC无法执行这些变更，它就没有办法拒绝这些变更。也就是说，如果UAC无法恢复到重新邀请前的状态，它将无法将此事实传达给UAS。
UASs should only return an error response to a re-INVITE if no changes to the session state have been executed since the re-INVITE was received. Such an error response indicates that no changes have been executed as a result of the re-INVITE or any other transaction within it.
如果自收到重新邀请后未对会话状态执行任何更改，UAS应仅向重新邀请返回错误响应。这样的错误响应表明，由于重新邀请或其中的任何其他事务，没有执行任何更改。
If any of the changes requested in a re-INVITE or in any transaction within it have already been executed, the UAS SHOULD return a 2xx response.
如果重新邀请中或其中任何事务中请求的任何更改已经执行，UAS应返回2xx响应。
A change to the session state is considered to have been executed if an offer/answer without preconditions [RFC4032] for the stream has completed successfully or the UA has sent or received media using the new parameters. Connection establishment messages (e.g., TCP SYN), connectivity checks (e.g., when using Interactive Connectivity Establishment (ICE) [RFC5245]), and any other messages used in the process of meeting the preconditions for a stream are not considered media.
如果流的无先决条件提供/应答[RFC4032]已成功完成，或者UA已使用新参数发送或接收媒体，则视为已执行对会话状态的更改。连接建立消息（例如，TCP SYN）、连接检查（例如，当使用交互式连接建立（ICE）[RFC5245]时）以及在满足流的先决条件的过程中使用的任何其他消息不被视为媒体。
Normally, a UA receiving media can easily detect when the new parameters for the media stream are used (e.g., media is received on a new port). However, in some scenarios, the UA will have to process incoming media packets in order to detect whether they use the old or new parameters.
通常，UA接收媒体可以容易地检测何时使用媒体流的新参数（例如，在新端口上接收媒体）。然而，在某些情况下，UA必须处理传入的媒体数据包，以便检测它们是否使用旧的或新的参数。
The successful completion of an offer/answer exchange without preconditions indicates that the new parameters for the media stream are already considered to be in use. The successful completion of an offer/answer exchange with preconditions means something different. The fact that all mandatory preconditions for the stream are met indicates that the new parameters for the media stream are ready to be used. However, they will not actually be used until the UAS decides to use them. During a session establishment, the UAS can wait before using the media parameters until the callee starts being alerted or until the callee accepts the session. During a session modification, the UAS can wait until its user accepts the changes to the session. When dealing with streams where the UAS sends media
在没有先决条件的情况下成功完成要约/应答交换表明媒体流的新参数已被认为在使用中。在有前提条件的情况下成功完成要约/应答交换意味着不同的事情。满足流的所有强制先决条件表明媒体流的新参数已准备好使用。然而，在UAS决定使用它们之前，它们实际上不会被使用。在会话建立期间，UAS可以在使用媒体参数之前等待，直到被叫方开始收到警报，或者直到被叫方接受会话。在会话修改期间，UAS可以等待直到其用户接受对会话的更改。处理UAS发送媒体的流时
more or less continuously, the UAC notices that the new parameters are in use because the UAC receives media that uses the new parameters. However, this mechanism does not work with other types of streams. Therefore, it is RECOMMENDED that when a UAS decides to start using the new parameters for a stream for which all mandatory preconditions have been met, the UAS either sends media using the new parameters or sends a new offer where the precondition-related attributes for the stream have been removed. As indicated above, the successful completion of an offer/answer exchange without preconditions indicates that the new parameters for the media stream are already considered to be in use.
UAC或多或少连续地注意到新参数正在使用，因为UAC接收使用新参数的媒体。但是，此机制不适用于其他类型的流。因此，建议当UAS决定开始为满足所有强制先决条件的流使用新参数时，UAS使用新参数发送媒体，或者在流的先决条件相关属性已被删除的情况下发送新要约。如上所述，在没有先决条件的情况下成功完成要约/应答交换表明媒体流的新参数已经被认为在使用中。
A UAC that receives an error response to a re-INVITE that undoes already executed changes within the re-INVITE may be facing a legacy UAS that does not support this specification (i.e., a UAS that does not follow the guidelines in Section 3.3). There are also certain race condition situations that get both user agents out of synchronization. In order to cope with these race condition situations, a UAC that receives an error response to a re-INVITE for which changes have been already executed SHOULD generate a new re-INVITE or UPDATE request in order to make sure that both UAs have a common view of the state of the session (the UAC uses the criteria in Section 3.3 in order to decide whether or not changes have been executed for a particular stream). The purpose of this new offer/ answer exchange is to synchronize both UAs, not to request changes that the UAS may choose to reject. Therefore, session parameters in the offer/answer exchange SHOULD be as close to those in the pre-re-INVITE state as possible.
接收到对重新邀请的错误响应并撤销重新邀请中已执行的更改的UAC可能面临不支持此规范的遗留UAS（即，不遵守第3.3节指南的UAS）。还有一些特定的竞争条件会使两个用户代理失去同步。为了应对这些竞争条件情况，接收到对已执行更改的重新邀请的错误响应的UAC应生成新的重新邀请或更新请求，以确保两个UAs都具有会话状态的通用视图（UAC使用第3.3节中的标准来决定是否对特定流执行了更改）。此新的提供/应答交换的目的是同步两个UAs，而不是请求UAs可能选择拒绝的更改。因此，提供/应答交换中的会话参数应尽可能接近重新邀请前状态中的会话参数。
Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user agent receiving an offer after having sent one but before having received an answer to it. That section specifies rules to avoid glare situations in most cases. When, despite following those rules, a glare condition occurs (as a result of a race condition), it is handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261]. The UAS returns a 491 (Request Pending) response and the UAC retries the offer after a randomly selected time, which depends on which user agent is the owner of the Call-ID of the dialog. The rules in RFC 3261 [RFC3261] not only cover collisions between re-INVITEs that contain offers, they cover collisions between two re-INVITEs in general, even if they do not contain offers. Sections 5.2 and 5.3 of RFC 3311 [RFC3311] extend those rules to also cover collisions between an UPDATE request carrying an offer and another message (UPDATE, PRACK, or INVITE) also carrying an offer.
RFC 3264[RFC3264]第4节将眩光条件定义为用户代理在发送报价后但在收到答复之前接收报价。该部分规定了在大多数情况下避免眩光情况的规则。尽管遵守了这些规则，但当眩光条件发生时（由于比赛条件），应按照RFC 3261[RFC3261]第14.1节和第14.2节的规定进行处理。UAS返回491（请求挂起）响应，UAC在随机选择的时间后重试该提议，这取决于哪个用户代理是对话框呼叫ID的所有者。RFC 3261[RFC3261]中的规则不仅涵盖包含要约的重新邀请之间的冲突，通常也涵盖两个重新邀请之间的冲突，即使它们不包含要约。RFC 3311[RFC3311]的第5.2节和第5.3节扩展了这些规则，以涵盖包含要约的更新请求与包含要约的另一条消息（更新、恶作剧或邀请）之间的冲突。
The rules in RFC 3261 [RFC3261] do not cover collisions between an UPDATE request and a non-2xx final response to a re-INVITE. Since both the UPDATE request and the reliable response could be requesting changes to the session state, it would not be clear which changes would need to be executed first. However, the procedures discussed in Section 3.4 already cover this type of situation. Therefore, there is no need to specify further rules here.
RFC 3261[RFC3261]中的规则不包括更新请求和重新邀请的非2xx最终响应之间的冲突。由于更新请求和可靠响应都可能请求更改会话状态，因此不清楚需要首先执行哪些更改。然而，第3.4节中讨论的程序已经涵盖了此类情况。因此，无需在此指定进一步的规则。
This section contains an example of a UAS that implements this specification using an UPDATE request and a 2xx response to a re-INVITE in order to revert to the pre-re-INVITE state. The example shown in Figure 4 assumes that the UAS requires its user's input in order to accept or reject the addition of a video stream and uses reliable provisional responses [RFC3262] (PRACK transactions are not shown for clarity).
本节包含一个UAS示例，该UAS使用更新请求和对重新邀请的2xx响应来实现本规范，以恢复到重新邀请前的状态。图4所示的示例假设UAS需要其用户的输入以接受或拒绝视频流的添加，并使用可靠的临时响应[RFC3262]（为清晰起见，未显示PRACK事务）。
UAC UAS
UAC UAS
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------------(2) 200 OK SDP2----------------|
| |
|------------------(3) ACK------------------>|
| |
| |
|-------------(4) INVITE SDP3--------------->|
| |
|<----(5) 183 Session Progress SDP4----------|
| |
|-------------(6) UPDATE SDP5--------------->|
| |
|<------------(7) 200 OK SDP6----------------|
| |
| |
|<------------(8) UPDATE SDP7----------------|
| |
|-------------(9) 200 OK SDP8--------------->|
| |
|<--------------(10) 200 OK------------------|
| |
|-----------------(11) ACK------------------>|
| |
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------------(2) 200 OK SDP2----------------|
| |
|------------------(3) ACK------------------>|
| |
| |
|-------------(4) INVITE SDP3--------------->|
| |
|<----(5) 183 Session Progress SDP4----------|
| |
|-------------(6) UPDATE SDP5--------------->|
| |
|<------------(7) 200 OK SDP6----------------|
| |
| |
|<------------(8) UPDATE SDP7----------------|
| |
|-------------(9) 200 OK SDP8--------------->|
| |
|<--------------(10) 200 OK------------------|
| |
|-----------------(11) ACK------------------>|
| |
Figure 4: Rejection of a video stream by the user
图4：用户拒绝视频流
The UAs perform an offer/answer exchange to establish an audio-only session:
UAs执行提供/应答交换以建立仅音频会话：
SDP1: m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.1
SDP1:m=音频30000 RTP/AVP 0 c=在IP4 192.0.2.1中
SDP2: m=audio 31000 RTP/AVP 0 c=IN IP4 192.0.2.5
SDP2:m=音频31000 RTP/AVP 0 c=在IP4 192.0.2.5中
At a later point, the UAC sends a re-INVITE (4) in order to add a new codec to the audio stream and to add a video stream to the session.
稍后，UAC发送重新邀请（4），以便向音频流添加新的编解码器，并向会话添加视频流。
SDP3:
m=audio 30000 RTP/AVP 0 3
c=IN IP4 192.0.2.1
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.1
SDP3:
m=audio 30000 RTP/AVP 0 3
c=IN IP4 192.0.2.1
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.1
In (5), the UAS accepts the addition of the audio codec but does not accept the video stream yet (it provides a null IP address instead of setting the stream to 'inactive' because inactive streams still need to exchange RTCP traffic).
在（5）中，UAS接受添加音频编解码器，但还不接受视频流（它提供空IP地址，而不是将流设置为“非活动”，因为非活动流仍需要交换RTCP流量）。
SDP4:
m=audio 31000 RTP/AVP 0 3
c=IN IP4 192.0.2.5
m=video 31002 RTP/AVP 31
c=IN IP4 0.0.0.0
SDP4:
m=audio 31000 RTP/AVP 0 3
c=IN IP4 192.0.2.5
m=video 31002 RTP/AVP 31
c=IN IP4 0.0.0.0
At a later point, the UAC sends an UPDATE request (6) to remove the original audio codec from the audio stream (the UAC could have also used the PRACK to (5) to request this change).
稍后，UAC发送更新请求（6）以从音频流中删除原始音频编解码器（UAC也可以使用PRACK to（5）请求此更改）。
SDP5:
m=audio 30000 RTP/AVP 3
c=IN IP4 192.0.2.1
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.1
SDP5:
m=audio 30000 RTP/AVP 3
c=IN IP4 192.0.2.1
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.1
SDP6:
m=audio 31000 RTP/AVP 3
c=IN IP4 192.0.2.5
m=video 31002 RTP/AVP 31
c=IN IP4 0.0.0.0
SDP6:
m=audio 31000 RTP/AVP 3
c=IN IP4 192.0.2.5
m=video 31002 RTP/AVP 31
c=IN IP4 0.0.0.0
Yet, at a later point, the UAS's user rejects the addition of the video stream. Additionally, the UAS decides to revert to the original audio codec. Consequently, the UAS sends an UPDATE request (8) setting the port of the video stream to zero and offering the original audio codec in its SDP.
然而，稍后，UAS的用户拒绝添加视频流。此外，UAS决定恢复到原始音频编解码器。因此，UAS发送更新请求（8），将视频流的端口设置为零，并在其SDP中提供原始音频编解码器。
SDP7:
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 0 RTP/AVP 31
c=IN IP4 0.0.0.0
SDP7:
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 0 RTP/AVP 31
c=IN IP4 0.0.0.0
The UAC accepts the change in the audio codec in its 200 (OK) response (9) to the UPDATE request.
UAC在其对更新请求的200（确定）响应（9）中接受音频编解码器中的更改。
SDP8:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.1
m=video 0 RTP/AVP 31
c=IN IP4 192.0.2.1
SDP8:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.1
m=video 0 RTP/AVP 31
c=IN IP4 192.0.2.1
The UAS now returns a 200 (OK) response (10) to the re-INVITE. Note that the media state after this 200 (OK) response is the same as the pre-re-INVITE media state.
UAS现在向重新邀请返回200（确定）响应（10）。请注意，此200（确定）响应后的媒体状态与重新邀请前的媒体状态相同。
Figure 5 shows an example of a race condition situation in which the UAs end up with different views of the state of the session.
图5显示了一个竞争条件的示例，在这种情况下，UAs以会话状态的不同视图结束。
a:sendrecv a:sendrecv
v:inactive v:inactive
a:sendrecv a:sendrecv
v:inactive v:inactive
UA1 Proxy UA2
UA1代理UA2
| | |
|----(1) INVITE SDP1-->| |
| |----(2) INVITE SDP1-->|
| | |
| |<----(3) 183 SDP2-----| a:sendrecv
a:sendrecv |<----(4) 183 SDP2-----| | v:recvonly
v:sendonly | | |
| |<------(5) 4xx -------|
| |-------(6) ACK ------>| a:sendrecv
| +-(7) 4xx -| | v:inactive
| | |<---(8) UPDATE SDP3---|
|<---(9) UPDATE SDP3---| |
| | | |
a:sendonly |---(10) 200 OK SDP4-->| |
v:inactive | | |---(11) 200 OK SDP4-->| a:recvonly
|<-(7) 4xx -+ | | v:inactive
a:sendrecv |------(12) ACK ------>| |
v:inactive | | |
| | |
|----(1) INVITE SDP1-->| |
| |----(2) INVITE SDP1-->|
| | |
| |<----(3) 183 SDP2-----| a:sendrecv
a:sendrecv |<----(4) 183 SDP2-----| | v:recvonly
v:sendonly | | |
| |<------(5) 4xx -------|
| |-------(6) ACK ------>| a:sendrecv
| +-(7) 4xx -| | v:inactive
| | |<---(8) UPDATE SDP3---|
|<---(9) UPDATE SDP3---| |
| | | |
a:sendonly |---(10) 200 OK SDP4-->| |
v:inactive | | |---(11) 200 OK SDP4-->| a:recvonly
|<-(7) 4xx -+ | | v:inactive
a:sendrecv |------(12) ACK ------>| |
v:inactive | | |
a: status of the audio stream v: status of the video stream
a：音频流的状态v：视频流的状态
Figure 5: Message flow with race condition
图5：具有竞争条件的消息流
The UAs in Figure 5 are involved in a session that, just before the message flows in the figures starts, includes a sendrecv audio stream and an inactive video stream. UA1 sends a re-INVITE (1) requesting to make the video stream sendrecv.
图5中的UAs参与了一个会话，在图中的消息流开始之前，该会话包括一个sendrecv音频流和一个非活动视频流。UA1发送重新邀请（1）请求使视频流sendrecv。
SDP1:
m=audio 20000 RTP/AVP 0
a=sendrecv
m=video 20002 RTP/AVP 31
a=sendrecv
SDP1:
m=audio 20000 RTP/AVP 0
a=sendrecv
m=video 20002 RTP/AVP 31
a=sendrecv
UA2 is configured to automatically accept incoming video streams but to ask for user input before generating an outgoing video stream. Therefore, UAS2 makes the video stream recvonly by returning a 183 (Session Progress) response (2).
UA2配置为自动接受传入视频流，但在生成传出视频流之前请求用户输入。因此，UAS2通过返回183（会话进度）响应（2）来仅使视频流返回。
SDP2:
m=audio 30000 RTP/AVP 0
a=sendrecv
m=video 30002 RTP/AVP 31
a=recvonly
SDP2:
m=audio 30000 RTP/AVP 0
a=sendrecv
m=video 30002 RTP/AVP 31
a=recvonly
When asked for input, UA2's user chooses not to have either incoming or outgoing video. In order to make the video stream inactive, UA2 returns a 4xx error response (5) to the re-INVITE. The ACK request (6) for this error response is generated by the proxy between both user agents. Note that this error response undoes already executed changes. So, UA2 is a legacy UA that does not support this specification.
当要求输入时，UA2的用户选择不接收传入或传出的视频。为了使视频流处于非活动状态，UA2向重新邀请返回4xx错误响应（5）。此错误响应的ACK请求（6）由两个用户代理之间的代理生成。请注意，此错误响应将撤消已执行的更改。因此，UA2是不支持此规范的遗留UA。
The proxy relays the 4xx response (7) towards UA1. However, the 4xx response (7) takes time to arrive to UA1 (e.g., the response may have been sent over UDP and the first few retransmissions were lost). In the meantime, UA2's user decides to put the audio stream on hold. UA2 sends an UPDATE request (8) making the audio stream recvonly. The video stream, which is inactive, is not modified and, thus, continues being inactive.
代理向UA1转发4xx响应（7）。但是，4xx响应（7）需要时间才能到达UA1（例如，响应可能已通过UDP发送，并且前几次重新传输丢失）。同时，UA2的用户决定暂停音频流。UA2发送一个更新请求（8），使音频流可恢复。未激活的视频流未被修改，因此继续处于未激活状态。
SDP3:
m=audio 30000 RTP/AVP 0
a=recvonly
m=video 30002 RTP/AVP 31
a=inactive
SDP3:
m=audio 30000 RTP/AVP 0
a=recvonly
m=video 30002 RTP/AVP 31
a=inactive
The proxy relays the UPDATE request (9) to UA1. The UPDATE request (9) arrives at UA1 before the 4xx response (7) that had been previously sent. UA1 accepts the changes in the UPDATE request and returns a 200 (OK) response (10) to it.
代理将更新请求（9）转发给UA1。更新请求（9）在先前发送的4xx响应（7）之前到达UA1。UA1接受更新请求中的更改，并向其返回200（OK）响应（10）。
SDP4:
m=audio 20000 RTP/AVP 0
a=sendonly
m=video 30002 RTP/AVP 31
a=inactive
SDP4:
m=audio 20000 RTP/AVP 0
a=sendonly
m=video 30002 RTP/AVP 31
a=inactive
At a later point, the 4xx response (7) finally arrives at UA1. This response makes the session return to its pre-re-INVITE state. Therefore, for UA1, the audio stream is sendrecv and the video stream is inactive. However, for UA2, the audio stream is recvonly (the video stream is also inactive).
稍后，4xx响应（7）最终到达UA1。此响应使会话返回其重新邀请前的状态。因此，对于UA1，音频流是sendrecv，视频流是非活动的。然而，对于UA2，音频流是可恢复的（视频流也是非活动的）。
After the message flow in Figure 5, following the recommendations in this section, when UA1 received an error response (7) that undid already executed changes, UA1 would generate an UPDATE request with an SDP reflecting the pre-re-INVITE state (i.e., sendrecv audio and inactive video). UA2 could then return a 200 (OK) response to the UPDATE request making the audio stream recvonly, which is the state UA2's user had requested. Such an UPDATE transaction would get the UAs back into synchronization.
在图5中的消息流之后，遵循本节中的建议，当UA1收到UNDD已执行更改的错误响应（7）时，UA1将生成一个更新请求，SDP反映重新邀请前的状态（即sendrecv音频和非活动视频）。然后，UA2可以对更新请求返回200（OK）响应，使音频流仅可恢复，这是UA2用户请求的状态。这样的更新事务将使UAs恢复同步。
Section 9.2 of RFC 3261 [RFC3261] specifies the behavior of a UAS responding to a CANCEL request. Such a UAS responds to the INVITE request with a 487 (Request Terminated) at the SHOULD level. Per the rules specified in Section 3.3, if the INVITE request was a re-INVITE and some of its requested changes had already been executed, the UAS would return a 2xx response instead.
RFC 3261[RFC3261]第9.2节规定了UAS响应取消请求的行为。这样的UAS在应该级别使用487（请求终止）响应INVITE请求。根据第3.3节中规定的规则，如果INVITE请求是重新邀请，并且其请求的一些更改已经执行，UAS将返回2xx响应。
The following sections discuss how to refresh the targets of a dialog.
以下各节讨论如何刷新对话框的目标。
As described in Section 12 of RFC 3261 [RFC3261], a UA involved in a dialog keeps a record of the SIP or Session Initiation Protocol Secure (SIPS) URI at which it can communicate with a specific instance of its peer (this is called the "dialog's remote target URI" and is equal to the URI contained in the Contact header of requests and responses it receives from the peer). This document introduces the complementary concept of the "dialog's local target URI", defined as a UA's record of the SIP or SIPS URI at which the peer can communicate with it (equal to the URI contained in the Contact header of requests and responses it sends to the peer). These terms are complementary because the "dialog's remote target URI" according to one UA is the "dialog's local target URI" according to the other UA, and vice versa.
如RFC 3261[RFC3261]第12节所述，对话中涉及的UA保留SIP或会话启动协议安全（SIPS）URI的记录，在该记录中，UA可以与其对等方的特定实例进行通信（这称为“对话的远程目标URI”）和等于它从对等方接收的请求和响应的联系人标头中包含的URI）。本文档介绍了“对话的本地目标URI”的补充概念，定义为UA对SIP或SIPS URI的记录，在该记录处，对等方可以与其通信（等于其发送给对等方的请求和响应的联系人标头中包含的URI）。这些术语是互补的，因为根据一个UA的“对话框的远程目标URI”是根据另一个UA的“对话框的本地目标URI”，反之亦然。
A target-refresh request is defined as follows in Section 6 of RFC 3261 [RFC3261]:
目标刷新请求在RFC 3261[RFC3261]第6节中定义如下：
A target-refresh request sent within a dialog is defined as a request that can modify the remote target of the dialog.
在对话框中发送的目标刷新请求被定义为可以修改对话框远程目标的请求。
Additionally, 2xx responses to target-refresh requests can also update the remote target of the dialog. As discussed in Section 12.2 of RFC 3261 [RFC3261], re-INVITEs are target-refresh requests.
此外，对目标刷新请求的2xx响应也可以更新对话框的远程目标。如RFC 3261[RFC3261]第12.2节所述，重新邀请是目标刷新请求。
RFC 3261 [RFC3261] specifies the behavior of UASs receiving target-refresh requests and of UACs receiving a 2xx response for a target-refresh request.
RFC 3261[RFC3261]指定UAS接收目标刷新请求和UAC接收目标刷新请求的2xx响应的行为。
Section 12.2.2 of RFC 3261 [RFC3261] says:
RFC 3261[RFC3261]第12.2.2节规定：
When a UAS receives a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that request, if present.
当UAS收到目标刷新请求时，它必须用该请求中联系人标头字段的URI（如果存在）替换对话框的远程目标URI。
Section 12.2.1.2 of RFC 3261 [RFC3261] says:
RFC 3261[RFC3261]第12.2.1.2节规定：
When a UAC receives a 2xx response to a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present.
当UAC收到对目标刷新请求的2xx响应时，它必须用该响应中联系人标题字段的URI（如果存在）替换对话框的远程目标URI。
The fact that re-INVITEs can be long-lived transactions and can have other transactions within them makes it necessary to revise these rules. Section 4.3 specifies new rules for the handling of target-refresh requests. Note that the new rules apply to any target-refresh request, not only to re-INVITEs.
重新邀请可以是长期的交易，并且可以包含其他交易，因此有必要修改这些规则。第4.3节规定了处理目标刷新请求的新规则。请注意，新规则适用于任何目标刷新请求，而不仅仅是重新邀请。
The local and remote targets of a dialog are special types of state information because of their essential role in the exchange of SIP messages between UAs in a dialog. A UA involved in a dialog receives the remote target of the dialog from the remote UA. The UA uses the received remote target to send SIP requests to the remote UA.
对话的本地和远程目标是特殊类型的状态信息，因为它们在对话中UAs之间的SIP消息交换中起着至关重要的作用。对话中涉及的UA从远程UA接收对话的远程目标。UA使用接收到的远程目标向远程UA发送SIP请求。
The dialog's local target is a piece of state information that is not meant to be negotiated. When a UA changes its local target (i.e., the UA changes its IP address), the UA simply communicates its new local target to the remote UA (e.g., the UA communicates its new IP address to the remote UA in order to remain reachable by the remote UA). UAs need to follow the behavior specified in Sections 4.4, 4.5, 4.6, and 4.7 of this specification instead of that specified in RFC 3261 [RFC3261], which was discussed in Section 4.2. The new behavior regarding target-refresh requests implies that a target-refresh request can, in some cases, update the remote target even if the request is responded to with a final error response. This means that target-refresh requests are not atomic.
对话框的本地目标是一段不打算协商的状态信息。当UA更改其本地目标（即UA更改其IP地址）时，UA仅将其新的本地目标传送给远程UA（例如，UA将其新的IP地址传送给远程UA，以保持远程UA的可访问性）。UAs需要遵循本规范第4.4、4.5、4.6和4.7节中规定的行为，而不是第4.2节中讨论的RFC 3261[RFC3261]中规定的行为。关于目标刷新请求的新行为意味着，在某些情况下，目标刷新请求可以更新远程目标，即使请求得到最终错误响应。这意味着目标刷新请求不是原子的。
In order to update its local target, a UA can send a target-refresh request. If the UA receives an error response to the target-refresh request, the remote UA has not updated its remote target.
为了更新其本地目标，UA可以发送目标刷新请求。如果UA收到对目标刷新请求的错误响应，则远程UA未更新其远程目标。
This allows UASs to authenticate target-refresh requests (see Section 26.2 of RFC 3261 [RFC3261]).
这允许UAS对目标刷新请求进行身份验证（参见RFC 3261[RFC3261]第26.2节）。
If the UA receives a reliable provisional response or a 2xx response to the target-refresh request, or the UA receives an in-dialog request on the new local target, the remote UA has updated its remote target. The UA can consider the target refresh operation completed.
如果UA收到对目标刷新请求的可靠临时响应或2xx响应，或者UA收到对新本地目标的对话内请求，则远程UA已更新其远程目标。UA可以考虑完成目标刷新操作。
Even if the target request was a re-INVITE and the final response to the re-INVITE was an error response, the UAS would not revert to the pre-re-INVITE remote target.
即使目标请求是重新邀请，并且对重新邀请的最终响应是错误响应，UAS也不会恢复到重新邀请前的远程目标。
A UA SHOULD NOT use the same target refresh request to refresh the target and to make session changes unless the session changes can be trivially accepted by the remote UA (e.g., an IP address change). Piggybacking a target refresh with more complicated session changes would make it unnecessarily complicated for the remote UA to accept the target refresh while rejecting the session changes. Only in case the target refresh request is a re-INVITE and the UAS supports reliable provisional response or UPDATE requests, the UAC MAY piggyback session changes and a target refresh in the same re-INVITE.
UA不应使用相同的目标刷新请求来刷新目标并进行会话更改，除非远程UA可以轻松地接受会话更改（例如，IP地址更改）。将目标刷新与更复杂的会话更改相结合，会使远程UA在拒绝会话更改的同时接受目标刷新变得不必要的复杂。只有在目标刷新请求是重新邀请且UAS支持可靠的临时响应或更新请求的情况下，UAC才能在相同的重新邀请中搭载会话更改和目标刷新。
A UA processing an incoming target refresh request can update its local target by returning a reliable provisional response or a 2xx response to the target-refresh request. The response needs to contain the updated local target URI in its Contact header field. On sending the response, the UA can consider the target refresh operation completed.
处理传入目标刷新请求的UA可以通过向目标刷新请求返回可靠的临时响应或2xx响应来更新其本地目标。响应需要在其联系人标头字段中包含更新的本地目标URI。在发送响应时，UA可以考虑完成目标刷新操作。
Behavior of a UA after having received a target-refresh request updating the remote target:
UA在收到更新远程目标的目标刷新请求后的行为：
If the UA receives a target-refresh request that has been properly authenticated (see Section 26.2 of RFC 3261 [RFC3261]), the UA SHOULD generate a reliable provisional response or a 2xx response to the target-refresh request. If generating such responses is not possible (e.g., the UA does not support reliable provisional responses and needs user input before generating a final response), the UA SHOULD
如果UA收到已正确验证的目标刷新请求（参见RFC 3261[RFC3261]第26.2节），UA应生成对目标刷新请求的可靠临时响应或2xx响应。如果无法生成此类响应（例如，UA不支持可靠的临时响应，在生成最终响应之前需要用户输入），UA应
send an in-dialog request to the remote UA using the new remote target (if the UA does not need to send a request for other reasons, the UAS can send an UPDATE request). On sending a reliable provisional response or a 2xx response to the target-refresh request, or a request to the new remote target, the UA MUST replace the dialog's remote target URI with the URI from the Contact header field in the target-refresh request.
使用新的远程目标向远程UA发送对话内请求（如果UA由于其他原因不需要发送请求，UAS可以发送更新请求）。在向目标刷新请求发送可靠的临时响应或2xx响应，或向新的远程目标发送请求时，UA必须将对话框的远程目标URI替换为目标刷新请求中联系人标头字段中的URI。
Reliable provisional responses in SIP are specified in RFC 3262 [RFC3262]. In this document, reliable provisional responses are those that use the mechanism defined in RFC 3262 [RFC3262]. Other specifications may define ways to send provisional responses reliably using non-SIP mechanisms (e.g., using media-level messages to acknowledge the reception of the SIP response). For the purposes of this document, provisional responses using those non-SIP mechanisms are considered unreliable responses. Note that non-100 provisional responses are only applicable to INVITE transactions [RFC4320].
RFC 3262[RFC3262]中规定了SIP中的可靠临时响应。在本文件中，可靠的临时响应是指使用RFC 3262[RFC3262]中定义的机制的响应。其他规范可以定义使用非SIP机制可靠地发送临时响应的方法（例如，使用媒体级消息来确认SIP响应的接收）。在本文件中，使用这些非SIP机制的临时响应被视为不可靠响应。注意，非100临时响应仅适用于INVITE事务[RFC4320]。
If instead of sending a reliable provisional response or a 2xx response to the target-refresh request, or a request to the new target, the UA generates an error response to the target-refresh request, the UA MUST NOT update its dialog's remote target.
如果UA不向目标刷新请求发送可靠的临时响应或2xx响应，或向新目标发送请求，而是向目标刷新请求生成错误响应，则UA不得更新其对话框的远程目标。
If a UA receives a reliable provisional response or a 2xx response to a target-refresh request, the UA MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present.
如果UA收到对目标刷新请求的可靠临时响应或2xx响应，则UA必须将该对话框的远程目标URI替换为该响应中联系人标头字段的URI（如果存在）。
If a UA receives an unreliable provisional response to a target-refresh request, the UA MUST NOT refresh the dialog's remote target.
如果UA收到对目标刷新请求的不可靠临时响应，则UA不得刷新对话框的远程目标。
SIP provides request ordering by using the Cseq header field. That is, a UA that receives two requests at roughly the same time can know which one is newer. However, SIP does not provide ordering between responses and requests. For example, if a UA receives a 200 (OK) response to an UPDATE request and an UPDATE request at roughly the same time, the UA cannot know which one was sent last. Since both messages can refresh the remote target, the UA needs to know which message was sent last in order to know which remote target needs to be used.
SIP通过使用Cseq头字段提供请求排序。也就是说，几乎同时接收两个请求的UA可以知道哪一个较新。但是，SIP不提供响应和请求之间的排序。例如，如果UA大致同时收到对更新请求和更新请求的200（OK）响应，则UA无法知道最后发送的是哪一个。由于这两条消息都可以刷新远程目标，UA需要知道最后发送的消息，以便知道需要使用哪个远程目标。
This document specifies the following rule to avoid the situation just described. If the protocol allows a UA to use a target-refresh request at the point in time that the UA wishes to refresh its local target, the UA MUST use a target-refresh request instead of a response to refresh its local target. This rule implies that a UA only uses a response (i.e., a reliable provisional response or a 2xx response to a target-refresh request) to refresh its local target if the UA is unable to use a target-refresh request at that point in time (e.g., the UAS of an ongoing re-INVITE without support for UPDATE).
本文档指定了以下规则以避免上述情况。如果协议允许UA在UA希望刷新其本地目标的时间点使用目标刷新请求，则UA必须使用目标刷新请求而不是响应来刷新其本地目标。此规则意味着，如果UA在该时间点无法使用目标刷新请求（例如，不支持更新的正在进行的重新邀请的UAS），则UA仅使用响应（即，对目标刷新请求的可靠临时响应或2xx响应）刷新其本地目标。
The rules given in this section about which messages can refresh the target of a dialog also apply to early dialogs created by an initial INVITE transaction. Additionally, as specified in Section 13.2.2.4 of RFC 3261 [RFC3261], on receiving a 2xx response to the initial INVITE, the UAC recomputes the whole route set of the dialog, which transitions from the "early" state to the "confirmed" state.
本节给出的关于哪些消息可以刷新对话框目标的规则也适用于初始INVITE事务创建的早期对话框。此外，如RFC 3261[RFC3261]第13.2.2.4节所述，当收到对初始邀请的2xx响应时，UAC重新计算对话框的整个路由集，该路由集从“早期”状态过渡到“确认”状态。
Section 12.1 of RFC 3261 allows unreliable provisional responses to create early dialogs. However, per the rules given in this section, unreliable provisional responses cannot refresh the target of a dialog. Therefore, the UAC of an initial INVITE transaction will not perform any target refresh as a result of the reception of an unreliable provisional response with an updated Contact value on an (already established) early dialog. Note also that a given UAS can establish additional early dialogs, which can have different targets, by returning additional unreliable provisional responses with different To tags.
RFC 3261第12.1节允许不可靠的临时响应创建早期对话框。但是，根据本节给出的规则，不可靠的临时响应无法刷新对话框的目标。因此，初始INVITE事务的UAC将不会执行任何目标刷新，因为在（已经建立的）早期对话框上接收到不可靠的临时响应以及更新的联系人值。还请注意，给定的UAS可以通过使用不同的To标记返回额外的不可靠临时响应来建立额外的早期对话框，这些对话框可以具有不同的目标。
The following sections discuss the case where a UA loses its transport address during an ongoing re-INVITE transaction. Such a UA will refresh the dialog's local target so that it reflects its new transport address. Note that target refreshes that do not involve changes in the UA's transport address are outside of the scope of this section. Also, UAs losing their transport address during a non-re-INVITE transaction (e.g., a UA losing its transport address right after having sent an UPDATE request before having received a response to it) are out of scope as well.
以下各节讨论UA在正在进行的重新邀请事务中丢失其传输地址的情况。这样的UA将刷新对话框的本地目标，以便它反映其新的传输地址。请注意，不涉及UA传输地址更改的目标刷新不在本节范围内。此外，在非重新邀请事务期间，UA丢失其传输地址（例如，UA在收到响应之前发送更新请求后立即丢失其传输地址）也不在范围之内。
The rules given in this section are also applicable to initial INVITE requests that have established early dialogs.
本节中给出的规则也适用于已建立早期对话框的初始INVITE请求。
Re-INVITEs are routed using the dialog's route set, which contains all the proxy servers that need to be traversed by requests sent within the dialog. Responses to the re-INVITE are routed using the Via entries in the re-INVITE.
重新邀请使用对话框的路由集进行路由，该路由集包含对话框内发送的请求需要遍历的所有代理服务器。对重新邀请的响应使用重新邀请中的Via条目进行路由。
ACK requests for 2xx responses and for non-2xx final responses are generated in different ways. As specified in Sections 14.1 and 13.2.1 of RFC 3261 [RFC3261], ACK requests for 2xx responses are generated by the UAC core and are routed using the dialog's route set. As specified in Section 17.1.1.2 of RFC 3261 [RFC3261], ACK requests for non-2xx final responses are generated by the INVITE client transaction (i.e., they are generated in a hop-by-hop fashion by the proxy servers in the path) and are sent to the same transport address as the re-INVITE.
2xx响应和非2xx最终响应的ACK请求以不同的方式生成。如RFC 3261[RFC3261]第14.1节和第13.2.1节所述，2xx响应的ACK请求由UAC核心生成，并使用对话框的路由集进行路由。如RFC 3261[RFC3261]第17.1.1.2节所述，非2xx最终响应的ACK请求由INVITE客户端事务生成（即，它们由路径中的代理服务器以逐跳方式生成），并发送到与重新INVITE相同的传输地址。
Refreshing the dialog's remote target during a re-INVITE transaction (see Section 4.3) presents some issues because of the fact that re-INVITE transactions can be long lived. As described in Section 5.1, the way responses to the re-INVITE and ACKs for non-2xx final responses are routed is fixed once the re-INVITE is sent. The routing of this messages does not depend on the dialog's route set and, thus, target refreshes within an ongoing re-INVITE do not affect their routing. A UA that changes its location (i.e., performs a target refresh) but is still reachable at its old location will be able to receive those messages (which will be sent to the old location). However, a UA that cannot be reachable at its old location any longer will not be able to receive them.
在重新邀请事务期间刷新对话框的远程目标（请参见第4.3节）会出现一些问题，因为重新邀请事务可能会长期存在。如第5.1节所述，发送重新邀请后，对重新邀请的响应和非2xx最终响应的确认的路由方式是固定的。此消息的路由不依赖于对话框的路由集，因此，正在进行的重新邀请中的目标刷新不会影响其路由。更改其位置（即执行目标刷新）但仍可在其旧位置访问的UA将能够接收这些消息（将发送到旧位置）。但是，在其旧位置无法再访问的UA将无法接收它们。
The following sections describe the errors UAs face when they lose their transport address during a re-INVITE. On detecting some of these errors, UAs following the rules specified in RFC 3261 [RFC3261] will terminate the dialog. When the dialog is terminated, the only option for the UAs is to establish a new dialog. The following sections change the requirements RFC 3261 [RFC3261] places on UAs when certain errors occur so that the UAs can recover from those errors. In short, the UAs generate a new re-INVITE transaction to synchronize both UAs. Note that there are existing UA implementations deployed that already implement this behavior.
以下部分描述了UAs在重新邀请过程中丢失传输地址时面临的错误。在检测到其中一些错误时，遵循RFC 3261[RFC3261]中指定的规则的UAs将终止对话框。当对话框终止时，UAs的唯一选项是建立一个新对话框。以下各节更改了发生某些错误时对UAs的RFC 3261[RFC3261]要求，以便UAs能够从这些错误中恢复。简言之，UAs生成一个新的重新邀请事务以同步两个UAs。请注意，已部署的现有UA实现已经实现了此行为。
When a UAS that moves to a new contact and loses its old contact generates a non-2xx final response to the re-INVITE, it will not be able to receive the ACK request. The entity receiving the response
当移动到新联系人并失去旧联系人的UAS对重新邀请生成非2xx最终响应时，它将无法接收ACK请求。接收响应的实体
and, thus, generating the ACK request will either get a transport error or a timeout error, which, as described in Section 8.1.3.1 of RFC 3261 [RFC3261], will be treated as a 503 (Service Unavailable) response and as a 408 (Request Timeout) response, respectively. If the sender of the ACK request is a proxy server, it will typically ignore this error. If the sender of the ACK request is the UAC, according to Section 12.2.1.2 of RFC 3261 [RFC3261], it is supposed to (at the SHOULD level) terminate the dialog by sending a BYE request. However, because of the special properties of ACK requests for non-2xx final responses, most existing UACs do not terminate the dialog when ACK request fails, which is fortunate.
因此，生成ACK请求将获得传输错误或超时错误，如RFC 3261[RFC3261]第8.1.3.1节所述，这将分别被视为503（服务不可用）响应和408（请求超时）响应。如果ACK请求的发送方是代理服务器，它通常会忽略此错误。根据RFC 3261[RFC3261]第12.2.1.2节，如果ACK请求的发送方是UAC，则应通过发送BYE请求（在“应”级别）终止对话。然而，由于非2xx最终响应的ACK请求的特殊属性，大多数现有UAC不会在ACK请求失败时终止对话框，这是幸运的。
A UAC that accepts a target refresh within a re-INVITE MUST ignore transport and timeout errors when generating an ACK request for a non-2xx final response. Additionally, UAC SHOULD generate a new re-INVITE in order to make sure that both UAs have a common view of the state of the session.
在重新邀请中接受目标刷新的UAC在生成非2xx最终响应的ACK请求时必须忽略传输和超时错误。此外，UAC应该生成一个新的重新邀请，以确保两个UAs对会话状态有一个共同的视图。
It is possible that the errors ignored by the UAC were not related to the target refresh operation. If that was the case, the second re-INVITE would fail and the UAC would terminate the dialog because, per the rules above, UACs only ignore errors when they accept a target refresh within the re-INVITE.
UAC忽略的错误可能与目标刷新操作无关。如果是这种情况，第二次重新邀请将失败，UAC将终止对话框，因为根据上述规则，UAC仅在接受重新邀请中的目标刷新时才会忽略错误。
When a UAC moves to a new contact and loses its old contact, it will not be able to receive responses to the re-INVITE. Consequently, it will never generate an ACK request.
当UAC移动到新联系人并失去其旧联系人时，它将无法接收对重新邀请的响应。因此，它永远不会生成ACK请求。
As described in Section 16.9 of RFC 3261 [RFC3261], a proxy server that gets an error when forwarding a response does not take any measures. Consequently, proxy servers relaying responses will effectively ignore the error.
如RFC 3261[RFC3261]第16.9节所述，转发响应时出错的代理服务器不采取任何措施。因此，中继响应的代理服务器将有效地忽略错误。
If there are no proxy servers in the dialog's route set, the UAS will get an error when sending a non-2xx final response. The UAS core will be notified of the transaction failure, as described in Section 17.2.1 of RFC 3261 [RFC3261]. Most existing UASs do not terminate the dialog on encountering this failure, which is fortunate.
如果对话框的路由集中没有代理服务器，UAS将在发送非2xx最终响应时出错。如RFC 3261[RFC3261]第17.2.1节所述，UAS核心将收到交易失败的通知。大多数现有的UAS在遇到此故障时不会终止对话，这是幸运的。
Regardless of the presence or absence of proxy servers in the dialog's route set, a UAS generating a 2xx response to the re-INVITE will never receive an ACK request for it. According to Section 14.2 of RFC 3261 [RFC3261], such a UAS is supposed to (at the "should" level) terminate the dialog by sending a BYE request.
无论对话框的路由集中是否存在代理服务器，对重新邀请生成2xx响应的UAS将永远不会收到ACK请求。根据RFC 3261[RFC3261]第14.2节，此类UAS应（在“应该”级别）通过发送BYE请求来终止对话。
A UAS that accepts a target refresh within a re-INVITE and never receives an ACK request after having sent a final response to the re-INVITE SHOULD NOT terminate the dialog if the UA has received a new re-INVITE with a higher CSeq sequence number than the original one.
如果UA收到CSeq序列号高于原始序列号的新重新邀请，则在重新邀请中接受目标刷新且在向重新邀请发送最终响应后从未收到ACK请求的UAS不应终止对话框。
When a UAC moves to a new contact and loses its old contact, it will not be able to receive responses to the re-INVITE. Consequently, it will never generate an ACK request.
当UAC移动到新联系人并失去其旧联系人时，它将无法接收对重新邀请的响应。因此，它永远不会生成ACK请求。
Such a UAC SHOULD generate a CANCEL request to cancel the re-INVITE and cause the INVITE client transaction corresponding to the re-INVITE to enter the "Terminated" state. The UAC SHOULD also send a new re-INVITE in order to make sure that both UAs have a common view of the state of the session.
此类UAC应生成取消请求以取消重新邀请，并使重新邀请对应的邀请客户端事务进入“终止”状态。UAC还应发送新的重新邀请，以确保两个UAs对会话状态有共同的看法。
Per Section 14.2 of RFC 3261 [RFC3261], the UAS will accept new incoming re-INVITEs as soon as it has generated a final response to the previous INVITE request, which had a lower CSeq sequence number.
根据RFC 3261[RFC3261]第14.2节，UAS将在对前一个INVITE请求（CSeq序列号较低）生成最终响应后，立即接受新的传入重新邀请。
This document does not introduce any new security issue. It just clarifies how certain transactions should be handled in SIP. Security issues related to re-INVITEs and UPDATE requests are discussed in RFC 3261 [RFC3261] and RFC 3311 [RFC3311].
本文档没有引入任何新的安全问题。它只是澄清了在SIP中应该如何处理某些事务。RFC 3261[RFC3261]和RFC 3311[RFC3311]中讨论了与重新邀请和更新请求相关的安全问题。
In particular, in order not to reduce the security level for a given session, re-INVITEs and UPDATE requests SHOULD be secured using a mechanism equivalent to or stronger than the initial INVITE request that created the session. For example, if the initial INVITE request was end-to-end integrity protected or encrypted, subsequent re-INVITEs and UPDATE requests should also be so.
特别是，为了不降低给定会话的安全级别，应使用与创建会话的初始INVITE请求等效或更强的机制保护重新邀请和更新请求。例如，如果初始INVITE请求是端到端完整性保护或加密的，则后续的重新邀请和更新请求也应如此。
Paul Kyzivat provided useful ideas on the topics discussed in this document.
Paul Kyzivat就本文件中讨论的主题提供了有用的想法。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] 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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 32622，2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.
[RFC4032]Camarillo，G.和P.Kyzivat，“会话启动协议（SIP）先决条件框架的更新”，RFC 4032，2005年3月。
[RFC4320] Sparks, R., "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4320, January 2006.
[RFC4320]Sparks，R.，“解决会话启动协议（SIP）非邀请事务已识别问题的措施”，RFC 4320，2006年1月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
Authors' Addresses
作者地址
Gonzalo Camarillo (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
冈萨洛·卡马里洛（编辑）爱立信·赫萨兰蒂11号乔瓦斯02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Christer.Holmberg@ericsson.com
EMail: Christer.Holmberg@ericsson.com
Yang Gao ZTE China
杨高中兴中国
EMail: gao.yang2@zte.com.cn
EMail: gao.yang2@zte.com.cn