Internet Engineering Task Force (IETF) R. Mahy
Request for Comments: 5850 Unaffiliated
Category: Informational R. Sparks
ISSN: 2070-1721 Tekelec
J. Rosenberg
jdrosen.net
D. Petrie
SIPez
A. Johnston, Ed.
Avaya
May 2010
Internet Engineering Task Force (IETF) R. Mahy
Request for Comments: 5850 Unaffiliated
Category: Informational R. Sparks
ISSN: 2070-1721 Tekelec
J. Rosenberg
jdrosen.net
D. Petrie
SIPez
A. Johnston, Ed.
Avaya
May 2010
A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP)
会话启动协议（SIP）的呼叫控制和多方使用框架
Abstract
摘要
This document defines a framework and the requirements for call control and multi-party usage of the Session Initiation Protocol (SIP). To enable discussion of multi-party features and applications, we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually set up the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state and session history. This framework also describes other goals that embody the spirit of SIP applications as used on the Internet such as the definition of primitives (not services), invoker and participant oriented primitives, signaling and mixing model independence, and others.
本文档定义了会话启动协议（SIP）的呼叫控制和多方使用的框架和要求。为了能够讨论多方功能和应用程序，我们定义了一个抽象调用模型来描述其中许多功能和应用程序所需的媒体关系。这里描述的模型和动作被特别选择为独立于SIP信令和/或选择用于实际建立媒体关系的混合方法。除了对话框操作方面，该框架还包括通信相关信息和事件（如会议和会话状态以及会话历史）的需求。该框架还描述了体现Internet上使用的SIP应用程序精神的其他目标，如原语（而非服务）的定义、面向调用方和参与者的原语、信令和混合模型独立性等。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5850.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5850.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Motivation and Background . . . . . . . . . . . . . . . . . . 4
2. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Conversation Space Model . . . . . . . . . . . . . . . . . 7
2.2. Relationship between Conversation Space, SIP Dialogs,
and SIP Sessions . . . . . . . . . . . . . . . . . . . . . 8
2.3. Signaling Models . . . . . . . . . . . . . . . . . . . . . 9
2.4. Mixing Models . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. Tightly Coupled . . . . . . . . . . . . . . . . . . . 11
2.4.2. Loosely Coupled . . . . . . . . . . . . . . . . . . . 12
2.5. Conveying Information and Events . . . . . . . . . . . . . 13
2.6. Componentization and Decomposition . . . . . . . . . . . . 15
2.6.1. Media Intermediaries . . . . . . . . . . . . . . . . . 15
2.6.2. Text-to-Speech and Automatic Speech Recognition . . . 17
2.6.3. VoiceXML . . . . . . . . . . . . . . . . . . . . . . . 17
2.7. Use of URIs . . . . . . . . . . . . . . . . . . . . . . . 18
2.7.1. Naming Users in SIP . . . . . . . . . . . . . . . . . 19
2.7.2. Naming Services with SIP URIs . . . . . . . . . . . . 20
2.8. Invoker Independence . . . . . . . . . . . . . . . . . . . 22
2.9. Billing Issues . . . . . . . . . . . . . . . . . . . . . . 23
1. Motivation and Background . . . . . . . . . . . . . . . . . . 4
2. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Conversation Space Model . . . . . . . . . . . . . . . . . 7
2.2. Relationship between Conversation Space, SIP Dialogs,
and SIP Sessions . . . . . . . . . . . . . . . . . . . . . 8
2.3. Signaling Models . . . . . . . . . . . . . . . . . . . . . 9
2.4. Mixing Models . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. Tightly Coupled . . . . . . . . . . . . . . . . . . . 11
2.4.2. Loosely Coupled . . . . . . . . . . . . . . . . . . . 12
2.5. Conveying Information and Events . . . . . . . . . . . . . 13
2.6. Componentization and Decomposition . . . . . . . . . . . . 15
2.6.1. Media Intermediaries . . . . . . . . . . . . . . . . . 15
2.6.2. Text-to-Speech and Automatic Speech Recognition . . . 17
2.6.3. VoiceXML . . . . . . . . . . . . . . . . . . . . . . . 17
2.7. Use of URIs . . . . . . . . . . . . . . . . . . . . . . . 18
2.7.1. Naming Users in SIP . . . . . . . . . . . . . . . . . 19
2.7.2. Naming Services with SIP URIs . . . . . . . . . . . . 20
2.8. Invoker Independence . . . . . . . . . . . . . . . . . . . 22
2.9. Billing Issues . . . . . . . . . . . . . . . . . . . . . . 23
3. Catalog of Call Control Actions and Sample Features . . . . . 23
3.1. Remote Call Control Actions on Early Dialogs . . . . . . . 24
3.1.1. Remote Answer . . . . . . . . . . . . . . . . . . . . 24
3.1.2. Remote Forward or Put . . . . . . . . . . . . . . . . 24
3.1.3. Remote Busy or Error Out . . . . . . . . . . . . . . . 24
3.2. Remote Call Control Actions on Single Dialogs . . . . . . 24
3.2.1. Remote Dial . . . . . . . . . . . . . . . . . . . . . 24
3.2.2. Remote On and Off Hold . . . . . . . . . . . . . . . . 25
3.2.3. Remote Hangup . . . . . . . . . . . . . . . . . . . . 25
3.3. Call Control Actions on Multiple Dialogs . . . . . . . . . 25
3.3.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.2. Take . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.3. Add . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.4. Local Join . . . . . . . . . . . . . . . . . . . . . . 28
3.3.5. Insert . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.6. Split . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.7. Near-Fork . . . . . . . . . . . . . . . . . . . . . . 29
3.3.8. Far-Fork . . . . . . . . . . . . . . . . . . . . . . . 29
4. Security Considerations . . . . . . . . . . . . . . . . . . . 30
Appendix A. Example Features . . . . . . . . . . . . . . . . . 32
Appendix A.1. Attended Transfer . . . . . . . . . . . . . . . . . 32
Appendix A.2. Auto Answer . . . . . . . . . . . . . . . . . . . . 32
Appendix A.3. Automatic Callback . . . . . . . . . . . . . . . . 32
Appendix A.4. Barge-In . . . . . . . . . . . . . . . . . . . . . 32
Appendix A.5. Blind Transfer . . . . . . . . . . . . . . . . . . 32
Appendix A.6. Call Forwarding . . . . . . . . . . . . . . . . . . 33
Appendix A.7. Call Monitoring . . . . . . . . . . . . . . . . . . 33
Appendix A.8. Call Park . . . . . . . . . . . . . . . . . . . . . 33
Appendix A.9. Call Pickup . . . . . . . . . . . . . . . . . . . . 33
Appendix A.10. Call Return . . . . . . . . . . . . . . . . . . . . 34
Appendix A.11. Call Waiting . . . . . . . . . . . . . . . . . . . 34
Appendix A.12. Click-to-Dial . . . . . . . . . . . . . . . . . . . 34
Appendix A.13. Conference Call . . . . . . . . . . . . . . . . . . 34
Appendix A.14. Consultative Transfer . . . . . . . . . . . . . . . 34
Appendix A.15. Distinctive Ring . . . . . . . . . . . . . . . . . 35
Appendix A.16. Do Not Disturb . . . . . . . . . . . . . . . . . . 35
Appendix A.17. Find-Me . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A.18. Hotline . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A.19. IM Conference Alerts . . . . . . . . . . . . . . . 35
Appendix A.20. Inbound Call Screening . . . . . . . . . . . . . . 35
Appendix A.21. Intercom . . . . . . . . . . . . . . . . . . . . . 36
Appendix A.22. Message Waiting . . . . . . . . . . . . . . . . . . 36
Appendix A.23. Music on Hold . . . . . . . . . . . . . . . . . . . 36
Appendix A.24. Outbound Call Screening . . . . . . . . . . . . . . 36
Appendix A.25. Pre-Paid Calling . . . . . . . . . . . . . . . . . 37
Appendix A.26. Presence-Enabled Conferencing . . . . . . . . . . . 37
Appendix A.27. Single Line Extension/Multiple Line Appearance . . 37
Appendix A.28. Speakerphone Paging . . . . . . . . . . . . . . . . 38
3. Catalog of Call Control Actions and Sample Features . . . . . 23
3.1. Remote Call Control Actions on Early Dialogs . . . . . . . 24
3.1.1. Remote Answer . . . . . . . . . . . . . . . . . . . . 24
3.1.2. Remote Forward or Put . . . . . . . . . . . . . . . . 24
3.1.3. Remote Busy or Error Out . . . . . . . . . . . . . . . 24
3.2. Remote Call Control Actions on Single Dialogs . . . . . . 24
3.2.1. Remote Dial . . . . . . . . . . . . . . . . . . . . . 24
3.2.2. Remote On and Off Hold . . . . . . . . . . . . . . . . 25
3.2.3. Remote Hangup . . . . . . . . . . . . . . . . . . . . 25
3.3. Call Control Actions on Multiple Dialogs . . . . . . . . . 25
3.3.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.2. Take . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.3. Add . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.4. Local Join . . . . . . . . . . . . . . . . . . . . . . 28
3.3.5. Insert . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.6. Split . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.7. Near-Fork . . . . . . . . . . . . . . . . . . . . . . 29
3.3.8. Far-Fork . . . . . . . . . . . . . . . . . . . . . . . 29
4. Security Considerations . . . . . . . . . . . . . . . . . . . 30
Appendix A. Example Features . . . . . . . . . . . . . . . . . 32
Appendix A.1. Attended Transfer . . . . . . . . . . . . . . . . . 32
Appendix A.2. Auto Answer . . . . . . . . . . . . . . . . . . . . 32
Appendix A.3. Automatic Callback . . . . . . . . . . . . . . . . 32
Appendix A.4. Barge-In . . . . . . . . . . . . . . . . . . . . . 32
Appendix A.5. Blind Transfer . . . . . . . . . . . . . . . . . . 32
Appendix A.6. Call Forwarding . . . . . . . . . . . . . . . . . . 33
Appendix A.7. Call Monitoring . . . . . . . . . . . . . . . . . . 33
Appendix A.8. Call Park . . . . . . . . . . . . . . . . . . . . . 33
Appendix A.9. Call Pickup . . . . . . . . . . . . . . . . . . . . 33
Appendix A.10. Call Return . . . . . . . . . . . . . . . . . . . . 34
Appendix A.11. Call Waiting . . . . . . . . . . . . . . . . . . . 34
Appendix A.12. Click-to-Dial . . . . . . . . . . . . . . . . . . . 34
Appendix A.13. Conference Call . . . . . . . . . . . . . . . . . . 34
Appendix A.14. Consultative Transfer . . . . . . . . . . . . . . . 34
Appendix A.15. Distinctive Ring . . . . . . . . . . . . . . . . . 35
Appendix A.16. Do Not Disturb . . . . . . . . . . . . . . . . . . 35
Appendix A.17. Find-Me . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A.18. Hotline . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A.19. IM Conference Alerts . . . . . . . . . . . . . . . 35
Appendix A.20. Inbound Call Screening . . . . . . . . . . . . . . 35
Appendix A.21. Intercom . . . . . . . . . . . . . . . . . . . . . 36
Appendix A.22. Message Waiting . . . . . . . . . . . . . . . . . . 36
Appendix A.23. Music on Hold . . . . . . . . . . . . . . . . . . . 36
Appendix A.24. Outbound Call Screening . . . . . . . . . . . . . . 36
Appendix A.25. Pre-Paid Calling . . . . . . . . . . . . . . . . . 37
Appendix A.26. Presence-Enabled Conferencing . . . . . . . . . . . 37
Appendix A.27. Single Line Extension/Multiple Line Appearance . . 37
Appendix A.28. Speakerphone Paging . . . . . . . . . . . . . . . . 38
Appendix A.29. Speed Dial . . . . . . . . . . . . . . . . . . . . 38
Appendix A.30. Voice Message Screening . . . . . . . . . . . . . . 38
Appendix A.31. Voice Portal . . . . . . . . . . . . . . . . . . . 39
Appendix A.32. Voicemail . . . . . . . . . . . . . . . . . . . . . 40
Appendix A.33. Whispered Call Waiting . . . . . . . . . . . . . . 40
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 40
5. Informative References . . . . . . . . . . . . . . . . . . . . 40
Appendix A.29. Speed Dial . . . . . . . . . . . . . . . . . . . . 38
Appendix A.30. Voice Message Screening . . . . . . . . . . . . . . 38
Appendix A.31. Voice Portal . . . . . . . . . . . . . . . . . . . 39
Appendix A.32. Voicemail . . . . . . . . . . . . . . . . . . . . . 40
Appendix A.33. Whispered Call Waiting . . . . . . . . . . . . . . 40
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 40
5. Informative References . . . . . . . . . . . . . . . . . . . . 40
The Session Initiation Protocol (SIP) [RFC3261] was defined for the initiation, maintenance, and termination of sessions or calls between one or more users. However, despite its origins as a large-scale multi-party conferencing protocol, SIP is used today primarily for point-to-point calls. This two-party configuration is the focus of the SIP specification and most of its extensions.
会话启动协议（SIP）[RFC3261]定义用于启动、维护和终止一个或多个用户之间的会话或呼叫。然而，尽管SIP起源于大规模多方会议协议，但如今主要用于点对点呼叫。这种两方配置是SIP规范及其大多数扩展的重点。
This document defines a framework and the requirements for call control and multi-party usage of SIP. Most multi-party operations manipulate SIP dialogs (also known as call legs) or SIP conference media policy to cause participants in a conversation to perceive specific media relationships. In other protocols that deal with the concept of calls, this manipulation is known as call control. In addition to its dialog or policy manipulation aspect, call control also includes communicating information and events related to manipulating calls, including information and events dealing with session state and history, conference state, user state, and even message state.
本文档定义了SIP呼叫控制和多方使用的框架和要求。大多数多方操作操纵SIP对话（也称为呼叫分支）或SIP会议媒体策略，以使会话参与者感知特定的媒体关系。在处理调用概念的其他协议中，这种操作称为调用控制。除了对话框或策略操纵方面，呼叫控制还包括与操纵呼叫相关的通信信息和事件，包括处理会话状态和历史记录、会议状态、用户状态甚至消息状态的信息和事件。
Based on input from the SIP community, the authors compiled the following set of goals for SIP call control and multi-party applications:
根据SIP社区的输入，作者为SIP呼叫控制和多方应用程序编制了以下目标：
o Define primitives, not services. Allow for a handful of robust yet simple mechanisms that can be combined to deliver features and services. Throughout this document, we refer to these simple mechanisms as "primitives". Primitives should be sufficiently robust so that when they are combined with each other, they can be used to build lots of services. However, the goal is not to define a provably complete set of primitives. Note that while the IETF will NOT standardize behavior or services, it may define example services for informational purposes, as in service examples [RFC5359].
o 定义原语，而不是服务。允许使用一些健壮但简单的机制，这些机制可以组合起来提供功能和服务。在本文档中，我们将这些简单机制称为“原语”。原语应该足够健壮，这样当它们相互结合时，就可以用来构建大量的服务。然而，目标不是定义一组可证明的完整原语。请注意，尽管IETF不会标准化行为或服务，但它可能会定义示例服务以供参考，如服务示例[RFC5359]。
o Be participant oriented. The primitives should be designed to provide services that are oriented around the experience of the participants. The authors observe that end users of features and services usually don't care how a media relationship is set up.
o 以参与者为导向。原语应设计为提供面向参与者体验的服务。作者观察到，功能和服务的最终用户通常不关心如何建立媒体关系。
Their ultimate experience is only based on the resulting media and other externally visible characteristics.
他们的最终体验仅基于由此产生的媒体和其他外部可见的特征。
o Be signaling model independent. Support both a central-control and a peer-to-peer feature invocation model (and combinations of the two). Baseline SIP already supports a centralized control model described in 3pcc (third party call control) [RFC3725], and the SIP community has expressed a great deal of interest in peer-to-peer or distributed call control using primitives such as those defined in REFER [RFC3515], Replaces [RFC3891], and Join [RFC3911].
o 独立于信令模型。支持中央控制和对等功能调用模型（以及两者的组合）。基线SIP已经支持3pcc（第三方呼叫控制）[RFC3725]中描述的集中式控制模型，SIP社区对使用原语（如参考[RFC3515]、替换[RFC3891]和加入[RFC3911]中定义的原语）的对等或分布式呼叫控制表示了极大的兴趣。
o Be mixing model independent. The bulk of interesting multi-party applications involve mixing or combining media from multiple participants. This mixing can be performed by one or more of the participants or by a centralized mixing resource. The experience of the participants should not depend on the mixing model used. While most examples in this document refer to audio mixing, the framework applies to any media type. In this context, a "mixer" refers to combining media of the same type in an appropriate, media-specific way. This is consistent with the model described in the SIP conferencing framework.
o 与模型无关。大量有趣的多方应用程序涉及混合或组合来自多个参与者的媒体。这种混合可以由一个或多个参与者或集中的混合资源执行。参与者的经验不应取决于所使用的混合模式。虽然本文档中的大多数示例都涉及音频混合，但该框架适用于任何媒体类型。在此上下文中，“混合器”指以适当的、特定于媒体的方式组合相同类型的媒体。这与SIP会议框架中描述的模型一致。
o Be invoker oriented. Only the user who invokes a feature or a service needs to know exactly which service is invoked or why. This is good because it allows new services to be created without requiring new primitives from all of the participants; and it allows for much simpler feature authorization policies, for example, when participation spans organizational boundaries. As discussed in Section 2.7, this also avoids exponential state explosion when combining features. The invoker only has to manage a user interface or application programming interface (API) to prevent local feature interactions. All the other participants simply need to manage the feature interactions of a much smaller number of primitives.
o 要面向调用方。只有调用功能或服务的用户才需要确切地知道调用了哪个服务或为什么。这很好，因为它允许创建新服务，而不需要来自所有参与者的新原语；并且它允许更简单的功能授权策略，例如，当参与跨越组织边界时。如第2.7节所述，这也避免了在组合特征时出现指数状态爆炸。调用方只需管理用户界面或应用程序编程接口（API），以防止本地功能交互。所有其他参与者只需要管理数量少得多的原语的特性交互。
o Primitives make full use of URIs (uniform resource identifiers). URIs are a very powerful mechanism for describing users and services. They represent a plentiful resource that can be extremely expressive and easily routed, translated, and manipulated -- even across organizational boundaries. URIs can contain special parameters and informational header fields that need only be relevant to the owner of the namespace (domain) of the URI. Just as a user who selects an http: URL need not understand the significance and organization of the web site it references, a user may encounter a SIP URI that translates into an email-style group alias, which plays a pre-recorded message or runs some complex call-handling logic. Note that while this may
o 原语充分利用URI（统一资源标识符）。URI是描述用户和服务的非常强大的机制。它们代表了一个丰富的资源，可以非常有表现力，并且可以轻松地路由、翻译和操纵——甚至可以跨越组织边界。URI可以包含特殊参数和信息头字段，这些字段只需要与URI的命名空间（域）的所有者相关。正如选择http:URL的用户不需要了解其引用的网站的意义和组织一样，用户可能会遇到一个SIP-URI，该URI转换为电子邮件样式的组别名，它播放预先录制的消息或运行一些复杂的呼叫处理逻辑。注意，虽然这可能
seem paradoxical to the previous goal, both goals can be satisfied by the same model.
与前一个目标似乎自相矛盾，两个目标都可以通过相同的模型来实现。
o Make use of SIP header fields and SIP event packages to provide SIP entities with information about their environment. These should include information about the status/handling of dialogs on other user agents (UAs), information about the history of other contacts attempted prior to the current contact, the status of participants, the status of conferences, user presence information, and the status of messages.
o 使用SIP头字段和SIP事件包为SIP实体提供有关其环境的信息。这些信息应包括关于其他用户代理（UAs）对话框的状态/处理的信息、关于当前联系人之前尝试的其他联系人的历史记录的信息、参与者的状态、会议状态、用户状态信息以及消息状态。
o Encourage service decomposition, and design to make use of standard components using well-defined, simple interfaces. Sample components include a SIP mixer, recording service, announcement server, and voice-dialog server. (This is not an exhaustive list).
o 鼓励服务分解，并设计为使用定义良好、简单的接口使用标准组件。示例组件包括SIP混音器、录音服务、公告服务器和语音对话服务器。（这不是一份详尽的清单）。
o Include authentication, authorization, policy, logging, and accounting mechanisms to allow these primitives to be used safely among mutually untrusted participants. Some of these mechanisms may be used to assist in billing, but no specific billing system will be endorsed.
o 包括身份验证、授权、策略、日志和记帐机制，以允许在相互不信任的参与者之间安全地使用这些原语。其中一些机制可用于协助计费，但不会认可特定的计费系统。
o Permit graceful fallback to baseline SIP. Definitions for new SIP call control extensions/primitives must describe a graceful way to fallback to baseline SIP behavior. Support for one primitive must not imply support for another primitive.
o 允许正常回退到基线SIP。新SIP呼叫控制扩展/原语的定义必须描述回退到基线SIP行为的优雅方式。对一个原语的支持不能意味着对另一个原语的支持。
o Don't reinvent traditional models, such as the model used for the H.450 family of protocols, JTAPI (Java Telephony Application Programming Interface), or the CSTA (Computer-supported telecommunications applications) call model, as these other models do not share the design goals presented in this document.
o 不要重新发明传统模型，例如用于H.450协议系列的模型、JTAPI（Java电话应用程序编程接口）或CSTA（计算机支持的电信应用程序）调用模型，因为这些其他模型与本文档中介绍的设计目标不相同。
Note that the flexibility in this model does have some disadvantages in terms of interoperability. It is possible to build a call control feature in SIP using different combinations of primitives. For a discussion of the issues associated with this, see [BLISS-PROBLEM].
请注意，此模型中的灵活性在互操作性方面确实存在一些缺点。可以使用不同的原语组合在SIP中构建呼叫控制功能。有关与此相关的问题的讨论，请参阅[BLISS-PROBLEM]。
This section introduces a number of key concepts that will be used to describe and explain various call control operations and services in the remainder of this document. This includes the conversation space model, signaling and mixing models, common components, and the use of URIs.
本节介绍了一些关键概念，这些概念将用于描述和解释本文档其余部分中的各种呼叫控制操作和服务。这包括会话空间模型、信令和混合模型、公共组件以及URI的使用。
This document introduces the concept of an abstract "conversation space" as a set of participants who believe they are all communicating among one another. Each conversation space contains one or more participants.
本文介绍了一个抽象的“对话空间”的概念，即一组相信他们都在相互交流的参与者。每个对话空间包含一个或多个参与者。
Participants are SIP UAs that send original media to or terminate and receive media from other members of the conversation space. Logically, every participant in the conversation space has access to all the media generated in that space (this is strictly true if all participants share a common media type). A SIP UA that does not contribute or consume any media is NOT a participant, nor is a UA that merely forwards, transcodes, mixes, or selects media originating elsewhere in the conversation space.
参与者是SIP UAs，向对话空间的其他成员发送原始媒体或终止并接收来自对话空间其他成员的媒体。从逻辑上讲，会话空间中的每个参与者都可以访问该空间中生成的所有媒体（如果所有参与者共享一种公共媒体类型，则严格来说这是正确的）。不贡献或使用任何媒体的SIP-UA不是参与者，也不是仅仅转发、转码、混合或选择源自会话空间中其他地方的媒体的UA。
Note that a conversation space consists of zero or more SIP calls or SIP conferences. A conversation space is similar to the definition of a "call" in some other call models.
请注意，会话空间由零个或多个SIP呼叫或SIP会议组成。对话空间类似于某些其他通话模型中的“通话”定义。
Participants may represent human users or non-human users (referred to as robots or automatons in this document). Some participants may be hidden within a conversation space. Some examples of hidden participants include: robots that generate tones, images, or announcements during a conference to announce users arriving and departing, a human call center supervisor monitoring a conversation between a trainee and a customer, and robots that record media for training or archival purposes.
参与者可以代表人类用户或非人类用户（在本文档中称为机器人或自动机）。一些参与者可能隐藏在对话空间中。隐藏参与者的一些示例包括：在会议期间生成音调、图像或公告以通知用户到达和离开的机器人，监控受训者和客户之间对话的人工呼叫中心主管，以及为培训或存档目的录制媒体的机器人。
Participants may also be active or passive. Active participants are expected to be intelligent enough to leave a conversation space when they no longer desire to participate. (An attentive human participant is obviously active.) Some robotic participants (such as a voice-messaging system, an instant-messaging agent, or a voice-dialog system) may be active participants if they can leave the conversation space when there is no human interaction. Other robots (for example, our tone-generating robot from the previous example) are passive participants. A human participant "on hold" is passive.
参与者也可以是主动的或被动的。积极的参与者应该足够聪明，当他们不再想参与时，可以留下一个对话空间。（专注的人类参与者显然是活跃的。）一些机器人参与者（如语音信息系统、即时信息代理或语音对话系统）可能是活跃的参与者，如果他们在没有人类交互的情况下可以离开对话空间。其他机器人（例如，上一个例子中的发声机器人）是被动参与者。人类参与者“暂停”是被动的。
An example diagram of a conversation space can be shown as a "bubble" or ovals, or as a "set" in curly or square bracket notation. Each set, oval, or bubble represents a conversation space. Hidden participants are shown in lowercase letters. Examples are given in Figure 1.
对话空间的示例图可以显示为“气泡”或椭圆形，也可以显示为花括号或方括号表示法中的“集合”。每个集合、椭圆形或气泡代表一个对话空间。隐藏的参与者以小写字母显示。示例如图1所示。
Note that while the term "conversation" usually applies to oral exchange of information, we apply the conversation space model to any media exchange between participants.
请注意，虽然术语“对话”通常适用于口头信息交流，但我们将对话空间模型应用于参与者之间的任何媒体交流。
{ A , B } [ A , b, C, D ]
{A，B}[A，B，C，D]
.-. .---.
/ \ / \
/ A \ / A b \
( ) ( )
\ B / \ C D /
\ / \ /
'-' '---'
.-. .---.
/ \ / \
/ A \ / A b \
( ) ( )
\ B / \ C D /
\ / \ /
'-' '---'
Figure 1. Conversation Spaces
图1。会话空间
2.2. Relationship between Conversation Space, SIP Dialogs, and SIP Sessions
2.2. 会话空间、SIP对话框和SIP会话之间的关系
In [RFC3261], a call is "an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation". The concept of a conversation space is needed because the SIP definition of call is not sufficiently precise for the purpose of describing the user experience of multi-party features.
在[RFC3261]中，呼叫是“一个非正式术语，指的是对等方之间的一些通信，通常是为了多媒体对话而设置的”。需要会话空间的概念，因为SIP对呼叫的定义对于描述多方功能的用户体验不够精确。
Do any other definitions convey the correct meaning? SIP and SDP (Session Description Protocol) [RFC4566] both define a conference as "a multimedia session identified by a common session description". A session is defined as "a set of multimedia senders and receivers and the data streams flowing from senders to receivers". The definition of "call" in some call models is more similar to our definition of a conversation space.
其他定义是否传达了正确的含义？SIP和SDP（会话描述协议）[RFC4566]都将会议定义为“由公共会话描述标识的多媒体会话”。会话被定义为“一组多媒体发送方和接收方以及从发送方流向接收方的数据流”。在一些通话模型中，“通话”的定义与我们对通话空间的定义更为相似。
Some examples of the relationship between conversation spaces, SIP dialogs, and SIP sessions are listed below. In each example, a human user will perceive that there is a single call.
下面列出了会话空间、SIP对话框和SIP会话之间关系的一些示例。在每个示例中，人类用户将感知到存在单个呼叫。
o A simple two-party call is a single conversation space, a single session, and a single dialog.
o 简单的两方通话是一个单独的对话空间、一个单独的会话和一个单独的对话。
o A locally mixed three-way call is two sessions and two dialogs. It is also a single conversation space.
o 本地混合三路呼叫是两个会话和两个对话框。它也是一个单一的对话空间。
o A simple dial-in audio conference is a single conversation space, but is represented by as many dialogs and sessions as there are human participants.
o 一个简单的拨入式音频会议是一个单独的对话空间，但它所代表的对话和会话数量与人类参与者的数量相同。
o A multicast conference is a single conversation space, a single session, and as many dialogs as participants.
o 多播会议是一个单独的对话空间、一个单独的会话以及与参与者一样多的对话。
Obviously, to make changes to a conversation space, you must be able to use SIP signaling to cause these changes. Specifically, there must be a way to manipulate SIP dialogs (call legs) to move participants into and out of conversation spaces. Although this is not as obvious, there also must be a way to manipulate SIP dialogs to include non-participant UAs that are otherwise involved in a conversation space (e.g., back-to-back user agents or B2BUAs, third party call control (3pcc) controllers, mixers, transcoders, translators, or relays).
显然，要对会话空间进行更改，您必须能够使用SIP信令来引起这些更改。具体地说，必须有一种方法来操纵SIP对话（呼叫腿），以将参与者移入和移出会话空间。虽然这不是很明显，但也必须有一种方法来操纵SIP对话框，以包括对话空间中涉及的非参与者UAs（例如，背对背用户代理或B2BUA、第三方呼叫控制（3pcc）控制器、混音器、转码器、翻译器或中继）。
Implementations may setup the media relationships described in the conversation space model using a centralized control model. One common way to implement this using SIP is known as third party call control (3pcc) and is described in 3pcc [RFC3725]. The 3pcc approach relies on only the following three primitive operations:
实现可以使用集中控制模型来设置会话空间模型中描述的媒体关系。使用SIP实现此功能的一种常见方法称为第三方呼叫控制（3pcc），并在3pcc[RFC3725]中进行了描述。3pcc方法仅依赖以下三种基本操作：
o Create a new dialog (INVITE)
o 创建新对话框（邀请）
o Modify a dialog (reINVITE)
o 修改对话框（重新邀请）
o Destroy a dialog (BYE)
o 销毁对话框（再见）
The main advantage of the 3pcc approach is that it only requires very basic SIP support from end systems to support call control features. As such, third party call control is a natural way to handle protocol conversion and mid-call features. It also has the advantage and disadvantage that new features can/must be implemented in one place only (the controller), and it neither requires enhanced client functionality nor takes advantage of it.
3pcc方法的主要优点是，它只需要终端系统提供非常基本的SIP支持即可支持呼叫控制功能。因此，第三方呼叫控制是处理协议转换和中间呼叫功能的自然方式。它还有一个优点和缺点，即新特性只能/必须在一个地方（控制器）实现，它既不需要增强的客户端功能，也不利用它。
In addition, a peer-to-peer approach is discussed at length in this document. The primary drawback of the peer-to-peer model is additional complexity in the end system and authentication and management models. The benefits of the peer-to-peer model include:
此外，本文还详细讨论了点对点方法。对等模型的主要缺点是终端系统以及身份验证和管理模型的复杂性增加。点对点模式的好处包括：
o state remains at the edges,
o 国家仍然处于边缘，
o call signaling need only go through participants involved (there are no additional points of failure), and
o 呼叫信号只需经过相关参与者（没有其他故障点），以及
o peers may take advantage of end-to-end message integrity or encryption
o 对等方可以利用端到端消息完整性或加密
The peer-to-peer approach relies on additional "primitive" operations, some of which are identified here.
点对点方法依赖于额外的“原始”操作，其中一些操作在这里被识别。
o Replace an existing dialog
o 替换现有对话框
o Join a new dialog with an existing dialog
o 将新对话框与现有对话框联接
o Locally perform media forking (multi-unicast)
o 本地执行媒体分叉（多单播）
o Ask another user agent (UA) to send a request on your behalf
o 请另一个用户代理（UA）代表您发送请求
The peer-to-peer approach also only results in a single SIP dialog, directly between the two UAs. The 3pcc approach results in two SIP dialogs, between each UA and the controller. As a result, the SIP features and extensions that will be used during the dialog are limited to the those understood by the controller. As a result, in a situation where both the UAs support an advanced SIP feature but the controller does not, the feature will not be able to be used.
点对点方法也只能在两个UAs之间直接产生一个SIP对话。3pcc方法在每个UA和控制器之间产生两个SIP对话框。因此，对话期间使用的SIP功能和扩展仅限于控制器能够理解的功能和扩展。因此，在两个UAs都支持高级SIP功能但控制器不支持的情况下，该功能将无法使用。
Many of the features, primitives, and actions described in this document also require some type of media mixing, combining, or selection as described in the next section.
本文档中描述的许多功能、原语和操作也需要某种类型的介质混合、组合或选择，如下一节所述。
SIP permits a variety of mixing models, which are discussed here briefly. This topic is discussed more thoroughly in the SIP conferencing framework [RFC4353] and [RFC4579]. SIP supports both tightly coupled and loosely coupled conferencing, although more sophisticated behavior is available in tightly coupled conferences. In a tightly coupled conference, a single SIP user agent (called the focus) has a direct dialog relationship with each participant (and may control non-participant user agents as well). The focus can authoritatively publish information about the character and participants in a conference. In a loosely coupled conference, there are no coordinated signaling relationships among the participants.
SIP允许各种混合模型，本文将对此进行简要讨论。本主题将在SIP会议框架[RFC4353]和[RFC4579]中进行更深入的讨论。SIP支持紧耦合和松耦合会议，尽管在紧耦合会议中可以使用更复杂的行为。在紧密耦合的会议中，单个SIP用户代理（称为focus）与每个参与者有直接对话关系（也可以控制非参与者用户代理）。焦点可以权威性地发布有关角色和会议参与者的信息。在松散耦合的会议中，参与者之间没有协调的信令关系。
For brevity, only the two most popular conferencing models are significantly discussed in this document (local and centralized mixing). Applications of the conversation spaces model to loosely coupled multicast and distributed full unicast mesh conferences are left as an exercise for the reader. Note that a distributed full mesh conference can be used for basic conferences, but does not easily allow for more complex conferencing actions like splitting, merging, and sidebars.
为简洁起见，本文档仅重点讨论了两种最流行的会议模式（本地和集中混合）。会话空间模型在松散耦合多播和分布式全单播网状会议中的应用留给读者练习。请注意，分布式全网格会议可用于基本会议，但不容易允许更复杂的会议操作，如拆分、合并和侧栏。
Call control features should be designed to allow a mixer (local or centralized) to decide when to reduce a conference back to a two-party call, or drop all the participants (for example, if only two automatons are communicating). The actual heuristics used to release calls are beyond the scope of this document, but may depend on properties in the conversation space, such as the number of active, passive, or hidden participants and the send-only, receive-only, or send-and-receive orientation of various participants.
呼叫控制功能应设计为允许混音器（本地或集中式）决定何时将会议还原为双方通话，或放弃所有参与者（例如，如果只有两个自动机在通信）。用于释放呼叫的实际试探法超出了本文档的范围，但可能取决于对话空间中的属性，如主动、被动或隐藏参与者的数量以及各种参与者的仅发送、仅接收或发送和接收方向。
Tightly coupled conferences utilize a central point for signaling and authentication known as a focus [RFC4353]. The actual media can be centrally mixed or distributed.
紧密耦合的会议利用一个中心点进行信令和身份验证，称为焦点[RFC4353]。实际介质可以集中混合或分布。
The first model we call "end system mixing". In this model, user A calls user B, and they have a conversation. At some point later, A decides to conference in user C. To do this, A calls C, using a completely separate SIP call. This call uses a different Call-ID, different tags, etc. There is no call set up directly between B and C. No SIP extension or external signaling is needed. A merely decides to locally join two dialogs.
我们称之为“末端系统混合”的第一个模型。在这个模型中，用户A呼叫用户B，他们进行对话。稍后，A决定在用户C中召开会议。为此，A使用完全独立的SIP呼叫呼叫C。此呼叫使用不同的呼叫ID、不同的标签等。B和C之间不直接建立呼叫。不需要SIP扩展或外部信令。A只决定在本地加入两个对话框。
B C
\ /
\ /
A
B C
\ /
\ /
A
Figure 2. End System Mixing Example
图2。末端系统混合示例
In Figure 2, A receives media streams from both B and C, and mixes them. A sends a stream containing A's and C's streams to B, and a stream containing A's and B's streams to C. Basically, user A handles both signaling and media mixing.
在图2中，A从B和C接收媒体流，并混合它们。A向B发送包含A和C流的流，向C发送包含A和B流的流。基本上，用户A处理信令和媒体混合。
In a centralized mixing model, all participants have a pairwise SIP and media relationship with the mixer. Common applications of centralized mixing include ad hoc conferences and scheduled dial-in or dial-out conferences. In Figure 3 below, the mixer M receives and sends media to participants A, B, C, D, and E.
在集中式混合模型中，所有参与者都与混合器具有成对的SIP和媒体关系。集中混合的常见应用包括临时会议和预定的拨入或拨出会议。在下面的图3中，混合器M接收媒体并将其发送给参与者A、B、C、D和E。
B C
\ /
\ /
M --- A
/ \
/ \
D E
B C
\ /
\ /
M --- A
/ \
/ \
D E
Figure 3. Centralized Mixing Example
图3。集中混合示例
In this conferencing model, there is a centralized controller, as in the dial-in and dial-out cases. However, the centralized server handles signaling only. The media is still sent directly between participants, using either multicast or multi-unicast. Participants perform their own mixing. Multi-unicast is when a user sends multiple packets (one for each recipient, addressed to that recipient). This is referred to as a "Decentralized Multipoint Conference" in [H.323]. Full mesh media with centralized mixing is another approach.
在这种会议模式中，有一个集中式控制器，如拨入和拨出情况。但是，集中式服务器仅处理信令。媒体仍然使用多播或多单播在参与者之间直接发送。参与者自己进行混合。多单播是指用户发送多个数据包（每个收件人一个，发往该收件人）。这在[H.323]中被称为“分散的多点会议”。另一种方法是采用集中混合的全网介质。
In these models, there is no point of central control of SIP signaling. As in the "Centralized Signaling, Distributed Media" case above, all endpoints send media to all other endpoints. Consequently, every endpoint mixes their own media from all the other sources and sends their own media to every other participant.
在这些模型中，没有SIP信令的集中控制点。在上面的“集中式信令，分布式媒体”案例中，所有端点都向所有其他端点发送媒体。因此，每个端点从所有其他来源混合他们自己的媒体，并将他们自己的媒体发送给每个其他参与者。
Large-scale multicast conferences were the original motivation for both the Session Description Protocol (SDP) [RFC4566] and SIP. In a large-scale multicast conference, one or more multicast addresses are allocated to the conference. Each participant joins those multicast groups and sends their media to those groups. Signaling is not sent to the multicast groups. The sole purpose of the signaling is to inform participants of which multicast groups to join. Large-scale multicast conferences are usually pre-arranged, with specific start and stop times. However, multicast conferences do not need to be pre-arranged, so long as a mechanism exists to dynamically obtain a multicast address.
大规模多播会议是会话描述协议（SDP）[RFC4566]和SIP的最初动机。在大规模多播会议中，一个或多个多播地址被分配给会议。每个参与者加入这些多播组并将其媒体发送到这些组。信令不会发送到多播组。信令的唯一目的是通知参与者要加入哪些多播组。大型多播会议通常是预先安排的，有特定的开始和停止时间。然而，只要存在动态获取多播地址的机制，多播会议就不需要预先安排。
In this conferencing model, each participant has both a pairwise media relationship and a pairwise signaling relationship with every other participant (a full mesh). This model requires a mechanism to maintain a consistent view of distributed state across the group. This is a classic, hard problem in computer science. Also, this model does not scale well for large numbers of participants. For <n> participants, the number of media and signaling relationships is approximately n-squared. As a result, this model is not generally available in commercial implementations; to the contrary, it is primarily the topic of research or experimental implementations. Note that this model assumes peer-to-peer signaling.
在这种会议模型中，每个参与者与其他参与者（一个完整的网格）既有成对的媒体关系，也有成对的信令关系。此模型需要一种机制来维护整个组中分布式状态的一致视图。这是计算机科学中的一个经典难题。此外，该模型不能很好地适用于大量参与者。对于<n>参与者，媒体和信号关系的数量约为n平方。因此，该模型在商业实现中通常不可用；相反，它主要是研究或实验实现的主题。请注意，此模型假设对等信令。
Participants should have access to information about the other participants in a conversation space so that this information can be rendered to a human user or processed by an automaton. Although some of this information may be available from the Request-URI or To, From, Contact, or other SIP header fields, another mechanism of reporting this information is necessary.
参与者应该能够访问对话空间中其他参与者的信息，以便将这些信息呈现给人类用户或由自动机处理。尽管这些信息中的一些可以从请求URI或To、from、Contact或其他SIP头字段中获得，但是报告这些信息的另一种机制是必要的。
Many applications are driven by knowledge about the progress of calls and conferences. In general, these types of events allow for the construction of distributed applications, where the application requires information on dialog and conference state, but is not necessarily a co-resident with an endpoint user agent or conference server. For example, a focus involved in a conversation space may wish to provide URIs for conference status and/or conference/floor control.
许多应用程序都是由有关电话和会议进度的知识驱动的。通常，这些类型的事件允许构造分布式应用程序，其中应用程序需要有关对话框和会议状态的信息，但不一定是与端点用户代理或会议服务器的共同驻留者。例如，会话空间中涉及的焦点可能希望为会议状态和/或会议/楼层控制提供uri。
The SIP Events architecture [RFC3265] defines general mechanisms for subscription to and notification of events within SIP networks. It introduces the notion of a package that is a specific "instantiation" of the events mechanism for a well-defined set of events.
SIP事件体系结构[RFC3265]定义了SIP网络内事件订阅和通知的一般机制。它引入了包的概念，包是一组定义良好的事件的事件机制的特定“实例化”。
Event packages are needed to provide the status of a user's dialogs, the status of conferences and their participants, user-presence information, the status of registrations, and the status of a user's messages. While this is not an exhaustive list, these are sufficient to enable the sample features described in this document.
需要事件包来提供用户对话框的状态、会议及其参与者的状态、用户状态信息、注册状态以及用户消息的状态。虽然这不是一个详尽的列表，但这些足以支持本文档中描述的示例功能。
The conference event package [RFC4575] allows users to subscribe to information about an entire tightly coupled SIP conference. Notifications convey information about the participants such as the SIP URI identifying each user, their status in the space (active, declined, departed), URIs to invoke other features (such as sidebar
会议事件包[RFC4575]允许用户订阅关于整个紧密耦合SIP会议的信息。通知传递有关参与者的信息，如标识每个用户的SIPURI、他们在空间中的状态（活动、拒绝、离开）、调用其他功能的URI（如侧边栏）
conversations), links to other relevant information (such as floor-control policies), and if floor-control policies are in place, the user's floor-control status. For conversation spaces created from cascaded conferences, conversation state can be gathered from relevant foci and merged into a cohesive set of state.
对话），指向其他相关信息（如楼层控制策略）的链接，如果楼层控制策略已到位，则显示用户的楼层控制状态。对于级联会议创建的会话空间，可以从相关焦点收集会话状态，并将其合并为一组内聚状态。
The dialog package [RFC4235] provides information about all the dialogs the target user is maintaining, in which conversations the user is participating, and how these are correlated. Likewise, the registration package [RFC3680] provides notifications when contacts have changed for a specific address-of-record (AOR). The combination of these allows a user agent to learn about all conversations occurring for the entire registered contact set for an address-of-record.
对话框包[RFC4235]提供有关目标用户正在维护的所有对话框、用户正在参与的对话以及这些对话之间的关联方式的信息。同样，注册包[RFC3680]在联系人更改特定记录地址（AOR）时提供通知。这些组合允许用户代理了解记录地址的整个已注册联系人集发生的所有对话。
Note that user presence in SIP [RFC3856] has a close relationship with these latter two event packages. It is fundamental to the presence model that the information used to obtain user presence is constructed from any number of different input sources. Examples of other such sources include calendaring information and uploads of presence documents. These two packages can be considered another mechanism that allows a presence agent to determine the presence state of the user. Specifically, a user presence server can act as a subscriber for the dialog and registration packages to obtain additional information that can be used to construct a presence document.
注意，SIP[RFC3856]中的用户存在与后两个事件包有着密切的关系。存在模型的基础是，用于获取用户存在的信息是从任意数量的不同输入源构建的。其他此类来源的示例包括日历信息和状态文档的上传。这两个包可以被视为另一种机制，允许存在代理确定用户的存在状态。具体而言，用户状态服务器可以充当对话框和注册包的订户，以获取可用于构建状态文档的附加信息。
The multi-party architecture may also need to provide a mechanism to get information about the status/handling of a dialog (for example, information about the history of other contacts attempted prior to the current contact). Finally, the architecture should provide ample opportunities to present informational URIs that relate to calls, conversations, or dialogs in some way. For example, consider the SIP Call-Info header or Contact header fields returned in a 300-class response. Frequently, additional information about a call or dialog can be fetched via non-SIP URIs. For example, consider a web page for package tracking when calling a delivery company or a web page with related documentation when joining a dial-in conference. The use of URIs in the multi-party framework is discussed in more detail in Section 3.7.
多方体系结构可能还需要提供一种机制来获取关于对话框的状态/处理的信息（例如，关于在当前联系人之前尝试的其他联系人的历史记录的信息）。最后，体系结构应该提供足够的机会以某种方式呈现与调用、对话或对话框相关的信息URI。例如，考虑在300类响应中返回的SIP调用信息头或联系人头字段。通常，有关调用或对话框的附加信息可以通过非SIPURI获取。例如，考虑在加入拨号会议时调用递送公司或具有相关文档的网页时进行包跟踪的网页。第3.7节将更详细地讨论URI在多方框架中的使用。
Finally, the interaction of SIP with stimulus-signaling-based applications, which allow a user agent to interact with an application without knowledge of the semantics of that application, is discussed in the SIP application interaction framework [RFC5629]. Stimulus signaling can occur with a user interface running locally with the client, or with a remote user interface, through media streams. Stimulus signaling encompasses a wide range of mechanisms,
最后，SIP应用程序交互框架[RFC5629]中讨论了SIP与基于刺激信令的应用程序的交互，该应用程序允许用户代理在不了解应用程序语义的情况下与应用程序交互。刺激信号可以通过与客户端本地运行的用户界面或通过媒体流与远程用户界面一起发生。刺激信号包括多种机制，
from clicking on hyperlinks, to pressing buttons, to traditional Dual-Tone Multi Frequency (DTMF) input. In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in that framework.
从点击超链接到按键，再到传统的双音多频（DTMF）输入。在所有情况下，刺激信号都是通过使用标记语言来支持的，标记语言在该框架中起着关键作用。
This framework proposes a decomposed component architecture with a very loose coupling of services and components. This means that a service (such as a conferencing server or an auto-attendant) need not be implemented as an actual server. Rather, these services can be built by combining a few basic components in straightforward or arbitrarily complex ways.
该框架提出了一种分解的组件体系结构，其中服务和组件的耦合非常松散。这意味着服务（如会议服务器或自动助理）不需要实现为实际服务器。相反，这些服务可以通过简单或任意复杂的方式组合一些基本组件来构建。
Since the components are easily deployed on separate boxes, by separate vendors, or even with separate providers, we achieve a separation of function that allows each piece to be developed in complete isolation. We can also reuse existing components for new applications. This allows rapid service creation, and the ability for services to be distributed across organizational domains anywhere in the Internet.
由于组件可以很容易地部署在单独的盒子上，由单独的供应商部署，甚至与单独的供应商部署，因此我们实现了功能的分离，允许在完全隔离的情况下开发每个组件。我们还可以为新的应用程序重用现有组件。这允许快速创建服务，并能够在Internet上的任何位置跨组织域分发服务。
For many of these components, it is also desirable to discover their capabilities, for example, querying the ability of a mixer to host a 10-dialog conference or to reserve resources for a specific time. These actions could be provided in the form of URIs, provided there is an a priori means of understanding their semantics. For example, if there is a published dictionary of operations, a way to query the service for the available operations and the associated URIs, the URI can be the interface for providing these service operations. This concept is described in more detail in the context of dialog operations in Section 3.
对于这些组件中的许多组件，还需要发现它们的功能，例如，查询混合器主持10对话会议或为特定时间保留资源的能力。这些动作可以以URI的形式提供，前提是有一种先验的方法来理解它们的语义。例如，如果有一个已发布的操作字典，一种查询服务中可用操作和关联URI的方法，则URI可以是提供这些服务操作的接口。在第3节的对话操作上下文中，将更详细地描述此概念。
Media intermediaries are not participants in any conversation space, although an entity that is also a media translator may also have a co-located participant component (for example, a mixer that also announces the arrival of a new participant; the announcement portion is a participant, but the mixer itself is not). Media intermediaries should be as transparent as possible to the end users -- offering a useful, fundamental service without getting in the way of new features implemented by participants. Some common media intermediaries are described below.
媒体中间人不是任何对话空间中的参与者，尽管同时也是媒体翻译人员的实体也可能具有共同定位的参与者组件（例如，也宣布新参与者到达的混合器；宣布部分是参与者，但混合器本身不是）。媒体中介应该对最终用户尽可能透明——提供有用的基本服务，而不妨碍参与者实现新功能。下面介绍一些常见的媒体中介。
A SIP mixer is a component that combines media from all dialogs in the same conversation in a media-specific way. For example, the default combining for an audio conference might be an N-1 configuration, while a text mixer might interleave text messages on a per-line basis. More details about how to manipulate the media policy used by mixers is discussed in [XCON-CCMP].
SIP混合器是一个组件，它以特定于媒体的方式将来自同一对话中所有对话的媒体组合在一起。例如，音频会议的默认组合可能是N-1配置，而文本混合器可能在每行的基础上交错文本消息。[XCON-CCMP]中讨论了有关如何操作混音器使用的媒体策略的更多详细信息。
A transcoder translates media from one encoding or format to another (for example, GSM (Global System for Mobile communications) voice to G.711, MPEG2 to H.261, or text/html to text/plain), or from one media type to another (for example, text to speech). A more thorough discussion of transcoding is described in the SIP transcoding services invocation [RFC5369].
转码器将媒体从一种编码或格式转换为另一种编码或格式（例如，GSM（全球移动通信系统）语音转换为G.711，MPEG2转换为H.261，或text/html转换为text/plain），或从一种媒体类型转换为另一种媒体类型（例如，文本转换为语音）。SIP代码转换服务调用[RFC5369]中描述了对代码转换的更深入的讨论。
A media relay terminates media and simply forwards it to a new destination without changing the content in any way. Sometimes, media relays are used to provide source IP address anonymity, to facilitate middlebox traversal, or to provide a trusted entity where media can be forcefully disconnected.
媒体中继终止媒体并将其转发到新的目的地，而不以任何方式更改内容。有时，媒体中继用于提供源IP地址匿名性、促进中间盒遍历或提供可强制断开媒体连接的可信实体。
A queue server is a location where calls can be entered into one of several FIFO (first-in, first-out) queues. A queue server would subscribe to the presence of groups or individuals who are interested in its queues. When detecting that a user is available to service a queue, the server redirects or transfers the last call in the relevant queue to the available user. On a queue-by-queue basis, authorized users could also subscribe to the call state (dialog information) of calls within a queue. Authorized users could use this information to effectively pluck (take) a call out of the queue (for example, by sending an INVITE with a Replaces header to one of the user agents in the queue).
队列服务器是一个可以将呼叫输入多个FIFO（先进先出）队列之一的位置。队列服务器将订阅对其队列感兴趣的组或个人的存在。当检测到一个用户可以为队列提供服务时，服务器会将相关队列中的最后一个呼叫重定向或转移给可用用户。在逐个队列的基础上，授权用户还可以订阅队列中呼叫的呼叫状态（对话框信息）。授权用户可以使用此信息有效地从队列中提取（接受）呼叫（例如，通过向队列中的一个用户代理发送带有Replaces头的INVITE）。
A parking place is a location where calls can be terminated temporarily and then retrieved later. While a call is "parked", it can receive media "on hold" such as music, announcements, or advertisements. Such a service could be further decomposed such that announcements or music are handled by a separate component.
停车场是一个可以暂时终止呼叫，然后稍后再检索的位置。当电话处于“暂停”状态时，它可以接收“暂停”媒体，如音乐、公告或广告。这样的服务可以进一步分解，以便公告或音乐由单独的组件处理。
An announcement server is a server that can play digitized media (frequently audio), such as music or recorded speech. These servers are typically accessible via SIP, HTTP (Hyper Text Transport Protocol), or RTSP (Real-Time Streaming Protocol). An analogous service is a recording service that stores digitized media. A convention for specifying announcements in SIP URIs is described in [RFC4240]. Likewise, the same server could easily provide a service that records digitized media.
公告服务器是可以播放数字化媒体（通常是音频）的服务器，如音乐或录制的语音。这些服务器通常可以通过SIP、HTTP（超文本传输协议）或RTSP（实时流协议）访问。类似服务是存储数字化媒体的录制服务。[RFC4240]中描述了在SIP URI中指定公告的约定。同样，同一台服务器可以轻松提供记录数字化媒体的服务。
A "voice dialog" is a model of spoken interactive behavior between a human and an automaton that can include synthesized speech, digitized audio, recognition of spoken and DTMF key input, a recording of spoken input, and interaction with call control. Voice dialogs frequently consist of forms or menus. Forms present information and gather input; menus offer choices of what to do next.
“语音对话”是人与自动机之间的语音交互行为模型，包括合成语音、数字化音频、语音和DTMF键输入识别、语音输入录制以及与呼叫控制的交互。语音对话框通常由窗体或菜单组成。表格呈现信息并收集输入；菜单提供了下一步操作的选择。
Spoken dialogs are a basic building block of applications that use voice. Consider, for example, that a voicemail system, the conference-id and passcode collection system for a conferencing system, and complicated voice-portal applications all require a voice-dialog component.
语音对话框是使用语音的应用程序的基本构建块。例如，考虑会议系统的语音邮件系统、会议ID和密码收集系统以及复杂的语音门户应用程序都需要语音对话组件。
Text-to-speech (TTS) is a service that converts text into digitized audio. TTS is frequently integrated into other applications, but when separated as a component, it provides greater opportunity for broad reuse. Automatic Speech Recognition (ASR) is a service that attempts to decipher digitized speech based on a proposed grammar. Like TTS, ASR services can be embedded, or exposed so that many applications can take advantage of such services. A standardized (decomposed) interface to access standalone TTS and ASR services is currently being developed as described in [RFC4313].
文本到语音（TTS）是一种将文本转换为数字化音频的服务。TTS经常集成到其他应用程序中，但当作为一个组件分离时，它提供了更广泛的重用机会。自动语音识别（ASR）是一种尝试根据建议的语法对数字化语音进行解码的服务。与TTS一样，ASR服务可以嵌入或公开，以便许多应用程序可以利用这些服务。如[RFC4313]所述，目前正在开发用于访问独立TTS和ASR服务的标准化（分解）接口。
VoiceXML is a W3C (World Wide Web Consortium) recommendation that was designed to give authors control over the spoken dialog between users and applications. The application and user take turns speaking: the application prompts the user, and the user in turn responds. Its major goal is to bring the advantages of web-based development and content delivery to interactive voice-response applications. We believe that VoiceXML represents the ideal partner for SIP in the development of distributed IVR (interactive voice response) servers. VoiceXML is an XML-based scripting language for describing IVR services at an abstract level. VoiceXML supports DTMF recognition,
VoiceXML是W3C（万维网联盟）的建议，旨在让作者控制用户和应用程序之间的对话。应用程序和用户轮流发言：应用程序提示用户，用户依次响应。其主要目标是将基于web的开发和内容交付的优势引入交互式语音响应应用程序。我们相信VoiceXML代表了SIP在开发分布式IVR（交互式语音响应）服务器方面的理想合作伙伴。VoiceXML是一种基于XML的脚本语言，用于在抽象级别描述IVR服务。VoiceXML支持DTMF识别，
speech recognition, text-to-speech, and the playing out of recorded media files. The results of the data collected from the user are passed to a controlling entity through an HTTP POST operation. The controller can then return another script, or terminate the interaction with the IVR server.
语音识别、文本到语音转换以及播放录制的媒体文件。从用户收集的数据的结果通过HTTP POST操作传递给控制实体。然后，控制器可以返回另一个脚本，或终止与IVR服务器的交互。
A VoiceXML server also need not be implemented as a monolithic server. Figure 4 shows a diagram of a VoiceXML browser that is split into media and non-media handling parts. The VoiceXML interpreter handles SIP dialog state and state within a VoiceXML document, and sends requests to the media component over another protocol.
VoiceXML服务器也不需要实现为单片服务器。图4显示了VoiceXML浏览器的示意图，该浏览器分为媒体和非媒体处理部分。VoiceXML解释器处理SIP对话框状态和VoiceXML文档中的状态，并通过另一个协议向媒体组件发送请求。
+-------------+
| |
| VoiceXML |
| Interpreter |
| (signaling) |
+-------------+
^ ^
| |
SIP | | RTSP
| |
| |
v v
+-------------+ +-------------+
| | | |
| SIP UA | RTP | RTSP Server |
| |<------>| (media) |
| | | |
+-------------+ +-------------+
+-------------+
| |
| VoiceXML |
| Interpreter |
| (signaling) |
+-------------+
^ ^
| |
SIP | | RTSP
| |
| |
v v
+-------------+ +-------------+
| | | |
| SIP UA | RTP | RTSP Server |
| |<------>| (media) |
| | | |
+-------------+ +-------------+
Figure 4. Decomposed VoiceXML Server
图4。分解的VoiceXML服务器
All naming in SIP uses URIs. URIs in SIP are used in a plethora of contexts: the Request-URI; Contact, To, From, and *-Info header fields; application/uri bodies; and embedded in email, web pages, instant messages, and ENUM records. The Request-URI identifies the user or service for which the call is destined.
SIP中的所有命名都使用URI。SIP中的URI用于过多的上下文：请求URI；联系人、收件人、发件人和*-信息标题字段；应用程序/uri机构；并嵌入电子邮件、网页、即时消息和枚举记录中。请求URI标识呼叫的目的地用户或服务。
SIP URIs embedded in informational SIP header fields, SIP bodies, and non-SIP content can also specify methods, special parameters, header fields, and even bodies. For example:
嵌入信息性SIP头字段、SIP正文和非SIP内容中的SIP URI还可以指定方法、特殊参数、头字段甚至正文。例如：
sip:bob@b.example.com;method=REFER?Refer-To=http://example.com/~alice
sip:bob@b.example.com;method=REFER?Refer-To=http://example.com/~alice
Throughout this document, we discuss call control primitive operations. One of the biggest problems is defining how these operations may be invoked. There are a number of ways to do this. One way is to define the primitives in the protocol itself such that SIP methods (for example, REFER) or SIP header fields (for example, Replaces) indicate a specific call control action. Another way to invoke call control primitives is to define a specific Request-URI naming convention. Either these conventions must be shared between the client (the invoker) and the server, or published by or on behalf of the server. The former involves defining URI construction techniques (e.g., URI parameters and/or token conventions) as proposed in [RFC4240]. The latter technique usually involves discovering the URI via a SIP event package, a web page, a business card, or an instant message. Yet, another means to acquire the URIs is to define a dictionary of primitives with well-defined semantics and provide a means to query the named primitives and corresponding URIs that may be invoked on the service or dialogs.
在本文档中，我们将讨论调用控制原语操作。最大的问题之一是定义如何调用这些操作。有很多方法可以做到这一点。一种方法是在协议本身中定义原语，以便SIP方法（例如，REFER）或SIP头字段（例如，Replaces）指示特定的呼叫控制操作。调用调用控制原语的另一种方法是定义特定的请求URI命名约定。这些约定必须在客户机（调用方）和服务器之间共享，或者由服务器发布或代表服务器发布。前者涉及定义[RFC4240]中提出的URI构造技术（例如，URI参数和/或令牌约定）。后一种技术通常涉及通过SIP事件包、网页、名片或即时消息发现URI。然而，获取uri的另一种方法是定义一个具有良好定义语义的原语词典，并提供一种查询已命名原语和可在服务或对话框上调用的相应uri的方法。
An address-of-record, or public SIP address, is a SIP (or Secure SIP (SIPS)) URI that points to a domain with a location service that can map the URI to set of Contact URIs where the user might be available. Typically, the Contact URIs are populated via registration.
记录地址或公共SIP地址是一个SIP（或安全SIP（SIPS））URI，它指向具有位置服务的域，该服务可以将URI映射到用户可能可用的联系人URI集。通常，通过注册来填充联系人URI。
Address-of-Record Contacts
记录联系人地址
sip:bob@biloxi.example.com -> sip:bob@babylon.biloxi.example.com:5060
sip:bbrown@mailbox.provider.example.net
sip:+1.408.555.6789@mobile.example.net
sip:bob@biloxi.example.com -> sip:bob@babylon.biloxi.example.com:5060
sip:bbrown@mailbox.provider.example.net
sip:+1.408.555.6789@mobile.example.net
Callee Capabilities [RFC3840] define a set of additional parameters to the Contact header field that define the characteristics of the user agent at the specified URI. For example, there is a mobility parameter that indicates whether the UA is fixed or mobile. When a user agent registers, it places these parameters in the Contact header fields to characterize the URIs it is registering. This allows a proxy for that domain to have information about the contact addresses for that user.
被调用者功能[RFC3840]为Contact header字段定义了一组附加参数，用于定义指定URI处用户代理的特征。例如，存在指示UA是固定的还是移动的移动参数。当用户代理注册时，它将这些参数放置在Contact header字段中，以描述它正在注册的URI。这允许该域的代理拥有有关该用户联系地址的信息。
When a caller sends a request, it can optionally request Caller Preferences [RFC3841] by including the Accept-Contact, Request-Disposition, and Reject-Contact header fields that request certain handling by the proxy in the target domain. These header fields contain preferences that describe the set of desired URIs to which the caller would like their request routed. The proxy in the target domain matches these preferences with the Contact characteristics originally registered by the target user. The target user can also
当调用者发送请求时，它可以选择性地请求调用者首选项[RFC3841]，包括接受联系人、请求处置和拒绝联系人头字段，这些字段请求目标域中的代理进行某些处理。这些标头字段包含描述调用方希望将其请求路由到的所需URI集的首选项。目标域中的代理将这些首选项与目标用户最初注册的联系人特征相匹配。目标用户还可以
choose to run arbitrarily complex "Find-me" feature logic on a proxy in the target domain.
选择在目标域中的代理上运行任意复杂的“查找我”功能逻辑。
There is a strong asymmetry in how preferences for callers and callees can be presented to the network. While a caller takes an active role by initiating the request, the callee takes a passive role in waiting for requests. This motivates the use of callee-supplied scripts and caller preferences included in the call request. This asymmetry is also reflected in the appropriate relationship between caller and callee preferences. A server for a callee should respect the wishes of the caller to avoid certain locations, while the preferences among locations has to be the callee's choice, as it determines where, for example, the phone rings and whether the callee incurs mobile telephone charges for incoming calls.
在如何向网络呈现呼叫者和被呼叫者的偏好方面存在着强烈的不对称性。调用方通过发起请求扮演主动角色，而被调用方在等待请求时扮演被动角色。这促使使用被调用方提供的脚本和调用方首选项，包括在调用请求中。这种不对称也反映在呼叫者和被呼叫者偏好之间的适当关系中。被呼叫者的服务器应尊重呼叫者避开某些位置的意愿，而位置之间的首选项必须是被呼叫者的选择，因为它确定电话铃响的位置，以及被呼叫者是否会对来电收取移动电话费。
SIP User Agent implementations are encouraged to make intelligent decisions based on the type of participants (active/passive, hidden, human/robot) in a conversation space. This information is conveyed via the dialog package or in a SIP header field parameter communicated using an appropriate SIP header field. For example, a music on hold service may take the sensible approach that if there are two or more unhidden participants, it should not provide hold music; or that it will not send hold music to robots.
鼓励SIP用户代理实现根据会话空间中参与者的类型（主动/被动、隐藏、人/机器人）做出智能决策。该信息通过对话包或使用适当的SIP头字段传递的SIP头字段参数传递。例如，音乐保留服务可能采取明智的做法，即如果有两个或两个以上未隐藏的参与者，则不应提供保留音乐；或者它不会向机器人发送hold音乐。
Multiple participants in the same conversation space may represent the same human user. For example, the user may use one participant device for video, chat, and whiteboard media on a PC and another for audio media on a SIP phone. In this case, the address-of-record is the same for both user agents, but the Contacts are different. In this case, there is really only one human participant. In addition, human users may add robot participants that act on their behalf (for example, a call recording service or a calendar announcement reminder). Call control features in SIP should continue to function as expected in such an environment.
同一对话空间中的多个参与者可能代表同一人类用户。例如，用户可以使用一个参与设备在PC上进行视频、聊天和白板媒体，使用另一个参与设备在SIP电话上进行音频媒体。在这种情况下，两个用户代理的记录地址相同，但联系人不同。在这种情况下，实际上只有一个人类参与者。此外，人类用户可以添加代表其行事的机器人参与者（例如，通话记录服务或日历公告提醒）。SIP中的呼叫控制功能应该在这样的环境中继续发挥预期的作用。
A critical piece of defining a session-level service that can be accessed by SIP is defining the naming of the resources within that service. This point cannot be overstated.
定义可由SIP访问的会话级服务的一个关键部分是定义该服务中资源的命名。这一点怎么强调也不过分。
In the context of SIP control of application components, we take advantage of the fact that the left-hand side of a standard SIP URI is a user part. Most services may be thought of as user automatons that participate in SIP sessions. It naturally follows that the user part should be utilized as a service indicator.
在应用程序组件的SIP控制上下文中，我们利用了一个事实，即标准SIPURI的左侧是用户部分。大多数服务可能被认为是参与SIP会话的用户自动机。自然地，用户部件应该被用作服务指示器。
For example, media servers commonly offer multiple services at a single host address. Use of the user part as a service indicator enables service consumers to direct their requests without ambiguity. It has the added benefit of enabling media services to register their availability with SIP Registrars just as any "real" SIP user would. This maintains consistency and provides enhanced flexibility in the deployment of media services in the network.
例如，媒体服务器通常在一个主机地址提供多个服务。使用用户部分作为服务指示符使服务使用者能够无歧义地引导他们的请求。它还有一个额外的好处，即使媒体服务能够像任何“真正的”SIP用户一样向SIP注册器注册它们的可用性。这保持了一致性，并增强了在网络中部署媒体服务的灵活性。
There has been much discussion about the potential for confusion if media-service URIs are not readily distinguishable from other types of SIP UAs. The use of a service namespace provides a mechanism to unambiguously identify standard interfaces while not constraining the development of private or experimental services.
如果媒体服务URI不能很容易地与其他类型的SIP UA区分开来，那么就有可能出现混淆，对此已经进行了很多讨论。服务名称空间的使用提供了一种明确标识标准接口的机制，同时不限制私有或实验服务的开发。
In SIP, the Request-URI identifies the user or service for which the call is destined. The great advantage of using URIs (specifically, the SIP Request-URI) as a service identifier comes because of the combination of two facts. First, unlike in the PSTN (Public Switched Telephone Network), where the namespace (dialable telephone numbers) is limited, URIs come from an infinite space. They are plentiful, and they are free. Secondly, the primary function of SIP is call routing through manipulations of the Request-URI. In the traditional SIP application, this URI represents a person. However, the URI can also represent a service, as we propose here. This means we can apply the routing services SIP provides to the routing of calls to services. The result -- the problem of service invocation and service location becomes a routing problem, for which SIP provides a scalable and flexible solution. Since there is such a vast namespace of services, we can explicitly name each service in a finely granular way. This allows the distribution of services across the network. For further discussion about services and SIP URIs, see RFC 3087 [RFC3087].
在SIP中，请求URI标识呼叫目的地的用户或服务。使用URI（特别是SIP请求URI）作为服务标识符的最大优势在于两个事实的结合。首先，与PSTN（公共交换电话网）中的命名空间（可拨打电话号码）有限不同，URI来自无限空间。它们很丰富，而且是免费的。第二，SIP的主要功能是通过操作请求URI进行呼叫路由。在传统的SIP应用程序中，此URI表示一个人。然而，URI也可以表示服务，正如我们在这里提出的那样。这意味着我们可以将SIP提供的路由服务应用于呼叫到服务的路由。结果——服务调用和服务位置问题变成了一个路由问题，SIP为此提供了一个可扩展且灵活的解决方案。由于存在如此庞大的服务名称空间，我们可以以精细粒度的方式显式命名每个服务。这允许跨网络分发服务。有关服务和SIP URI的进一步讨论，请参阅RFC 3087[RFC3087]。
Consider a conferencing service, where we have separated the names of ad hoc conferences from scheduled conferences, we can program proxies to route calls for ad hoc conferences to one set of servers and calls for scheduled ones to another, possibly even in a different provider. In fact, since each conference itself is given a URI, we can distribute conferences across servers, and easily guarantee that calls for the same conference always get routed to the same server. This is in stark contrast to conferences in the telephone network, where the equivalent of the URI -- the phone number -- is scarce. An entire conferencing provider generally has one or two numbers. Conference IDs must be obtained through IVR interactions with the caller or through a human attendant. This makes it difficult to distribute conferences across servers all over the network, since the PSTN routing only knows about the dialed number.
考虑会议服务，在这里我们已经将特设会议的名称与预定会议分开，我们可以将代理程序路由到特定会议的路由到一组服务器，并调用预定的会议到另一组，甚至可能在不同的提供者中。事实上，由于每个会议本身都有一个URI，因此我们可以跨服务器分发会议，并轻松保证对同一会议的调用始终路由到同一服务器。这与电话网络中的会议形成了鲜明的对比，在电话网络中，相当于URI的电话号码很少。整个会议提供商通常有一个或两个号码。会议ID必须通过与呼叫方的IVR交互或通过人工助理获得。由于PSTN路由只知道拨号号码，因此很难在整个网络的服务器上分发会议。
For more examples, consider the URI conventions of RFC 4240 [RFC4240] for media servers and RFC 4458 [RFC4458] for voicemail and IVR systems.
对于更多的例子，考虑用于媒体服务器的RFC 4240 [RFC4240]的URI约定和用于语音邮件和IVR系统的RFC 4458 [RFC4358]。
In practical applications, it is important that an invoker does not necessarily apply semantic rules to various URIs it did not create. Instead, it should allow any arbitrary string to be provisioned, and map the string to the desired behavior. The administrator of a service may choose to provision specific conventions or mnemonic strings, but the application should not require it. In any large installation, the system owner is likely to have preexisting rules for mnemonic URIs, and any attempt by an application to define its own rules may create a conflict. Implementations should allow an arbitrary mix of URIs from these schemes, or any other scheme that renders valid SIP URIs, rather than enforce only one particular scheme.
在实际应用中，重要的是调用程序不一定要将语义规则应用于它没有创建的各种URI。相反，它应该允许设置任意字符串，并将该字符串映射到所需的行为。服务的管理员可以选择提供特定的约定或助记符字符串，但应用程序不应该需要它。在任何大型安装中，系统所有者都可能拥有先前存在的助记符URI规则，应用程序试图定义自己的规则可能会产生冲突。实现应该允许来自这些方案的URI的任意混合，或者呈现有效SIPURI的任何其他方案，而不是只强制执行一个特定方案。
As we have shown, SIP URIs represent an ideal, flexible mechanism for describing and naming service resources, regardless of whether the resources are queues, conferences, voice dialogs, announcements, voicemail treatments, or phone features.
如我们所示，SIPURI代表了一种理想、灵活的机制，用于描述和命名服务资源，而不管资源是队列、会议、语音对话框、公告、语音邮件处理还是电话功能。
With functional signaling, only the invoker of features in SIP needs to know exactly which feature they are invoking. One of the primary benefits of this approach is that combinations of functional features work in SIP call control without requiring complex feature-interaction matrices. For example, let us examine the combination of a "transfer" of a call that is "conferenced".
对于功能性信令，只有SIP中功能的调用者需要确切地知道他们正在调用哪个功能。这种方法的主要优点之一是功能特性的组合在SIP呼叫控制中工作，而不需要复杂的特性交互矩阵。例如，让我们检查“conferenced”呼叫的“transfer”组合。
Alice calls Bob. Alice silently "conferences in" her robotic assistant Albert as a hidden party. Bob transfers Alice to Carol. If Bob asks Alice to Replace her leg with a new one to Carol, then both Alice and Albert should be communicating with Carol (transparently).
爱丽丝打电话给鲍勃。爱丽丝默默地“会议”在她的机器人助手阿尔伯特身上作为一个隐藏的聚会。鲍勃把爱丽丝转给卡罗尔。如果Bob要求Alice给Carol换一条新腿，那么Alice和Albert都应该（透明地）与Carol沟通。
Using the peer-to-peer model, this combination of features works fine if A is doing local mixing (Alice replaces Bob's dialog with Carol's), or if A is using a central mixer (the mixer replaces Bob's dialog with Carol's). A clever implementation using the 3pcc model can generate similar results.
使用点对点模型，如果A正在进行本地混合（Alice将Bob的对话框替换为Carol的），或者如果A正在使用中央混合器（混合器将Bob的对话框替换为Carol的），则这种功能组合可以很好地工作。使用3pcc模型的巧妙实现可以产生类似的结果。
New extensions to the SIP Call Control Framework should attempt to preserve this property.
SIP呼叫控制框架的新扩展应尝试保留此属性。
Billing in the PSTN is typically based on who initiated a call. At the moment, billing in a SIP network is neither consistent with itself nor with the PSTN. (A billing model for SIP should allow for both PSTN-style billing and non-PSTN billing.) The example below demonstrates one such inconsistency.
PSTN中的计费通常基于发起呼叫的人。目前，SIP网络中的计费既不与自身一致，也不与PSTN一致。（SIP的计费模型应同时考虑PSTN类型的计费和非PSTN计费。）下面的示例演示了这样一种不一致性。
Alice places a call to Bob. Alice then blind transfers Bob to Carol through a PSTN gateway. In current usage of REFER, Bob may be billed for a call he did not initiate (his UA originated the outgoing dialog, however). This is not necessarily a terrible thing, but it demonstrates a security concern (Bob must have appropriate local policy to prevent fraud). Also, Alice may wish to pay for Bob's session with Carol. There should be a way to signal this in SIP.
爱丽丝打电话给鲍勃。Alice然后通过PSTN网关将Bob传送给Carol。在当前的REFER用法中，Bob可能会为一个他没有发起的呼叫付费（然而，他的UA发起了传出对话框）。这不一定是一件可怕的事情，但它表明了一个安全问题（Bob必须有适当的本地政策来防止欺诈）。此外，Alice可能希望支付Bob与Carol的会面费用。应该有一种方法在SIP中发出信号。
Likewise, a Replacement call may maintain the same billing relationship as a Replaced call, so if Alice first calls Carol, then asks Bob to Replace this call, Alice may continue to receive a bill.
同样，替换呼叫可能与替换呼叫保持相同的计费关系，因此，如果Alice先打电话给Carol，然后要求Bob替换此呼叫，Alice可能会继续收到账单。
Further work in SIP billing should define a way to set or discover the direction of billing.
SIP计费的进一步工作应定义设置或发现计费方向的方法。
Call control actions can be categorized by the dialogs upon which they operate. The actions may involve a single or multiple dialogs. These dialogs can be early or established. Multiple dialogs may be related in a conversation space to form a conference or other interesting media topologies.
调用控制操作可以按其操作的对话框进行分类。这些操作可能涉及一个或多个对话框。这些对话框可以是早期的，也可以是已建立的。多个对话可能在对话空间中相互关联，以形成会议或其他有趣的媒体拓扑。
It should be noted that it is desirable to provide a means by which a party can discover the actions that may be performed on a dialog. The interested party may be independent or related to the dialogs. One means of accomplishing this is through the ability to define and obtain URIs for these actions, as described in Section 2.7.2.
应当注意的是，希望提供一种方法，使一方能够发现可能在对话中执行的动作。相关方可能是独立的或与对话相关的。实现这一点的一种方法是通过定义和获取这些操作的URI，如第2.7.2节所述。
Below are listed several call control "actions" that establish or modify dialogs and relate the participants in a conversation space. The names of the actions listed are for descriptive purposes only (they are not normative). This list of actions is not meant to be exhaustive.
下面列出了几个呼叫控制“动作”，用于建立或修改对话，并将参与者与对话空间联系起来。所列行动的名称仅用于说明目的（它们不是规范性的）。本行动清单并非详尽无遗。
In the examples, all actions are initiated by the user "Alice" represented by UA "A".
在示例中，所有操作都由用户“Alice”发起，用户“Alice”由UA“A”表示。
The following are a set of actions that may be performed on a single early dialog. These actions can be thought of as a set of remote control operations. For example, an automaton might perform the operation on behalf of a user. Alternatively, a user might use the remote control in the form of an application to perform the action on the early dialog of a UA that may be out of reach. All of these actions correspond to telling the UA how to respond to a request to establish an early dialog. These actions provide useful functionality for PDA-, PC-, and server-based applications that desire the ability to control a UA. A proposed mechanism for this type of functionality is described in remote call control [FEATURE-REF].
以下是可以在单个早期对话框上执行的一组操作。这些操作可以看作是一组远程控制操作。例如，自动机可能代表用户执行操作。或者，用户可以以应用程序的形式使用遥控器对可能无法触及的UA的早期对话框执行操作。所有这些动作都对应于告诉UA如何响应建立早期对话的请求。这些操作为需要控制UA的基于PDA、PC和服务器的应用程序提供了有用的功能。远程呼叫控制[FEATURE-REF]中描述了此类功能的拟议机制。
A dialog is in some early dialog state such as 180 Ringing. It may be desirable to tell the UA to answer the dialog. That is, tell it to send a 200 OK response to establish the dialog.
对话框处于某些早期对话框状态，如180响。可能需要通知UA回答该对话框。也就是说，告诉它发送200 OK响应以建立对话框。
It may be desirable to tell the UA to respond with a 3xx class response to forward an early dialog to another UA.
可能需要告诉UA使用3xx类响应来响应，以便将早期对话转发给另一个UA。
It may be desirable to instruct the UA to send an error response such as 486 Busy Here.
可能需要指示UA发送诸如486 Busy之类的错误响应。
There is another useful set of actions that operate on a single established dialog. These operations are useful in building productivity applications for aiding users in controlling their phones. For example, a Customer Relationship Management (CRM) application that sets up calls for a user eliminating the need for the user to actually enter an address. These operations can also be thought of as remote control actions. A proposed mechanism for this type of functionality is described in remote call control [FEATURE-REF].
还有另一组对单个已建立的对话框进行操作的有用操作。这些操作有助于构建生产力应用程序，帮助用户控制手机。例如，客户关系管理（CRM）应用程序为用户建立呼叫，而不需要用户实际输入地址。这些操作也可以被视为远程控制操作。远程呼叫控制[FEATURE-REF]中描述了此类功能的拟议机制。
This action instructs the UA to initiate a dialog. This action can be performed using the REFER method.
此操作指示UA启动对话。可以使用REFER方法执行此操作。
This action instructs the UA to put an established dialog on hold. Though this operation can conceptually be performed with the REFER method, there are no semantics defined as to what the referred party should do with the SDP. There is no way to distinguish between the desire to go on or off hold on a per-media stream basis.
此操作指示UA暂停已建立的对话。虽然这个操作在概念上可以用refere方法执行，但是对于被引用方应该用SDP做什么，没有定义语义。在每个媒体流的基础上，无法区分是否希望继续保持。
This action instructs the UA to terminate an early or established dialog. A REFER request with the following Refer-To URI and Target-Dialog header field [RFC4538] performs this action. Note: this example does not show the full set of header fields.
此操作指示UA终止早期或已建立的对话。具有以下引用URI和目标对话框标题字段[RFC4538]的引用请求执行此操作。注意：此示例未显示完整的标题字段集。
REFER sip:carol@client.chicago.net SIP/2.0
Refer-To: sip:bob@babylon.biloxi.example.com;method=BYE
Target-Dialog: 13413098;local-tag=879738;remote-tag=023214
REFER sip:carol@client.chicago.net SIP/2.0
Refer-To: sip:bob@babylon.biloxi.example.com;method=BYE
Target-Dialog: 13413098;local-tag=879738;remote-tag=023214
These actions apply to a set of related dialogs.
这些操作适用于一组相关对话框。
This section describes how call transfer can be achieved using centralized (3pcc) and peer-to-peer (REFER) approaches.
本节介绍如何使用集中式（3pcc）和点对点（REFER）方法实现呼叫转移。
The conversation space changes as follows:
对话空间的变化如下：
before after
{ A , B } --> { C , B }
before after
{ A , B } --> { C , B }
A replaces itself with C.
A用C替换自己。
To make this happen using the peer-to-peer approach, "A" would send two SIP requests. A shorthand for those requests is shown below:
为了使用对等方法实现这一点，“A”将发送两个SIP请求。这些请求的简写如下所示：
REFER B Refer-To:C BYE B
参考B参考：C再见
To make this happen using the 3pcc approach instead, the controller sends requests represented by the shorthand below:
为了使用3pcc方法实现这一点，控制器发送以下速记形式的请求：
INVITE C (w/SDP of B) reINVITE B (w/SDP of C) BYE A
邀请C（带SDP的B）再次邀请B（带SDP的C）再见A
Features enabled by this action:
此操作启用的功能：
- blind transfer - transfer to a central mixer (some type of conference or forking) - transfer to park server (park) - transfer to music on hold or announcement server - transfer to a "queue" - transfer to a service (such as voice-dialog service) - transition from local mixer to central mixer
- 盲传输-传输到中央混音器（某种类型的会议或分叉）-传输到公园服务器（公园）-传输到音乐保留或公告服务器-传输到“队列”-传输到服务（如语音对话服务）-从本地混音器转换到中央混音器
This action is frequently referred to as "completing an attended transfer". It is described in more detail in [RFC5589].
此操作通常被称为“完成有人值守的转移”。[RFC5589]对其进行了更详细的描述。
Note that if a transfer requires URI hiding or privacy, then the 3pcc approach can more easily implement this. For example, if the URI of C needs to be hidden from B, then the use of 3pcc helps accomplish this.
注意，如果传输需要URI隐藏或隐私，那么3pcc方法可以更容易地实现这一点。例如，如果需要对B隐藏C的URI，那么使用3pcc有助于实现这一点。
The conversation space changes as follows:
对话空间的变化如下：
{ B , C } --> { B , A }
{ B , C } --> { B , A }
A forcibly replaces C with itself. In most uses of this primitive, A is just "un-replacing" itself.
A强制用自身替换C。在这个原语的大多数用法中，A只是“不替换”本身。
Using the peer-to-peer approach, "A" sends:
使用点对点方法，“A”发送：
INVITE B Replaces: <dialog between B and C>
INVITE B Replaces: <dialog between B and C>
Using the 3pcc approach (all requests sent from controller):
使用3pcc方法（从控制器发送的所有请求）：
INVITE A (w/SDP of B) reINVITE B (w/SDP of A) BYE C
邀请A（带SDP的B）再次邀请B（带SDP的A）再见C
Features enabled by this action:
此操作启用的功能：
- transferee completes an attended transfer - retrieve from central mixer (not recommended) - retrieve from music on hold or park - retrieve from queue - call center take - voice portal resuming ownership of a call it originated - answering-machine style screening (pickup) - pickup of a ringing call (i.e., early dialog)
- 受让人完成有人值守转接-从中央调音台取回（不推荐）-从暂停音乐或停车场取回-从队列取回-呼叫中心取回-语音门户恢复其发起呼叫的所有权-应答机式筛选（取回）-接听来电（即，提前对话）
Note that pick up of a ringing call has perhaps some interesting additional requirements. First of all, it is an early dialog as opposed to an established dialog. Secondly, the party that is to pick up the call may only wish to do so only while it is an early dialog. That is in the race condition where the ringing UA accepts just before it receives signaling from the party wishing to take the call, the taking party wishes to yield or cancel the take. The goal is to avoid yanking an answered call from the called party.
请注意，接听来电可能有一些有趣的附加要求。首先，这是一个早期的对话，而不是一个已建立的对话。第二，接听电话的一方可能只希望在提前对话时接听。也就是说，在竞争条件下，振铃UA在接收到来自希望接听呼叫的一方的信令之前接受，接听方希望放弃或取消接听。这样做的目的是避免从被叫方接到应答电话。
This action is described in Replaces [RFC3891] and in [RFC5589].
此操作在[RFC3891]和[RFC5589]中进行了说明。
Note that the following four actions are described in [RFC4579].
请注意，[RFC4579]中描述了以下四个操作。
This is merely adding a participant to a SIP conference. The conversation space changes as follows:
这仅仅是将参与者添加到SIP会议。对话空间的变化如下：
{ A , B } --> { A , B , C }
{ A , B } --> { A , B , C }
A adds C to the conversation.
A在对话中添加C。
Using the peer-to-peer approach, adding a party using local mixing requires no signaling. To transition from a two-party call or a locally mixed conference to central mixing, A could send the following requests:
使用对等方法，添加使用本地混合的一方不需要信令。要从两方通话或本地混音会议过渡到中央混音，a可以发送以下请求：
REFER B Refer-To: conference-URI INVITE conference-URI BYE B
参考B参考：会议URI邀请会议URI再见B
To add a party to a conference:
要向会议添加参与方，请执行以下操作：
REFER C Refer-To: conference-URI or REFER conference-URI Refer-To: C
参考C参考：会议URI或参考会议URI参考：C
Using the 3pcc approach to transition to centrally mixed, the controller would send:
使用3pcc方法过渡到集中混合，控制器将发送：
INVITE mixer leg 1 (w/SDP of A) INVITE mixer leg 2 (w/SDP of B) INVITE C (late SDP) reINVITE A (w/SDP of mixer leg 1) reINVITE B (w/SDP of mixer leg 2) INVITE mixer leg3 (w/SDP of C)
邀请搅拌机支腿1（带A的SDP）邀请搅拌机支腿2（带B的SDP）邀请C（晚SDP）重新邀请A（带搅拌机支腿1的SDP）重新邀请B（带搅拌机支腿2的SDP）邀请搅拌机支腿3（带C的SDP）
To add a party to a SIP conference:
要将参与方添加到SIP会议，请执行以下操作：
INVITE C (late SDP) INVITE conference-URI (w/SDP of C)
邀请C（后期SDP）邀请会议URI（w/SDP of C）
Features enabled:
启用的功能：
- standard conference feature - call recording - answering-machine style screening (screening)
- 标准会议功能-通话录音-答录机式屏蔽（屏蔽）
The conversation space changes like this:
对话空间的变化如下：
{ A , B } , { A , C } --> { A , B , C }
{ A , B } , { A , C } --> { A , B , C }
or like this
还是像这样
{ A , B } , { C , D } --> { A , B , C , D }
{ A , B } , { C , D } --> { A , B , C , D }
A takes two conversation spaces and joins them together into a single space.
A占用两个对话空间，并将它们连接到一个单独的空间中。
Using the peer-to-peer approach, A can mix locally, or REFER the participants of both conversation spaces to the same central mixer (as in Section 3.3.5).
使用点对点方法，A可以在本地混合，或者将两个对话空间的参与者推荐给同一个中央混合器（如第3.3.5节所述）。
For the 3pcc approach, the call flows for inserting participants, and joining and splitting conversation spaces are tedious yet straightforward, so these are left as an exercise for the reader.
对于3pcc方法，用于插入参与者、加入和分割对话空间的调用流既繁琐又简单，因此留给读者作为练习。
Features enabled:
启用的功能：
- standard conference feature - leaving a sidebar to rejoin a larger conference
- 标准会议功能-留下侧边栏重新加入更大的会议
The conversation space changes like this:
对话空间的变化如下：
{ B , C } --> { A , B , C }
{ B , C } --> { A , B , C }
A inserts itself into a conversation space.
A将自身插入对话空间。
A proposed mechanism for signaling this using the peer-to-peer approach is to send a new header field in an INVITE with "joining" [RFC3911] semantics. For example:
使用点对点方法发出此信号的一种建议机制是在INVITE中发送一个具有“加入”[RFC3911]语义的新头字段。例如：
INVITE B Join: <dialog id of B and C>
INVITE B Join: <dialog id of B and C>
If B accepted the INVITE, B would accept responsibility to set up the dialogs and mixing necessary (for example, to mix locally or to transfer the participants to a central mixer).
如果B接受邀请，B将负责设置对话和必要的混音（例如，本地混音或将参与者转移到中央混音器）。
Features enabled:
启用的功能：
- barge-in - call center monitoring - call recording
- 驳船进港-呼叫中心监控-呼叫记录
{ A , B , C , D } --> { A , B } , { C , D }
{ A , B , C , D } --> { A , B } , { C , D }
If using a central conference with peer-to-peer
如果使用具有点对点的中心会议
REFER C Refer-To: conference-URI (new URI) REFER D Refer-To: conference-URI (new URI) BYE C BYE D
参考C参考：会议URI（新URI）参考D参考：会议URI（新URI）再见
Features enabled:
启用的功能：
- sidebar conversations during a larger conference
- 大型会议期间的侧边栏对话
A participates in two conversation spaces simultaneously:
A同时参与两个对话空间：
{ A, B } --> { B , A } & { A , C }
{ A, B } --> { B , A } & { A , C }
A is a participant in two conversation spaces such that A sends the same media to both spaces, and renders media from both spaces, presumably by mixing or rendering the media from both. We can define that A is the "anchor" point for both forks, each of which is a separate conversation space.
A是两个对话空间中的参与者，因此A向两个空间发送相同的媒体，并渲染两个空间中的媒体，可能是通过混合或渲染两个空间中的媒体。我们可以定义A是两个分叉的“锚”点，每个分叉都是一个单独的对话空间。
This action is purely local implementation (it requires no special signaling). Local features such as switching calls between the background and foreground are possible using this media relationship.
此操作纯粹是本地实现（不需要特殊的信令）。使用此媒体关系，可以在后台和前台之间切换呼叫等本地功能。
The conversation space diagram.
对话空间图。
{ A, B } --> { A , B } & { B , C }
{ A, B } --> { A , B } & { B , C }
A requests B to be the "anchor" of two conversation spaces.
A要求B成为两个对话空间的“锚”。
This is easily set up by creating a conference with two sub-conferences and setting the media policy appropriately such that B is a participant in both. Media forking can also be set up using 3pcc, as described in Section 5.1 of RFC 3264 [RFC3264] (an offer/answer model for SDP). The session descriptions for forking are quite complex. Controllers should verify that endpoints can handle forked media, for example, using prior configuration.
通过创建一个包含两个子会议的会议，并适当设置媒体策略，使B同时参与这两个会议，就可以轻松地进行设置。也可以使用3pcc设置媒体分叉，如RFC 3264[RFC3264]（SDP的提供/应答模型）第5.1节所述。分叉的会话描述相当复杂。控制器应验证端点是否可以处理分叉介质，例如，使用先前的配置。
Features enabled:
启用的功能：
- barge-in - voice-portal services - whisper - key word detection - sending DTMF somewhere else
- 驳入-语音门户服务-耳语-关键字检测-将DTMF发送到其他地方
Call control primitives provide a powerful set of features that can be dangerous in the hands of an attacker. To complicate matters, call control primitives are likely to be automatically authorized without direct human oversight.
调用控制原语提供了一组强大的功能，这些功能在攻击者手中可能很危险。使事情复杂化的是，调用控制原语可能会在没有直接人工监督的情况下自动授权。
The class of attacks that are possible using these tools includes the ability to eavesdrop on calls, disconnect calls, redirect calls, render irritating content (including ringing) at a user agent, cause an action that has billing consequences, subvert billing (theft-of-service), and obtain private information. Call control extensions must take extra care to describe how these attacks will be prevented.
使用这些工具可能发生的攻击类型包括窃听呼叫、断开呼叫、重定向呼叫、在用户代理上呈现刺激性内容（包括铃声）、导致产生计费后果的行为、颠覆计费（盗用服务）和获取私人信息。呼叫控制扩展必须特别注意描述如何防止这些攻击。
We can also make some general observations about authorization and trust with respect to call control. The security model is dramatically dependent on the signaling model chosen (see Section 2.3)
我们还可以对呼叫控制的授权和信任进行一些一般性的观察。安全模型在很大程度上取决于所选的信令模型（见第2.3节）
Let us first examine the security model used in the 3pcc approach. All signaling goes through the controller, which is a trusted entity. Traditional SIP authentication and hop-by-hop encryption and message integrity work fine in this environment, but end-to-end encryption and message integrity may not be possible.
让我们首先检查3pcc方法中使用的安全模型。所有信令都通过控制器，控制器是一个受信任的实体。传统的SIP身份验证、逐跳加密和消息完整性在这种环境下工作良好，但端到端加密和消息完整性可能不可能实现。
When using the peer-to-peer approach, call control actions and primitives can be legitimately initiated by a) an existing participant in the conversation space, b) a former participant in the conversation space, or c) an entity trusted by one of the participants. For example, a participant always initiates a
使用对等方法时，呼叫控制操作和原语可以由a）会话空间中的现有参与者、b）会话空间中的前参与者或c）其中一个参与者信任的实体合法发起。例如，参与者总是发起
transfer; a retrieve from park (a take) is initiated on behalf of a former participant, and a barge-in (insert or far-fork) is initiated by a trusted entity (an operator, for example).
转移从停车场取回（take）是代表前参与者发起的，而驳船进港（insert或far fork）是由可信实体（例如，运营商）发起的。
Authenticating requests by an existing participant or a trusted entity can be done with baseline SIP mechanisms. In the case of features initiated by a former participant, these should be protected against replay attacks, e.g., by using a unique name or identifier per invocation. The Replaces header field exhibits this behavior as a by-product of its operation (once a Replaces operation is successful, the dialog being Replaced no longer exists). These credentials may, for example, need to be passed transitively or fetched in an event body.
现有参与者或受信任实体的身份验证请求可以通过基线SIP机制完成。对于前参与者发起的功能，应保护这些功能免受重播攻击，例如，每次调用使用唯一的名称或标识符。Replaces header字段将此行为显示为其操作的副产品（一旦Replaces操作成功，被替换的对话框将不再存在）。例如，这些凭证可能需要传递或在事件体中获取。
To authorize call control primitives that trigger special behavior (such as an INVITE with Replaces or Join semantics), the receiving user agent may have trouble finding appropriate credentials with which to challenge or authorize the request, as the sender may be completely unknown to the receiver, except through the introduction of a third party. These credentials need to be passed transitively in some way or fetched in an event body, for example.
为了授权触发特殊行为的呼叫控制原语（例如带有替换或加入语义的INVITE），接收用户代理可能无法找到适当的凭据来质疑或授权请求，因为接收方可能完全不知道发送方，除非通过引入第三方。例如，这些凭证需要以某种方式传递或在事件体中获取。
Standard SIP privacy and anonymity mechanisms such as [RFC3323] and [RFC3325] used during SIP session establishment apply equally well to SIP call control operations. SIP call control mechanisms should address privacy and anonymity issues associated with that operation. For example, privacy during a transfer operation using REFER is discussed in Section 7.2 of [RFC5589]
SIP会话建立期间使用的标准SIP隐私和匿名机制（如[RFC3323]和[RFC3325]）同样适用于SIP呼叫控制操作。SIP呼叫控制机制应解决与该操作相关的隐私和匿名性问题。例如，[RFC5589]第7.2节讨论了使用REFER进行传输操作期间的隐私问题
Primitives are defined in terms of their ability to provide features. These example features should require an amply robust set of services to demonstrate a useful set of primitives. They are described here briefly. Note that the descriptions of these features are non-normative. Note also that this document describes a mixture of both features originating in the world of telephones and features that are clearly Internet oriented.
基本体是根据其提供功能的能力来定义的。这些示例功能应该需要一组足够健壮的服务来演示一组有用的原语。这里简要地描述了它们。请注意，这些特征的描述是非规范性的。还请注意，本文档描述了源自电话世界的功能和明确面向互联网的功能的混合。
Appendix A.1. Attended Transfer
附录A.1。有人接送
In Attended Transfer [RFC5589], the transferring party establishes a session with the transfer target before completing the transfer.
在有人参与传输[RFC5589]中，传输方在完成传输之前与传输目标建立会话。
Appendix A.2. Auto Answer
附录A.2。自动应答
In Auto Answer, calls to a certain address or URI answer immediately via a speakerphone. The Answer-Mode header field [RFC5373] can be used for this feature.
在自动应答中，对某个地址或URI的呼叫通过扬声器立即应答。应答模式标题字段[RFC5373]可用于此功能。
Appendix A.3. Automatic Callback
附录A.3。自动回拨
In Automatic Callback [RFC5359], Alice calls Bob, but Bob is busy. Alice would like Bob to call her automatically when he is available. When Bob hangs up, Alice's phone rings. When Alice answers, Bob's phone rings. Bob answers and they talk.
在自动回调[RFC5359]中，Alice给Bob打电话，但Bob很忙。艾丽斯希望鲍勃有空时自动给她打电话。鲍勃挂断电话时，爱丽丝的电话响了。爱丽丝接电话时，鲍勃的电话响了。鲍勃回答，他们交谈。
Appendix A.4. Barge-In
附录A.4。中断功能
In Barge-in, Carol interrupts Alice who has an in-progress call with Bob. In some variations, Alice forcibly joins a new conversation with Carol, in other variations, all three parties are placed in the same conversation (basically a three-way conference). Barge-in works the same as call monitoring except that it must indicate that the send media stream be mixed so that all of the other parties can hear the stream from the UA that is barging in.
在闯入时，卡罗尔打断了爱丽丝的话，爱丽丝正在和鲍勃通话。在一些变体中，Alice强行加入与Carol的新对话，在其他变体中，所有三方都处于同一对话中（基本上是三方会谈）。驳入的工作原理与呼叫监控相同，只是它必须指示发送媒体流是混合的，以便所有其他方都能听到来自正在驳入的UA的流。
Appendix A.5. Blind Transfer
附录A.5。盲转移
In Blind Transfer [RFC5589], Alice is in a conversation with Bob. Alice asks Bob to contact Carol, but makes no attempt to contact Carol independently. In many implementations, Alice does not verify Bob's success or failure in contacting Carol.
在盲传输[RFC5589]中，Alice正在与Bob对话。爱丽丝要求鲍勃联系卡罗尔，但没有试图单独联系卡罗尔。在许多实现中，Alice不会验证Bob联系Carol的成功与否。
Appendix A.6. Call Forwarding
附录A.6。呼叫转移
In call forwarding [RFC5359], before a dialog is accepted, it is redirected to another location, for example, because the originally intended recipient is busy, does not answer, is disconnected from the network, or has configured all requests to go elsewhere.
在呼叫转移[RFC5359]中，在接受对话框之前，它会被重定向到另一个位置，例如，因为最初预期的收件人正忙、不应答、与网络断开连接或已将所有请求配置为转到其他位置。
Appendix A.7. Call Monitoring
附录A.7。呼叫监控
Call monitoring is a Join operation [RFC3911]. For example, a call center supervisor joins an in-progress call for monitoring purposes. The monitoring UA sends a Join to the dialog to which it wants to listen. It is able to discover the dialog via the dialog state on the monitored UA. The monitoring UA sends SDP in the INVITE that indicates receive-only media. As the UA is only monitoring, it does not matter whether the UA indicates it wishes the send stream to be mixed or point to point.
呼叫监控是一种连接操作[RFC3911]。例如，呼叫中心主管加入正在进行的呼叫以进行监控。监视UA向它要侦听的对话框发送联接。它能够通过受监控UA上的对话状态发现对话。监控UA在INVITE中发送SDP，指示仅接收媒体。由于UA只是监视，所以UA表示希望混合发送流还是点对点发送流并不重要。
Appendix A.8. Call Park
附录A.8。呼叫停车场
In Call Park [RFC5359], a participant parks a call (essentially puts the call on hold), and then retrieves it at a later time (typically from another location). Call park requires the ability to put a dialog some place, advertise it to users in a pickup group, and to uniquely identify it in a means that can be communicated (including human voice). The dialog can be held locally on the UA parking the dialog or alternatively transferred to the park service for the pickup group. The parked dialog then needs to be labeled (e.g., orbit 12) in a way that can be communicated to the party that is to pick up the call. The UAs in the pickup group discover the parked dialog(s) via the dialog package from the park service. If the dialog is parked locally, the park service merely aggregates the parked call states from the set of UAs in the pickup group.
在呼叫停止[RFC5359]中，参与者停止呼叫（实质上是将呼叫挂起），然后稍后再检索（通常从另一个位置）。呼叫停车场需要能够将对话放在某个地方，向接送组中的用户宣传对话，并以可以交流的方式（包括人声）唯一地识别对话。该对话框可以在UA驻车系统上本地保存，也可以传输到皮卡组的驻车服务。然后，需要以一种能够与接电话的一方进行沟通的方式，对停驻的对话进行标记（例如，轨道12）。皮卡组中的UAs通过停车服务的对话框包发现停车对话框。如果该对话框停在本地，则停车服务仅会聚合皮卡组中UAs集合中的已停呼叫状态。
Appendix A.9. Call Pickup
附录A.9。接电话
There are two different features that are called Call Pickup [RFC5359]. The first is the pickup of a parked dialog. The UA from which the dialog is to be picked up subscribes to the dialog state of the park service or the UA that has locally parked the dialog. Dialogs that are parked should be labeled with an identifier. The labels are used by the UA to allow the user to indicate which dialog is to be picked up. The UA picking up the call invoked the URI in the call state that is labeled as replace-remote.
有两种不同的功能称为呼叫拾取[RFC5359]。第一个是拾取一个停驻的对话框。从中拾取对话框的UA订阅停车服务的对话框状态或已在本地停放该对话框的UA。停驻的对话框应标有标识符。UA使用标签来允许用户指示要拾取的对话框。拾取呼叫的UA在标记为replace remote的呼叫状态下调用URI。
The other call pickup feature involves picking up an early dialog (typically ringing). A party picks up a call that was ringing at another location. One variation allows the caller to choose which
另一个呼叫接听功能包括接听早期对话（通常是铃声）。一方接听了另一个地点的电话。一种变体允许调用者选择
location, another variation just picks up any call in that user's "pickup group". This feature uses some of the same primitives as the pickup of a parked call. The call state of the UA ringing phone is advertised using the dialog package. The UA that is to pick up the early dialog subscribes either directly to the ringing UA or to a service aggregating the states for UAs in the pickup group. The call state identifies early dialogs. The UA uses the call state(s) to help the user choose which early dialog is to be picked up. The UA then invokes the URI in the call state labeled as replace-remote.
位置，另一个变体只是拾取该用户“拾取组”中的任何呼叫。此功能使用与接听停驻呼叫相同的一些原语。UA振铃电话的呼叫状态通过对话框包公布。要拾取早期对话框的UA直接订阅振铃UA或订阅聚合拾取组中UAs状态的服务。调用状态标识早期对话框。UA使用呼叫状态帮助用户选择要拾取的早期对话。UA然后在标记为replace remote的调用状态中调用URI。
Appendix A.10. Call Return
附录A.10。回叫
In Call Return, Alice calls Bob. Bob misses the call or is disconnected before he is finished talking to Alice. Bob invokes Call return, which calls Alice, even if Alice did not provide her real identity or location to Bob.
在回叫时，爱丽丝打电话给鲍勃。鲍勃没有接到电话，或者在与爱丽丝通话结束之前就断开了连接。Bob调用Call return，调用Alice，即使Alice没有向Bob提供她的真实身份或位置。
Appendix A.11. Call Waiting
附录A.11。呼叫等待
In Call Waiting, Alice is in a call, then receives another call. Alice can place the first call on hold, and talk with the other caller. She can typically switch back and forth between the callers.
在Call Waiting中，Alice正在接听一个电话，然后接到另一个电话。Alice可以将第一个呼叫挂起，并与另一个呼叫方通话。她通常可以在呼叫者之间来回切换。
Appendix A.12. Click-to-Dial
附录A.12。点击拨号
In Click-to-Dial [RFC5359], Alice looks in her company directory for Bob. When she finds Bob, she clicks on a URI to call him. Her phone rings (or possibly answers automatically), and when she answers, Bob's phone rings. The application or server that hosts the Click-to-Dial application captures the URI to be dialed and can set up the call using 3pcc or can send a REFER request to the UA that is to dial the address. As users sometimes change their mind or wish to give up listing to a ringing or voicemail answered phone, this application illustrates the need to also have the ability to remotely hangup a call.
在点击拨号[RFC5359]中，Alice在她的公司目录中查找Bob。当她找到鲍勃时，她点击一个URI给他打电话。她的电话响了（或者可能是自动接听），当她接听时，鲍勃的电话响了。承载点击拨号应用程序的应用程序或服务器捕获要拨号的URI，并可以使用3pcc设置呼叫，或者可以向UA发送要拨号的REFER请求。由于用户有时会改变主意，或希望放弃登录到铃声或语音邮件接听的电话，此应用程序说明还需要具备远程挂断电话的功能。
Appendix A.13. Conference Call
附录A.13。会议电话
In a Conference Call [RFC4579], there are three or more active, visible participants in the same conversation space.
在电话会议[RFC4579]中，同一对话空间中有三个或三个以上活跃的、可见的参与者。
Appendix A.14. Consultative Transfer
附录A.14。协商转让
In Consultative Transfer [RFC5589], the transferring party establishes a session with the target and mixes both sessions together so that all three parties can participate, then disconnects leaving the transferee and transfer target with an active session.
在协商转让[RFC5589]中，转让方与目标方建立一个会话，并将两个会话混合在一起，以便所有三方都能参与，然后断开连接，使受让方和转让目标方保留一个活动会话。
Appendix A.15. Distinctive Ring
附录A.15。独特环
In Distinctive Ring, incoming calls have different ring cadences or sample sounds depending on the From party, the To party, or other factors. The target UA either makes a local decision based on information in an incoming INVITE (To, From, Contact, Request-URI) or trusts an Alert-Info header field [RFC3261] provided by the caller or inserted by a trusted proxy. In the latter case, the UA fetches the content described in the URI (typically via HTTP) and renders it to the user.
在独特的铃声中，来电具有不同的铃声节奏或样本声音，具体取决于对方、对方或其他因素。目标UA或者根据传入邀请（收件人、发件人、联系人、请求URI）中的信息做出本地决定，或者信任调用者提供的或由受信任代理插入的警报信息头字段[RFC3261]。在后一种情况下，UA获取URI中描述的内容（通常通过HTTP）并将其呈现给用户。
Appendix A.16. Do Not Disturb
附录A.16。请勿打扰
In Do Not Disturb, Alice selects the Do Not Disturb option. Calls to her either ring briefly or not at all and are forwarded elsewhere. Some variations allow specially authorized callers to override this feature and ring Alice anyway. Do Not Disturb is best implemented in SIP using presence [RFC3856].
在“请勿打扰”中，Alice选择“请勿打扰”选项。打给她的电话要么短暂地响起来，要么根本不响，然后转到别处。有些变体允许经过特别授权的呼叫者覆盖此功能并拨打Alice电话。请勿打扰最好在SIP中使用状态[RFC3856]实现。
Appendix A.17. Find-Me
附录A.17。找到我
In Find-Me, Alice sets up complicated rules for how she can be reached (possibly using CPL (Call Processing Language) [RFC3880], presence [RFC3856], or other factors). When Bob calls Alice, his call is eventually routed to a temporary Contact where Alice happens to be available.
在Find Me中，Alice为如何联系她建立了复杂的规则（可能使用CPL（呼叫处理语言）[RFC3880]、状态[RFC3856]或其他因素）。当鲍勃给爱丽丝打电话时，他的电话最终被转接到一个临时联系人那里，爱丽丝正好在那里。
Appendix A.18. Hotline
附录A.18。热线电话
In Hotline, Alice picks up a phone and is immediately connected to the technical support hotline, for example. Hotline is also sometimes known as a Ringdown line.
例如，在热线中，Alice拿起一个电话，立即连接到技术支持热线。热线有时也被称为电话铃。
Appendix A.19. IM Conference Alerts
附录A.19。即时通讯会议警报
In IM Conference Alerts, a user receives a notification as an instant message whenever someone joins a conference in which they are already a participant.
在IM会议警报中，当有人加入他们已经是参与者的会议时，用户会收到即时消息形式的通知。
Appendix A.20. Inbound Call Screening
附录A.20。入站呼叫屏蔽
In Inbound Call Screening, Alice doesn't want to receive calls from Matt. Inbound Screening prevents Matt from disturbing Alice. In some variations, this works even if Matt hides his identity.
在入站呼叫屏蔽中，Alice不想接收Matt的呼叫。入站屏蔽可防止Matt打扰Alice。在某些变体中，即使马特隐藏了自己的身份，这种方法仍然有效。
Appendix A.21. Intercom
附录A.21。对讲机
In Intercom, Alice typically presses a button on a phone that immediately connects to another user or phone and causes that phone to play her voice over its speaker. Some variations immediately set up two-way communications, other variations require another button to be pressed to enable a two-way conversation. The UA initiates a dialog using INVITE and the Answer-Mode: Auto header field as described in [RFC5373]. The called UA accepts the INVITE with a 200 OK and automatically enables the speakerphone.
在对讲机中，Alice通常会按下手机上的一个按钮，立即连接到另一个用户或手机，并使该手机通过扬声器播放她的声音。有些变体会立即建立双向通信，而另一些变体则需要按下另一个按钮以实现双向对话。UA使用[RFC5373]中所述的邀请和应答模式：自动标题字段启动对话框。被呼叫的UA以200 OK接受邀请，并自动启用扬声器。
Alternatively, this can be a local decision for the UA to auto answer based upon called-party identification.
或者，这可以是UA根据被叫方标识自动应答的本地决定。
Appendix A.22. Message Waiting
附录A.22。文电等候
In Message Waiting [RFC3842], Bob calls Alice when she has stepped away from her phone. When she returns, a visible or audible indicator conveys that someone has left her a voicemail message. The message waiting indication may also convey how many messages are waiting, from whom, at what time, and other useful pieces of information.
在messagewaiting[RFC3842]中，当爱丽丝离开手机时，鲍勃给她打电话。当她回来时，一个可视或可听的指示器显示有人给她留言。消息等待指示还可传达正在等待的消息数量、来自谁、何时以及其他有用信息。
Appendix A.23. Music on Hold
附录A.23。音乐暂停
In Music on Hold [RFC5359], when Alice places a call with Bob on hold, it replaces its audio with streaming content such as music, announcements, or advertisements. Music on hold can be implemented a number of ways. One way is to transfer the held call to a holding service. When the UA wishes to take the call off hold, it basically performs a take on the call from the holding service. This involves subscribing to call state on the holding service and then invoking the URI in the call state labeled as replace-remote.
在Music on Hold[RFC5359]中，当Alice与Bob通话时，它会将其音频替换为流媒体内容，如音乐、公告或广告。暂停音乐可以通过多种方式实现。一种方法是将保留的呼叫转移到保留服务。当UA希望接收呼叫保持时，它基本上执行从等待服务接收呼叫。这涉及到订阅保持服务上的调用状态，然后在标记为replace remote的调用状态中调用URI。
Alternatively, music on hold can be performed as a local mixing operation. The UA holding the call can mix in the music from the music service via RTP (i.e., an additional dialog) or RTSP or other streaming media source. This approach is simpler (i.e., the held dialog does not move so there is less chance of loosing them) from a protocol perspective, however it does use more LAN bandwidth and resources on the UA.
或者，保持音乐可以作为本地混音操作来执行。持有呼叫的UA可以通过RTP（即附加对话框）或RTSP或其他流媒体源混入来自音乐服务的音乐。从协议的角度来看，这种方法更简单（即，保持的对话框不会移动，因此丢失它们的可能性更小），但是它确实在UA上使用了更多的LAN带宽和资源。
Appendix A.24. Outbound Call Screening
附录A.24。出站呼叫屏蔽
In Outbound Call Screening, Alice is paged and unknowingly calls a PSTN pay-service telephone number in the Caribbean, but local policy blocks her call, and possibly informs her why.
在对外呼叫屏蔽中，Alice被呼叫，并在不知不觉中拨打加勒比地区的PSTN付费服务电话号码，但当地政策阻止了她的呼叫，并可能告知她原因。
Appendix A.25. Pre-Paid Calling
附录A.25。预付费电话
In Pre-paid Calling, Alice pays for a certain currency or unit amount of calling value. When she places a call, she provides her account number somehow. If her account runs out of calling value during a call, her call is disconnected or redirected to a service where she can purchase more calling value.
在预付费通话中，Alice支付一定的货币或通话价值的单位金额。当她打电话时，她不知怎么地提供了她的帐号。如果她的帐户在通话过程中用完了通话价值，她的通话将被断开或重定向到她可以购买更多通话价值的服务。
For prepaid calling, the user's media always passes through a device that is trusted by the pre-paid provider. This may be the other endpoint (for example, a PSTN gateway). In either case, an intermediary proxy or B2BUA can periodically verify the amount of time available on the pre-paid account, and use the session-timer extension to cause the trusted endpoint (gateway) or intermediary (media relay) to send a reINVITE before that time runs out. During the reINVITE, the SIP intermediary can re-verify the account and insert another session-timer header field.
对于预付费呼叫，用户的媒体始终通过预付费提供商信任的设备。这可能是另一个端点（例如，PSTN网关）。在任何一种情况下，中介代理或B2BUA都可以定期验证预付费帐户上的可用时间，并使用会话计时器扩展使受信任的端点（网关）或中介（媒体中继）在该时间用完之前发送重新邀请。在重新邀请期间，SIP中介可以重新验证帐户并插入另一个会话计时器标头字段。
Note that while most pre-paid systems on the PSTN use an IVR to collect the account number and destination, this isn't strictly necessary for a SIP-originated prepaid call. SIP requests and SIP URIs are sufficiently expressive to convey the final destination, the provider of the prepaid service, the location from which the user is calling, and the prepaid account they want to use. If a pre-paid IVR is used, the mechanism described below (Voice Portals) can be combined as well.
请注意，虽然PSTN上的大多数预付费系统使用IVR来收集帐号和目的地，但对于SIP发起的预付费呼叫来说，这并不是绝对必要的。SIP请求和SIP URI具有足够的表达能力，能够传达最终目的地、预付费服务的提供者、用户呼叫的位置以及他们想要使用的预付费帐户。如果使用预付费IVR，也可以组合下面描述的机制（语音门户）。
Appendix A.26. Presence-Enabled Conferencing
附录A.26。支持状态的会议
In Presence-Enabled Conferencing, Alice wants to set up a conference call with Bob and Cathy when they all happen to be available (rather than scheduling a predefined time). The server providing the application monitors their status, and calls all three when they are all "online", not idle, and not in another call. This could be implemented using conferencing [RFC4579] and presence [RFC3264] primitives.
在支持状态的会议中，Alice希望在Bob和Cathy都有空时（而不是安排预定义的时间）与他们进行电话会议。提供应用程序的服务器监视它们的状态，并在它们都处于“联机”状态、非空闲状态以及不在另一个调用中时调用所有三个。这可以使用会议[RFC4579]和状态[RFC3264]原语来实现。
Appendix A.27. Single Line Extension/Multiple Line Appearance
附录A.27。单线延伸/多线外观
In Single Line Extension/Multiple Line Appearances, groups of phones are all treated as "extensions" of a single line or AOR. A call for one rings them all. As soon as one answers, the others stop ringing. If any extension is actively in a conversation, another extension can "pick up" and immediately join the conversation. This emulates the behavior of a home telephone line with multiple phones. Incoming calls ring all the extensions through basic parallel forking. Each extension subscribes to dialog events from each other extension. While one user has an active call, any other UA extension can insert
在单线延伸/多线外观中，手机组都被视为单线或AOR的“延伸”。一声呼唤，他们都打电话了。一个人接电话，其他人就不打电话了。如果会话中有任何分机处于活动状态，则另一分机可以“拾取”并立即加入会话。这将模拟具有多部电话的家庭电话线的行为。通过基本的并行分叉，传入的呼叫会响铃所有分机。每个扩展都订阅来自其他扩展的对话框事件。当一个用户有一个活动呼叫时，任何其他UA分机都可以插入
itself into that conversation (it already knows the dialog information) in the same way as barge-in.
它自己进入对话（它已经知道对话信息）的方式与闯入的方式相同。
When implemented using SIP, this feature is known as Shared Appearances of an AOR [BLISS-SHARED]. Extensions to the dialog package are used to convey appearance numbers (line numbers).
使用SIP实现时，此功能称为AOR的共享外观[BLISH-Shared]。对话框包的扩展用于传递外观编号（行号）。
Appendix A.28. Speakerphone Paging
附录A.28。扬声器寻呼
In Speakerphone Paging, Alice calls the paging address and speaks. Her voice is played on the speaker of every idle phone in a preconfigured group of phones. Speakerphone paging can be implemented using either multicast or through a simple multipoint mixer. In the multicast solution, the paging UA sends a multicast INVITE with send-only media in the SDP (see also [RFC3264]). The automatic answer and enabling of the speakerphone is a locally configured decision on the paged UAs. The paging UA sends RTP via the multicast address indicated in the SDP.
在扬声器寻呼中，Alice调用寻呼地址并讲话。她的声音在预先配置好的一组手机中的每个闲置手机的扬声器上播放。扬声器寻呼可以使用多播或通过简单的多点混音器来实现。在多播解决方案中，寻呼UA使用SDP中的仅发送媒体发送多播邀请（另请参见[RFC3264]）。扬声器的自动应答和启用是呼叫UAs上的本地配置决定。寻呼UA通过SDP中指示的多播地址发送RTP。
The multipoint solution is accomplished by sending an INVITE to the multipoint mixer. The mixer is configured to automatically answer the dialog. The paging UA then sends REFER requests for each of the UAs that are to become paging speakers (the UA is likely to send out a single REFER that is parallel forked by the proxy server). The UAs performing as paging speakers are configured to automatically answer based upon caller identification (e.g., the To field, URI, or Referred-To header fields).
多点解决方案通过向多点混合器发送邀请来完成。混音器配置为自动应答对话框。然后，寻呼UA向将成为寻呼扬声器的每个UA发送REFER请求（UA可能发送一个由代理服务器并行分叉的REFER）。用作寻呼扬声器的UAs被配置为根据呼叫者标识（例如，to字段、URI或参考报头字段）自动应答。
Finally, as a third option, the user agent can send a mass-invitation request to a conference server, which would create a conference and send INVITEs containing the Answer-Mode: Auto header field to all user agents in the paging group.
最后，作为第三个选项，用户代理可以向会议服务器发送批量邀请请求，会议服务器将创建一个会议，并向分页组中的所有用户代理发送包含应答模式：自动头字段的邀请。
Appendix A.29. Speed Dial
附录A.29。快速拨号
In Speed Dial, Alice dials an abbreviated number, enters an alias, or presses a special speed-dial button representing Bob. Her action is interpreted as if she specified the full address of Bob.
在快速拨号中，Alice拨打一个缩写号码，输入别名，或按下代表Bob的特殊快速拨号按钮。她的行为被理解为她指明了鲍勃的完整地址。
Appendix A.30. Voice Message Screening
附录A.30。语音信息屏蔽
In Voice Message Screening, Bob calls Alice. Alice is screening her calls, so Bob hears Alice's voicemail greeting. Alice can hear Bob leave his message. If she decides to talk to Bob, she can take the call back from the voicemail system; otherwise, she can let Bob leave a message. This emulates the behavior of a home telephone answering machine.
在语音信息屏蔽中，鲍勃给爱丽丝打电话。爱丽丝正在屏蔽她的电话，所以鲍勃听到了爱丽丝的语音留言问候。爱丽丝能听到鲍勃留言。如果她决定和鲍勃通话，她可以从语音信箱系统接回电话；否则，她可以让鲍勃留言。这模拟了家庭电话答录机的行为。
At first, this is the same as Call Monitoring (Appendix A.7). In this case, the voicemail service is one of the UAs. The UA screening the message monitors the call on the voicemail service, and also subscribes to dialog information. If the user screening their messages decides to answer, they perform a take from the voicemail system (for example, send an INVITE with Replaces to the UA leaving the message).
首先，这与呼叫监控相同（附录A.7）。在本例中，语音邮件服务是UAs之一。UA屏蔽消息时会监视语音邮件服务上的呼叫，并订阅对话信息。如果用户屏蔽其邮件后决定应答，他们将从语音邮件系统中执行一次接收（例如，向UA发送一个带有替换的邀请，让其离开邮件）。
Appendix A.31. Voice Portal
附录A.31。语音门户
Voice Portal is service that allows users to access a portal site using spoken dialog interaction. For example, Alice needs to schedule a working dinner with her co-worker Carol. Alice uses a voice portal to check Carol's flight schedule, find a restaurant near her hotel, make a reservation, get directions there, and page Carol with this information. A voice portal is essentially a complex collection of voice dialogs used to access interesting content. One of the most desirable call control features of a Voice Portal is the ability to start a new outgoing call from within the context of the Portal (to make a restaurant reservation, or return a voicemail message, for example). Once the new call is over, the user should be able to return to the Portal by pressing a special key, using some DTMF sequence (e.g., a very long pound or hash tone), or by speaking a key word (e.g., "Main Menu").
语音门户是一种允许用户使用语音对话交互访问门户网站的服务。例如，Alice需要安排与同事Carol共进工作晚餐。Alice使用语音门户查看Carol的航班时刻表，找到酒店附近的一家餐厅，预订房间，了解那里的方向，并向Carol发送此信息。语音门户本质上是用于访问有趣内容的语音对话框的复杂集合。语音门户最理想的呼叫控制功能之一是能够在门户上下文中启动新的传出呼叫（例如，进行餐厅预订或返回语音邮件消息）。新呼叫结束后，用户应能够通过按特殊键、使用某种DTMF序列（例如，很长的磅或哈希音）或说出关键字（例如，“主菜单”）返回门户。
In order to accomplish this, the Voice Portal starts with the following media relationship:
为了实现这一点，语音门户从以下媒体关系开始：
{ User , Voice Portal }
{用户，语音门户}
The user then asks to make an outgoing call. The Voice Portal asks the user to perform a far-fork. In other words, the Voice Portal wants the following media relationship:
然后，用户要求拨打一个呼出电话。语音门户要求用户执行远端分叉。换句话说，语音门户需要以下媒体关系：
{ Target , User } & { User , Voice Portal }
{ Target , User } & { User , Voice Portal }
The Voice Portal is now just listening for a key word or the appropriate DTMF. As soon as the user indicates they are done, the Voice Portal takes the call from the old target, and we are back to the original media relationship.
语音门户现在只是在侦听关键字或相应的DTMF。一旦用户表示完成了，语音门户就会接收来自旧目标的呼叫，我们就回到了原始的媒体关系。
This feature can also be used by the account number and phone number collection menu in a pre-paid calling service. A user can press a DTMF sequence that presents them with the appropriate menu again.
预付费电话服务中的帐号和电话号码收集菜单也可以使用此功能。用户可以按DTMF序列再次显示相应的菜单。
Appendix A.32. Voicemail
附录A.32。语音信箱
In Voicemail, Alice calls Bob who does not answer or is not available. The call forwards to a voicemail server that plays Bob's greeting and records Alice's message for Bob. An indication is sent to Bob that a new message is waiting, and he retrieves the message at a later date. This feature is implemented using features such as Call Forwarding (Appendix A.6) and the History-Info header field [RFC4244] or voicemail URI convention [RFC4458] and Message Waiting [RFC3842] features.
在语音信箱中，爱丽丝打电话给鲍勃，鲍勃不接电话或不在。呼叫将转发到语音邮件服务器，该服务器播放Bob的问候语并为Bob记录Alice的消息。将向Bob发送一个新消息正在等待的指示，Bob将在稍后日期检索该消息。此功能使用呼叫转移（附录A.6）和历史信息报头字段[RFC4244]或语音邮件URI约定[RFC4458]和消息等待[RFC3842]等功能实现。
Appendix A.33. Whispered Call Waiting
附录A.33。耳语呼叫等待
In Whispered Call Waiting, Alice is in a conversation with Bob. Carol calls Alice. Either Carol can "whisper" to Alice directly ("Can you get lunch in 15 minutes?"), or an automaton whispers to Alice informing her that Carol is trying to reach her.
在窃窃私语电话等待中，爱丽丝正在与鲍勃交谈。卡罗尔打电话给爱丽丝。卡罗尔可以直接“耳语”爱丽丝（“你能在15分钟内吃到午饭吗？”），或者一台自动售货机向爱丽丝耳语，告诉她卡罗尔正试图联系她。
The authors would like to acknowledge Ben Campbell for his contributions to the document and thank AC Mahendran, John Elwell, and Xavier Marjou for their detailed Working-Group review of the document. The authors would like to thank Magnus Nystrom for his review of the document.
作者感谢Ben Campbell对该文件的贡献，并感谢AC Mahendran、John Elwell和Xavier Marjou工作组对该文件的详细审查。作者要感谢Magnus Nystrom对该文件的审查。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)- Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008.
[RFC5359]Johnston，A.，Sparks，R.，Cunningham，C.，Donovan，S.，和K.Summers，“会话启动协议服务示例”，BCP 144，RFC 5359，2008年10月。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725]Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的当前最佳实践”，BCP 85，RFC 37252004年4月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891]Mahy，R.，Biggs，B.，和R.Dean，“会话启动协议（SIP）”取代了RFC 38912004年9月的“头”。
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[RFC3911]Mahy，R.和D.Petrie，“会话启动协议（SIP）”加入“头”，RFC 3911，2004年10月。
[BLISS-PROBLEM] Rosenberg, J., "Basic Level of Interoperability for Session Initiation Protocol (SIP) Services (BLISS) Problem Statement", Work in Progress, March 2009.
[BLISS-PROBLEM]Rosenberg，J.，“会话启动协议（SIP）服务互操作性的基本水平（BLISS）问题陈述”，正在进行的工作，2009年3月。
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[RFC4235]Rosenberg，J.，Schulzrinne，H.，和R.Mahy，“会话启动协议（SIP）的邀请启动对话事件包”，RFC 4235，2005年11月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575]Rosenberg，J.，Schulzrinne，H.，和O.Levin，“会议状态的会话启动协议（SIP）事件包”，RFC 45752006年8月。
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[RFC3680]Rosenberg，J.，“用于注册的会话启动协议（SIP）事件包”，RFC3680，2004年3月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856]Rosenberg，J.，“会话启动协议（SIP）的存在事件包”，RFC3856，2004年8月。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353]Rosenberg，J.，“会话启动协议（SIP）会议框架”，RFC 4353，2006年2月。
[RFC5629] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", RFC 5629, October 2009.
[RFC5629]Rosenberg，J.，“会话启动协议（SIP）中的应用程序交互框架”，RFC 5629，2009年10月。
[RFC5369] Camarillo, G., "Framework for Transcoding with the Session Initiation Protocol (SIP)", RFC 5369, October 2008.
[RFC5369]Camarillo，G.“会话启动协议（SIP）转码框架”，RFC 5369，2008年10月。
[XCON-CCMP] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, "Centralized Conferencing Manipulation Protocol", Work in Progress, February 2010.
[XCON-CCMP]Barnes，M.，Boulton，C.，Romano，S.，和H.Schulzrinne，“集中式会议操纵协议”，正在进行的工作，2010年2月。
[RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, June 2009.
[RFC5589]Sparks，R.，Johnston，A.，和D.Petrie，“会话启动协议（SIP）呼叫控制-传输”，BCP 149，RFC 5589，2009年6月。
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.
[RFC4579]Johnston，A.和O.Levin，“会话发起协议（SIP）呼叫控制-用户代理会议”，BCP 119，RFC 4579，2006年8月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“会话启动协议（SIP）的呼叫方偏好”，RFC 38412004年8月。
[RFC3087] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001.
[RFC3087]Campbell，B.和R.Sparks，“使用SIP请求URI控制服务上下文”，RFC 3087，2001年4月。
[FEATURE-REF] Audet, F., Johnston, A., Mahy, R., and C. Jennings, "Feature Referral in the Session Initiation Protocol (SIP)", Work in Progress, February 2008.
[FEATURE-REF]Audet，F.，Johnston，A.，Mahy，R.，和C.Jennings，“会话启动协议（SIP）中的功能引用”，正在进行的工作，2008年2月。
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[RFC4240]Burger，E.，Van Dyke，J.，和A.Spitzer，“具有SIP的基本网络媒体服务”，RFC 42402005年12月。
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", RFC 4458, April 2006.
[RFC4458]Jennings，C.，Audet，F.，和J.Elwell，“语音邮件和交互式语音应答（IVR）等应用程序的会话启动协议（SIP）URI”，RFC 4458，2006年4月。
[RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
[RFC4538]Rosenberg，J.，“通过会话启动协议（SIP）中的对话标识请求授权”，RFC 4538，2006年6月。
[RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing Language (CPL): A Language for User Control of Internet Telephony Services", RFC 3880, October 2004.
[RFC3880]Lennox，J.，Wu，X.，和H.Schulzrinne，“呼叫处理语言（CPL）：互联网电话服务的用户控制语言”，RFC 3880，2004年10月。
[RFC5373] Willis, D. and A. Allen, "Requesting Answering Modes for the Session Initiation Protocol (SIP)", RFC 5373, November 2008.
[RFC5373]Willis，D.和A.Allen，“请求会话启动协议（SIP）的应答模式”，RFC 53732008年11月。
[RFC3842] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[RFC3842]Mahy，R.“会话启动协议（SIP）的消息摘要和消息等待指示事件包”，RFC 3842，2004年8月。
[BLISS-SHARED] Johnston, A., Soroushnejad, M., and V. Venkataramanan, "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)", Work in Progress, October 2009.
[BLISS-SHARED]Johnston，A.，Soroushnejad，M.，和V.Venkataramanan，“会话启动协议（SIP）记录地址（AOR）的共享外观”，正在进行的工作，2009年10月。
[RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[RFC4244]Barnes，M.，“请求历史信息会话启动协议（SIP）的扩展”，RFC 4244，2005年11月。
[RFC4313] Oran, D., "Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources", RFC 4313, December 2005.
[RFC4313]Oran，D.“自动语音识别（ASR）、说话人识别/说话人验证（SI/SV）和文本到语音（TTS）资源的分布式控制要求”，RFC 4313，2005年12月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
Authors' Addresses
作者地址
Rohan Mahy Unaffiliated
Rohan Mahy非附属公司
EMail: rohan@ekabal.com
EMail: rohan@ekabal.com
Robert Sparks Tekelec
罗伯特·斯帕克斯·特凯莱克
EMail: rjsparks@nostrum.com
EMail: rjsparks@nostrum.com
Jonathan Rosenberg jdrosen.net
Jonathan Rosenberg jdrosen.net
EMail: jdrosen@jdrosen.net
EMail: jdrosen@jdrosen.net
Dan Petrie SIPez
丹·佩特里·西佩斯
EMail: dan.ietf@sipez.com
EMail: dan.ietf@sipez.com
Alan Johnston (editor) Avaya
艾伦·约翰斯顿（编辑）阿瓦亚
EMail: alan.b.johnston@gmail.com
EMail: alan.b.johnston@gmail.com