Network Working Group A. Allen, Ed.
Request for Comments: 4964 Research in Motion (RIM)
Category: Informational J. Holm
Ericsson
T. Hallin
Motorola
September 2007
Network Working Group A. Allen, Ed.
Request for Comments: 4964 Research in Motion (RIM)
Category: Informational J. Holm
Ericsson
T. Hallin
Motorola
September 2007
The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular
开放移动联盟推送通话蜂窝网络会话发起协议的P-Answer-State报头扩展
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document describes a private Session Initiation Protocol (SIP) header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The P-Answer-State header is used for indicating the answering mode of the handset, which is particular to the PoC application.
本文档描述了开放移动联盟（OMA）用于蜂窝式按键通话（PoC）的专用会话发起协议（SIP）报头（P报头）及其适用性，该报头仅限于OMA PoC应用。P-Answer-State报头用于指示手持设备的应答模式，这是特定于PoC应用的。
Table of Contents
目录
1. Introduction ....................................................3
2. Overall Applicability ...........................................3
3. Terminology .....................................................3
4. Background for the Extension ....................................4
5. Overview ........................................................5
6. The P-Answer-State Header .......................................6
6.1. Requirements ...............................................8
6.2. Alternatives Considered ....................................8
6.3. Applicability Statement for the P-Answer-State Header ......9
6.4. Usage of the P-Answer-State Header ........................10
6.4.1. Procedures at the UA (Terminal) ....................11
6.4.2. Procedures at the UA (PTT Server) ..................11
6.4.3. Procedures at the Proxy Server .....................14
7. Formal Syntax ..................................................14
7.1. P-Answer-State Header Syntax ..............................14
7.2. Table of the New Header ...................................14
8. Example Usage Session Flows ....................................15
8.1. Pre-Arranged Group Call Using On-Demand Session ...........15
8.2. 1-1 Call Using Pre-Established Session ....................21
9. Security Considerations ........................................28
10. IANA Considerations ...........................................28
10.1. Registration of Header Fields ............................28
11. Acknowledgements ..............................................29
12. References ....................................................29
12.1. Normative References .....................................29
12.2. Informative References ...................................30
1. Introduction ....................................................3
2. Overall Applicability ...........................................3
3. Terminology .....................................................3
4. Background for the Extension ....................................4
5. Overview ........................................................5
6. The P-Answer-State Header .......................................6
6.1. Requirements ...............................................8
6.2. Alternatives Considered ....................................8
6.3. Applicability Statement for the P-Answer-State Header ......9
6.4. Usage of the P-Answer-State Header ........................10
6.4.1. Procedures at the UA (Terminal) ....................11
6.4.2. Procedures at the UA (PTT Server) ..................11
6.4.3. Procedures at the Proxy Server .....................14
7. Formal Syntax ..................................................14
7.1. P-Answer-State Header Syntax ..............................14
7.2. Table of the New Header ...................................14
8. Example Usage Session Flows ....................................15
8.1. Pre-Arranged Group Call Using On-Demand Session ...........15
8.2. 1-1 Call Using Pre-Established Session ....................21
9. Security Considerations ........................................28
10. IANA Considerations ...........................................28
10.1. Registration of Header Fields ............................28
11. Acknowledgements ..............................................29
12. References ....................................................29
12.1. Normative References .....................................29
12.2. Informative References ...................................30
The Open Mobile Alliance (OMA) (http://www.openmobilealliance.org) is specifying the Push to talk Over Cellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions across different participants. This document describes a private extension to address specific requirements of the PoC service and may not be applicable to the general Internet.
开放移动联盟（OMA）(http://www.openmobilealliance.org)正在指定通过蜂窝网络的一键通（PoC）服务，其中SIP是用于在不同参与者之间建立半双工媒体会话的协议。本文档描述了一个专用扩展，用于满足PoC服务的特定要求，可能不适用于通用互联网。
The PoC service allows a SIP User Agent (UA) (PoC terminal) to establish a session to one or more SIP UAs simultaneously, usually initiated by the initiating user pushing a button.
PoC服务允许SIP用户代理（UA）（PoC终端）同时建立到一个或多个SIP UA的会话，通常由发起用户按下按钮发起。
OMA has defined a collection of very stringent requirements in support of the PoC service. In order to provide the user with a satisfactory experience, the initial session establishment (from the time the user presses the button to the time they get an indication to speak) must be minimized.
OMA为支持PoC服务定义了一系列非常严格的要求。为了向用户提供令人满意的体验，必须最小化初始会话建立（从用户按下按钮到获得讲话指示的时间）。
The SIP extension specified in this document makes certain assumptions regarding network topology and the existence of transitive trust. These assumptions are generally NOT APPLICABLE in the Internet as a whole. The mechanism specified here was designed to satisfy the requirements specified by the Open Mobile Alliance for Push to talk over Cellular for which either no general-purpose solution was found, where insufficient operational experience was available to understand if a general solution is needed, or where a more general solution is not yet mature. For more details about the assumptions made about this extension, consult the applicability statement in section 6.3.
本文档中指定的SIP扩展对网络拓扑和可传递信任的存在做出了某些假设。这些假设通常不适用于整个互联网。此处规定的机制旨在满足开放移动联盟规定的蜂窝电话一键通（Push-to-talk over Cellular）要求，该要求要么没有找到通用解决方案，要么没有足够的运营经验来理解是否需要通用解决方案，或者，更普遍的解决方案尚未成熟。有关此扩展假设的更多详细信息，请参阅第6.3节中的适用性声明。
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 [1].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。
The terms "PTT Server" (Push to talk Server), "Unconfirmed Indication", "Unconfirmed Response", "Confirmed Indication", and "Confirmed Response" are introduced in this document.
本文件中介绍了术语“PTT服务器”（按键通话服务器）、“未确认指示”、“未确认响应”、“确认指示”和“确认响应”。
A "PTT Server" as referred to here is a SIP network server that performs the network-based functions for the Push to talk service. The PTT Server can act as a SIP Proxy (as defined in [2]) or a back-
这里提到的“PTT服务器”是执行按键通话服务的基于网络的功能的SIP网络服务器。PTT服务器可以充当SIP代理（如[2]中所定义）或备份-
to-back UA (B2BUA) (as defined in [2]) based on the functions it needs to perform. There can be one or more PTT Servers involved in a SIP Push to talk session.
根据UA（B2BUA）（定义见[2]）需要执行的功能，支持UA（B2BUA）。SIP一键通会话中可能涉及一个或多个PTT服务器。
An "Unconfirmed Indication" as referred to here is an indication that the final target UA for the request has yet to be contacted and an intermediate SIP node is indicating that it has information that hints that the request is likely to be answered by the target UA.
这里提到的“未确认指示”是指尚未联系请求的最终目标UA，并且中间SIP节点指示其具有提示该请求可能由目标UA应答的信息。
An "Unconfirmed Response" is a SIP 18x or 2xx response containing an "Unconfirmed Indication".
“未确认响应”是包含“未确认指示”的SIP 18x或2xx响应。
A "Confirmed Indication" as referred to here is an indication that the target UA has accepted the session invitation and is ready to receive media.
此处所指的“确认指示”表示目标UA已接受会话邀请并准备接收媒体。
A "Confirmed Response" is a SIP 200 (OK) response containing a "Confirmed Indication" and has the usual semantics of a SIP 200 (OK) response containing an answer (such as a Session Description Protocol (SDP) answer).
“确认响应”是包含“确认指示”的SIP 200（OK）响应，并且具有包含应答（例如会话描述协议（SDP）应答）的SIP 200（OK）响应的通常语义。
The PoC terminal could support such hardware capabilities as a speakerphone and/or headset and software that provide the capability for the user to configure the PoC terminal to accept the session invitations immediately and play out the media as soon as it is received without requiring the intervention of the called user. This mode of operation is known as Automatic Answer mode. The user can alternatively configure the PoC terminal to first alert the user and require the user to manually accept the session invitation before media is accepted. This mode of operation is known as Manual Answer mode. The PoC terminal could support both or only one of these modes of operation. The user can change the Answer Mode (AM) configuration of the PoC terminal frequently based on their current circumstances and preference (perhaps because the user is busy, or in a public area where she cannot use a speakerphone, etc.).
PoC终端可以支持诸如扬声器和/或耳机之类的硬件功能和软件，这些硬件功能为用户提供配置PoC终端以立即接受会话邀请并在接收到媒体时立即播放媒体的能力，而无需被叫用户的干预。这种操作模式称为自动应答模式。用户也可以将PoC终端配置为首先提醒用户，并要求用户在接受媒体之前手动接受会话邀请。这种操作模式称为手动应答模式。PoC终端可以同时支持或仅支持其中一种操作模式。用户可以根据其当前情况和偏好（可能是因为用户忙，或者在不能使用扬声器的公共区域等）频繁地改变PoC终端的应答模式（AM）配置。
The OMA PoC Architecture [3] utilizes PTT Servers within the network that can perform such roles as a conference focus [10], a real-time transport protocol (RTP) translator, or a network policy enforcement server. A possible optimization to minimize the delay in the providing of the caller with an indication to speak is for the PTT server to perform buffering of media packets in order to provide an early or "Unconfirmed Indication" back to the caller and allow the caller to start speaking before the called PoC terminal has answered. An event package and mechanisms for a SIP UA to indicate its current answer mode to a PTT Server in order to enable buffering are defined
OMA PoC体系结构[3]利用网络内的PTT服务器，这些服务器可以执行会议焦点[10]、实时传输协议（RTP）转换器或网络策略实施服务器等角色。最小化向呼叫者提供讲话指示的延迟的可能优化是，PTT服务器执行媒体分组的缓冲，以便向呼叫者提供早期或“未确认的指示”，并允许呼叫者在被叫PoC终端应答之前开始讲话。定义了用于SIP UA向PTT服务器指示其当前应答模式以启用缓冲的事件包和机制
in [11]. In addition, particularly when multiple domains are involved in the session, more than one PTT Server could be involved in the signaling path for the session. Also, the PTT Server that performs the buffering might not be the PTT Server that has knowledge of the current answer mode of the SIP UA that is the final destination for the SIP INVITE request. A mechanism is defined in [12] that allows a terminal that acts as a SIP UA (or as a PTT Server that acts as a SIP UA) to indicate a preference to the final destination SIP User Agent Server (UAS) to answer in a particular mode. However, a mechanism is required for a PTT Server to relay the "Unconfirmed Indication" in a response back towards the originating SIP User Agent Client (UAC).
在[11]中。此外，特别是当会话中涉及多个域时，会话的信令路径中可能涉及多个PTT服务器。此外，执行缓冲的PTT服务器可能不是知道作为SIP INVITE请求的最终目的地的SIP UA的当前应答模式的PTT服务器。[12]中定义了一种机制，该机制允许充当SIP UA的终端（或充当SIP UA的PTT服务器）指示对最终目的地SIP用户代理服务器（UAS）的偏好以特定模式应答。然而，PTT服务器需要一种机制来将响应中的“未确认指示”中继回发起SIP用户代理客户端（UAC）。
The purpose of this extension is to support an optimization that makes it possible for the network to provide a faster push to talk experience, through an intermediate SIP user agent (PTT Server) providing a SIP 200 (OK) response before the called UA does, and a PTT Server buffering the media generated by the calling UA for replay to the called UA when it answers. Because of the half-duplex nature of the call, where media bursts are short typically in the order of 10-30 seconds, the additional end-to-end latency can be tolerated, and this considerably improves the user experience. However, the PTT Server only can do this when there is a high probability that the called SIP UA is in Automatic Answer mode. It is likely that PTT Servers near the called UA have up-to-date knowledge of the answering mode of the called UA, and due to the restricted bandwidth nature of the cellular network, they can pass upstream an indication of the called SIP UA's answering mode faster than the called UA can deliver an automatically generated SIP 200 (OK) response.
该扩展的目的是支持优化，该优化使得网络能够通过中间SIP用户代理（PTT服务器）在被呼叫UA之前提供SIP 200（OK）响应，从而提供更快的一键通体验，以及PTT服务器，该PTT服务器缓冲由主叫UA生成的媒体，以便在被叫UA应答时重播给被叫UA。由于呼叫的半双工性质，其中媒体突发通常短于10-30秒，因此可以容忍额外的端到端延迟，这大大改善了用户体验。然而，PTT服务器仅在被叫SIP-UA处于自动应答模式的概率很高的情况下才能这样做。很可能，被叫UA附近的PTT服务器具有被叫UA的应答模式的最新知识，并且由于蜂窝网络的带宽受限性质，它们可以比被叫UA能够交付自动生成的SIP 200（OK）响应更快地向上游传递被叫SIP UA应答模式的指示。
This document proposes a new SIP header field, the P-Answer-State header field to support an "Unconfirmed Indication". The new SIP header field can be optionally included in a response to a SIP INVITE request, or in a sipfrag of a response included in a SIP NOTIFY request sent as a result of a SIP REFER request that requests a SIP INVITE request to be sent. The header field is used to provide an indication from a PTT Server acting as a SIP proxy or back-to-back UA that it has information that hints that the terminating UA will likely answer automatically. This provides an "Unconfirmed Indication" back towards the inviting SIP UA to transmit media prior to receiving a final response from the final destination of the SIP INVITE request. No Supported or Require headers are needed because the sender of the P-Answer-State header field does not depend on the receiver to understand the extension. If the extension is not understood, the header field is simply ignored by the recipient. The extension is described below.
本文档提出了一个新的SIP报头字段，即支持“未确认指示”的P应答状态报头字段。新的SIP报头字段可以可选地包括在对SIP INVITE请求的响应中，或者包括在作为请求发送SIP INVITE请求的SIP REFER请求的结果而发送的SIP NOTIFY请求中的响应的sipfrag中。报头字段用于从充当SIP代理或背对背UA的PTT服务器提供指示，表明其具有提示终止UA可能自动应答的信息。这在接收到来自SIP INVITE请求的最终目的地的最终响应之前，向邀请SIP UA返回“未确认指示”以发送媒体。不需要Supported或Require标头，因为P-Answer-State标头字段的发送方不依赖接收方来理解扩展。如果不理解扩展名，则收件人将忽略标题字段。下面描述扩展。
Thus, when a PTT Server forwards a SIP INVITE request and knows that the called UA is likely to be in Automatic Answer mode, it also generates a SIP 183 provisional response with a P-Answer-State header field with a parameter of "Unconfirmed" to signal to upstream PTT Servers that they can buffer the caller's media.
因此，当PTT服务器转发SIP INVITE请求并且知道被叫UA可能处于自动应答模式时，它还生成具有参数为“unconfirm”的P-Answer-State报头字段的SIP 183临时响应，以向上游PTT服务器发送信号，表示它们可以缓冲呼叫者的媒体。
A PTT Server that wishes to buffer the caller's media, upon seeing the provisional response with a P-Answer-State header field with a parameter of "Unconfirmed", absorbs it and generates a SIP 200 (OK) response for the caller's SIP UA with an appropriate answer.
希望缓冲呼叫者的媒体的PTT服务器在看到具有参数为“unconfirm”的P-Answer-State报头字段的临时响应时，吸收该临时响应并为呼叫者的SIP-UA生成具有适当应答的SIP 200（OK）响应。
When the called UA generates a SIP 200 (OK) response, the PTT Server that generated the provisional response with a P-Answer-State header field with a parameter "Unconfirmed" adds to the SIP 200 (OK) response a P-Answer-State header field with a parameter of "Confirmed". The SIP 200 (OK) response is absorbed by the PTT Server that is buffering the caller's media, as it has already generated a SIP 200 (OK) response. The buffering PTT Server then starts playing out the buffered media.
当被叫UA生成SIP 200（OK）响应时，生成具有参数“未确认”的P应答状态报头字段的临时响应的PTT服务器向SIP 200（OK）响应添加具有参数“已确认”的P应答状态报头字段。SIP 200（OK）响应被正在缓冲呼叫者的媒体的PTT服务器吸收，因为它已经生成SIP 200（OK）响应。然后，缓冲PTT服务器开始播放缓冲介质。
The purpose of the P-Answer-State header field is to provide an indication from a PTT Server acting as a SIP proxy or back-to-back UA that it has information that hints that the terminating UA identified in the Request-URI of the request will likely answer automatically. Thus, it enables the PTT Server to provide an "Unconfirmed Indication" back towards the inviting SIP UA permitting it to transmit media prior to receiving a final response from the final destination of the SIP INVITE request. If a provisional response contains the P-Answer-State header field with the value "Unconfirmed" and does not contain an answer, then a receiving PTT Server can send a SIP 200 (OK) response containing an answer and a P-Answer-State header field with the value "Unconfirmed" if the PTT Server is willing to perform media buffering. If the response containing the P-Answer-State header field with the value "Unconfirmed" also contains an answer, the PTT Server that included the P-Answer-State header field and answer in the response is also indicating that it is willing to buffer the media until a final "Confirmed Indication" is received.
P-Answer-State报头字段的目的是从充当SIP代理或背对背UA的PTT服务器提供指示，其具有提示在请求的请求URI中标识的终止UA可能会自动应答的信息。因此，它使得PTT服务器能够向邀请SIP UA提供“未确认指示”，允许其在从SIP INVITE请求的最终目的地接收最终响应之前发送媒体。如果临时响应包含值为“unconfirm”的P-Answer-State报头字段且不包含应答，则如果PTT服务器愿意执行媒体缓冲，则接收PTT服务器可以发送包含应答的SIP 200（OK）响应和值为“unconfirm”的P-Answer-State报头字段。如果包含值为“unconfirm”的P-Answer-State报头字段的响应也包含应答，则在响应中包括P-Answer-State报头字段和应答的PTT服务器还指示其愿意缓冲媒体，直到接收到最终的“确认指示”。
The P-Answer-State header field can be included in a provisional or final response to a SIP INVITE request or in the sipfrag of a SIP NOTIFY request sent as a result of a SIP REFER request to send a SIP INVITE request. If the P-Answer-State header field with value "Unconfirmed" is included in a provisional response that contains an answer, the PTT Server is leaving the decision of where to do buffering to other PTT Servers upstream and will forward upstream a
P-Answer-State报头字段可以包括在对SIP INVITE请求的临时或最终响应中，或者包括在作为发送SIP INVITE请求的SIP REFER请求的结果而发送的SIP NOTIFY请求的sipfrag中。如果值为“unconfirm”的P-Answer-State报头字段包含在包含应答的临时响应中，则PTT服务器将在何处进行缓冲的决定留给上游的其他PTT服务器，并将向上游转发消息
"Confirmed indication" in a SIP 200 (OK) response when the final response is received from the destination UA.
当从目的地UA接收到最终响应时，SIP 200（OK）响应中的“确认指示”。
NOTE It is not intended that multiple PTT Servers perform buffering serially. If a PTT Server includes an answer along with P-Answer-State header field with the value "Unconfirmed" in a provisional response, then a receiving PTT Server can determine whether it buffers the media or forwards the media and allows the downstrean PTT Server that sent the "Unconfirmed Indication" to buffer the media. It is intended that if a PTT Server buffers media, it does so until a final "Confirmed Indication" is received, and therefore serial buffering by multiple PTT Servers does not take place.
注：多个PTT服务器不打算串行执行缓冲。如果PTT服务器在临时响应中包括值为“unconfirm”的应答和P-answer-State报头字段，则接收PTT服务器可以确定它是缓冲媒体还是转发媒体，并允许发送“unconfirm指示”的下游PTT服务器缓冲媒体。如果一个PTT服务器缓冲介质，它将这样做，直到接收到最终的“确认指示”，因此多个PTT服务器的串行缓冲不会发生。
The P-Answer-State header is only included in a provisional response when the node that sends the response has knowledge that there is a PTT Server acting as a B2BUA that understands this extension in the signaling path between itself and the originating UAC. This PTT Server between the sending node and the originating UAC will only pass the header field on in either a SIP 200 (OK) response or in the sipfrag (as defined in [4]) of a SIP NOTIFY request (as defined in [5]) sent as a result of a SIP REFER request (as defined in [6]). Such a situation only occurs with specific network topologies, which is another reason why use of this header field is not relevant to the general Internet. The originating UAC will only receive the P-Answer-state header field in a SIP 200 (OK) response or in the sipfrag of a SIP NOTIFY request.
当发送响应的节点知道存在充当B2BUA的PTT服务器时，P-Answer-State报头仅包括在临时响应中，该B2BUA在其自身和发起UAC之间的信令路径中理解该扩展。发送节点和发起UAC之间的该PTT服务器将仅在SIP 200（OK）响应中或作为SIP REFER请求（定义见[6]）的结果发送的SIP NOTIFY请求（定义见[5]）的sipfrag（定义见[4]）中传递头字段。这种情况只发生在特定的网络拓扑中，这是使用此标头字段与通用Internet无关的另一个原因。发起UAC将仅在SIP 200（OK）响应或SIP NOTIFY请求的sipfrag中接收P应答状态报头字段。
Provisional responses containing the P-Answer-State header field can be sent reliably using the mechanism defined in [13], but this is not required. This is a performance optimization, and the impact of a provisional response sent unreliably (failing to arrive) is simply that buffering does not take place. However, if the provisional responses are sent reliably and the provisional response fails to arrive, the time taken for the provisional response sender to time out on the receipt of a SIP PRACK request is likely to be such that, by the time the provisional response has been resent, the "Confirmed Response" could have already been received. When provisional responses that contain an answer are sent reliably, the 200 (OK) response for the SIP INVITE request cannot be sent before the SIP PRACK request is received. Therefore, sending provisional responses reliably could potentially delay the sending of the "Confirmed Response".
使用[13]中定义的机制可以可靠地发送包含P-Answer-State头字段的临时响应，但这不是必需的。这是一种性能优化，不可靠地发送临时响应（未能到达）的影响只是缓冲没有发生。然而，如果临时响应被可靠地发送并且临时响应未能到达，则临时响应发送者在接收到SIP PRACK请求时超时所花费的时间很可能是这样的，即在重新发送临时响应时，可能已经接收到“确认的响应”。当包含应答的临时响应可靠发送时，在收到SIP PRACK请求之前，无法发送SIP INVITE请求的200（OK）响应。因此，可靠地发送临时响应可能会延迟“确认响应”的发送。
The OMA PoC service has initial setup performance requirements that can be met by a PTT Server acting as a B2BUA spooling media from the inviting PoC subscriber until one or more invited PoC subscribers have accepted the session. The specific requirements are:
OMA PoC服务具有初始设置性能要求，在一个或多个受邀PoC订阅者接受会话之前，PTT服务器充当来自邀请PoC订阅者的B2BUA假脱机介质可以满足该要求。具体要求如下：
REQ-1: An intermediate server MAY spool media from the inviting SIP UA until one or more invited PoC SIP UASs has accepted the invitation.
REQ-1：中间服务器可以从邀请的SIP UA假脱机媒体，直到一个或多个被邀请的PoC SIP UAS接受邀请。
REQ-2: An intermediate server that is capable of spooling media MAY accept a SIP INVITE request from an inviting SIP UAC even if no invited SIP UAS has accepted the SIP INVITE request if it has a hint that the invited SIP UAS is likely to accept the request without requiring user intervention.
REQ-2：能够假脱机媒体的中间服务器可以接受来自邀请SIP UAC的SIP INVITE请求，即使没有被邀请的SIP UAS接受SIP INVITE请求，如果它有一个提示，表明被邀请的SIP UAS可能会接受请求而不需要用户干预。
REQ-3: An intermediate server or proxy that is incapable of spooling media or does not wish to, but has a hint that the invited SIP UAS is likely to automatically accept the session invitation, MUST be able to indicate back to another intermediate server that can spool media that it has some hint that the invited UAS is likely to automatically accept the session invitation.
REQ-3：一种中间服务器或代理，不能后台处理媒体或不希望后台处理媒体，但提示受邀请的SIP UAS可能会自动接受会话邀请，必须能够向另一个可以假脱机媒体的中间服务器指出，它有一些提示，表明受邀请的UAS可能会自动接受会话邀请。
REQ-4: An intermediate server that is willing to spool media from the inviting SIP UAC until one or more invited SIP UASs have accepted the SIP INVITE request SHOULD indicate that it is spooling media to the inviting SIP UAC.
REQ-4：在一个或多个被邀请的SIP UAS接受SIP INVITE请求之前，愿意将媒体从邀请的SIP UAC假脱机的中间服务器应表明它正在将媒体假脱机到邀请的SIP UAC。
In order to meet REQ-3, a PTT Server needs to receive an indication back that the invited SIP UA is likely to accept the SIP INVITE request without requiring user intervention. In this case, the PTT Server that has a hint that the invited SIP UAC is likely to accept the request can include an answer state indication in the SIP 183 (Session Progress) response or SIP 200 (OK) response.
为了满足REQ-3，PTT服务器需要接收被邀请SIP UA可能接受SIP INVITE请求的指示，而不需要用户干预。在这种情况下，具有被邀请的SIP UAC可能接受请求的提示的PTT服务器可以在SIP 183（会话进度）响应或SIP 200（OK）响应中包括应答状态指示。
A number of alternatives were considered for the PTT Server to inform another PTT Server or the inviting SIP UAC of the invited PoC SIP UAS's answer mode settings.
考虑了PTT服务器通知另一个PTT服务器或邀请SIP UAC被邀请PoC SIP UAS的应答模式设置的许多备选方案。
One proposal was to create a unique reason-phrase in the SIP 183 response and SIP 200 (OK) response. This was rejected because the reason phrases are normally intended for human readers and not meant to be parsed by servers for special syntactic and semantic meaning.
一项建议是在SIP 183响应和SIP 200（OK）响应中创建一个独特的原因短语。这被拒绝了，因为这些短语通常是为人类读者设计的，而不是为了特殊的语法和语义意义而由服务器解析。
Another proposal was to use a Reason header [14] in the SIP 183 response and SIP 200 (OK) response. This was rejected because this would be inconsistent with the intended use of the Reason header and its usage is not defined for these response codes and would have required creating and registering a new protocol identifier.
另一个建议是在SIP 183响应和SIP 200（OK）响应中使用原因头[14]。这被拒绝，因为这与原因标头的预期用途不一致，并且没有为这些响应代码定义其用途，并且需要创建和注册新的协议标识符。
Another proposal was to use a feature-tag in the returned Contact header as defined in [15]. This was rejected because it was not a different feature, but is an attribute of the session and can be applied to many different features.
另一个建议是在返回的联系人标题中使用[15]中定义的功能标签。这被拒绝，因为它不是一个不同的功能，而是会话的一个属性，可以应用于许多不同的功能。
Another proposal was to use a new SDP attribute. The choice of an SDP parameter was rejected because the answer state applies to the session and not to a media stream.
另一个建议是使用新的SDP属性。SDP参数的选择被拒绝，因为应答状态应用于会话而不是媒体流。
The P-Answer-State header was chosen to give additional information about the state of the SIP session progress and acceptance. Even though the UAC sees that its offer has been answered and accepted, the header lets the UAC know whether the invited PoC subscriber or just an intermediary has accepted the SIP INVITE request.
选择P-Answer-State报头是为了提供关于SIP会话进度和接受状态的附加信息。即使UAC看到其报价已被应答和接受，但标头也会让UAC知道被邀请的PoC订户或只是中间人是否已接受SIP INVITE请求。
The P-Answer-State header is applicable in the following circumstances:
P-Answer-State标头适用于以下情况：
o In networks where there are UAs that engage in half-duplex communication where there is not the possibility for the invited user to verbally acknowledge the answering of the session as is normal in full-duplex communication;
o 在有UAs参与半双工通信的网络中，受邀用户不可能像全双工通信中的正常情况那样口头确认会话应答；
o Where the invited UA can automatically accept the session without user intervention;
o 被邀请的UA可以自动接受会话而无需用户干预；
o The network also contains intermediate network SIP servers that are trusted;
o 该网络还包含受信任的中间网络SIP服务器；
o The intermediate network SIP servers have knowledge of the current answer mode setting of the terminating UAS; and,
o 中间网络SIP服务器知道终端ua的当前应答模式设置；和
o The intermediate network SIP servers have knowledge of the media types and codecs likely to be accepted by the terminating UAS; and,
o 中间网络SIP服务器了解终端UAS可能接受的媒体类型和编解码器；和
o The intermediate network SIP servers can provide buffering of the media in order to reduce the time for the inviting user to send media.
o 中间网络SIP服务器可以提供媒体缓冲，以减少邀请用户发送媒体的时间。
o The intermediate network SIP servers assume knowledge of the network topology and the existence of similar intermediate network SIP servers in the signaling path.
o 中间网络SIP服务器假定了解网络拓扑以及信令路径中存在类似的中间网络SIP服务器。
Such configurations are generally not applicable to the Internet as a whole where such trust relationships do not exist.
这种配置通常不适用于不存在这种信任关系的整个互联网。
In addition, security issues have only been considered for networks that are trusted and use hop-by-hop security mechanisms with transitive trust. Security issues with usage of this mechanism in the general Internet have not been evaluated.
此外，安全问题只考虑了受信任的网络，并使用具有可传递信任的逐跳安全机制。尚未评估在通用Internet中使用此机制的安全问题。
A UAS, B2BUA, or proxy MAY include a P-Answer-State header field in any SIP 18x or 2xx response that does not contain an offer, sent in response to an offer contained in a SIP INVITE request as specified in [7]. Typically, the P-Answer-State header field is included in either a SIP 183 Session Progress or a SIP 200 (OK) response. A UA that receives a SIP REFER request to send a SIP INVITE request MAY also include a P-Answer-State header field in the sipfrag of a response included in a SIP NOTIFY request it sends as a result of the implicit subscription created by the SIP REFER request.
UAS、B2BUA或代理可以在任何SIP 18x或2xx响应中包含P-Answer-State头字段，该响应不包含要约，该响应是响应[7]中指定的SIP INVITE请求中包含的要约而发送的。通常，P-Answer-State报头字段包括在SIP 183会话进度或SIP 200（OK）响应中。接收SIP REFER请求以发送SIP INVITE请求的UA还可以在sipfrag中包括作为SIP REFER请求创建的隐式订阅的结果而发送的SIP NOTIFY请求中包括的响应的P-Answer-State报头字段。
When the P-Answer-State header field contains the parameter "Unconfirmed", the UAS or proxy is indicating that it has information that hints that the final destination UAS for the SIP INVITE request is likely to automatically accept the session, but that this is unconfirmed and it is possible that the final destination UAS will first alert the user and require manual acceptance of the session or not accept the session request. When the P-Answer-State header field contains the parameter "Confirmed", the UAS or proxy is indicating that the destination UAS has accepted the session and is ready to receive media. The parameter value of "Confirmed" has the usual semantics of a SIP 200 (OK) response containing an answer and is included for completeness. A parameter value of "Confirmed" is only included in a SIP 200 (OK) response or in the sipfrag of a 200 (OK) contained in the body of a SIP NOTIFY request.
当P-Answer-State标头字段包含参数“unconfirm”时，UAS或代理表示其具有提示SIP INVITE请求的最终目标UAS可能自动接受会话的信息，但这是未确认的，最终目的地UAS可能会首先警告用户，并要求手动接受会话或不接受会话请求。当P-Answer-State标头字段包含参数“已确认”时，UAS或代理表示目标UAS已接受会话并准备接收媒体。“确认”的参数值具有包含答案的SIP 200（OK）响应的通常语义，并且为了完整性而包括该参数值。“确认”参数值仅包括在SIP 200（OK）响应中或包含在SIP NOTIFY请求主体中的200（OK）的sipfrag中。
A received SIP 18x response without a P-Answer-State header field SHOULD NOT be treated as an "Unconfirmed Response". A SIP 18x response containing a P-Answer-State header field containing the parameter "Confirmed" MUST NOT be treated as a "Confirmed Response" because this is an invalid condition.
不应将接收到的没有P-Answer-State报头字段的SIP 18x响应视为“未确认响应”。包含P-Answer-State头字段（包含参数“confirm”）的SIP 18x响应不得视为“confirm response”，因为这是一种无效条件。
A SIP 200 (OK) response without a P-Answer-State Header field MUST be treated as a "Confirmed Response".
没有P-Answer-State报头字段的SIP 200（OK）响应必须视为“确认响应”。
A UAC (terminal) that receives an "Unconfirmed Response" containing an answer MAY send media as specified in [7]; however, there is no guarantee that the media will be received by the final recipient.
接收到包含应答的“未确认响应”的UAC（终端）可以发送[7]中规定的媒体；但是，不能保证最终接收者会收到媒体。
How a UAC confirms whether or not the media was received by the final destination when it has received a SIP 2xx response containing an "Unconfirmed Indication" is application specific and outside of the scope of this document. If the application is a conference then the mechanism specified in [7] could be used to determine that the invited user joined. Alternatively, a SIP BYE request could be received or the media could be placed on hold if the final destination UAS does not accept the session.
当UAC收到包含“未确认指示”的SIP 2xx响应时，UAC如何确认最终目的地是否接收到媒体是特定于应用程序的，不在本文档的范围内。如果应用程序是一个会议，那么可以使用[7]中指定的机制来确定被邀请的用户是否加入。或者，如果最终目的地UAS不接受会话，则可以接收SIP BYE请求或将媒体置于等待状态。
A UAC (terminal) that receives, in response to a SIP REFER request, a SIP NOTIFY request containing an "Unconfirmed Response" in a sipfrag in the body of the SIP NOTIFY request related to a dialog for which there has been a successful offer-answer exchange according to [5] MAY send media. However, there is no guarantee that the media will be received by the final recipient that was indicated in the Refer-To header in the original SIP REFER request. The dialog could be related either because the SIP REFER request was sent on the same dialog or because the SIP REFER request contained a Target-Dialog header, as defined in [16], that identified the dialog.
响应于SIP REFER请求，接收SIP NOTIFY请求的UAC（终端）可以发送媒体，该SIP NOTIFY请求包含SIP NOTIFY请求主体中的sipfrag中的“未确认响应”，该sipfrag与根据[5]已经成功进行了要约-应答交换的对话相关。但是，不能保证介质将由原始SIP Refer请求中Refer Refer标头中指示的最终接收者接收。该对话框可能是相关的，因为SIP REFER请求是在同一个对话框上发送的，或者因为SIP REFER请求包含标识该对话框的目标对话框头（如[16]中所定义）。
A UAC (terminal) that receives an "Unconfirmed Response" that does not contain an answer MAY buffer media until it receives another "Unconfirmed Response" containing an answer or a "Confirmed Response".
接收不包含应答的“未确认应答”的UAC（终端）可以缓冲介质，直到接收到另一个包含应答或“确认应答”的“未确认应答”。
There are no P-Answer-State procedures for a terminal acting in the UAS role.
对于扮演UAS角色的终端，没有P应答状态程序。
A PTT Server that receives a SIP INVITE request at the UAS part of its back-to-back UA MAY include, in any SIP 18x or 2xx response that does not contain an offer, a P-Answer-State header field with the parameter "Unconfirmed" in the response if it has not yet received a "Confirmed Response" from the final destination UA, and it has information that hints that the final destination UA for the SIP INVITE request is likely to automatically accept the session.
在其背对背UA的UAS部分接收SIP INVITE请求的PTT服务器可以在不包含要约的任何SIP 18x或2xx响应中包括P-ANSWERK-State报头字段，如果其尚未从最终目的地UA接收到“确认响应”，则在响应中具有参数“未确认”，并且它具有提示SIP INVITE请求的最终目的地UA可能自动接受会话的信息。
A PTT Server that receives a SIP 18x response to a SIP INVITE request containing a P-Answer-State header field with the parameter "Unconfirmed" at the UAC part of its back-to-back UA MAY include the P-Answer-State header field with the parameter "Unconfirmed" in a SIP
接收对SIP INVITE请求的SIP 18x响应的PTT服务器，该SIP INVITE请求包含在其背对背UA的UAC部分具有参数“未确认”的P应答状态报头字段，该PTT服务器可以在SIP中包括具有参数“未确认”的P应答状态报头字段
2xx response that the UAS part of its back-to-back UA sends as a result of receiving that response. Otherwise, a PTT Server that receives a SIP 18x or 2xx response to a SIP INVITE request containing a P-Answer-State header field at the UAC part of its back-to-back UA SHOULD include the P-Answer-State header field unmodified in the SIP 18x or 2xx response that the UAS part of its back-to-back UA sends as a result of receiving that response. If the response sent by the UAS part of its back-to-back UA is a SIP 18x response, then the P-Answer-State header field included in the response MUST contain a parameter of "Unconfirmed".
作为接收该响应的结果，其背对背UA的UAS部分发送的2xx响应。否则，在其背对背UA的UAC部分接收包含P-Answer-State报头字段的SIP INVITE请求的SIP 18x或2xx响应的PTT服务器应包括其背对背UA的UAS部分作为接收该响应的结果而发送的SIP 18x或2xx响应中未修改的P-Answer-State报头字段。如果由其背对背UA的UAS部分发送的响应是SIP 18x响应，则响应中包含的P-Answer-State头字段必须包含参数“unconfirm”。
The UAS part of the back-to-back UA of a PTT Server MAY include an answer in the "Unconfirmed Response" it sends even if the "Unconfirmed Response" received by the UAC part of the back-to-back UA did not contain an answer.
即使背对背UA的UAC部分接收到的“未确认响应”不包含应答，PTT服务器的背对背UA的UAS部分也可以在其发送的“未确认响应”中包括应答。
If a PTT Server receives a "Confirmed Response" at the UAC part of its back-to-back UA, then the UAS part of its back-to-back UA MAY include in the forwarded response a P-Answer-State header field with the parameter "Confirmed". If the UAS part of its back-to-back UA previously sent an "Unconfirmed Response" as part of this dialog, the UAS part of its back-to-back UA SHOULD include in the forwarded "Confirmed Response" a P-Answer-State header field with the parameter "Confirmed".
如果PTT服务器在其背对背UA的UAC部分接收到“确认的响应”，则其背对背UA的UAS部分可以在转发的响应中包括具有参数“确认”的P应答状态报头字段。如果其背对背UA的UAS部分先前发送了“未确认响应”作为该对话框的一部分，则其背对背UA的UAS部分应在转发的“确认响应”中包含一个带有参数“已确认”的P应答状态标头字段。
If the UAS part of the back-to-back UA of a PTT Server includes an answer in a response along with a P-Answer-State header field with the parameter "Unconfirmed", then the UAS part of its back-to-back UA needs to be ready to receive media as specified in [7]. Also, it MAY buffer any media it receives until it receives a "Confirmed Response" from the final destination UA or until its buffer is full.
如果PTT服务器的背对背UA的UAS部分包括响应中的应答以及参数为“unconfirm”的P-answer-State报头字段，则其背对背UA的UAS部分需要准备好接收[7]中规定的媒体。此外，它可以缓冲它接收到的任何媒体，直到它从最终目的地UA接收到“确认响应”，或者直到它的缓冲区已满。
A UAS part of the back-to-back UA of a PTT Server that receives a SIP REFER request to send a SIP INVITE request to another UA, as specified in [6], MAY generate a sipfrag of a SIP 200 (OK) response containing a P-Answer-State header field with the parameter "Unconfirmed" prior to the UAC part of its back-to-back UA receiving a response to the SIP INVITE request, if it has information that hints that the final destination UA for the SIP INVITE request is likely to automatically accept the session.
如[6]中所述，PTT服务器的背对背UA的UAS部分接收SIP REFER请求以向另一UA发送SIP INVITE请求，可生成SIP 200（OK）响应的sipfrag，该sipfrag包含参数为“未确认”的P应答状态报头字段在其背对背UA的UAC部分接收到对SIP INVITE请求的响应之前，如果其具有提示SIP INVITE请求的最终目的地UA可能自动接受会话的信息。
If the UAC part of a back-to-back UA of a PTT Server sent a SIP INVITE request as a result of receiving a SIP REFER Request, receives a SIP 18x or 2xx response containing a P-Answer-State header field at the UAC part of its back-to-back UA, then the UAS part of its back-to-back UA SHOULD include the P-Answer-State header field in the sipfrag of the response contained in a SIP NOTIFY request. The P-Answer-State header field that is contained in the sipfrag,
如果PTT服务器的背对背UA的UAC部分由于接收到SIP REFER请求而发送SIP INVITE请求，则在其背对背UA的UAC部分接收到包含P应答状态报头字段的SIP 18x或2xx响应，然后，其背对背UA的UAS部分应在SIP NOTIFY请求中包含的响应的sipfrag中包含P-Answer-State头字段。sipfrag中包含的P-Answer-State标头字段，
contains the parameters from the P-Answer-State from the original response unmodified. This SIP NOTIFY request is the SIP NOTIFY request that the UAS part of the back-to-back UA of the PTT Server sends in response to the original SIP REFER request based upon receiving the SIP 18x or 2xx response. If the sipfrag of the response sent in the SIP NOTIFY request is a SIP 18x response, then the P-Answer-State header field included in the sipfrag of the response MUST contain a parameter of "Unconfirmed". If the UAC part of its back-to-back UA receives a "Confirmed Response" that does not contain a P-Answer-State header field, then the UAS part of its back-to-back UA MAY include a P-Answer-State header field with the parameter "Confirmed" in the sipfrag of the response contained in a SIP NOTIFY request sent in response to the SIP REFER request.
包含原始响应中未修改的P-Answer-State的参数。该SIP NOTIFY请求是PTT服务器的背对背UA的UAS部分基于接收SIP 18x或2xx响应响应原始SIP REFER请求而发送的SIP NOTIFY请求。如果SIP NOTIFY请求中发送的响应的sipfrag是SIP 18x响应，则响应的sipfrag中包含的P-Answer-State头字段必须包含参数“未确认”。如果其背对背UA的UAC部分接收到不包含P-Answer-State报头字段的“确认响应”，则其背对背UA的UAS部分可以包括P-Answer-State报头字段，其中参数“confirm”位于响应SIP REFER请求而发送的SIP NOTIFY请求中包含的响应的sipfrag中。
In the case where a PTT Server that's UAS part of its back-to-back UA previously sent a SIP NOTIFY request as a result of the SIP REFER request:
在作为其背对背UA的UAS部分的PTT服务器先前作为SIP REFER请求的结果发送SIP NOTIFY请求的情况下：
1) the SIP NOTIFY request contains a P-Answer-State header field with the parameter "Unconfirmed" in the sipfrag of a response, and
1) SIP NOTIFY请求包含一个P-ANSWERK-State标头字段，该字段在响应的sipfrag中具有参数“unconfirm”，并且
2) the PTT Server subsequently receives at the UAC part of its back-to-back UA a "Confirmed Response" to the SIP INVITE request.
2) PTT服务器随后在其背对背UA的UAC部分接收对SIP INVITE请求的“确认响应”。
Such a PTT Server SHOULD include a P-Answer-State header field with the parameter "Confirmed" in the sipfrag of the response included in the subsequent SIP NOTIFY request that the UAS part of its back-to-back UA sends as a result of receiving the "Confirmed Response".
这样的PTT服务器应包括P-Answer-State报头字段，该字段在后续SIP NOTIFY请求中包括的响应的sipfrag中具有参数“confirm”，该后续SIP NOTIFY请求是其背对背UA的UAS部分作为接收“confirm response”的结果而发送的。
If the SIP REFER request is related to an existing dialog established by a SIP INVITE request for which there has been a successful offer-answer exchange, the UAS part of its back-to-back UA MUST be ready to receive media as specified in [7]. Also, it MAY buffer any media it receives until the UAC part of its back-to-back UA receives a "Confirmed Response" from the final destination UA or until its buffer is full. The dialog could be related either because the SIP REFER request was sent on the same dialog or because the SIP REFER request contained a Target-Dialog header, as defined in [16], that identified the dialog.
如果SIP REFER请求与SIP INVITE请求建立的现有对话相关，且已成功进行要约-应答交换，则其背对背UA的UAS部分必须准备好接收[7]中规定的媒体。此外，它可以缓冲它接收的任何媒体，直到其背对背UA的UAC部分从最终目的地UA接收到“确认响应”，或者直到其缓冲区已满。该对话框可能是相关的，因为SIP REFER请求是在同一个对话框上发送的，或者因为SIP REFER请求包含标识该对话框的目标对话框头（如[16]中所定义）。
A PTT Server that buffers media SHOULD be prepared for the possibility of not receiving a "Confirmed Response" and SHOULD release the session if a "Confirmed Response" is not received before the buffer overflows.
缓冲介质的PTT服务器应准备好不接收“确认响应”的可能性，如果在缓冲区溢出之前未接收到“确认响应”，则应释放会话。
SIP proxy servers do not need to understand the semantics of the P-Answer-State header field. As part of the regular SIP rules for unknown headers, a proxy will forward unknown headers.
SIP代理服务器不需要理解P-Answer-State头字段的语义。作为未知头的常规SIP规则的一部分，代理将转发未知头。
A PTT Server that acts as a proxy MAY include a P-Answer-State header field with the parameter "Unconfirmed" in a SIP 18x response that it originates (in a manner compliant with [2]) if it has information that hints that the final destination UA for the SIP INVITE request is likely to automatically accept the session.
作为代理的PTT服务器如果具有提示SIP INVITE请求的最终目的地UA可能会自动接受会话的信息，则可以在其发起的SIP 18x响应（以符合[2]的方式）中包括具有参数“unconfirm”的P-Answer-State报头字段。
A PTT Server that acts as a proxy MAY add a P-Answer-State header field with the parameter "Confirmed" to a "Confirmed Response".
充当代理的PTT服务器可以向“确认响应”添加带有参数“确认”的P-Answer-State报头字段。
The mechanisms specified in this document is described in both prose and an augmented Backus-Naur Form (BNF) defined in [8]. Further, several BNF definitions are inherited from SIP and are not repeated here. Implementers need to be familiar with the notation and contents of SIP [2] and [8] to understand this document.
本文中规定的机制在散文和[8]中定义的增广巴科斯-诺尔形式（BNF）中均有描述。此外，几个BNF定义是从SIP继承的，这里不再重复。实施者需要熟悉SIP[2]和[8]的符号和内容才能理解本文档。
The syntax of the P-Answer-State header is described as follows:
P-Answer-State头的语法描述如下：
P-Answer-State = "P-Answer-State" HCOLON answer-type
*(SEMI generic-param)
answer-type = "Confirmed" / "Unconfirmed" / token
P-Answer-State = "P-Answer-State" HCOLON answer-type
*(SEMI generic-param)
answer-type = "Confirmed" / "Unconfirmed" / token
Table 1 provides the additional table entries for the P-Answer-State header needed to extend Table 2 in SIP [2], section 7.1 of the SIP-specific event notification [5], Tables 1 and 2 in the SIP INFO method [17], Tables 1 and 2 in Reliability of provisional responses in SIP [13], Tables 1 and 2 in the SIP UPDATE method [18], Tables 1 and 2 in the SIP extension for Instant Messaging [19], Table 1 in the SIP REFER method [6], and Table 2 in the SIP PUBLISH method [20]:
表1提供了扩展SIP[2]中的表2、SIP特定事件通知[5]第7.1节、SIP信息方法[17]中的表1和表2、SIP[13]中的临时响应可靠性中的表1和表2、SIP更新方法[18]中的表1和表2所需的P-Answer-State报头的附加表项，即时消息[19]的SIP扩展中的表1和表2、SIP引用方法[6]中的表1以及SIP发布方法[20]中的表2：
Header field where proxy ACK BYE CAN INV OPT REG SUB
_______________________________________________________________
P-Answer-State 18x,2xx ar - - - o - - -
Header field where proxy ACK BYE CAN INV OPT REG SUB
_______________________________________________________________
P-Answer-State 18x,2xx ar - - - o - - -
Header field NOT PRA INF UPD MSG REF PUB
_______________________________________________________________
P-Answer-State R - - - - - - -
Header field NOT PRA INF UPD MSG REF PUB
_______________________________________________________________
P-Answer-State R - - - - - - -
Table 1: Additional Table Entries for the P-Answer-State Header
表1：P-Answer-State标题的其他表格条目
For simplicity, some details such as intermediate proxies and SIP 100 Trying responses are not shown in the following example flows.
为简单起见，以下示例流中未显示一些细节，例如中间代理和SIP 100尝试响应。
The following flow shows Alice making a pre-arranged group call using a Conference URI which has Bob on the member list. The session initiation uses the on-demand session establishment mechanism where a SIP INVITE request containing an SDP offer is sent by Alice's terminal when Alice pushes her push to talk button.
下面的流程显示Alice使用成员列表中包含Bob的会议URI进行预先安排的组呼叫。会话启动使用按需会话建立机制，其中当Alice按下按键通话按钮时，Alice的终端发送包含SDP提供的SIP INVITE请求。
In this example, Alice's PTT Server acts a Call Stateful SIP Proxy and Bob's PTT Server (which is aware that the current Answer Mode setting of Bob's terminal is set to Auto Answer) acts as a B2BUA.
在此示例中，Alice的PTT服务器充当呼叫状态SIP代理，Bob的PTT服务器（知道Bob终端的当前应答模式设置设置为自动应答）充当B2BUA。
For simplicity, the invitations by the Conference Focus to the other members of the group are not shown in this example.
为简单起见，本例中未显示会议焦点向组的其他成员发出的邀请。
Alice's Alice's Conference Bob's Bob's
Terminal PTT Server Focus PTT Server Terminal
| | | | |
|--(1)INVITE-->| | | |
| |--(2)INVITE-->| | |
| | |--(3)INVITE->| |
| | | |--(4)INVITE-->|
| | |<--(5)183----| |
| |<---(6)200----| | |
|<---(7)200----| | | |
|----(8)ACK--->| | | |
| |---(9)ACK---->| | |
| | | | |
|=====Early Media Session====>| | |
| | MEDIA | |
| | BUFFERING | |
| | | |<---(10)200---|
| | | |---(11)ACK--->|
| | |<--(12)200---| |
| | |--(13)ACK--->| |
| | | | |
| | |========Media Session======>|
| | | | |
| | | | |
Alice's Alice's Conference Bob's Bob's
Terminal PTT Server Focus PTT Server Terminal
| | | | |
|--(1)INVITE-->| | | |
| |--(2)INVITE-->| | |
| | |--(3)INVITE->| |
| | | |--(4)INVITE-->|
| | |<--(5)183----| |
| |<---(6)200----| | |
|<---(7)200----| | | |
|----(8)ACK--->| | | |
| |---(9)ACK---->| | |
| | | | |
|=====Early Media Session====>| | |
| | MEDIA | |
| | BUFFERING | |
| | | |<---(10)200---|
| | | |---(11)ACK--->|
| | |<--(12)200---| |
| | |--(13)ACK--->| |
| | | | |
| | |========Media Session======>|
| | | | |
| | | | |
Figure 1: Pre-Arranged Group Call Using On-Demand Session
图1：使用随需应变会话的预先安排的群呼
1 INVITE Alice -> Alice's PTT Server
1邀请Alice->Alice的PTT服务器
INVITE sip:FriendsOfAlice@example.org SIP/2.0
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
Max-Forwards: 70
To: "Alice's Friends" <sip:FriendsOfAlice@example.org>
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.example.org>
Content-Type: application/sdp
Content-Length: 142
INVITE sip:FriendsOfAlice@example.org SIP/2.0
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
Max-Forwards: 70
To: "Alice's Friends" <sip:FriendsOfAlice@example.org>
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.example.org>
Content-Type: application/sdp
Content-Length: 142
(SDP not shown)
（未显示SDP）
2 INVITE Alice's PTT Server -> Conference Focus
2邀请Alice的PTT服务器->会议焦点
INVITE sip:FriendsOfAlice@example.org SIP/2.0
Via: SIP/2.0/UDP
AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
INVITE sip:FriendsOfAlice@example.org SIP/2.0
Via: SIP/2.0/UDP
AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
Record-Route: <sip:AlicesPTTServer.example.org>
Max-Forwards: 69
To: "Alice's Friends" <sip:FriendsOfAlice@example.org>
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.example.org>
Content-Type: application/sdp
Content-Length: 142
Record-Route: <sip:AlicesPTTServer.example.org>
Max-Forwards: 69
To: "Alice's Friends" <sip:FriendsOfAlice@example.org>
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.example.org>
Content-Type: application/sdp
Content-Length: 142
(SDP not shown)
（未显示SDP）
The Conference Focus explodes the Conference URI and Invites Bob
会议焦点爆炸会议URI并邀请Bob
3 INVITE Conference Focus -> Bob's PTT Server
3邀请会议焦点->鲍勃的PTT服务器
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP
AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
CSeq: 301166605 INVITE
Contact: <sip:AlicesConferenceFocus.example.org>
Content-Type: application/sdp
Content-Length: 142
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP
AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
CSeq: 301166605 INVITE
Contact: <sip:AlicesConferenceFocus.example.org>
Content-Type: application/sdp
Content-Length: 142
(SDP not shown)
（未显示SDP）
4 INVITE Bob's PTT Server -> Bob
4邀请Bob的PTT服务器->Bob
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP
BobsPTTServer.example.com;branch=z9hG4bKa27bc93
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 INVITE
Contact: <sip:BobsPTTServer.example.com>
Content-Type: application/sdp
Content-Length: 142
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP
BobsPTTServer.example.com;branch=z9hG4bKa27bc93
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 INVITE
Contact: <sip:BobsPTTServer.example.com>
Content-Type: application/sdp
Content-Length: 142
(SDP not shown)
（未显示SDP）
5 183 (Session Progress) Bob's PTT Server -> Conference Focus
5 183（会话进度）Bob的PTT服务器->会议焦点
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
To: "Bob" <sip:bob@example.com>;tag=a6c85cf
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
Contact: <sip:BobsPTTServer.example.com>
CSeq: 301166605 INVITE
P-Answer-State: Unconfirmed
Content-Length: 0
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
To: "Bob" <sip:bob@example.com>;tag=a6c85cf
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
Contact: <sip:BobsPTTServer.example.com>
CSeq: 301166605 INVITE
P-Answer-State: Unconfirmed
Content-Length: 0
6 200 (OK) Conference Focus -> Alice's PTT Server
6200（确定）会议焦点->Alice的PTT服务器
SIP/2.0 200 OK
Via: SIP/2.0/UDP
AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP
pc33.example.org;branch=z9hG4bKnashds8
Record-Route: <sip:AlicesPTTServer.example.org>
To: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=c70ef99
From: "Alice"
<sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:AlicesConferenceFocus.example.org>
P-Answer-State: Unconfirmed
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)
SIP/2.0 200 OK
Via: SIP/2.0/UDP
AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP
pc33.example.org;branch=z9hG4bKnashds8
Record-Route: <sip:AlicesPTTServer.example.org>
To: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=c70ef99
From: "Alice"
<sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:AlicesConferenceFocus.example.org>
P-Answer-State: Unconfirmed
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)
7 200 (OK) Alice's PTT Server -> Alice
7200（确定）Alice的PTT服务器->Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
Record-Route: <sip:AlicesPTTServer.example.org>
To: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:AlicesConferenceFocus.example.org>
P-Answer-State: Unconfirmed
Content-Type: application/sdp
Content-Length: 131
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
Record-Route: <sip:AlicesPTTServer.example.org>
To: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:AlicesConferenceFocus.example.org>
P-Answer-State: Unconfirmed
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)
（未显示SDP）
8 ACK Alice -> Alice's PTT Server
8确认Alice->Alice的PTT服务器
ACK sip:AlicesConferenceFocus.example.org SIP/2.0
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds9
Route: <sip:AlicesPTTServer.example.org>
Max-Forwards: 70
To: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0
ACK sip:AlicesConferenceFocus.example.org SIP/2.0
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds9
Route: <sip:AlicesPTTServer.example.org>
Max-Forwards: 70
To: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0
9 ACK Alice's PTT Server -> Conference Focus
9确认Alice的PTT服务器->会议焦点
ACK sip:AlicesConferenceFocus.example.org SIP/2.0
Via: SIP/2.0/UDP
AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP
pc33.example.org;branch=z9hG4bKnashds9
Max-Forwards: 69
To: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0
ACK sip:AlicesConferenceFocus.example.org SIP/2.0
Via: SIP/2.0/UDP
AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP
pc33.example.org;branch=z9hG4bKnashds9
Max-Forwards: 69
To: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0
The early half-duplex media session between Alice and the Conference Focus is now established, and the Conference Focus buffers the media it receives from Alice.
Alice和Conference Focus之间的早期半双工媒体会话现在已建立，并且Conference Focus缓冲它从Alice接收的媒体。
10 200 (OK) Bob -> Bob's PTT Server
10 200（正常）鲍勃->鲍勃的PTT服务器
SIP/2.0 200 OK
Via: SIP/2.0/UDP
BobsPTTServer.example.com;branch=z9hG4bKa27bc93
To: "Bob" <sip:bob@example.com>;tag=d28119a
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
SIP/2.0 200 OK
Via: SIP/2.0/UDP
BobsPTTServer.example.com;branch=z9hG4bKa27bc93
To: "Bob" <sip:bob@example.com>;tag=d28119a
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)
（未显示SDP）
11 ACK Bob's PTT Server -> Bob
11确认鲍勃的PTT服务器->鲍勃
ACK sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP BobsPTTServer.example.com;branch=z9hG4bKa27bc93
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>;tag=d28119a
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 ACK
Content-Length: 0
ACK sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP BobsPTTServer.example.com;branch=z9hG4bKa27bc93
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>;tag=d28119a
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 ACK
Content-Length: 0
12 200 (OK) Bob's PTT Server -> Conference Focus
12 200（正常）鲍勃的PTT服务器->会议焦点
SIP/2.0 200 OK
Via: SIP/2.0/UDP
AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
To: "Bob" <sip:bob@example.com>;tag=a6670811
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
Contact: <sip:BobsPTTServer.example.com>
CSeq: 301166605 INVITE
P-Answer-State: Confirmed
Content-Type: application/sdp
Content-Length: 131
SIP/2.0 200 OK
Via: SIP/2.0/UDP
AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
To: "Bob" <sip:bob@example.com>;tag=a6670811
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
Contact: <sip:BobsPTTServer.example.com>
CSeq: 301166605 INVITE
P-Answer-State: Confirmed
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)
（未显示SDP）
13 ACK Conference Focus -> Bob's PTT Server
13 ACK会议焦点->鲍勃的PTT服务器
ACK sip:BobsPTTServer.example.com SIP/2.0
Via: SIP/2.0/UDP
AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
Max-Forwards: 70
To: "Bob"
<sip:bob@example.com>;tag=a6670811
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
CSeq: 301166605 ACK
Content-Length: 0
ACK sip:BobsPTTServer.example.com SIP/2.0
Via: SIP/2.0/UDP
AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
Max-Forwards: 70
To: "Bob"
<sip:bob@example.com>;tag=a6670811
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
CSeq: 301166605 ACK
Content-Length: 0
The media session between Alice and Bob is now established and the Conference Focus forwards the buffered media to Bob.
Alice和Bob之间的媒体会话现已建立，会议焦点将缓冲媒体转发给Bob。
The following flow shows Alice making a 1-1 Call to Bob using a pre-established session. A pre-established session is where a dialog is established with Alice's PTT Server using a SIP INVITE SDP offer-answer exchange to pre-negotiate the codecs and other media parameters to be used for media sessions ahead of Alice initiating a communication. When Alice initiates a communication to Bob, a SIP REFER request is used to request Alice's PTT Server to send a SIP INVITE request to Bob. In this example, Bob's terminal does not use the pre-established session mechanism.
以下流程显示Alice使用预先建立的会话对Bob进行1-1调用。预先建立的会话是指在Alice启动通信之前，使用SIP INVITE SDP OFFERE answer交换与Alice的PTT服务器建立对话，以预先协商用于媒体会话的编解码器和其他媒体参数。当Alice向Bob发起通信时，SIP REFER请求用于请求Alice的PTT服务器向Bob发送SIP INVITE请求。在本例中，Bob的终端不使用预先建立的会话机制。
In this example, Alice's PTT Server acts as a B2BUA and also performs the Conference Focus function. Bob's PTT Server (which is aware that the current Answer Mode setting of Bob's terminal is set to Auto Answer) acts as a B2BUA.
在本例中，Alice的PTT服务器充当B2BUA并执行会议焦点功能。Bob的PTT服务器（知道Bob终端的当前应答模式设置为自动应答）充当B2BUA。
Alice's Alice's Bob's Bob's
Terminal PTT Server / PTT Server Terminal
Conference Focus
| | | |
|-----(1)INVITE-- ----->| | |
|<-----(2)200-----------| | |
|-------(3)ACK--------->| | |
| | | |
| | | |
| | | |
|----(4)REFER---------->| | |
|<-----(5)202-----------| | |
| |----(6)INVITE---->| |
| | |--(7)INVITE---->|
| | | |
| |<----(8)183-------| |
|<---(9)NOTIFY----------| | |
|-----(10)200---------->| | |
| | | |
|=Early Media Session==>| | |
| MEDIA | |
| BUFFERING | |
| | |<---(11)200-----|
| | |---(12)ACK----->|
| |<----(13)200------| |
| |-----(14)ACK----->| |
| |===========Media Session==========>|
| | | |
|<---(15)NOTIFY---------| | |
|-----(16)200---------->| | |
| | | |
Alice's Alice's Bob's Bob's
Terminal PTT Server / PTT Server Terminal
Conference Focus
| | | |
|-----(1)INVITE-- ----->| | |
|<-----(2)200-----------| | |
|-------(3)ACK--------->| | |
| | | |
| | | |
| | | |
|----(4)REFER---------->| | |
|<-----(5)202-----------| | |
| |----(6)INVITE---->| |
| | |--(7)INVITE---->|
| | | |
| |<----(8)183-------| |
|<---(9)NOTIFY----------| | |
|-----(10)200---------->| | |
| | | |
|=Early Media Session==>| | |
| MEDIA | |
| BUFFERING | |
| | |<---(11)200-----|
| | |---(12)ACK----->|
| |<----(13)200------| |
| |-----(14)ACK----->| |
| |===========Media Session==========>|
| | | |
|<---(15)NOTIFY---------| | |
|-----(16)200---------->| | |
| | | |
Figure 2: 1-1 Call Using Pre-Established Session
图2：使用预先建立的会话的1-1呼叫
1 INVITE Alice -> Alice's PTT Server
1邀请Alice->Alice的PTT服务器
INVITE sip:AlicesConferenceFactoryURI.example.org SIP/2.0 Via:
SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.example.org> From: "Alice"
<sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq:
314159 INVITE Contact: <sip:alice@pc33.example.org> Content-Type:
application/sdp Content-Length: 142
INVITE sip:AlicesConferenceFactoryURI.example.org SIP/2.0 Via:
SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.example.org> From: "Alice"
<sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq:
314159 INVITE Contact: <sip:alice@pc33.example.org> Content-Type:
application/sdp Content-Length: 142
(SDP not shown)
（未显示SDP）
2 200 (OK) Alice's PTT Server -> Alice
2200（正常）Alice的PTT服务器->Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:AlicesPre-establishedSession@
AlicesPTTServer.example.org>
Content-Type: application/sdp
Content-Length: 131
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:AlicesPre-establishedSession@
AlicesPTTServer.example.org>
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)
（未显示SDP）
3 ACK Alice -> Alice's PTT Server
3确认Alice->Alice的PTT服务器
ACK sip:AlicesPre-establishedSession@AlicesPTTServer.example.org
SIP/2.0
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0
ACK sip:AlicesPre-establishedSession@AlicesPTTServer.example.org
SIP/2.0
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0
Alice's terminal has established a Pre-established Session with Alice's PTT Server. All the media parameters are pre-negotiated for use at communication time.
Alice的终端已经与Alice的PTT服务器建立了预先建立的会话。所有媒体参数都经过预先协商，以便在通信时使用。
Alice initiates a communication to Bob.
爱丽丝开始与鲍勃沟通。
4 REFER Alice -> Alice's PTT Server
4参考Alice->Alice的PTT服务器
REFER sip:AlicesPre-establishedSession@AlicesPTTServer.example.org
SIP/2.0
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
Refer-To: "Bob" <sip:bob@example.com>
Contact: <sip:alice@pc33.example.org>
REFER sip:AlicesPre-establishedSession@AlicesPTTServer.example.org
SIP/2.0
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
Refer-To: "Bob" <sip:bob@example.com>
Contact: <sip:alice@pc33.example.org>
5 202 (ACCEPTED) Alice's PTT Server -> Alice
5202（已接受）Alice的PTT服务器->Alice
SIP/2.0 202 ACCEPTED
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
Contact: <sip:AlicesPre-establishedSession@
AlicesPTTServer.example.org>
SIP/2.0 202 ACCEPTED
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
Contact: <sip:AlicesPre-establishedSession@
AlicesPTTServer.example.org>
6 INVITE Conference Focus -> Bob's PTT Server
6邀请会议焦点->鲍勃的PTT服务器
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP
AlicesConferenceFocus.example.org;branch=z9hG4bk4721d8
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>
From: "Alice" <sip:Alice@example.org>;tag=2178309898
Referred-By: <sip:Alice@example.org>
Call-ID: e60a4c784b6716
CSeq: 301166605 INVITE
Contact: <sip:AlicesConferenceFocus.example.org>
Content-Type: application/sdp
Content-Length: 142
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP
AlicesConferenceFocus.example.org;branch=z9hG4bk4721d8
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>
From: "Alice" <sip:Alice@example.org>;tag=2178309898
Referred-By: <sip:Alice@example.org>
Call-ID: e60a4c784b6716
CSeq: 301166605 INVITE
Contact: <sip:AlicesConferenceFocus.example.org>
Content-Type: application/sdp
Content-Length: 142
(SDP not shown)
（未显示SDP）
7 INVITE Bob's PTT Server -> Bob
7邀请Bob的PTT服务器->Bob
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP
BobsPTTServer.example.com;branch=z9hG4bKa27bc93
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>
From: "Alice" <sip:Alice@example.org>;tag=781299330
Referred-By: <sip:Alice@example.org>
Call-ID: 6eb4c66a847710
CSeq: 478209 INVITE
Contact: <sip:BobsPTTServer.example.com>
Content-Type: application/sdp
Content-Length: 142
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP
BobsPTTServer.example.com;branch=z9hG4bKa27bc93
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>
From: "Alice" <sip:Alice@example.org>;tag=781299330
Referred-By: <sip:Alice@example.org>
Call-ID: 6eb4c66a847710
CSeq: 478209 INVITE
Contact: <sip:BobsPTTServer.example.com>
Content-Type: application/sdp
Content-Length: 142
(SDP not shown)
（未显示SDP）
8 183 (Session Progress) Bob's PTT Server -> Conference Focus
8 183（会话进度）Bob的PTT服务器->会议焦点
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
To: "Bob" <sip:bob@example.com>;tag=a6c85cf
From: "Alice" <sip:Alice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
Contact: <sip:BobsPTTServer.example.com>
CSeq: 301166605 INVITE
P-Answer-State: Unconfirmed
Content-Length: 0
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
To: "Bob" <sip:bob@example.com>;tag=a6c85cf
From: "Alice" <sip:Alice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
Contact: <sip:BobsPTTServer.example.com>
CSeq: 301166605 INVITE
P-Answer-State: Unconfirmed
Content-Length: 0
9 NOTIFY Alice's PTT Server -> Alice
9通知Alice的PTT服务器->Alice
NOTIFY sip:alice@pc33.example.org SIP/2.0
Via: SIP/2.0/UDP
AlicesPre-establishedSession@AlicesPTTServer.example.org;
branch=z9hG4bKnashds8
Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 NOTIFY
Contact:
<sip:AlicesPre-establishedSession@AlicesPTTServer.example.org>
Event: refer
Subscription-State: Active;Expires=60
Content-Type: message/sipfrag;version=2.0
Content-Length: 99
NOTIFY sip:alice@pc33.example.org SIP/2.0
Via: SIP/2.0/UDP
AlicesPre-establishedSession@AlicesPTTServer.example.org;
branch=z9hG4bKnashds8
Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 NOTIFY
Contact:
<sip:AlicesPre-establishedSession@AlicesPTTServer.example.org>
Event: refer
Subscription-State: Active;Expires=60
Content-Type: message/sipfrag;version=2.0
Content-Length: 99
SIP/2.0 183 Session Progress
To: "Bob" <sip:bob@example.com>;tag=d28119a
P-Answer-State: Unconfirmed
SIP/2.0 183 Session Progress
To: "Bob" <sip:bob@example.com>;tag=d28119a
P-Answer-State: Unconfirmed
10 200 (OK) Alice -> Alice's PTT Server
10200（确定）Alice->Alice的PTT服务器
SIP/2.0 200 OK
Via: SIP/2.0/UDP
AlicesPre-establishedSession@AlicesPTTServer.example.org;
branch=z9hG4bKnashds8
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 NOTIFY
SIP/2.0 200 OK
Via: SIP/2.0/UDP
AlicesPre-establishedSession@AlicesPTTServer.example.org;
branch=z9hG4bKnashds8
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 NOTIFY
The early half-duplex media session between Alice and the Conference Focus is now established and the Conference Focus buffers the media it receives from Alice.
Alice和Conference Focus之间的早期半双工媒体会话现在已建立，Conference Focus缓冲从Alice接收的媒体。
11 200 (OK) Bob -> Bob's PTT Server
11200（正常）鲍勃->鲍勃的PTT服务器
SIP/2.0 200 OK
Via: SIP/2.0/UDP
BobsPTTServer.example.com;branch=z9hG4bK927bc93
To: "Bob" <sip:bob@example.com>;tag=d28119a
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
SIP/2.0 200 OK
Via: SIP/2.0/UDP
BobsPTTServer.example.com;branch=z9hG4bK927bc93
To: "Bob" <sip:bob@example.com>;tag=d28119a
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)
（未显示SDP）
12 ACK Bob's PTT Server -> Bob
12确认Bob的PTT服务器->Bob
ACK sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP BobsPTTServer.example.com;branch=z9hG4bK927bc93
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>;tag=d28119a
From: "Alice" <sip:Alice@example.org>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 ACK
Content-Length: 0
ACK sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP BobsPTTServer.example.com;branch=z9hG4bK927bc93
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>;tag=d28119a
From: "Alice" <sip:Alice@example.org>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 ACK
Content-Length: 0
F13 200 (OK) Bob's PTT Server -> Conference Focus
F13 200（正常）鲍勃的PTT服务器->会议焦点
SIP/2.0 200 OK
Via: SIP/2.0/UDP
AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
To: "Bob" <sip:bob@example.com>;tag=a6670811
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
Contact: <sip:BobsPTTServer.example.com>
CSeq: 301166605 INVITE
P-Answer-State: Confirmed
Content-Type: application/sdp
Content-Length: 131
SIP/2.0 200 OK
Via: SIP/2.0/UDP
AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
To: "Bob" <sip:bob@example.com>;tag=a6670811
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
Contact: <sip:BobsPTTServer.example.com>
CSeq: 301166605 INVITE
P-Answer-State: Confirmed
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)
（未显示SDP）
14 ACK Conference Focus -> Bob's PTT Server
14 ACK会议焦点->鲍勃的PTT服务器
ACK sip:BobsPTTServer.example.com SIP/2.0
Via: SIP/2.0/UDP
AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>;tag=a6670811
From: "Alice" <sip:Alice@example.org>;tag=1928301774
Call-ID: e60a4c784b6716
CSeq: 301166605 ACK
Content-Length: 0
ACK sip:BobsPTTServer.example.com SIP/2.0
Via: SIP/2.0/UDP
AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>;tag=a6670811
From: "Alice" <sip:Alice@example.org>;tag=1928301774
Call-ID: e60a4c784b6716
CSeq: 301166605 ACK
Content-Length: 0
The media session between Alice and Bob is now established and the Conference Focus forwards the buffered media to Bob.
Alice和Bob之间的媒体会话现已建立，会议焦点将缓冲媒体转发给Bob。
15 NOTIFY Alice's PTT Server -> Alice
15通知Alice的PTT服务器->Alice
NOTIFY sip:alice@pc33.example.org SIP/2.0
Via: SIP/2.0/UDP
AlicesPre-establishedSession@AlicesPTTServer.example.org;
branch=z9hG4bKnashds8
Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 NOTIFY
Contact: <sip:AlicesPre-establishedSession@
AlicesPTTServer.example.org>
Event: refer
Subscription-State: Active;Expires=60
Content-Type: message/sipfrag;version=2.0
Content-Length: 83
NOTIFY sip:alice@pc33.example.org SIP/2.0
Via: SIP/2.0/UDP
AlicesPre-establishedSession@AlicesPTTServer.example.org;
branch=z9hG4bKnashds8
Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 NOTIFY
Contact: <sip:AlicesPre-establishedSession@
AlicesPTTServer.example.org>
Event: refer
Subscription-State: Active;Expires=60
Content-Type: message/sipfrag;version=2.0
Content-Length: 83
SIP/2.0 200 OK
To: "Bob" <sip:bob@example.com>;tag=d28119a
P-Answer-State: Confirmed
SIP/2.0 200 OK
To: "Bob" <sip:bob@example.com>;tag=d28119a
P-Answer-State: Confirmed
16 200 (OK) Alice -> Alice's PTTServer
16200（确定）Alice->Alice的PTT服务器
SIP/2.0 200 OK
Via: SIP/2.0/UDP
AlicesPre-establishedSession@AlicesPTTServer.example.org;
branch=z9hG4bKnashds8
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 NOTIFY
SIP/2.0 200 OK
Via: SIP/2.0/UDP
AlicesPre-establishedSession@AlicesPTTServer.example.org;
branch=z9hG4bKnashds8
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 NOTIFY
The information returned in the P-Answer-State header is not viewed as particularly sensitive. Rather, it is informational in nature, providing an indication to the UAC that delivery of any media sent as a result of an answer in this response is not guaranteed. An eavesdropper cannot gain any useful information by obtaining the contents of this header.
P-Answer-State报头中返回的信息不被视为特别敏感。相反，它本质上是信息性的，向UAC提供了一个指示，即不保证根据此响应中的答复发送任何媒体。窃听者无法通过获取此头的内容获得任何有用的信息。
End-to-end protection is not appropriate because the P-Answer-State header is used and added by proxies and intermediate UAs. As a result, a "malicious" proxy between the UAs or attackers on the signaling path could add or remove the header or modify the contents of the header value. This attack either denies the caller the knowledge that the callee has yet to be contacted or falsely indicates that the callee has yet to be contacted when they have already answered. The attack that falsely indicates that the callee has yet to be contacted when they have already answered attack could result in the caller deciding not to transmit media because they do not wish to have their media stored by an intermediary even though in reality the callee has answered. The attack that denies the callee the additional knowledge that the callee has yet to be contacted does not appear to be a significant concern since this is the same as the situation when a B2BUA sends a 200 (OK) before the callee has answered without the use of this extension.
端到端保护不合适，因为P-Answer-State标头由代理和中间UAs使用和添加。因此，UAs或信令路径上的攻击者之间的“恶意”代理可能会添加或删除标头或修改标头值的内容。这种攻击要么拒绝呼叫者知道被呼叫者尚未被联系，要么在被呼叫者已经应答时错误地表示尚未被联系。当被叫人已经应答攻击时，错误地表示尚未与被叫人联系的攻击可能会导致被叫人决定不传输媒体，因为即使被叫人实际上已经应答，他们也不希望媒体被中间人存储。拒绝被叫方知道被叫方尚未联系的额外信息的攻击似乎不是一个重大问题，因为这与B2BUA在被叫方未使用此分机应答之前发送200（OK）的情况相同。
It is therefore necessary to protect the messages between proxies and implementation SHOULD use a transport that provides integrity and confidentially between the signaling hops. The Transport Layer Security (TLS) [9] based signaling in SIP can be used to provide this protection.
因此，有必要保护代理之间的消息，并且实现应使用在信令跳之间提供完整性和机密性的传输。SIP中基于传输层安全性（TLS）[9]的信令可用于提供这种保护。
Security issues have only been considered for networks that are trusted and use hop-by-hop security mechanisms with transitive trust. Security issues with usage of this mechanism in the general Internet have not been evaluated.
安全问题只被考虑用于受信任的网络，并使用具有可传递信任的逐跳安全机制。尚未评估在通用Internet中使用此机制的安全问题。
This document defines a private SIP extension header field (beginning with the prefix "P-" ) based on the registration procedures defined in RFC 3427 [21].
本文档根据RFC 3427[21]中定义的注册过程定义了专用SIP扩展头字段（以前缀“P-”）开头）。
The following row has been added to the "Header Fields" section of the SIP parameter registry:
以下行已添加到SIP参数注册表的“标题字段”部分：
+----------------+--------------+-----------+
| Header Name | Compact Form | Reference |
+----------------+--------------+-----------+
| P-Answer-State | | [RFC4964] |
+----------------+--------------+-----------+
+----------------+--------------+-----------+
| Header Name | Compact Form | Reference |
+----------------+--------------+-----------+
| P-Answer-State | | [RFC4964] |
+----------------+--------------+-----------+
The authors would like to thank Jon Peterson, Cullen Jennings, Jeroen van Bemmel, Paul Kyzivat, Dale Worley, Dean Willis, Rohan Mahay, Christian Schmidt, Mike Hammer, and Miguel Garcia-Martin for their comments that contributed to the progression of this work. The authors would also like to thank the OMA POC Working Group members for their support of this document and, in particular, Tom Hiller for presenting the concept of the P-Answer-State header to SIPPING at IETF 62.
作者要感谢Jon Peterson、Cullen Jennings、Jeroen van Bemmel、Paul Kyzivat、Dale Worley、Dean Willis、Rohan Mahay、Christian Schmidt、Mike Hammer和Miguel Garcia Martin的评论，他们的评论为这项工作的进展做出了贡献。作者还想感谢OMA POC工作组成员对本文件的支持，特别是Tom Hiller在IETF 62上向啜饮者介绍了P应答状态标题的概念。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[3] OMA, "Push to talk over Cellular - Architecture", OMA-AD-PoC-V1_0_1-20061128-A, November 2006.
[3] OMA，“蜂窝网络架构上的按键通话”，OMA-AD-PoC-V1_0_1-20061128-A，2006年11月。
[4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[4] Sparks，R.，“互联网媒体类型信息/sipfrag”，RFC 3420，2002年11月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[6] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[6] Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，2003年4月。
[7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[7] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[8] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[8] Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[9] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[9] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[10] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[10] Rosenberg，J.，“会话启动协议（SIP）会议框架”，RFC 4353，2006年2月。
[11] Garcia-Martin, M., "A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service", RFC 4354, January 2006.
[11] Garcia Martin，M.，“支持蜂窝式按键通话（PoC）服务的各种设置的会话启动协议（SIP）事件包和数据格式”，RFC 4354，2006年1月。
[12] Willis, D., Ed., and A. Allen, "Requesting Answering Modes for the Session Initiation Protocol (SIP)", Work in Progress, June 2007.
[12] Willis，D.，Ed.，和A.Allen，“请求会话启动协议（SIP）的应答模式”，正在进行的工作，2007年6月。
[13] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[13] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 3262，2002年6月。
[14] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[14] Schulzrinne，H.，Oran，D.，和G.Camarillo，“会话启动协议（SIP）的原因头字段”，RFC3326，2002年12月。
[15] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[15] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[16] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
[16] Rosenberg，J.，“通过会话启动协议（SIP）中的对话标识请求授权”，RFC 4538，2006年6月。
[17] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[17] Donovan，S.，“SIP信息方法”，RFC 29762000年10月。
[18] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[18] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[19] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[19] Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[20] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[20] Niemi，A.，“事件状态发布的会话启动协议（SIP）扩展”，RFC 3903，2004年10月。
[21] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[21] Mankin，A.，Bradner，S.，Mahy，R.，Willis，D.，Ott，J.，和B.Rosen，“会话启动协议（SIP）的变更过程”，BCP 67，RFC 3427，2002年12月。
Authors' Addresses
作者地址
Andrew Allen (editor) Research in Motion (RIM) 102 Decker Court, Suite 100 Irving, Texas 75062 USA
安德鲁·艾伦（编辑）《运动研究》（RIM）美国德克萨斯州欧文市德克法院102号100室，邮编75062
EMail: aallen@rim.com
EMail: aallen@rim.com
Jan Holm Ericsson Tellusborgsvagen 83-87 Stockholm 12526 Sweden
Jan Holm Ericsson Tellusborgsvagen 83-87瑞典斯德哥尔摩12526
EMail: Jan.Holm@ericsson.com
EMail: Jan.Holm@ericsson.com
Tom Hallin Motorola 1501 W Shure Drive Arlington Heights, IL 60004 USA
Tom Hallin摩托罗拉1501 W舒尔大道美国伊利诺伊州阿灵顿高地60004
EMail: thallin@motorola.com
EMail: thallin@motorola.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.