Network Working Group J. Rosenberg
Request for Comments: 3725 dynamicsoft
BCP: 85 J. Peterson
Category: Best Current Practice Neustar
H. Schulzrinne
Columbia University
G. Camarillo
Ericsson
April 2004
Network Working Group J. Rosenberg
Request for Comments: 3725 dynamicsoft
BCP: 85 J. Peterson
Category: Best Current Practice Neustar
H. Schulzrinne
Columbia University
G. Camarillo
Ericsson
April 2004
Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)
会话启动协议（SIP）中第三方呼叫控制（3pcc）的最佳当前实践
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of SIP for third party call control.
第三方呼叫控制是指一个实体创建呼叫的能力，在该呼叫中，通信实际上是在其他方之间进行的。第三方呼叫控制可以使用会话启动协议（SIP）中指定的机制。然而，有几种可能的方法，每种方法都有不同的优点和缺点。本文档讨论了将SIP用于第三方呼叫控制的最佳实践。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
4. 3pcc Call Establishment . . . . . . . . . . . . . . . . . . 3
4.1. Flow I . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Flow II. . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Flow III . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Flow IV. . . . . . . . . . . . . . . . . . . . . . . . 8
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . 9
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10
7. Continued Processing . . . . . . . . . . . . . . . . . . . . 11
8. 3pcc and Early Media . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
4. 3pcc Call Establishment . . . . . . . . . . . . . . . . . . 3
4.1. Flow I . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Flow II. . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Flow III . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Flow IV. . . . . . . . . . . . . . . . . . . . . . . . 8
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . 9
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10
7. Continued Processing . . . . . . . . . . . . . . . . . . . . 11
8. 3pcc and Early Media . . . . . . . . . . . . . . . . . . . . 13
9. Third Party Call Control and SDP Preconditions . . . . . . . 16
9.1. Controller Initiates . . . . . . . . . . . . . . . . . 16
9.2. Party A Initiates. . . . . . . . . . . . . . . . . . . 18
10. Example Call Flows . . . . . . . . . . . . . . . . . . . . . 21
10.1. Click-to-Dial. . . . . . . . . . . . . . . . . . . . . 21
10.2. Mid-Call Announcement Capability . . . . . . . . . . . 23
11. Implementation Recommendations . . . . . . . . . . . . . . . 25
12. Security Considerations. . . . . . . . . . . . . . . . . . . 26
12.1. Authorization and Authentication . . . . . . . . . . . 26
12.2. End-to-End Encryption and Integrity. . . . . . . . . . 27
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
14.1. Normative References . . . . . . . . . . . . . . . . . 28
14.2. Informative References . . . . . . . . . . . . . . . . 29
15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
16. Full Copyright Statement . . . . . . . . . . . . . . . . . . 31
9. Third Party Call Control and SDP Preconditions . . . . . . . 16
9.1. Controller Initiates . . . . . . . . . . . . . . . . . 16
9.2. Party A Initiates. . . . . . . . . . . . . . . . . . . 18
10. Example Call Flows . . . . . . . . . . . . . . . . . . . . . 21
10.1. Click-to-Dial. . . . . . . . . . . . . . . . . . . . . 21
10.2. Mid-Call Announcement Capability . . . . . . . . . . . 23
11. Implementation Recommendations . . . . . . . . . . . . . . . 25
12. Security Considerations. . . . . . . . . . . . . . . . . . . 26
12.1. Authorization and Authentication . . . . . . . . . . . 26
12.2. End-to-End Encryption and Integrity. . . . . . . . . . 27
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
14.1. Normative References . . . . . . . . . . . . . . . . . 28
14.2. Informative References . . . . . . . . . . . . . . . . 29
15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
16. Full Copyright Statement . . . . . . . . . . . . . . . . . . 31
In the traditional telephony context, third party call control allows one entity (which we call the controller) to set up and manage a communications relationship between two or more other parties. Third party call control (referred to as 3pcc) is often used for operator services (where an operator creates a call that connects two participants together) and conferencing.
在传统的电话环境中，第三方呼叫控制允许一个实体（我们称之为控制器）在两个或多个其他方之间建立和管理通信关系。第三方呼叫控制（称为3pcc）通常用于运营商服务（运营商创建一个连接两个参与者的呼叫）和会议。
Similarly, many SIP services are possible through third party call control. These include the traditional ones on the PSTN, but also new ones such as click-to-dial. Click-to-dial allows a user to click on a web page when they wish to speak to a customer service representative. The web server then creates a call between the user and a customer service representative. The call can be between two phones, a phone and an IP host, or two IP hosts.
类似地，许多SIP服务都可以通过第三方呼叫控制实现。这些包括传统的PSTN，但也有新的，如点击拨号。单击拨号允许用户在希望与客户服务代表通话时单击网页。然后，web服务器在用户和客户服务代表之间创建一个呼叫。通话可以在两部电话之间进行，一部电话和一个IP主机，或者两个IP主机。
Third party call control is possible using only the mechanisms specified within RFC 3261 [1]. Indeed, many different call flows are possible, each of which will work with SIP compliant user agents. However, there are benefits and drawbacks to each of these flows. The usage of third party call control also becomes more complex when aspects of the call utilize SIP extensions or optional features of SIP. In particular, the usage of RFC 3312 [2] (used for coupling of signaling to resource reservation) with third party call control is non-trivial, and is discussed in Section 9. Similarly, the usage of early media (where session data is exchanged before the call is accepted) with third party call control is not trivial; both of them specify the way in which user agents generate and respond to SDP, and it is not clear how to do both at the same time. This is discussed further in Section 8.
第三方呼叫控制只能使用RFC 3261[1]中指定的机制。事实上，许多不同的呼叫流都是可能的，每个呼叫流都将与SIP兼容的用户代理一起工作。然而，每一种流程都有其优点和缺点。当呼叫的各个方面利用SIP扩展或SIP的可选功能时，第三方呼叫控制的使用也变得更加复杂。具体而言，RFC 3312[2]（用于将信令耦合到资源预留）与第三方呼叫控制的使用是非常重要的，并且在第9节中讨论。类似地，早期媒体（在接受呼叫之前交换会话数据）与第三方呼叫控制的使用并非微不足道；它们都指定了用户代理生成和响应SDP的方式，但不清楚如何同时执行这两种操作。这将在第8节中进一步讨论。
This document serves as a best current practice for implementing third party call control without usage of any extensions specifically designed for that purpose. Section 4 presents the known call flows that can be used to achieve third party call control, and provides guidelines on their usage. Section 9 discusses the interactions of RFC 3312 [2] with third party call control. Section 8 discusses the interactions of early media with third party call control. Section 10 provides example applications that make usage of the flows recommended here.
本文档是实现第三方呼叫控制的最佳实践，无需使用专门为此目的设计的任何扩展。第4节介绍了可用于实现第三方呼叫控制的已知呼叫流，并提供了使用指南。第9节讨论RFC 3312[2]与第三方呼叫控制的交互。第8节讨论早期媒体与第三方呼叫控制的交互。第10节提供了使用此处推荐的流的示例应用程序。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[3]中所述进行解释，并指出符合性实施的要求级别。
The following terms are used throughout this document:
本文件中使用了以下术语：
3pcc: Third Party Call Control, which refers to the general ability to manipulate calls between other parties.
3pcc：第三方呼叫控制，指操纵其他方之间呼叫的一般能力。
Controller: A controller is a SIP User Agent that wishes to create a session between two other user agents.
控制器：控制器是希望在其他两个用户代理之间创建会话的SIP用户代理。
The primary primitive operation of third party call control is the establishment of a session between participants A and B. Establishment of this session is orchestrated by a third party, referred to as the controller.
第三方呼叫控制的主要基本操作是在参与者a和B之间建立会话。该会话的建立由称为控制器的第三方协调。
This section documents three call flows that the controller can utilize in order to provide this primitive operation.
本节记录了控制器可用于提供此基本操作的三个调用流。
A Controller B
|(1) INVITE no SDP | |
|<------------------| |
|(2) 200 offer1 | |
|------------------>| |
| |(3) INVITE offer1 |
| |------------------>|
| |(4) 200 OK answer1 |
| |<------------------|
| |(5) ACK |
| |------------------>|
|(6) ACK answer1 | |
|<------------------| |
|(7) RTP | |
|.......................................|
A Controller B
|(1) INVITE no SDP | |
|<------------------| |
|(2) 200 offer1 | |
|------------------>| |
| |(3) INVITE offer1 |
| |------------------>|
| |(4) 200 OK answer1 |
| |<------------------|
| |(5) ACK |
| |------------------>|
|(6) ACK answer1 | |
|<------------------| |
|(7) RTP | |
|.......................................|
Figure 1
图1
The call flow for Flow I is shown in Figure 1. The controller first sends an INVITE A (1). This INVITE has no session description. A's phone rings, and A answers. This results in a 200 OK (2) that contains an offer [4]. The controller needs to send its answer in the ACK, as mandated by [1]. To obtain the answer, it sends the offer it got from A (offer1) in an INVITE to B (3). B's phone rings. When B answers, the 200 OK (4) contains the answer to this offer, answer1. The controller sends an ACK to B (5), and then passes answer1 to A in an ACK sent to it (6). Because the offer was generated by A, and the answer generated by B, the actual media session is between A and B. Therefore, media flows between them (7).
流I的调用流如图1所示。控制器首先发送一个INVITE A（1）。此邀请没有会话描述。A的电话响了，A接了电话。这将产生一个200 OK（2），其中包含报价[4]。控制器需要按照[1]的要求在ACK中发送其应答。为了获得答案，它将在邀请中从A（offer1）获得的报价发送给B（3）。B的电话响了。当B回答时，200 OK（4）包含此报价的答案answer1。控制器向B（5）发送ACK，然后在发送给它的ACK（6）中将应答器1传递给A。因为报价由A生成，答案由B生成，所以实际的媒体会话在A和B之间。因此，媒体在A和B之间流动（7）。
This flow is simple, requires no manipulation of the SDP by the controller, and works for any media types supported by both endpoints. However, it has a serious timeout problem. User B may not answer the call immediately. The result is that the controller cannot send the ACK to A right away. This causes A to retransmit the 200 OK response periodically. As specified in RFC 3261 Section 13.3.1.4, the 200 OK will be retransmitted for 64*T1 seconds. If an ACK does not arrive by then, the call is considered to have failed. This limits the applicability of this flow to scenarios where the controller knows that B will answer the INVITE immediately.
此流很简单，不需要控制器操纵SDP，并且适用于两个端点支持的任何媒体类型。但是，它有一个严重的超时问题。用户B可能不会立即接听电话。结果是控制器无法立即将ACK发送到服务器。这导致A周期性地重新传输200 OK响应。按照RFC 3261第13.3.1.4节的规定，200 OK将被重新传输64*T1秒。如果此时未收到ACK，则认为呼叫失败。这限制了此流程在控制器知道B将立即响应邀请的情况下的适用性。
A Controller B
|(1) INVITE bh sdp1 | |
|<------------------| |
|(2) 200 sdp2 | |
|------------------>| |
| |(3) INVITE sdp2 |
| |------------------>|
|(4) ACK | |
|<------------------| |
| |(5) 200 OK sdp3 |
| |<------------------|
| |(6) ACK |
| |------------------>|
|(7) INVITE sdp3 | |
|<------------------| |
|(8) 200 OK sdp2 | |
|------------------>| |
|(9) ACK | |
|<------------------| |
|(10) RTP | |
|.......................................|
A Controller B
|(1) INVITE bh sdp1 | |
|<------------------| |
|(2) 200 sdp2 | |
|------------------>| |
| |(3) INVITE sdp2 |
| |------------------>|
|(4) ACK | |
|<------------------| |
| |(5) 200 OK sdp3 |
| |<------------------|
| |(6) ACK |
| |------------------>|
|(7) INVITE sdp3 | |
|<------------------| |
|(8) 200 OK sdp2 | |
|------------------>| |
|(9) ACK | |
|<------------------| |
|(10) RTP | |
|.......................................|
Figure 2
图2
An alternative flow, Flow II, is shown in Figure 2. The controller first sends an INVITE to user A (1). This is a standard INVITE, containing an offer (sdp1) with a single audio media line, one codec, a random port number (but not zero), and a connection address of 0.0.0.0. This creates an initial media stream that is "black holed", since no media (or RTCP packets [8]) will flow from A. The INVITE causes A's phone to ring.
图2显示了另一种流程，流程II。控制器首先向用户A（1）发送邀请。这是一个标准的INVITE，包含一个带有单个音频媒体线路、一个编解码器、一个随机端口号（但不是零）和一个连接地址为0.0.0.0的要约（sdp1）。这会创建一个“黑洞”的初始媒体流，因为不会有媒体（或RTCP数据包[8]）从A流出。INVITE会导致A的电话铃响。
Note that the usage of 0.0.0.0, though recommended by RFC 3264, has numerous drawbacks. It is anticipated that a future specification will recommend usage of a domain within the .invalid DNS top level domain instead of the 0.0.0.0 IP address. As a result, implementors are encouraged to track such developments once they arise.
请注意，尽管RFC 3264建议使用0.0.0.0，但它有许多缺点。预计未来的规范将建议使用.invalid DNS顶级域中的域，而不是0.0.0.0 IP地址。因此，鼓励实施者在出现此类开发时跟踪它们。
When A answers (2), the 200 OK contains an answer, sdp2, with a valid address in the connection line. The controller sends an ACK (4). It then generates a second INVITE (3). This INVITE is addressed to user B, and it contains sdp2 as the offer to B. Note that the role of sdp2 has changed. In the 200 OK (message 2), it was an answer, but in the INVITE, it is an offer. Fortunately, all valid answers are valid
当A回答（2）时，200 OK包含一个回答sdp2，连接线路中有一个有效地址。控制器发送ACK（4）。然后，它生成第二个邀请（3）。此邀请发送给用户B，其中包含sdp2作为对B的邀请。请注意，sdp2的角色已更改。在200 OK（信息2）中，这是一个回答，但在邀请中，这是一个提议。幸运的是，所有有效的答案都是有效的
initial offers. This INVITE causes B's phone to ring. When it answers, it generates a 200 OK (5) with an answer, sdp3. The controller then generates an ACK (6). Next, it sends a re-INVITE to A (7) containing sdp3 as the offer. Once again, there has been a reversal of roles. sdp3 was an answer, and now it is an offer. Fortunately, an answer to an answer recast as an offer is, in turn, a valid offer. This re-INVITE generates a 200 OK (8) with sdp2, assuming that A doesn't decide to change any aspects of the session as a result of this re-INVITE. This 200 OK is ACKed (9), and then media can flow from A to B. Media from B to A could already start flowing once message 5 was sent.
初始报价。此邀请导致B的电话铃响。当它回答时，它会生成一个200 OK（5）的答案sdp3。然后，控制器生成ACK（6）。接下来，它向包含sdp3的（7）发送重新邀请作为要约。角色又一次发生了逆转。sdp3是一个答案，现在它是一个报价。幸运的是，一个答案的答案被改写为一个提议，反过来，就是一个有效的提议。此重新邀请使用sdp2生成一个200 OK（8），假设a不会因为此重新邀请而决定更改会话的任何方面。确认此200 OK（9），然后介质可以从A流向B。一旦发送消息5，从B流向A的介质可能已经开始流动。
This flow has the advantage that all final responses are immediately ACKed. It therefore does not suffer from the timeout and message inefficiency problems of flow 1. However, it too has troubles. First off, it requires that the controller know the media types to be used for the call (since it must generate a "blackhole" SDP, which requires media lines). Secondly, the first INVITE to A (1) contains media with a 0.0.0.0 connection address. The controller expects that the response contains a valid, non-zero connection address for A. However, experience has shown that many UAs respond to an offer of a 0.0.0.0 connection address with an answer containing a 0.0.0.0 connection address. The offer-answer specification [4] explicitly tells implementors not to do this, but at the time of publication of this document, many implementations still did. If A should respond with a 0.0.0.0 connection address in sdp2, the flow will not work.
此流程的优点是所有最终响应都会立即确认。因此，它不会遇到流1的超时和消息低效问题。然而，它也有麻烦。首先，它要求控制器知道用于呼叫的媒体类型（因为它必须生成“黑洞”SDP，这需要媒体线路）。其次，对（1）的第一个邀请包含连接地址为0.0.0.0的媒体。控制器期望响应包含a的有效、非零连接地址。然而，经验表明，许多UAs对0.0.0.0连接地址的报价作出响应，其答案包含0.0.0.0连接地址。offer-answer规范[4]明确告诉实现者不要这样做，但在本文档发布时，许多实现仍然这样做。如果sdp2中的连接地址为0.0.0.0，则流将不起作用。
However, the most serious flaw in this flow is the assumption that the 200 OK to the re-INVITE (message 8) contains the same SDP as in message 2. This may not be the case. If it is not, the controller needs to re-INVITE B with that SDP (say, sdp4), which may result in getting a different SDP, sdp5, in the 200 OK from B. Then, the controller needs to re-INVITE A again, and so on. The result is an infinite loop of re-INVITEs. It is possible to break this cycle by having very smart UAs which can return the same SDP whenever possible, or really smart controllers that can analyze the SDP to determine if a re-INVITE is really needed. However, we wish to keep this mechanism simple, and avoid SDP awareness in the controller. As a result, this flow is not really workable. It is therefore NOT RECOMMENDED.
但是，此流中最严重的缺陷是假设重新邀请的200 OK（消息8）包含与消息2中相同的SDP。情况可能并非如此。如果不是，则控制器需要使用该SDP（例如，sdp4）重新邀请B，这可能会导致从B获得200 OK中的不同SDP sdp5。然后，控制器需要再次重新邀请a，依此类推。结果是无限循环的重新邀请。通过拥有非常智能的UAs（只要有可能，它可以返回相同的SDP）或真正智能的控制器（它可以分析SDP以确定是否真的需要重新邀请），可以打破这种循环。然而，我们希望保持这种机制的简单，并避免控制器中的SDP感知。因此，这个流程实际上并不可行。因此，不建议这样做。
A Controller B
|(1) INVITE no SDP | |
|<---------------------| |
|(2) 200 offer1 | |
|--------------------->| |
|(3) ACK answer1 (bh) | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| |(5) 200 OK offer2 |
| |<---------------------|
|(6) INVITE offer2' | |
|<---------------------| |
|(7) 200 answer2' | |
|--------------------->| |
| |(8) ACK answer2 |
| |--------------------->|
|(9) ACK | |
|<---------------------| |
|(10) RTP | |
|.............................................|
A Controller B
|(1) INVITE no SDP | |
|<---------------------| |
|(2) 200 offer1 | |
|--------------------->| |
|(3) ACK answer1 (bh) | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| |(5) 200 OK offer2 |
| |<---------------------|
|(6) INVITE offer2' | |
|<---------------------| |
|(7) 200 answer2' | |
|--------------------->| |
| |(8) ACK answer2 |
| |--------------------->|
|(9) ACK | |
|<---------------------| |
|(10) RTP | |
|.............................................|
Figure 3
图3
A third flow, Flow III, is shown in Figure 3.
第三个流程，流程III，如图3所示。
First, the controller sends an INVITE (1) to user A without any SDP (which is good, since it means that the controller doesn't need to assume anything about the media composition of the session). A's phone rings. When A answers, a 200 OK is generated (2) containing its offer, offer1. The controller generates an immediate ACK containing an answer (3). This answer is a "black hole" SDP, with its connection address equal to 0.0.0.0.
首先，控制器向没有任何SDP的用户A发送INVITE（1）（这很好，因为这意味着控制器不需要假设会话的媒体组成）。A的电话响了。当A回答时，生成一个200 OK（2），其中包含其报价offer1。控制器生成包含应答（3）的即时确认。这个答案是一个“黑洞”SDP，其连接地址等于0.0.0.0。
The controller then sends an INVITE to B without SDP (4). This causes B's phone to ring. When they answer, a 200 OK is sent, containing their offer, offer2 (5). This SDP is used to create a re-INVITE back to A (6). That re-INVITE is based on offer2, but may need to be reorganized to match up media lines, or to trim media lines. For example, if offer1 contained an audio and a video line, in that order, but offer2 contained just an audio line, the controller would need to add a video line to the offer (setting its port to zero) to create offer2'. Since this is a re-INVITE, it should complete quickly in the general case. That's good, since user B is retransmitting their 200 OK, waiting for an ACK. The SDP in the
然后，控制器向B发送一个不带SDP的INVITE（4）。这会导致B的电话响。当他们回答时，发送一个200 OK，包含他们的报价，offer2（5）。此SDP用于创建对a（6）的重新邀请。该重新邀请基于offer2，但可能需要重新组织以匹配媒体线路或修剪媒体线路。例如，如果offer1包含音频线和视频线，但offer2仅包含音频线，则控制器需要将视频线添加到offer（将其端口设置为零）以创建offer2’。由于这是一个重新邀请，一般情况下应该很快完成。这很好，因为用户B正在重新传输其200 OK，等待ACK。美国的SDP
200 OK (7) from A, answer2', may also need to be reorganized or trimmed before sending it an the ACK to B (8) as answer2. Finally, an ACK is sent to A (9), and then media can flow.
在将应答发送给B（8）作为应答2之前，A的200 OK（7）应答2'可能还需要重新组织或修剪。最后，ACK被发送到A（9），然后媒体可以流动。
This flow has many benefits. First, it will usually operate without any spurious retransmissions or timeouts (although this may still happen if a re-INVITE is not responded to quickly). Secondly, it does not require the controller to guess the media that will be used by the participants.
这种流动有很多好处。首先，它通常在没有任何虚假的重新传输或超时的情况下运行（尽管如果没有快速响应重新邀请，这种情况仍然可能发生）。其次，它不需要控制员猜测参与者将使用的媒体。
There are some drawbacks. The controller does need to perform SDP manipulations. Specifically, it must take some SDP, and generate another SDP which has the same media composition, but has connection addresses equal to 0.0.0.0. This is needed for message 3. Secondly, it may need to reorder and trim SDP X, so that its media lines match up with those in some other SDP, Y. Thirdly, the offer from B (offer2) may have no codecs or media streams in common with the offer from A (offer 1). The controller will need to detect this condition, and terminate the call. Finally, the flow is far more complicated than the simple and elegant Flow I (Figure 1).
有一些缺点。控制器确实需要执行SDP操作。具体来说，它必须使用一些SDP，并生成另一个SDP，该SDP具有相同的媒体组成，但连接地址等于0.0.0.0。这是信息3所需要的。其次，它可能需要重新排序和修剪SDP X，以便其媒体线与其他SDP中的媒体线相匹配，即Y。第三，来自B（报价2）的报价可能没有与来自A（报价1）的报价相同的编解码器或媒体流。控制器需要检测这种情况，并终止呼叫。最后，这个流程要比简单而优雅的流程I（图1）复杂得多。
A Controller B
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
|(2) 200 answer1 | |
|no media | |
|--------------------->| |
|(3) ACK | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| |(5) 200 OK offer2 |
| |<---------------------|
|(6) INVITE offer2' | |
|<---------------------| |
|(7) 200 answer2' | |
|--------------------->| |
| |(8) ACK answer2 |
| |--------------------->|
|(9) ACK | |
|<---------------------| |
|(10) RTP | |
|.............................................|
A Controller B
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
|(2) 200 answer1 | |
|no media | |
|--------------------->| |
|(3) ACK | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| |(5) 200 OK offer2 |
| |<---------------------|
|(6) INVITE offer2' | |
|<---------------------| |
|(7) 200 answer2' | |
|--------------------->| |
| |(8) ACK answer2 |
| |--------------------->|
|(9) ACK | |
|<---------------------| |
|(10) RTP | |
|.............................................|
Figure 4
图4
Flow IV shows a variation on Flow III that reduces its complexity. The actual message flow is identical, but the SDP placement and construction differs. The initial INVITE (1) contains SDP with no media at all, meaning that there are no m lines. This is valid, and implies that the media makeup of the session will be established later through a re-INVITE [4]. Once the INVITE is received, user A is alerted. When they answer the call, the 200 OK (2) has an answer with no media either. This is acknowledged by the controller (3). The flow from this point onwards is identical to Flow III. However, the manipulations required to convert offer2 to offer2', and answer2' to answer2, are much simpler. Indeed, no media manipulations are needed at all. The only change that is needed is to modify the origin lines, so that the origin line in offer2' is valid based on the value in offer1 (validity requires that the version increments by one, and that the other parameters remain unchanged).
流程IV显示了流程III的一个变体，该变体降低了其复杂性。实际的消息流是相同的，但SDP的位置和构造不同。初始INVITE（1）包含完全没有媒体的SDP，这意味着没有m行。这是有效的，并意味着会议的媒体组成将在稍后通过重新邀请确定[4]。收到邀请后，将向用户A发出警报。当他们接听电话时，200 OK（2）也有一个没有媒体的应答。这由控制器（3）确认。从这一点开始的流程与流程III相同。但是，将offer2转换为offer2'，并将answer2'转换为answer2'所需的操作要简单得多。事实上，根本不需要操纵媒体。唯一需要的更改是修改原点，以便offer2'中的原点根据offer1中的值有效（有效性要求版本增加1，其他参数保持不变）。
There are some limitations associated with this flow. First, user A will be alerted without any media having been established yet. This means that user A will not be able to reject or accept the call based on its media composition. Secondly, both A and B will end up answering the call (i.e., generating a 200 OK) before it is known whether there is compatible media. If there is no media in common, the call can be terminated later with a BYE. However, the users will have already been alerted, resulting in user annoyance and possibly resulting in billing events.
此流程有一些限制。首先，将在尚未建立任何媒体的情况下向用户A发出警报。这意味着用户A将无法根据其媒体组成拒绝或接受呼叫。第二，在知道是否存在兼容媒体之前，A和B都将应答呼叫（即，生成200 OK）。如果没有共用介质，则稍后可以通过BYE终止呼叫。然而，用户将已经被提醒，这将导致用户烦恼，并可能导致计费事件。
Flow I (Figure 1) represents the simplest and the most efficient flow. This flow SHOULD be used by a controller if it knows with certainty that user B is actually an automata that will answer the call immediately. This is the case for devices such as media servers, conferencing servers, and messaging servers, for example. Since we expect a great deal of third party call control to be to automata, special casing in this scenario is reasonable.
流I（图1）表示最简单和最有效的流。如果控制器确信用户B实际上是一个自动机，它将立即应答呼叫，那么该流应该由控制器使用。例如，媒体服务器、会议服务器和消息服务器等设备就是如此。因为我们期望大量的第三方呼叫控制会自动进行，所以在这个场景中使用特殊的大小写是合理的。
For calls to unknown entities, or to entities known to represent people, it is RECOMMENDED that Flow IV (Figure 4) be used for third party call control. Flow III MAY be used instead, but it provides no additional benefits over Flow IV. However, Flow II SHOULD NOT be used, because of the potential for infinite ping-ponging of re-INVITEs.
对于对未知实体或已知代表人员的实体的调用，建议将流IV（图4）用于第三方调用控制。可以改用流III，但与流IV相比，它没有提供额外的好处。但是，不应使用流II，因为可能会出现无限的重新邀请乒乓球。
Several of these flows use a "black hole" connection address of 0.0.0.0. This is an IPv4 address with the property that packets sent to it will never leave the host which sent them; they are just
其中一些流使用0.0.0.0的“黑洞”连接地址。这是一个IPv4地址，其属性是发送到该地址的数据包永远不会离开发送它们的主机；他们只是
discarded. Those flows are therefore specific to IPv4. For other network or address types, an address with an equivalent property SHOULD be used.
丢弃的。因此，这些流特定于IPv4。对于其他网络或地址类型，应使用具有等效属性的地址。
In most cases, including the recommended flows, user A will hear silence while the call to B completes. This may not always be ideal. It can be remedied by connecting the caller to a music-on-hold source while the call to B occurs.
在大多数情况下，包括推荐的流，用户A将在对B的调用完成时听到静默。这可能并不总是理想的。当呼叫B时，可以通过将呼叫方连接到音乐保留源来修复此问题。
There are numerous error cases which merit discussion.
有许多错误案例值得讨论。
With all of the call flows in Section 4, one call is established to A, and then the controller attempts to establish a call to B. However, this call attempt may fail, for any number of reasons. User B might be busy (resulting in a 486 response to the INVITE), there may not be any media in common, the request may time out, and so on. If the call attempt to B should fail, it is RECOMMENDED that the controller send a BYE to A. This BYE SHOULD include a Reason header [5] which carries the status code from the error response. This will inform A of the precise reason for the failure. The information is important from a user interface perspective. For example, if A was calling from a black phone, and B generated a 486, the BYE will contain a Reason code of 486, and this could be used to generate a local busy signal so that A knows that B is busy.
在第4节中的所有呼叫流中，一个呼叫建立到A，然后控制器尝试建立到B的呼叫。但是，由于多种原因，此呼叫尝试可能失败。用户B可能很忙（导致对邀请的486响应），可能没有任何公共媒体，请求可能超时，等等。如果对B的呼叫尝试失败，建议控制器向a发送BYE。该BYE应包括一个原因标头[5]，其中包含错误响应中的状态代码。这将通知A故障的确切原因。从用户界面的角度来看，这些信息很重要。例如，如果A从黑色电话呼叫，B生成486，BYE将包含原因码486，这可用于生成本地忙信号，以便A知道B正忙。
A Controller B
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
|(2) 200 answer1 | |
|no media | |
|--------------------->| |
|(3) ACK | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| |(5) 180 |
| |<---------------------|
|(6) INVITE offer2 | |
|--------------------->| |
|(7) 491 | |
|<---------------------| |
|(8) ACK | |
|--------------------->| |
A Controller B
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
|(2) 200 answer1 | |
|no media | |
|--------------------->| |
|(3) ACK | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| |(5) 180 |
| |<---------------------|
|(6) INVITE offer2 | |
|--------------------->| |
|(7) 491 | |
|<---------------------| |
|(8) ACK | |
|--------------------->| |
Figure 5
图5
Another error condition worth discussion is shown in Figure 5. After the controller establishes the dialog with A (messages 1-3) it attempts to contact B (message 4). Contacting B may take some time. During that interval, A could possibly attempt a re-INVITE, providing an updated offer. However, the controller cannot pass this offer on to B, since it has an INVITE transaction pending with it. As a result, the controller needs to reject the request. It is RECOMMENDED that a 491 response be used. The situation here is similar to the glare condition described in [1], and thus the same error handling is sensible. However, A is likely to retry its request (as a result of the 491), and this may occur before the exchange with B is completed. In that case, the controller would respond with another 491.
另一个值得讨论的错误条件如图5所示。控制器与A（消息1-3）建立对话后，尝试联系B（消息4）。联系B可能需要一些时间。在这段时间内，A可能会尝试重新邀请，提供更新的报价。但是，控制器无法将此提供传递给B，因为它有一个INVITE事务挂起。因此，控制器需要拒绝该请求。建议使用491响应。这里的情况类似于[1]中描述的眩光条件，因此相同的错误处理是合理的。但是，A可能会重试其请求（由于491），这可能发生在与B的交换完成之前。在这种情况下，控制器将以另一个491响应。
Once the calls are established, both participants believe they are in a single point-to-point call. However, they are exchanging media directly with each other, rather than with the controller. The controller is involved in two dialogs, yet sees no media.
一旦建立呼叫，两个参与者都认为他们是在一个点对点呼叫中。但是，它们直接彼此交换介质，而不是与控制器交换介质。控制器包含两个对话框，但看不到媒体。
Since the controller is still a central point for signaling, it now has complete control over the call. If it receives a BYE from one of the participants, it can create a new BYE and hang up with the other participant. This is shown in Figure 6.
由于控制器仍然是信令的中心点，它现在可以完全控制呼叫。如果它从一个参与者那里收到一个再见，它可以创建一个新的再见并与另一个参与者挂断。如图6所示。
A Controller B
|(1) BYE | |
|------------------>| |
|(2) 200 OK | |
|<------------------| |
| |(3) BYE |
| |------------------>|
| |(4) 200 OK |
| |<------------------|
A Controller B
|(1) BYE | |
|------------------>| |
|(2) 200 OK | |
|<------------------| |
| |(3) BYE |
| |------------------>|
| |(4) 200 OK |
| |<------------------|
Figure 6
图6
Similarly, if it receives a re-INVITE from one of the participants, it can forward it to the other participant. Depending on which flow was used, this may require some manipulation on the SDP before passing it on.
类似地，如果它收到来自其中一个参与者的重新邀请，它可以将其转发给另一个参与者。根据所使用的流，这可能需要在传递SDP之前对其进行一些操作。
However, the controller need not "proxy" the SIP messages received from one of the parties. Since it is a Back-to-Back User Agent (B2BUA), it can invoke any signaling mechanism on each dialog, as it sees fit. For example, if the controller receives a BYE from A, it can generate a new INVITE to a third party, C, and connect B to that
然而，控制器不需要“代理”从其中一方接收的SIP消息。因为它是一个背对背的用户代理（B2BUA），所以它可以调用每个对话框上的任何信号机制。例如，如果控制器从a收到BYE，它可以向第三方C生成一个新的邀请，并将B连接到该邀请
participant instead. A call flow for this is shown in Figure 7, assuming the case where C represents an end user, not an automata. Note that it is just Flow IV.
而不是参与者。图7显示了这方面的调用流，假设C代表最终用户，而不是自动机。注意，它只是流IV。
A Controller B C
|(1) BYE | | |
|--------------->| | |
|(2) 200 OK | | |
|<---------------| | |
| |(3) INV no media| |
| |-------------------------------->|
| |(4) 200 no media| |
| |<--------------------------------|
| |(5) ACK | |
| |-------------------------------->|
| |(6) INV no SDP | |
| |--------------->| |
| |(7) 200 offer3 | |
| |<---------------| |
| |(8) INV offer3' | |
| |-------------------------------->|
| |(9) 200 answer3'| |
| |<--------------------------------|
| |(10) ACK | |
| |-------------------------------->|
| |(11) ACK answer3| |
| |--------------->| |
| | |(12) RTP |
| | |................|
A Controller B C
|(1) BYE | | |
|--------------->| | |
|(2) 200 OK | | |
|<---------------| | |
| |(3) INV no media| |
| |-------------------------------->|
| |(4) 200 no media| |
| |<--------------------------------|
| |(5) ACK | |
| |-------------------------------->|
| |(6) INV no SDP | |
| |--------------->| |
| |(7) 200 offer3 | |
| |<---------------| |
| |(8) INV offer3' | |
| |-------------------------------->|
| |(9) 200 answer3'| |
| |<--------------------------------|
| |(10) ACK | |
| |-------------------------------->|
| |(11) ACK answer3| |
| |--------------->| |
| | |(12) RTP |
| | |................|
Figure 7
图7
From here, new parties can be added, removed, transferred, and so on, as the controller sees fit. In many cases, the controller will be required to modify the SDP exchanged between the participants in order to affect these changes. In particular, the version number in the SDP will need to be changed by the controller in certain cases. If the controller should issue an SDP offer on its own (for example, to place a call on hold), it will need to increment the version number in the SDP offer. The other participant in the call will not know that the controller has done this, and any subsequent offer it generates will have the wrong version number as far as its peer is concerned. As a result, the controller will be required to modify the version number in SDP messages to match what the recipient is expecting.
从这里，可以根据控制器的需要添加、删除、转移新的参与方，等等。在许多情况下，控制器需要修改参与者之间交换的SDP，以影响这些更改。特别是，在某些情况下，控制器需要更改SDP中的版本号。如果控制器应自行发出SDP报价（例如，将呼叫置于等待状态），则需要增加SDP报价中的版本号。呼叫中的另一个参与者将不知道控制器已经这样做了，并且就其对等方而言，它生成的任何后续报价将具有错误的版本号。因此，控制器需要修改SDP消息中的版本号，以匹配收件人的期望。
It is important to point out that the call need not have been established by the controller in order for the processing of this section to be used. Rather, the controller could have acted as a B2BUA during a call established by A towards B (or vice versa).
重要的是要指出，为了使用本节的处理，控制器无需建立呼叫。相反，控制器可以在a向B建立的呼叫期间充当B2BUA（反之亦然）。
Early media represents the condition where the session is established (as a result of the completion of an offer/answer exchange), yet the call itself has not been accepted. This is usually used to convey tones or announcements regarding progress of the call. Handling of early media in a third party call is straightforward.
早期媒体表示会话已建立（由于完成要约/应答交换），但呼叫本身尚未被接受的情况。这通常用于传达有关通话进度的音调或通知。在第三方通话中处理早期媒体非常简单。
A Controller B
| | |
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
| | |
|<ring> | |
| | |
|<answer> | |
| | |
|(2) 200 answer1 | |
|no media | |
|--------------------->| |
|(3) ACK | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| | |<ring>
| |(5) 183 offer2 |
| |<---------------------|
|(6) INVITE offer2' | |
|<---------------------| |
|(7) 200 answer2' | |
|--------------------->| |
|(8) ACK | |
|<---------------------| |
| |(9) PRACK answer2 |
| |--------------------->|
| |(10) 200 PRACK |
| |<---------------------|
|(11) RTP | |
|.............................................|
| | |<answer>
| |(12) 200 OK |
| |<---------------------|
| |(13) ACK |
| |--------------------->|
A Controller B
| | |
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
| | |
|<ring> | |
| | |
|<answer> | |
| | |
|(2) 200 answer1 | |
|no media | |
|--------------------->| |
|(3) ACK | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| | |<ring>
| |(5) 183 offer2 |
| |<---------------------|
|(6) INVITE offer2' | |
|<---------------------| |
|(7) 200 answer2' | |
|--------------------->| |
|(8) ACK | |
|<---------------------| |
| |(9) PRACK answer2 |
| |--------------------->|
| |(10) 200 PRACK |
| |<---------------------|
|(11) RTP | |
|.............................................|
| | |<answer>
| |(12) 200 OK |
| |<---------------------|
| |(13) ACK |
| |--------------------->|
Figure 8
图8
Figure 8 shows the case where user B generates early media before answering the call. The flow is almost identical to Flow IV from Figure 4. The only difference is that user B generates a reliable provisional response (5) [6] instead of a final response, and answer2 is carried in a PRACK (9) instead of an ACK. When party B finally does accept the call (12), there is no change in the session state, and therefore, no signaling needs to be done with user A. The controller simply ACKs the 200 OK (13) to confirm the dialog.
图8显示了用户B在应答呼叫之前生成早期媒体的情况。该流程与图4中的流程IV几乎相同。唯一的区别是，用户B生成可靠的临时响应（5）[6]而不是最终响应，并且应答2以PRACK（9）而不是ACK进行。当乙方最终接受呼叫（12）时，会话状态没有变化，因此无需与用户A进行信令。控制器只需确认200 OK（13）即可确认对话。
A Controller B
| | |
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
| | |
|ring | |
| | |
|(2) 183 answer1 | |
|no media | |
|--------------------->| |
|(3) PRACK | |
|<---------------------| |
|(4) 200 PRACK | |
|--------------------->| |
| |(5) INVITE no SDP |
| |--------------------->|
| | |ring
| | |
| | |answer
| | |
| |(6) 200 OK offer2 |
| |<---------------------|
|(7) UPDATE offer2' | |
|<---------------------| |
| | |
|(8) 200 answer2' | |
|--------------------->| |
| |(9) ACK answer2 |
| |--------------------->|
|(10) RTP | |
|.............................................|
| | |
|answer | |
| | |
|(11) 200 OK | |
|--------------------->| |
|(12) ACK | |
|<---------------------| |
A Controller B
| | |
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
| | |
|ring | |
| | |
|(2) 183 answer1 | |
|no media | |
|--------------------->| |
|(3) PRACK | |
|<---------------------| |
|(4) 200 PRACK | |
|--------------------->| |
| |(5) INVITE no SDP |
| |--------------------->|
| | |ring
| | |
| | |answer
| | |
| |(6) 200 OK offer2 |
| |<---------------------|
|(7) UPDATE offer2' | |
|<---------------------| |
| | |
|(8) 200 answer2' | |
|--------------------->| |
| |(9) ACK answer2 |
| |--------------------->|
|(10) RTP | |
|.............................................|
| | |
|answer | |
| | |
|(11) 200 OK | |
|--------------------->| |
|(12) ACK | |
|<---------------------| |
Figure 9
图9
The case where user A generates early media is more complicated, and is shown in Figure 9. The flow is based on Flow IV. The controller sends an INVITE to user A (1), with an offer containing no media streams. User A generates a reliable provisional response (2) containing an answer with no media streams. The controller PRACKs this provisional response (3). Now, the controller sends an INVITE
用户A生成早期媒体的情况更复杂，如图9所示。该流基于流IV。控制器向用户A（1）发送邀请，邀请中不包含媒体流。用户A生成可靠的临时响应（2），该响应包含没有媒体流的应答。控制员演练这个临时响应（3）。现在，控制器发送一个邀请
without SDP to user B (5). User B's phone rings, and they answer, resulting in a 200 OK (6) with an offer, offer2. The controller now needs to update the session parameters with user A. However, since the call has not been answered, it cannot use a re-INVITE. Rather, it uses a SIP UPDATE request (7) [7], passing the offer (after modifying it to get the origin field correct). User A generates its answer in the 200 OK to the UPDATE (8). This answer is passed to user B in the ACK (9). When user A finally answers (11), there is no change in session state, so the controller simply ACKs the 200 OK (12).
不向用户B（5）发送SDP。用户B的电话铃响了，他们接了电话，结果是200 OK（6）加上一个offer，offer2。控制器现在需要使用用户A更新会话参数。但是，由于呼叫尚未应答，因此无法使用重新邀请。相反，它使用SIP更新请求（7）[7]，传递报价（在修改它以获得正确的来源字段之后）。用户A在更新的200 OK中生成其答案（8）。该答案在ACK（9）中传递给用户B。当用户A最终回答（11）时，会话状态没有变化，因此控制器只确认200 OK（12）。
Note that it is likely that there will be clipping of media in this call flow. User A is likely a PSTN gateway, and has generated a provisional response because of early media from the PSTN side. The PSTN will deliver this media even though the gateway does not have anywhere to send it, since the initial offer from the controller had no media streams. When user B answers, media can begin to flow. However, any media sent to the gateway from the PSTN up to that point will be lost.
请注意，此调用流中可能会有媒体剪辑。用户A可能是PSTN网关，并且由于来自PSTN侧的早期媒体而生成了临时响应。PSTN将提供此媒体，即使网关没有任何地方可以发送，因为控制器的初始报价没有媒体流。当用户B回答时，媒体可以开始流动。但是，从PSTN发送到网关的任何媒体都将丢失。
A SIP extension has been specified that allows for the coupling of signaling and resource reservation [2]. This specification relies on exchanges of session descriptions before completion of the call setup. These flows are initiated when certain SDP parameters are passed in the initial INVITE. As a result, the interaction of this mechanism with third party call control is not obvious, and worth detailing.
已指定允许信令和资源预留耦合的SIP扩展[2]。此规范依赖于在完成呼叫设置之前会话描述的交换。这些流在初始INVITE中传递某些SDP参数时启动。因此，该机制与第三方呼叫控制的交互作用并不明显，值得详细说明。
In one usage scenario, the controller wishes to make use of preconditions in order to avoid the call failure scenarios documented in Section 4.4. Specifically, the controller can use preconditions in order to guarantee that neither party is alerted unless there is a common set of media and codecs. It can also provide both parties with information on the media composition of the call before they decide to accept it.
在一种使用场景中，控制器希望利用先决条件，以避免第4.4节中记录的呼叫失败场景。具体来说，控制器可以使用先决条件，以确保任何一方都不会收到警报，除非存在一组通用的媒体和编解码器。在双方决定接受电话之前，它还可以向双方提供有关电话媒体组成的信息。
User A Controller Customer Service
(User B)
| | |
|(1) INVITE no SDP | |
|require precon | |
|<------------------| |
|(2) 183 offer1 | |
|optional precon | |
|------------------>| |
| | |
| |(3) INVITE offer1 |
| |------------------>|
| | |
| | |
| | |<answer>
| |(4) 200 OK answer1 |
| |no precon |
| |<------------------|
| |(5) ACK |
| |------------------>|
|(6) PRACK answer1 | |
|<------------------| |
|<ring> | |
| | |
|(7) 200 PRACK | |
|------------------>| |
|<answer> | |
| | |
|(8) 200 INVITE | |
|------------------>| |
|(9) ACK | |
|<------------------| |
User A Controller Customer Service
(User B)
| | |
|(1) INVITE no SDP | |
|require precon | |
|<------------------| |
|(2) 183 offer1 | |
|optional precon | |
|------------------>| |
| | |
| |(3) INVITE offer1 |
| |------------------>|
| | |
| | |
| | |<answer>
| |(4) 200 OK answer1 |
| |no precon |
| |<------------------|
| |(5) ACK |
| |------------------>|
|(6) PRACK answer1 | |
|<------------------| |
|<ring> | |
| | |
|(7) 200 PRACK | |
|------------------>| |
|<answer> | |
| | |
|(8) 200 INVITE | |
|------------------>| |
|(9) ACK | |
|<------------------| |
Figure 10
图10
The flow for this scenario is shown in Figure 10. In this example, we assume that user B is an automata or agent of some sort which will answer the call immediately. Therefore, the flow is based on Flow I. The controller sends an INVITE to user A containing no SDP, but with a Require header indicating that preconditions are required. This specific scenario (an INVITE without an offer, but with a Require header indicating preconditions) is not described in [2]. It is RECOMMENDED that the UAS respond with an offer in a 1xx including the media streams it wishes to use for the call, and for each, list all preconditions it supports as optional. Of course, the user is not alerted at this time. The controller takes this offer and passes it to user B (3). User B does not support preconditions, or does, but
此场景的流程如图10所示。在本例中，我们假设用户B是某种自动机或代理，它将立即应答呼叫。因此，流基于流I。控制器向用户A发送一个邀请，该邀请不包含SDP，但带有一个Require头，指示需要先决条件。[2]中未描述此特定场景（没有报价的邀请，但带有指示先决条件的Require标头）。建议UAS在1xx中回复报价，包括其希望用于呼叫的媒体流，并将其支持的所有前提条件列为可选条件。当然，此时不会提醒用户。控制器接受此报价并将其传递给用户B（3）。用户B不支持先决条件，或者支持，但是
is not interested in them. Therefore, when it answers the call, the 200 OK contains an answer without any preconditions listed (4). This answer is passed to user A in the PRACK (6). At this point, user A knows that there are no preconditions actually in use for the call, and therefore, it can alert the user. When the call is answered, user A sends a 200 OK to the controller (8) and the call is complete.
我对他们不感兴趣。因此，当它应答呼叫时，200 OK包含一个没有列出任何先决条件的应答（4）。这个答案在PRACK（6）中传递给用户A。此时，用户A知道调用中没有实际使用的前提条件，因此，它可以提醒用户。当呼叫应答时，用户A向控制器（8）发送200 OK，呼叫完成。
In the event that the offer generated by user A was not acceptable to user B (because of non-overlapping codecs or media, for example), user B would immediately reject the INVITE (message 3). The controller would then CANCEL the request to user A. In this situation, neither user A nor user B would have been alerted, achieving the desired effect. It is interesting to note that this property is achieved using preconditions even though it doesn't matter what specific types of preconditions are supported by user A.
如果用户A生成的报价不被用户B接受（例如，由于编解码器或媒体不重叠），用户B将立即拒绝邀请（消息3）。然后，控制器将取消对用户A的请求。在这种情况下，用户A和用户B都不会收到警报，从而达到预期效果。值得注意的是，这个属性是使用前提条件实现的，即使用户A支持什么类型的前提条件并不重要。
It is also entirely possible that user B does actually desire preconditions. In that case, it might generate a 1xx of its own with an answer containing preconditions. That answer would still be passed to user A, and both parties would proceed with whatever measures are necessary to meet the preconditions. Neither user would be alerted until the preconditions were met.
也完全有可能用户B确实需要先决条件。在这种情况下，它可能会生成自己的1xx，其答案包含前提条件。该答案仍将传递给用户A，双方将采取任何必要措施来满足前提条件。在满足前提条件之前，不会向任何用户发出警报。
In Section 9.1, the controller requested the use of preconditions to achieve a specific goal. It is also possible that the controller doesn't care (or perhaps doesn't even know) about preconditions, but one of the participants in the call does care. A call flow for this case is shown in Figure 11.
在第9.1节中，控制员要求使用先决条件来实现特定目标。控制器也可能不关心（或者甚至不知道）前提条件，但通话中的一个参与者确实关心。这种情况下的调用流如图11所示。
A Controller B
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
|(2) 183 answer1 | |
|no media | |
|--------------------->| |
|(3) PRACK | |
|<---------------------| |
|(4) 200 OK | |
|--------------------->| |
| |(5) INVITE no SDP |
| |--------------------->|
| |(6) 183 offer2 |
| |des=sendrecv |
| |conf=recv |
| |cur=none |
A Controller B
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
|(2) 183 answer1 | |
|no media | |
|--------------------->| |
|(3) PRACK | |
|<---------------------| |
|(4) 200 OK | |
|--------------------->| |
| |(5) INVITE no SDP |
| |--------------------->|
| |(6) 183 offer2 |
| |des=sendrecv |
| |conf=recv |
| |cur=none |
| |<---------------------|
|(7) UPDATE offer2' | |
|des=sendrecv | |
|conf=recv | |
|cur=none | |
|<---------------------| |
|(8) 200 UPDATE | |
|answer2' | |
|des=sendrecv | |
|conf=recv | |
|cur=none | |
|--------------------->| |
| |(9) PRACK answer2 |
| |des=sendrecv |
| |conf=recv |
| |cur=none |
| |--------------------->|
| |(10) 200 PRACK |
| |<---------------------|
|(11) reservation | |
|-------------------------------------------->|
|(12) reservation | |
|<--------------------------------------------|
|(13) UPDATE offer3 | |
|des=sendrecv | |
|conf=recv | |
|cur=recv | |
|--------------------->| |
| |(14) UPDATE offer3' |
| |des=sendrecv |
| |conf=recv |
| |cur=recv |
| |--------------------->|
| |(15) 200 UPDATE |
| |answer3' |
| |des=sendrecv |
| |conf=recv |
| |cur=send |
| |<---------------------|
|(16) 200 UPDATE | |
|answer3 | |
|des=sendrecv | |
|conf=recv | |
|cur=send | |
|<---------------------| |
| | |<ring>
| |(17) UPDATE offer4 |
| |des=sendrecv |
| |<---------------------|
|(7) UPDATE offer2' | |
|des=sendrecv | |
|conf=recv | |
|cur=none | |
|<---------------------| |
|(8) 200 UPDATE | |
|answer2' | |
|des=sendrecv | |
|conf=recv | |
|cur=none | |
|--------------------->| |
| |(9) PRACK answer2 |
| |des=sendrecv |
| |conf=recv |
| |cur=none |
| |--------------------->|
| |(10) 200 PRACK |
| |<---------------------|
|(11) reservation | |
|-------------------------------------------->|
|(12) reservation | |
|<--------------------------------------------|
|(13) UPDATE offer3 | |
|des=sendrecv | |
|conf=recv | |
|cur=recv | |
|--------------------->| |
| |(14) UPDATE offer3' |
| |des=sendrecv |
| |conf=recv |
| |cur=recv |
| |--------------------->|
| |(15) 200 UPDATE |
| |answer3' |
| |des=sendrecv |
| |conf=recv |
| |cur=send |
| |<---------------------|
|(16) 200 UPDATE | |
|answer3 | |
|des=sendrecv | |
|conf=recv | |
|cur=send | |
|<---------------------| |
| | |<ring>
| |(17) UPDATE offer4 |
| |des=sendrecv |
| |conf=recv |
| |cur=sendrecv |
| |<---------------------|
|(18) UPDATE offer4' | |
|des=sendrecv | |
|conf=recv | |
|cur=sendrecv | |
|<---------------------| |
|<ring> | |
|(19) 200 UPDATE | |
|answer4' | |
|des=sendrecv | |
|conf=recv | |
|cur=sendrecv | |
|--------------------->| |
| |(20) 200 UPDATE |
| |answer4 |
| |des=sendrecv |
| |conf=recv |
| |cur=sendrecv |
| |--------------------->|
|(21) 180 INVITE | |
|--------------------->| |
| |(22) 180 INVITE |
| |<---------------------|
|<answer> | |
|(23) 200 INVITE | |
|--------------------->| |
|(24) ACK | |
|<---------------------| |
| | |<answer>
| |(25) 200 INVITE |
| |<---------------------|
| |(26) ACK |
| |--------------------->|
| |conf=recv |
| |cur=sendrecv |
| |<---------------------|
|(18) UPDATE offer4' | |
|des=sendrecv | |
|conf=recv | |
|cur=sendrecv | |
|<---------------------| |
|<ring> | |
|(19) 200 UPDATE | |
|answer4' | |
|des=sendrecv | |
|conf=recv | |
|cur=sendrecv | |
|--------------------->| |
| |(20) 200 UPDATE |
| |answer4 |
| |des=sendrecv |
| |conf=recv |
| |cur=sendrecv |
| |--------------------->|
|(21) 180 INVITE | |
|--------------------->| |
| |(22) 180 INVITE |
| |<---------------------|
|<answer> | |
|(23) 200 INVITE | |
|--------------------->| |
|(24) ACK | |
|<---------------------| |
| | |<answer>
| |(25) 200 INVITE |
| |<---------------------|
| |(26) ACK |
| |--------------------->|
Figure 11
图11
The controller follows Flow IV; it has no specific requirements for support of the preconditions specification [2]. Therefore, it sends an INVITE (1) with SDP that contains no media lines. User A is interested in supporting preconditions, and does not want to ring its phone until resources are reserved. Since there are no media streams in the INVITE, it can't reserve resources for media streams, and therefore it can't ring the phone until they are conveyed in a subsequent offer and then reserved. Therefore, it generates a 183 with the answer, and doesn't alert the user (2). The controller PRACKs this (3) and A responds to the PRACK (4).
控制器遵循流程IV；它没有支持先决条件规范[2]的具体要求。因此，它使用不包含媒体行的SDP发送INVITE（1）。用户A对支持先决条件感兴趣，在资源被保留之前不想打电话。由于邀请中没有媒体流，它无法为媒体流保留资源，因此在随后的邀请中传达并保留资源之前，它无法拨打电话。因此，它会生成一个包含答案的183，并且不会提醒用户（2）。控制器发出此（3）指令，A响应该指令（4）。
At this point, the controller attempts to bring B into the call. It sends B an INVITE without SDP (5). B is interested in having preconditions for this call. Therefore, it generates its offer in a 183 that contains the appropriate SDP attributes (6). The controller passes this offer to A in an UPDATE request (7). The controller uses UPDATE because the call has not been answered yet, and therefore, it cannot use a re-INVITE. User A sees that its peer is capable of supporting preconditions. Since it desires preconditions for the call, it generates an answer in the 200 OK (8) to the UPDATE. This answer, in turn, is passed to B in the PRACK for the provisional response (9). Now, both sides perform resource reservation. User A succeeds first, and passes an updated session description in an UPDATE request (13). The controller simply passes this to A (after the manipulation of the origin field, as required in Flow IV) in an UPDATE (14), and the answer (15) is passed back to A (16). The same flow happens, but from B to A, when B's reservation succeeds (17-20). Since the preconditions have been met, both sides ring (21 and 22), and then both answer (23 and 25), completing the call.
此时，控制器尝试将B引入呼叫。它向B发送一个不带SDP的INVITE（5）。B有兴趣为这次电话提供先决条件。因此，它在包含适当SDP属性的183中生成其报价（6）。控制器在更新请求（7）中将此提议传递给。控制器使用更新，因为呼叫尚未应答，因此无法使用重新邀请。用户A看到其对等方能够支持前提条件。因为它需要呼叫的先决条件，所以它在更新的200 OK（8）中生成一个应答。这个答案依次在PRACK中传递给B，用于临时响应（9）。现在，双方都执行资源预留。用户A首先成功，并在更新请求（13）中传递更新的会话描述。控制器在更新（14）中简单地将其传递给A（在对原始字段进行操作之后，如流程IV中所要求的），并且答案（15）被传递回A（16）。当B的预订成功时（17-20），同样的流程也会发生，但是从B到A。由于先决条件已经满足，双方都会打电话（21和22），然后双方都会接听（23和25），完成通话。
What is important about this flow is that the controller doesn't know anything about preconditions. It merely passes the SDP back and forth as needed. The trick is the usage of UPDATE and PRACK to pass the SDP when needed. That determination is made entirely based on the offer/answer rules described in [6] and [7], and is independent of preconditions.
关于这个流，重要的是控制器不知道任何关于先决条件的事情。它只是根据需要来回传递SDP。诀窍是在需要时使用UPDATE和PRACK传递SDP。该决定完全基于[6]和[7]中所述的提供/回答规则，且不受先决条件的影响。
The first application of this capability we discuss is click-to-dial. In this service, a user is browsing the web page of an e-commerce site, and would like to speak to a customer service representative. The user clicks on a link, and a call is placed to a customer service representative. When the representative picks up, the phone on the user's desk rings. When the user pick up, the customer service representative is there, ready to talk to the user.
我们讨论的这个功能的第一个应用是点击拨号。在此服务中，用户正在浏览电子商务网站的网页，并希望与客户服务代表通话。用户点击一个链接，然后打电话给客户服务代表。当代表接电话时，用户桌上的电话响了。当用户接电话时，客户服务代表就在那里，随时准备与用户交谈。
Customer Service Controller User's Phone User's Browser
| |(1) HTTP POST | |
| |<--------------------------------------|
| |(2) HTTP 200 OK | |
| |-------------------------------------->|
|(3) INVITE offer1 | | |
|no media | | |
|<------------------| | |
|(4) 200 answer1 | | |
|no media | | |
|------------------>| | |
|(5) ACK | | |
|<------------------| | |
| |(6) INVITE no SDP | |
| |------------------>| |
| |(7) 200 OK offer2 | |
| |<------------------| |
|(8) INVITE offer2' | | |
|<------------------| | |
|(9) 200 answer2' | | |
|------------------>| | |
| |(10) ACK answer2 | |
| |------------------>| |
|(11) ACK | | |
|<------------------| | |
|(12) RTP | | |
|.......................................| |
Customer Service Controller User's Phone User's Browser
| |(1) HTTP POST | |
| |<--------------------------------------|
| |(2) HTTP 200 OK | |
| |-------------------------------------->|
|(3) INVITE offer1 | | |
|no media | | |
|<------------------| | |
|(4) 200 answer1 | | |
|no media | | |
|------------------>| | |
|(5) ACK | | |
|<------------------| | |
| |(6) INVITE no SDP | |
| |------------------>| |
| |(7) 200 OK offer2 | |
| |<------------------| |
|(8) INVITE offer2' | | |
|<------------------| | |
|(9) 200 answer2' | | |
|------------------>| | |
| |(10) ACK answer2 | |
| |------------------>| |
|(11) ACK | | |
|<------------------| | |
|(12) RTP | | |
|.......................................| |
Figure 12
图12
The call flow for this service is given in Figure 12. It is identical to that of Figure 4, with the exception that the service is triggered through an HTTP POST request when the user clicks on the link. Normally, this POST request would contain neither the number of the user or of the customer service representative. The user's number would typically be obtained by the web application from back-end databases, since the user would have presumably logged into the site, giving the server the needed context. The customer service number would typically be obtained through provisioning. Thus, the HTTP POST is actually providing the server nothing more than an indication that a call is desired.
此服务的调用流如图12所示。它与图4相同，只是当用户单击链接时，通过HTTP POST请求触发服务。通常，此POST请求既不包含用户的号码，也不包含客户服务代表的号码。用户的号码通常由web应用程序从后端数据库获取，因为用户可能已经登录到该站点，从而为服务器提供所需的上下文。客户服务号码通常通过供应获得。因此，HTTP POST实际上只为服务器提供了一个需要调用的指示。
We note that this service can be provided through other mechanisms, namely PINT [9]. However, there are numerous differences between the way in which the service is provided by PINT, and the way in which it is provided here:
我们注意到该服务可以通过其他机制提供，即PINT[9]。然而，PINT提供服务的方式与此处提供服务的方式存在许多差异：
o The PINT solution enables calls only between two PSTN endpoints. The solution described here allows calls between PSTN phones (through SIP enabled gateways) and native IP phones.
o PINT解决方案仅支持两个PSTN端点之间的呼叫。这里描述的解决方案允许PSTN电话（通过支持SIP的网关）和本机IP电话之间进行呼叫。
o When used for calls between two PSTN phones, the solution here may result in a portion of the call being routed over the Internet. In PINT, the call is always routed only over the PSTN. This may result in better quality calls with the PINT solution, depending on the codec in use and QoS capabilities of the network routing the Internet portion of the call.
o 当用于两部PSTN电话之间的呼叫时，此处的解决方案可能会导致部分呼叫通过Internet路由。在PINT中，呼叫始终仅通过PSTN路由。这可能会使用PINT解决方案产生更好的通话质量，这取决于正在使用的编解码器和网络路由呼叫的Internet部分的QoS能力。
o The PINT solution requires extensions to SIP (PINT is an extension to SIP), whereas the solution described here is done with baseline SIP.
o PINT解决方案需要对SIP进行扩展（PINT是SIP的扩展），而这里描述的解决方案是使用基线SIP完成的。
o The PINT solution allows the controller (acting as a PINT client) to "step out" once the call is established. The solution described here requires the controller to maintain call state for the entire duration of the call.
o PINT解决方案允许控制器（充当PINT客户端）在呼叫建立后“退出”。这里描述的解决方案要求控制器在整个呼叫期间保持呼叫状态。
The third party call control mechanism described here can also be used to enable mid-call announcements. Consider a service for pre-paid calling cards. Once the pre-paid call is established, the system needs to set a timer to fire when they run out of minutes. When this timer fires, we would like the user to hear an announcement which tells them to enter a credit card to continue. Once they enter the credit card info, more money is added to the pre-paid card, and the user is reconnected to the destination party.
此处描述的第三方呼叫控制机制也可用于启用通话中通知。考虑一个预付费电话卡服务。一旦建立了预付费呼叫，系统需要设置一个计时器，当它们在分钟内用完时触发。当这个计时器启动时，我们希望用户听到一个通知，告诉他们输入信用卡继续。一旦他们输入了信用卡信息，更多的钱就会添加到预付卡中，用户就会重新连接到目的地方。
We consider here the usage of third party call control just for playing the mid-call dialog to collect the credit card information.
在这里，我们考虑使用第三方呼叫控制来播放MID呼叫对话框来收集信用卡信息。
Pre-Paid User Controller Called Party Media Server
| |(1) INV SDP c=bh | |
| |------------------>| |
| |(2) 200 answer1 | |
| |<------------------| |
| |(3) ACK | |
| |------------------>| |
|(4) INV no SDP | | |
|<------------------| | |
|(5) 200 offer2 | | |
|------------------>| | |
| |(6) INV offer2 | |
| |-------------------------------------->|
| |(7) 200 answer2 | |
| |<--------------------------------------|
|(8) ACK answer2 | | |
|<------------------| | |
| |(9) ACK | |
| |-------------------------------------->|
|(10) RTP | | |
|...........................................................|
| |(11) BYE | |
| |-------------------------------------->|
| |(12) 200 OK | |
| |<--------------------------------------|
| |(13) INV no SDP | |
| |------------------>| |
| |(14) 200 offer3 | |
| |<------------------| |
|(15) INV offer3' | | |
|<------------------| | |
|(16) 200 answer3' | | |
|------------------>| | |
| |(17) ACK answer3' | |
| |------------------>| |
|(18) ACK | | |
|<------------------| | |
|(19) RTP | | |
|.......................................| |
Pre-Paid User Controller Called Party Media Server
| |(1) INV SDP c=bh | |
| |------------------>| |
| |(2) 200 answer1 | |
| |<------------------| |
| |(3) ACK | |
| |------------------>| |
|(4) INV no SDP | | |
|<------------------| | |
|(5) 200 offer2 | | |
|------------------>| | |
| |(6) INV offer2 | |
| |-------------------------------------->|
| |(7) 200 answer2 | |
| |<--------------------------------------|
|(8) ACK answer2 | | |
|<------------------| | |
| |(9) ACK | |
| |-------------------------------------->|
|(10) RTP | | |
|...........................................................|
| |(11) BYE | |
| |-------------------------------------->|
| |(12) 200 OK | |
| |<--------------------------------------|
| |(13) INV no SDP | |
| |------------------>| |
| |(14) 200 offer3 | |
| |<------------------| |
|(15) INV offer3' | | |
|<------------------| | |
|(16) 200 answer3' | | |
|------------------>| | |
| |(17) ACK answer3' | |
| |------------------>| |
|(18) ACK | | |
|<------------------| | |
|(19) RTP | | |
|.......................................| |
Figure 13
图13
We assume the call is set up so that the controller is in the call as a B2BUA. When the timer fires, we wish to connect the caller to a media server. The flow for this is shown in Figure 13. When the timer expires, the controller places the called party with a connection address of 0.0.0.0 (1). This effectively "disconnects" the called party. The controller then sends an INVITE without SDP to
我们假设呼叫已设置为控制器作为B2BUA在呼叫中。当计时器启动时，我们希望将调用者连接到媒体服务器。其流程如图13所示。当计时器过期时，控制器将被叫方的连接地址设置为0.0.0.0（1）。这有效地“断开”了被叫方。然后，控制器将不带SDP的INVITE发送到
the pre-paid caller (4). The offer returned from the caller (5) is used in an INVITE to the media server which will be collecting digits (6). This is an instantiation of Flow I. This flow can only be used here because the media server is an automata, and will answer the INVITE immediately. If the controller was connecting the pre-paid user with another end user, Flow III would need to be used. The media server returns an immediate 200 OK (7) with an answer, which is passed to the caller in an ACK (8). The result is that the media server and the pre-paid caller have their media streams connected.
预付费来电者（4）。从呼叫者（5）返回的要约用于邀请媒体服务器，媒体服务器将收集数字（6）。这是流I的一个实例。此流只能在此处使用，因为媒体服务器是一个自动机，将立即响应邀请。如果控制器将预付费用户与另一个终端用户连接，则需要使用Flow III。媒体服务器立即返回200 OK（7）和应答，并在ACK（8）中传递给调用者。结果是媒体服务器和预付费呼叫方连接了媒体流。
The media server plays an announcement, and prompts the user to enter a credit card number. After collecting the number, the card number is validated. The media server then passes the card number to the controller (using some means outside the scope of this specification), and then hangs up the call (11).
媒体服务器播放公告，并提示用户输入信用卡号。收集号码后，验证卡号。然后，媒体服务器将卡号传递给控制器（使用本规范范围之外的某些方法），然后挂断呼叫（11）。
After hanging up with the media server, the controller reconnects the user to the original called party. To do this, the controller sends an INVITE without SDP to the called party (13). The 200 OK (14) contains an offer, offer3. The controller modifies the SDP (as is done in Flow III), and passes the offer in an INVITE to the pre-paid user (15). The pre-paid user generates an answer in a 200 OK (16) which the controller passes to user B in the ACK (17). At this point, the caller and called party are reconnected.
与媒体服务器挂断后，控制器将用户重新连接到原始被叫方。为此，控制器向被叫方发送不带SDP的INVITE（13）。200 OK（14）包含一个offer，offer3。控制器修改SDP（如流程III中所做的），并将邀请中的要约传递给预付费用户（15）。预付费用户在200 OK（16）中生成应答，控制器在ACK（17）中将该应答传递给用户B。此时，呼叫者和被叫方将重新连接。
Most of the work involved in supporting third party call control is within the controller. A standard SIP UA should be controllable using the mechanisms described here. However, third party call control relies on a few features that might not be implemented. As such, we RECOMMEND that implementors of user agent servers support the following:
支持第三方呼叫控制所涉及的大部分工作都在控制器内。标准SIP UA应该可以使用这里描述的机制进行控制。但是，第三方呼叫控制依赖于一些可能无法实现的功能。因此，我们建议用户代理服务器的实现者支持以下内容：
o Offers and answers that contain a connection line with an address of 0.0.0.0.
o 包含地址为0.0.0.0的连接线的报价和应答。
o Re-INVITE requests that change the port to which media should be sent
o 重新邀请更改媒体发送端口的请求
o Re-INVITEs that change the connection address
o 重新邀请更改连接地址的用户
o Re-INVITEs that add a media stream
o 重新邀请添加媒体流的用户
o Re-INVITEs that remove a media stream (setting its port to zero)
o 删除媒体流的重新邀请（将其端口设置为零）
o Re-INVITEs that add a codec amongst the set in a media stream
o 在媒体流中的集合中添加编解码器的重新邀请
o SDP Connection address of zero
o 零的SDP连接地址
o Initial INVITE requests with a connection address of zero
o 连接地址为零的初始INVITE请求
o Initial INVITE requests with no SDP
o 没有SDP的初始INVITE请求
o Initial INVITE requests with SDP but no media lines
o 使用SDP但不使用媒体线路的初始邀请请求
o Re-INVITEs with no SDP
o 没有SDP的重新邀请
o The UPDATE method [7]
o 更新方法[7]
o Reliability of provisional responses [6]
o 临时响应的可靠性[6]
o Integration of resource management and SIP [2].
o 资源管理与SIP的集成[2]。
In most uses of SIP INVITE, whether or not a call is accepted is based on a decision made by a human when presented information about the call, such as the identity of the caller. In other cases, automata answer the calls, and whether or not they do so may depend on the particular application to which SIP is applied. For example, if a caller makes a SIP call to a voice portal service, the call may be rejected unless the caller has previously signed up (perhaps via a web site). In other cases, call handling policies are made based on automated scripts, such as those described by the Call Processing Language [11]. Frequently, those decisions are also made based on the identity of the caller.
在SIP INVITE的大多数使用中，呼叫是否被接受取决于当提供有关呼叫的信息（例如呼叫方的身份）时，人工做出的决定。在其他情况下，自动机应答呼叫，并且它们是否应答可能取决于应用SIP的特定应用程序。例如，如果呼叫者对语音门户服务进行SIP呼叫，则呼叫可能会被拒绝，除非呼叫者之前已注册（可能通过网站）。在其他情况下，呼叫处理策略是基于自动脚本制定的，如呼叫处理语言[11]所描述的脚本。通常，这些决定也是根据呼叫者的身份做出的。
These authorization mechanisms would be applied to normal first party calls and third party calls, as these two are indistinguishable. As a result, it is important for these authorization policies to continue to operate correctly for third party calls. Of course, third party calls introduce a new party - the one initiating the third party call. Do the authorization policies apply based on the identity of that third party, or do they apply based on the participants in the call? Ideally, the participants would be able to know the identities of both other parties, and have authorization policies be based on those, as appropriate. However, this is not possible using existing mechanisms. As a result, the next best thing is for the INVITE requests to contain the identity of the third party. Ultimately, this is the user who is requesting communication, and it makes sense for call authorization policies to be based on that identity.
这些授权机制将应用于正常的第一方呼叫和第三方呼叫，因为这两种呼叫无法区分。因此，对于第三方呼叫，这些授权策略必须继续正确运行。当然，第三方通话会引入一个新的通话方——发起第三方通话的那个。授权策略是基于该第三方的身份应用的，还是基于呼叫中的参与者应用的？理想情况下，参与者将能够了解其他双方的身份，并根据需要制定授权策略。然而，使用现有机制是不可能做到这一点的。因此，次好的方法是让INVITE请求包含第三方的身份。最终，这是请求通信的用户，因此基于该身份的呼叫授权策略是有意义的。
This requires, in turn, that the controller authenticate itself as that third party. This can be challenging, and the appropriate mechanism depends on the specific application scenario.
这反过来要求控制器将自己验证为第三方。这可能具有挑战性，适当的机制取决于特定的应用场景。
In one common scenario, the controller is acting on behalf of one of the participants in the call. A typical example is click-to-dial, where the controller and the customer service representative are run by the same administrative domain. Indeed, for the purposes of identification, the controller can legitimately claim to be the customer service representative. In this scenario, it would be appropriate for the INVITE to the end user to contain a From field identifying the customer service rep, and authenticate the request using S/MIME (see RFC 3261 [1], Section 23) signed by the key of the customer service rep (which is held by the controller).
在一个常见场景中，控制器代表通话中的一个参与者。一个典型的例子是点击拨号，其中控制器和客户服务代表由同一管理域运行。事实上，为了识别，控制员可以合法地声称自己是客户服务代表。在这种情况下，对最终用户的邀请应该包含一个识别客户服务代表的From字段，并使用客户服务代表的密钥（由控制器持有）签名的S/MIME（参见RFC 3261[1]，第23节）对请求进行身份验证。
This requires the controller to actually have credentials with which it can authenticate itself as the customer support representative. In many other cases, the controller is representing one of the participants, but does not possess their credentials. Unfortunately, there are currently no standardized mechanisms that allow a user to delegate credentials to the controller in a way that limits their usage to specific third party call control operations. In the absence of such a mechanisms, the best that can be done is to use the display name in the From field to indicate the identity of the user on whose behalf the call is being made. It is RECOMMENDED that the display name be set to "[controller] on behalf of [user]", where user and controller are textual identities of the user and controller, respectively. In this case, the URI in the From field would identify the controller.
这要求控制器实际具有凭据，以便作为客户支持代表对自己进行身份验证。在许多其他情况下，控制器代表其中一个参与者，但不拥有他们的凭据。不幸的是，目前还没有标准化的机制允许用户将凭据委托给控制器，从而将其使用限制为特定的第三方呼叫控制操作。在没有这种机制的情况下，最好的办法是使用“发件人”字段中的显示名称来指示代表其进行呼叫的用户的身份。建议将显示名称设置为“[控制器]代表[用户]”，其中用户和控制器分别是用户和控制器的文本标识。在这种情况下，“发件人”字段中的URI将标识控制器。
In other situations, there is no real relationship between the controller and the participants in the call. In these situations, ideally the controller would have a means to assert that the call is from a particular identity (which could be one of the participants, or even a third party, depending on the application), and to validate that assertion with a signature using the key of the controller.
在其他情况下，控制器和通话参与者之间没有真正的关系。在这些情况下，理想情况下，控制器将有一种方法来断言调用来自特定身份（可能是参与者之一，甚至是第三方，取决于应用程序），并使用控制器的密钥通过签名验证该断言。
With third party call control, the controller is actually one of the participants as far as the SIP dialog is concerned. Therefore, encryption and integrity of the SIP messages, as provided by S/MIME, will occur between participants and the controller, rather than directly between participants.
对于第三方呼叫控制，就SIP对话而言，控制器实际上是参与者之一。因此，由S/MIME提供的SIP消息的加密和完整性将发生在参与者和控制器之间，而不是直接发生在参与者之间。
However, integrity, authenticity and confidentiality of the media sessions can be provided through a controller. End-to-end media security is based on the exchange of keying material within SDP [10].
然而，可以通过控制器提供媒体会话的完整性、真实性和机密性。端到端媒体安全性基于SDP内密钥材料的交换[10]。
The proper operation of these mechanisms with third party call control depends on the controller behaving properly. So long as it is not attempting to explicitly disable these mechanisms, the protocols will properly operate between the participants, resulting in a secure media session that even the controller cannot eavesdrop or modify. Since third party call control is based on a model of trust between the users and the controller, it is reasonable to assume it is operating in a well-behaved manner. However, there is no cryptographic means that can prevent the controller from interfering with the initial exchanges of keying materials. As a result, it is trivially possibly for the controller to insert itself as an intermediary on the media exchange, if it should so desire.
这些具有第三方调用控制的机制的正确运行取决于控制器的正常运行。只要不试图显式禁用这些机制，协议将在参与者之间正常运行，从而产生一个即使控制器也无法窃听或修改的安全媒体会话。由于第三方呼叫控制基于用户和控制器之间的信任模型，因此可以合理地假设它以良好的方式运行。然而，没有任何加密手段可以防止控制器干扰密钥材料的初始交换。因此，如果控制器愿意的话，它很可能在媒体交换上插入自己作为中介。
The authors would like to thank Paul Kyzivat, Rohan Mahy, Eric Rescorla, Allison Mankin and Sriram Parameswar for their comments.
作者要感谢Paul Kyzivat、Rohan Mahy、Eric Rescorla、Allison Mankin和Sriram Parameswar的评论。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Camarillo, G., Ed., Marshall, W., Ed. and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[2] Camarillo，G.，Ed.，Marshall，W.，Ed.和J.Rosenberg，“资源管理和会话启动协议（SIP）的集成”，RFC 3312，2002年10月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[5] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[5] Schulzrinne，H.，Oran，D.和G.Camarillo，“会话启动协议（SIP）的原因头字段”，RFC3326，2002年12月。
[6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[6] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 3262，2002年6月。
[7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[7] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[8] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 35502003年7月。
[9] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services", RFC 2848, June 2000.
[9] Petrack，S.和L.Conroy，“PINT服务协议：电话呼叫服务IP接入的SIP和SDP扩展”，RFC 28482000年6月。
[10] Andreasen, F., Baugher, M. and D. Wing, "SDP Security Descriptions for Media Streams", Work in Progress, October 2003.
[10] Andreasen，F.，Baugher，M.和D.Wing，“媒体流的SDP安全描述”，正在进行的工作，2003年10月。
[11] Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for User Control of Internet Telephony Services", Work in Progress, August 2003.
[11] Lennox，J.，Wu，X.和H.Schulzrinne，“CPL：互联网电话服务的用户控制语言”，正在进行的工作，2003年8月。
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg dynamicsoft 600美国新泽西州帕西帕尼拉尼德斯广场07054
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Jon Peterson Neustar 1800 Sutter Street Suite 570 Concord, CA 94520 US
美国加利福尼亚州康科德市萨特街1800号乔恩·彼得森纽斯塔570室，邮编94520
Phone: +1 925 363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz
Phone: +1 925 363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
Henning Schulzrinne哥伦比亚大学M/S 0401 1214美国纽约州阿姆斯特丹大道10027号
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。